Nginx 웹서버 정리 1

NginX 윈도우 이슈

Version of nginx for Windows uses the native Win32 API (not the Cygwin emulation layer). Only the select() and poll() (1.15.9) connection processing methods are currently used, so high performance and scalability should not be expected. Due to this and some other known issues version of nginx for Windows is considered to be a beta version. At

 

nginx/Windows runs as a standard console application (not a service), and it can be managed using the following commands:

 

nginx -s stop fast shutdown

nginx -s quit graceful shutdown

nginx -s reload changing configuration, starting new worker processes with a new configuration, graceful shutdown of old worker processes

nginx -s reopen re-opening log files

 

Known issues

Although several workers can be started, only one of them actually does any work.

The UDP proxy functionality is not supported.

 

Possible future enhancements

Running as a service.

Using the I/O completion ports as a connection processing method.

Using multiple worker threads inside a single worker process.

https://nginx.org/en/docs/windows.html

 

가장 매칭이 되는 것을 찾고 없으면 이전 Location으로 처리한다. 요청을 주고 특정 파라미터 값을 넘기는 것도 가능한 것으로 보인다. 

루트 경로를 명시하면 root/requst 형태로 매핑해준다. 

 

해당 경로에 파일이 없는 경우, 옆에 추가적으로 값을 넘기고 그 주소에 값이 존재하면, 해당 주소로 리다이렉트 처리를 해준다. 

그러면 리다이렉트된 주소를 가지고 처리를 매핑을 시도한다.

https://nginx.org/en/docs/http/request_processing.html

 

NginX 로드밸런싱

라운드로빈: 라운드 로빈 방식으로 처리, 적은 연결: 연결이 적은 순으로, ip-hash: 클라이언트의 ip에 기반하여

 

기본은 라운드 로빈 방식으로 처리된다. 적은 연결 방식은 더 오래 걸리는 처리에 대해 꽤 공정하게 처리된다. 

적은 요청을 처리하는 곳에 처리.

 

라운드 로빈, 적은 연결 방식은 같은 클라가 지정된 서버에서 처리됨을 보장하지 않는다. 

특정 서버에서만 처리되도록 묶을 필요가 있다면, ip-hash 로드밸런싱을 사용할 수 있다.

 

ip주소가 해싱 키로 사용된다. 클라의 요청을 처리하기 위한 서버를 지정하는 용도로.

이러한 방식은 같은 클라에게 대해서 항상 같은 서버를 지정하도록 한다. (서버가 해당 요청을 처리할 수 없는 상황을 제외하고)

 

동일한 가중치를 가진 상태에서 라운드 로빈 알고리즘은 적절하게 처리된다. (충분한 요청, 획일적으로 요청이 빠르게 처리되는 경우)

  upstream myapp1 {

        server srv1.example.com weight=3;

        server srv2.example.com;

        server srv3.example.com;

    }

With this configuration, every 5 new requests will be distributed across the application instances as the following: 3 requests will be directed to srv1, one request will go to srv2, and another one — to srv3.

 

상태 체크에 대한 옵션을 제공하여 max_fails, failure_timeout 값을 설정할 수 있다.

https://nginx.org/en/docs/http/load_balancing.html

 

HTTPS server optimization

SSL 동작은 여분의 CPU 자원을 사용한다. 사용 가능한 CPU 코어 수만큼 작업자 프로세스가 동작되어야 한다. SSL 핸드쉐이크 과정이 가장 리소스를 많이 먹는다. 이를 해소하기 위한 방법이 2가지 있는데, keepalive 옵션을 활성화하여 하나의 커넥션에 여러 요청을 보내는 것과 SSL 세션 파라미터를 재사용하는 방법이 있다. 세션은 SSL 세션 캐시에 저장되며, 세션 캐시는 워커들 사이에서 공유된다. 1MB의 캐시는 4000개의 세션을 갖는다. 기본 세션 타임아웃은 5분이며 ssl_session_timeout에서 설정할 수 있다. 

 

worker_processes auto;

 

http {

    ssl_session_cache   shared:SSL:10m;

    ssl_session_timeout 10m;

 

    server {

        listen              443 ssl;

        server_name         www.example.com;

        keepalive_timeout   70;

 

        ssl_certificate     www.example.com.crt;

        ssl_certificate_key www.example.com.key;

        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        ssl_ciphers         HIGH:!aNULL:!MD5;

 

특정 브라우저에서 중간 인증서를 사용하여 문제가 발생할 수 있는데, 이때 인증서 체인을 사용할 수 있다고 한다.