(1) ngnix & WebServer

1. 웹서버란?

1-1) 정의

웹 서버 (Web Server) 는 웹 문서를 클라이언트에게 보여주기 위한 서버를 뜻함, 보통 정적 서버를 의미

• 보통 웹 서버 소프트웨어가 동작하는 컴퓨터 혹은 그 응용프로그램을 지칭
• 웹 서버의 가장 중요한 기능은 클라이언트(Client)가 요청하는 HTML 문서나 각종 리소스(Resource)의 "응답" 전달
• 통신 방식은 HTTP(Hyper Text Transfer Protocol) 통신을 통함
• 웹 브라우저나 웹 크롤러가 요청하는 리소스는 컴퓨터에 저장된 정적(static)인 데이터이거나 동적인 결과

 

 

2. 웹서버가 제공하는 데이터(응답) 종류

- 내글 참조(클라이언트 vs 서버사이드 랜더링) : https://korshika.tistory.com/58

Client side - Server side rendering

- CSR 같은 경우 View만 담당, 페이지만 그려내므로 Static이라고 볼 수 있음
- SSR 같은 경우 추가 데이터는 WAS에서 Model을 통해 가져오고 이를 view에 추가하며 Servelt을 거치기 때문에
  보통 Dynamic 하게 구현되는 경우라고 볼 수 있음 - 물론 Static으로만도 구현 가능

 

2-1) 정적 데이터(응답/페이지) 

(a) 정의

이미 만들어져있어서, 서버에 저장되어있는 파일을 작업 없이 응답받는 것

보통, request 시 추가 작업이 없이 Html, CSS, JS로 이루어진 웹 페이지를 응답하는 것을 의미(JavaScript 까지도 포함)

> 참조 링크 : https://stackoverflow.com/questions/44458712/can-a-static-website-consist-of-javascript

Can A Static Website Consist of JavaScript?

- 보통, raw Html과 그 하위 파일들로 이루어져서, 서버단에서 Web Application(Web Container / Servlet)의

"작업"을 통해 제공되는 web page가 아닌 것

- 그냥 raw파일 보내는 것과 거의 동일한 의미

- 종류 : Apach, Nginx 등

 

2-2) 동적 데이터(응답/페이지) 

(a) 정의

서버의 "작업"이 들어간 결과를 응답받는 것

보통, 해당 서버의 Web Server 안의 Web Container(서블릿 컨테이너)를 통해 동적 페이지를 요청하게 됨

- 종류 : Apach Tomcat, Glass Fish, JBoss 등

 

2-3) 정리

1. HTTP Request(요청) 보냄
   - Textual, Stateless, 통신 규약 등이 특징
   HTTP 내글 목록 참조 : https://korshika.tistory.com/category/HTTP%20%EC%9B%B9/Http%20%EC%9B%B9%20%EA%B8%B0%EB%B3%B8
2. url 접근이 맞는 경우 → Controller 에서 유도하는 대로 동작
   url 접근이 틀린 경우 → 보통 404 Not found 생성 후, Web Server가 이를 응답
3. Static(정적) 페이지가 필요한 경우, Runtime시 이미 생성되어 저장된 HTML 페이지 전송
4. Dynamic(동적) 페이지가 필요한 경우, Container로 Request 보냄
5. Container는 적합한 Servlet(어플리케이션 서버)에게 Request 요청, 동적인 작업 수행
6. Servlet이 작업 후 HTML 페이지로 변환해서 Server로 보냄
   → 이 과정에서 사용되는 생성 라이브러리(Java Spring : Thymleaf, 장고 : django, jinja2 등등... )
   → 혹은 API로 연결되어 View만 담당하는 Front-end에서 Back의 응답으로 view rendering
7. Server가 HTTP Response(응답)

 

2-4) 추가 참조

- 파이썬 Django 용 참조 글 : https://velog.io/@muchogusto/%EC%9B%B9%EC%84%9C%EB%B2%84%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

웹서버란 무엇인가

 

 

3. Web Container( ~= WAS - Web Application Server)

3-1) Web Application Server 의 구성

ex) Apach - Tomcat

a) Web Server

• 정의
  - 정적인 데이터 담당
  - 80 포트
• 역할
  - 간단한 정적 데이터를 담당하는 역할
  - 간단한 작업을 빠르게 처리하기 위함
  - 장애 극복 기능 : WAS가 죽으면, 재부팅을 하면서 Web Server가 기본 기능만 담당하며 장애를 극복하는 등의
     방식을 사용할 수 있음 → "무중단 운영"을 위해 중요한 기술
  - Web Container 혹은 WAS 전체 앞단에 배치하면 Proxy의 기능도 겸할 수 있음
  - Proxy기능을 이용하여 공격 등에 대해 분산처리를 할 수 있음, 혹은 분산처리를 지원
• 종류
  - Apache, Apache-Tomcat(여기서는 Tomcat의 웹서비스 데몬, Httpd 기능을 지칭), Nginx 
  
  

b) Web Container

• 정의
  - 동적인 작업 담당
  - 8080 포트(http/https)
  - 보통 WAS를 Web Container를 지칭하는 용어로도 사용하는 경우가 있음
      → 요즘  Web Container 안에도 정적 처리 기능이 포함되어있는 경우가 있어서 이 자체가 WAS처럼 동작
  - ※ Tomcat의 경우, 현재는 Apache를 제외하고 단독으로 설치해도 충분히 정적, 동적을 모두 담당할 수 있음
• 역할
  - 동적 작업에서 필요한 DB 등을 처리하기 위함
  - 복잡한 작업을 처리하기 위함

 

3-2) 미들웨어로써의 WAS

a) 정의

미들웨어는 <웹-클라이언트 ↔ DB > 사이에 WAS(Web Server + Web Container[~=WAS])를 지칭

- 웹-클라이언트의 요청 중에도 Web Application(Model)이 동작하도록 하는 것

- 동적인 기능 수행

- 복잡한 기능 수행 : 보통 DBMS와 관련

b) 기능

1. 프로그램 실행환경, DB접속 기능 제공
2. 여러개의 트랜잭션(DB- Query 논리적 처리 작업단위) 관리
   참조 : https://korshika.tistory.com/171
3. 비지니스 로직 수행

 

 

4. Nginx

4-1) 정의

트래픽이 많은 웹사이트의 확장성 및 트래픽 분산을 위해 설계된

"비동기 이벤트 기반" 구조의 웹서버 소프트웨어

 

4-2) 구현 방식

1. Nginx 설치
2. nginx.conf 파일을 원하는 대로 웹서버 기능을 추가한 후 저장
   

       server {
          listen       81; 
          server_name  localhost;
   
          location / { 
              proxy_pass http://127.0.0.1:3000/;  
          }
       }​

3. Web Server Nginx 프로그램 실행
4. WAS 실행
   

   var express = require('express')
   var app = express();
   app.get('/', (req,res)=>{
       res.send("3000번 서버입니다.")
   })
   app.listen(3000, ()=>{
       console.log(3000);
   })​

5. 81 포트로 접속시 3000으로 redirection 됨
   

   

 

4-3) 특징

- 더 적은 자원으로 더 빠르게 서비스!

- 하나의 웹서버에 10,000개의 클라이언트 접속을 동시에 다루기 위한 기술

- Event-driven 구조로 동작

- HTTP, Reverser Proxy, IMAP/POP PROXY server를 제공하는오픈소스 서버 프로그램

- 보안성이 좋음

※ Nginx의 보안선

> 버퍼 오버플로우 : 버퍼는 보통 데이타가 저장되는 메모리 공간을 뜻하는데 메모리 공간을 벗어나는 경우 오버플로우가 되고 이 때 사용되지 않아야 할 영역에 데이터가 덮어씌워져 주소, 값을 바꾸는 공격

> 버퍼 오버플로우로 인한 큰 이슈 : 하트블리드사태

- 실제포트를 숨기고 nginx의 80포트를 통해서 프록시하면 보안적으로 막을 수 있음

- 정적자료에 대한 gzip압축, 그리고 앞단에서의 로그를 저장할 수 있음

 

4-4) Apache VS Nginx

a) Apache

- 쓰레드 / 프로세스 기반 구조로 요청 하나당 쓰레드 하나가 처리하는 구조

- 사용자가 많으면 많은 쓰레드 생성, 메모리 및 CPU 낭비가 심함

- 시작부터 프로세스 개수를 지정해놓고, 각 프로세스 하위의 Thread개수를 관리하다,  모자라면 Process Fork를 통해 thread를 더 할당하여 증가한 request에 대응하도록 함

- 하나의 쓰레드 : 하나의 클라이언트 라는 구조

b) Nginx

- 비동기 Event-Driven 기반 구조, Single-Thread   → 이벤트 드라이븐방식은 여러개의 커넥션을 몽땅 다

Event Handler를 통해 비동기 방식으로 먼저 할당되는 것부터 로직이 진행되게끔 처리

- 하나의 Master Process에서 다수의 Worker Process를 관리

    - Master Process : Worker Process 관리만 수행

    - Worker Process : Single Thread로 구성, 사용자의 요청에 응답 → Core수만큼 Process가 있고, Single Thread만 가짐

- 비동기 이벤트 처리 + 이벤트 드라이븐 참조 : https://niklasjang.tistory.com/56

쉽게 정리한 네트워크 | Apache와 Nginx의 요청 응답 구조

- 다수의 연결을 효과적으로 처리가능

- 대부분의 코어 모듈이 Apache보다 적은 리소스로 더 빠르게 동작가능

- 더 작은 쓰레드로 클라이언트의 요청들을 처리가능

 

4-5) Worker Process

nginx는 프로세스나 스레드에 대한 지속적인 생성/파괴 패턴이 없기 때문에 CPU 사이클이 절약됨

a) nginx가 하는 일

• 네트워크와 스토리지의 상태 확인
• 새로운 연결을 초기화
• 런 루프에 추가
• 완료될 때까지 비동기적으로 처리
• 완료되면 연결이 할당 해제되고 런 루프에서 제거됨

b) 처리 방식

1) 연결 요청이 CPU 집약적인 경우( 많은 TCP/IP 처리, SSL 수행 또는 압축)
    worker process의 수는 CPU 코어의 수와 일치하는 것이 권장

2)연결 요청이 disk I/O 집약적인 경우 worker process의 수는 CPU 코어의 수의 1~2배가 권장

 

---

참조

https://m.blog.naver.com/jhc9639/220967352282

[개발자 면접준비]#2. nginx의 이해와 활용

https://yeon-kr.tistory.com/121

웹 서버란?

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=mincoding&logNo=221718892885 

웹 서버란? Web Server is...?