히포

• https://nginx.org/en/docs/http/ngx_http_v2_module.html

• ngx_http_v2_module 모듈(1.9.5)은 HTTP/2를 지원
• ngx_http_v2_module 모듈은 기본적으로 빌드되지 않으며, --with-http_v2_module 구성 매개변수를 사용하여 활성화

• TLS를 통해 HTTP/2 연결을 수락하려면 OpenSSL 버전 1.0.2부터 제공되는 “ALPN(Application-Layer Protocol Negotiation)” TLS 확장 지원이 필요
• ssl_prefer_server_ciphers 지시어가 on 값으로 설정된 경우 암호는 RFC 9113의 부록 A 블랙리스트(black list)를 준수하고 클라이언트에서 지원하도록 구성
• RFC 9113의 부록 A : https://datatracker.ietf.org/doc/html/rfc9113#appendix-A

• Nginx 1.9.14 버전 이전에는 proxy_request_buffering, fastcgi_request_buffering, uwsgi_request_buffering 및 scgi_request_buffering 지시어 값에 관계없이 client request body 버퍼링(Buffering)을 비활성화할 수 없음
• Nginx 1.19.1 이전에는 HTTP/2 연결(connections) 종료를 제어하는 데, lingering_close 메커니즘 사용 X

ngx_http_v2_module 구성 예

server {
    listen 443 ssl;

    http2 on;

    ssl_certificate server.crt;
    ssl_certificate_key server.key;
}

http2 지시자

• HTTP/2 프로토콜을 활성화
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2 on | off;

• 기본 사용 예시

  http2 off;

http2_body_preread_size 지시자

• 요청(request)을 처리 시작하기 전에 요청 본문(request body)이 저장될 수 있는 각 요청(request)당 버퍼(buffer)의 크기를 설정
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2_body_preread_size size;

• 기본 사용 예시

  http2_body_preread_size 64k;

http2_chunk_size 지시자

• 응답 본문(response body)이 슬라이스(slice)되는 청크(chunks)의 최대 크기를 설정 
• 슬라이스(slice)되는 청크(chunks) 값이 너무 낮으면 오버헤드가 증가 
• 슬라이스(slice)되는 청크(chunks) 값이 너무 높으면 HOL 블로킹으로 인해 우선 순위가 손상
   
• 문맥: http, server, location
• 사용 문법

  # 문법
  http2_chunk_size size;

• 기본 사용 예시

  http2_chunk_size 8k;

http2_max_concurrent_streams 지시자

• 연결(connection)에서 최대 동시 HTTP/2 스트림(concurrent HTTP/2 streams) 수를 설정
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2_max_concurrent_streams number;

• 기본 사용 예시

  http2_max_concurrent_streams 128;

http2_recv_buffer_size 지시자

• 작업자(worker)당 입력 버퍼(input buffer)의 크기를 설정
   
• 문맥: http
• 사용 문법

  # 문법
  http2_recv_buffer_size size;

• 기본 사용 예시

  http2_recv_buffer_size 256k;

ngx_http_v2_module 모듈의 내장 변수 → $http2

• negotiated protocol identifier(협상된 프로토콜 식별자)
  1. TLS를 통한 HTTP/2의 경우 “h2”
  2. 투명 텍스트 TCP(cleartext TCP)를 통한 HTTP/2의 경우 “h2c”
  3. 그렇지 않으면 빈 문자열

http2_max_concurrent_pushes 지시자

• http2_max_concurrent_pushes 지시어는 버전 1.25.1부터 사용 X
• 연결(connection)에서 동시 푸시 요청(concurrent push requests )의 최대 수(maximum number)를 제한
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2_max_concurrent_pushes number;

• 기본 사용 예시

  http2_max_concurrent_pushes 10;

http2_push 지시자

• http2_push 지시어는 버전 1.25.1부터 사용 X
• original 요청에 대한 응답과 함께 지정된 URI로 요청을 선제적(pre-emptively)으로 전송(푸시)
• 예) 절대 경로(absolute path)를 가진 상대 URI(relative URI)만 처리 : http2_push /static/css/main.css;
   
• URI 값에는 변수가 포함 가능
• 동일한 설정 수준에서 여러 개의 http2_push 지시문을 지정 가능 
• http2_push 지시어의 off 매개변수는 이전 configuration에서 상속된 http2_push 지시어의 효과를 취소함
   
• 문맥: http, server, location
• 사용 문법

  # 문법
  http2_push uri | off;

• 기본 사용 예시

  http2_push off;

http2_push_preload 지시자

• http2_push_preload 지시어는 버전 1.25.1부터 사용 X
• Link 응답 헤더 필드(response header field)에 지정된 프리로드 링크(preload links)를 푸시 요청(push requests)으로 자동 변환
   
• 문맥: http, server, location
• 사용 문법

  # 문법
  http2_push_preload on | off;

• 기본 사용 예시

  http2_push_preload off;

http2_idle_timeout 지시자

• http2_idle_timeout 지시어는 버전 1.19.7부터 사용 X → http2_idle_timeout 대신 keepalive_timeout를 사용
• 연결(connection)이 닫히는 비활성 시간 제한(timeout of inactivity)을 설정
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2_idle_timeout time;

• 기본 사용 예시

  http2_idle_timeout 3m;

http2_max_field_size 지시자

• http2_max_field_size 지시어는 버전 1.19.7부터 사용 X → http2_max_field_size 대신 large_client_header_buffers 사용
• HPACK 압축 요청 헤더 필드(HPACK-compressed request header)의 최대 크기를 제한 → 최대 크기 제한은 이름과 값 모두에 동일하게 적용 
• 허프만 인코딩(Huffman encoding)이 적용되면 압축 해제된 이름 및 값 문자열의 실제 크기가 더 커질 수 있음
• 대부분의 요청은 http2_max_field_size 기본 제한 크기로 충분
• HPACK 압축 : https://datatracker.ietf.org/doc/html/rfc7541
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2_max_field_size size;

• 기본 사용 예시

  http2_max_field_size 4k;

http2_max_header_size 지시자

• http2_max_header_size 지시어는 1.19.7부터 사용 X → http2_max_header_size 대신 large_client_header_buffers 사용
• HPACK 압축 해제(HPACK decompression) 후 전체 요청 헤더 목록(entire request header list)의 최대 크기를 제한 
• 대부분의 요청(requests)에서는 기본 제한으로 충분
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2_max_header_size size;

• 기본 사용 예시

  http2_max_header_size 16k;

http2_max_requests 지시자

• http2_max_requests 지시어는 버전 1.19.7부터 사용 X → http2_max_requests 대신 keepalive_requests 사용
• 하나의 HTTP/2 연결(HTTP/2 connection)을 통해 처리할 수 있는 최대 요청 수(push requests 포함)를 설정하며, 그 이후 다음 클라이언트 요청(next client request)이 있을 때 연결이 닫히고 새 연결을 진행
• 주기적으로 연결을 닫는 것은 연결별 메모리 할당(per-connection memory allocations)을 확보하기 위해 필요 
• 최대 요청 수를 너무 많이 사용하면 메모리를 과도하게 사용할 수 있으므로 권장 X
   
• 문맥: http, server
• 사용 문법

  # 문법
  http2_max_requests number;

• 기본 사용 예시

  http2_max_requests 1000;

http2_recv_timeout  지시자

• http2_recv_timeout 지시어는 1.19.7부터 사용 X → http2_recv_timeout  대신 client_header_timeout를 사용
• 클라이언트로부터 추가로 전달될 데이터를 기대하는 시간 제한(timeout) 설정한 후 연결을 닫음.
   
• 문맥: http, server
• 사용 문법 
• # 문법 http2_recv_timeout time;
• 기본 사용 예시

  http2_recv_timeout 30s;

• Nginx http dav 모듈 : Module ngx_http_dav_module

• ngx_http_dav_module 모듈은 WebDAV 프로토콜을 통한 파일 관리 자동화를 위한 모듈
• HTTP 및 WebDAV 메서드 PUT, DELETE, MKCOL, COPY, MOVE를 처리
• 기본적으로 빌드되지 않으며, --with-http_dav_module 구성 매개변수를 사용하여 활성화 필요
  
  

create_full_put_path 지시자

• WebDAV 사양은 이미 존재하는 디렉토리에만 파일을 생성 가능 
• create_full_put_path 지시자를 통해 필요한 모든 중간 디렉토리를 생성 가능
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  create_full_put_path on | off;

• 사용 예시

  ## 기본 설정
  create_full_put_path off;

dav_access 지시자

• 새로 만든 파일 및 디렉터리에 대한 액세스 권한을 설정 → dav_access user:rw group:rw all:r;
• 그룹 또는 모든 액세스 권한이 지정되면 사용자 권한은 생략 가능 → dav_access group:rw all:r;
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  dav_access users:permissions ...;

• 사용 예시

  ## 기본 설정
  dav_access user:rw;

dav_methods 지시자

• 지정된 HTTP 및 WebDAV 메서드를 허용
• 매개변수 off는 ngx_http_dav 모듈에서 처리하는 모든 메서드를 거부 
• ngx_http_dav 모듈 지원되는 메서드 → PUT, DELETE, MKCOL, COPY, MOVE
  
  
• PUT 메서드로 업로드된 파일은 먼저 임시 파일에 기록된 다음 파일 이름이 변경됨 
• 버전 0.8.9부터는 PUT 메서드로 임시 파일과 영구 저장소를 서로 다른 파일 시스템에 등록 가능
  1. 서로 다른 파일 시스템에 등록은 이름 변경 작업 대신 두 파일 시스템에 걸쳐 복사된다는 의미 
  2. 특정 위치에 대해 저장된 파일과 client_body_temp_path 지시어로 설정한 임시 파일이 있는 디렉토리를 모두 같은 파일 시스템에 저장하는 것을 추천
• PUT 방식으로 파일을 만들 때 "Date" 헤더 필드에 수정 날짜(modification date)를 전달하여 수정 날짜를 지정 가능
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  dav_methods off | method ...;

• 사용 예시

  ## 기본 설정
  dav_methods off;

min_delete_depth 지시자

• 요청 경로(request path)의 요소 수(number of elements)가 지정된 수보다 작지 않은 경우 DELETE 메서드가 파일을 제거 가능
• min_delete_depth 지시자 예시

  ## min_delete_depth 지시자 설정
  min_delete_depth 4;
  
  ## 요청 시 파일 제거 허용
  /users/00/00/name
  /users/00/00/name/pic.jpg
  /users/00/00/page.html
  
  ## 요청 시 파일 제제거를 거부
  /users/00/00

• 문맥 : http, server, location
• 사용 문법

  ## 문법
  min_delete_depth number;

• 사용 예시

  ## 기본 설정
  min_delete_depth 0;

• nginx는 새로 들어오는 모든 요청에 대해 upstream(backend) 서버에 대한 새 연결(incoming request)→ 안전하지만 비효율적
  1. nginx와 upstream(backend) 서버가 연결을 설정하려면 패킷 3개를 교환
  2. nginx와 upstream(backend) 서버가 연결을 종료하려면 패킷 3~4개를 교환

• 트래픽이 많을 경우 모든 요청에 대해 새 연결을 열면 시스템 리소스가 고갈되어 연결을 열지 못 함
• nginx에서 upstream 서버로 연결하는 경우 source address, destination address, and destination port 는 고정되어 있고 source port만 변수
• nginx 연경은 source address, source port, destination address, and destination port 4가지 요소로 구성

• nginx에서 upstream 서버와 연결이 닫히면 linux 소켓은 2분 동안 TIME-WAIT 상태가 됨
  • 트래픽이 많으면 사용 가능한 source port가 소진될 가능성이 높아짐 → nginx는 upstream 서버에 대한 새 연결을 열 수 없는 상태가 됨
  • source port가 고갈되는 것을 막기 위해 요청이 완료되면 연결이 닫히는 대신 추가 요청에 사용할 수 있도록 연결을 열어두는 keep-alive 연결을 nginx와 upstream 간에 활성화

• 각 worker process의 캐시에 보존되는 upstream 서버에 대한 idle keep-alive 연결 수를 설정하려면 upstream{} 블록에 keepalive 지시어 사용
  • keepalive 지시어는 worker process가 열 수 있는 upstream 서버에 대한 총 연결 수(total number of connections)를 제한하지 않음
  • keepalive 지시어는 upstream{} 블록에 나열된 서버 수의 두 배로 설정하는 것이 좋음
  • 두배 설정은 nginx가 upstrem 모든 서버와의 keep-alive 연결을 유지하기에 충분히 크며, upstream 서버에 새로 들어오는 연결도 처리 가능하도록 작음
     
  • upstream{} 블록에서 hash, ip_hash, least_conn, least_time, random 지시어를 사용하여 load‑balancing algorithm 을 지정
  • hash, ip_hash, least_conn, least_time, random 지시어가 keepalive 지시어 위에 표시 필요(필수) 

• 요청을 upstream으로 전달하는 location{} 블록에 proxy_pass 지시어와 함께 아래 지시어를 포함
  • nginx는 upstream 서버에 대한 연결에 HTTP/1.0을 사용 → 서버로 전달되는 요청에 Connection: close 헤더를 추가
  • upstream{} 블록에 keepalive 지시어가 있음에도 불구하고 요청이 완료되면 각 연결이 닫힘
  • proxy_http_version 지시어는 nginx가 HTTP/1.1을 대신 사용하도록 지시 → proxy_set_header Connection "" 헤더를 통해서 close 값을 제거함
    

    proxy_http_version 1.1;
    proxy_set_header Connection "";

     

• proxy_http_version 지시자
  • 프록시 서버를 위한 HTTP 프로토콜 버전을 설정
  • 기본적으로 버전 1.0이 사용
  • keep-alive 연결 및 NTLM 인증과 함께 사용하려면 버전 1.1을 사용하는 것이 좋음
    

    구문 :	proxy_http_version 1.0 | 1.1;
    기본 :	proxy_http_version 1.0;
    문맥 :	http, server, location​

     

• proxy_set_header Connection "" 설정
  
  • nginx서버에서 upstream으로 요청을 프록시할 때 HTTP 버전을 1.0으로, Connection 헤더를 close로 바꿔서 보냄
  • upstream으로 keepalive 커넥션을 사용하기 위해서는 프록시 HTTP 버전을 1.1로 변경해야 한다고 권장
  • 추가적으로 proxy_set_header Connection "" 설정을 통해 Connection 헤더를 없애주는 설정 진행
    
    
  • upstream 서버로 HTTP 버전을 1.0, Connection 헤더를 close으로 전송
    

    

  • upstream 서버로 HTTP 버전을 1.1, Connection 헤더를 초기화하여 전송
    

    

참고 자료 : Avoiding the Top 10 NGINX Configuration Mistakes - NGINX

참고 자료 : https://seungtaek-overflow.tistory.com/10

• error_log off 지시문으로는 로깅을 비활성화 불가 → access_log 지시어와 달리 error_log는 off 매개 변수를 사용하지 않음
• 만약 nginx에 error_log off 지시어를 포함하면 nginx 구성 파일의 기본 디렉토리(/etc/nginx)에 off라는 이름의 에러 로그 파일을 생성됨
   
• error_log 로그는 nginx의 문제를 디버깅할 때 중요한 정보 소스이므로 비활성화하지 않는 것이 좋지 않음
• 만약 스토리지가 너무 제한적이어서 사용 가능한 디스크 공간을 모두 소진할 정도의 경우 오류 로깅을 비활성화하는 것이 좋음
  
  
• main 설정에 error_log 지시어 사용 예시
  

  error_log /dev/null emerg;​

• error_log 지시어
  • 여러 개의 로그를 지정 가능 
  • main configuration 수준에서 로그를 쓰는 것이 명시적으로 정의되어 있지 않으면 기본 파일이 사용
    

    구문 :	error_log file [level];
    기본 :	error_log logs/error.log error;
    문맥 :	main, http, mail, stream, server, location​

     

• error_log 지시어의 매개변수
  1. error_log 첫 번째 매개변수
     • 로그를 저장할 파일을 정의
     • stderr 특수 값은 표준 오류 파일(standard error file)을 선택 
     • "syslog:" 접두사를 지정하여 syslog에 로깅하도록 구성 가능 
     • "memory: size" 접두사와 버퍼 크기를 지정하여 순환 메모리 버퍼에 로깅 구성 가능. 일반적으로 디버깅에 사용
        
  2. erorr_log 두 번째 매개변수
     • 로깅 수준을 결정
     • debug, info, notice, warn, error, crit, alert 중 하나가 될 수 있음
     • 로그 수준(Log levels)은 심각도가 높아지는 순서대로 나열
     • 특정 로그 수준(certain log level)을 설정하면 지정된 로그 수준보다 더 심각한 로그 수준의 모든 메시지가 기록됨 → 예시) 오류 로그(error log)는  error, crit 및 alert  메시지가 기록됨
     • error_log 매개 변수를 생략하면 error가 사용

• error_log 지시어는 nginx가 구성을 읽고 유효성을 검사할 때까지 적용되지 않는다는 점에 유의
• nginx가 시작하거나 구성이 다시 로드될 때마다 구성의 유효성이 검사 → 기본 error log(/var/log/nginx/error.log) 로깅
• 로그 디렉터리를 변경하려면 nginx 명령에 -e <error_log_location> 파라미터를 포함

참고 자료 : Avoiding the Top 10 NGINX Configuration Mistakes - NGINX

• worker_connections 지시어는 nginx의 worker process가 열 수 있는 최대 동시 연결 수를 설정(기본값은 512). 
• 클라이언트 연결뿐만 아니라 모든 유형의 연결(프록시 서버와의 연결)이 최대 연결 수에 포함 → proxy_pass도 포함
• worker당 동시 연결 수에는 다른 제한이 있음 → 각 프로세스에 할당된 File Descriptors(파일 설명자)의 최대 수에 대한 OS 제한 
• 최신 UNIX 배포판에서  File Descriptors(파일 설명자)의 최대 수에 대한 기본 제한은 1024개
• 가장 작은 규모의 nginx 배포를 제외한 모든 배포에서 worker당 512개의 연결 제한은 너무 작을 수 있음 
• 이 문제를 해결하려면 기본 구성 컨텍스트에서 worker_rlimit_nofile 지시어를 사용하여 설정

• worker_rlimit_nofile 지시자
  • worker process의 최대 파일 열기 수 제한(RLIMIT_NOFILE)을 변경 
  • Main Process를 다시 시작하지 않고 제한을 늘리는 데 사용
    

    구문 :	worker_rlimit_nofile number;
    기본 :	—
    문맥 :	main​

• 더 많은 File Descriptors(파일 설명자)가 필요한 이유
  • nginx worker process에서 클라이언트 또는 업스트림 서버로의 각 연결은 File Descriptors를 소비 
  • nginx가 웹 서버로 작동하는 경우, 클라이언트 연결에 하나의 File Descriptors를 사용하고 제공되는 파일당 하나의 File Descriptors를 사용하여 클라이언트당 최소 2개의 File Descriptors를 사용
  • 프록시 서버로 작동하는 경우, nginx는 클라이언트 및 업스트림 서버 연결에 각각 하나의 File Descriptors 사용(2개 사용)하고, 서버의 응답을 임시로 저장하는 데 사용되는 파일에 세 번째 File Descriptors를 사용
  • nginx가 캐싱 서버로 작동하는 경우, 캐시된 응답에 대해서는 웹 서버처럼 작동하고 캐시가 비어 있거나 만료된 경우에는 프록시 서버처럼 작동
  • nginx는 로그 파일당 File Descriptors를 사용하고 Master 프로세스와 통신하기 위해 몇 개의 File Descriptors를 사용 → 일반적으로 몇 개의 File Descriptors 숫자는 연결 및 파일에 사용되는 File Descriptors의 수에 비해 작음

• UNIX는 프로세스당 File Descriptors 수를 설정하는 몇 가지 방법을 제공
  1. nginx를 시작하는 경우 ulimit 명령어
     • ulimit 명령어는 프로세스가 사용하는 자원에 대한 제어 및 관리할 수 있게 해줌
     • ulimit 명령어는 하나의 유저(쉘,프로세스)에 대해서 할당할 자원량의 한계를 정하는 것으로서 리눅스 시스템에서 과부하를 막아주는 방패가 되어 주는 유용한 설정
     • ulimit는 일시적 설정
       

       $ ulimit -n 65536

        
     • soft와 hard 두 가지 타입
       • soft → 새로운 프로그램을 생성하면 기본으로 적용되는 한도
       • hard → soft 한도에서 최대로 늘릴 수 있는 한도
          
  2. nginx를 서비스로 시작하는 경우 init 스크립트 또는 systemd 서비스 manifest 변수 사용
     

     $ vi /etc/systemd/system/nginx.service
     [Unit]
     Description=The NGINX HTTP and reverse proxy server
     After=syslog.target network.target remote-fs.target nss-lookup.target
     
     [Service]
     Type=forking
     PIDFile=/run/nginx.pid
     ExecStartPre=/usr/local/nginx/sbin/nginx -t
     ExecStart=/usr/local/nginx/sbin/nginx
     ExecReload=/usr/local/nginx/sbin/nginx -s reload
     ExecStop=/bin/kill -s QUIT $MAINPID
     PrivateTmp=true
     LimitNOFILE=65535
     LimitNOFILESoft=65535
     
     [Install]
     WantedBy=multi-user.target​​

      
  3. /etc/security/limits.conf 파일 → 유저의 프로세스별 file open을 설정
     • /etc/security/limits.conf 파일은 유저의 프로세스별 사용하는 자원에 대한 제어 및 관리할 수 있게 해줌
     • 할당할 자원량의 한계를 정함으로 리눅스 시스템에서 과부하를 막아줌
       
       
     • /etc/security/limits.conf 파일은 영구적 설정
       

       $ vi /etc/security/limits.conf
       
       ## nginx 사용자 계정에 수치를 지정
       nginx   soft  nofile  1048576
       nginx   hard  nofile  1048576
       nginx   soft  nproc   1048576
       nginx   hard  nproc   1048576
       
       ## *를 사용하여 모든 계정에 수치를 지정
       *   soft  nofile  1048576
       *   hard  nofile  1048576
       *   soft  nproc   1048576
       *   hard  nproc   1048576​

      
  4. sysctl.conf 의 file open 확인 및 커널 설정
     • sysctl.conf에서 시스템 전체에 대한 file open 개수를 설정
       

       $ cat /proc/sys/fs/file-nr
       3072    0       300000
       |         |       |
       |         |       |
       |         |       최대 오픈 파일 디스크립터 수(fs.file-max)
       |        할당되지 않은 파일 디스크립터 수 (2.6 커널에서는 항상 0으로 표기되며 이는 에러 아님)
       할당된 파일 디스크립터 수

        
     • 커널의 fs.file-max 파라미터는 시스템 전체에서 최대로 열 수 있는 파일 개수
     • 커널의 fs.file-max 파라미터는 시스템의 메모리를 KB로 표현한 값의 10%가 적당
     • 커널의 fs.nr_open 파라미터는 하나의 프로세스가 열 수 있는 최대 파일 개수
     • 커널의 fs.nr_open 파라미터는 기본값은 1024*1024 (1048576) → 대부분의 머신에서 충분(Actual limit depends on RLIMIT_NOFILE resource limit.)
        
     • 커널의 fs.file-max 파라미터와 fs.nr_open 파라미터 설정 확인 및 변경
       

       ## 기존 설정값 확인
       $ sysctl -a | grep fs.file-max
       fs.file-max = 300000
       
       $ cat /proc/sys/fs/file-max
       300000
       
       ## 기존 파라미터 값 수정
       $ vim /etc/sysctl.conf
       fs.file-max = 1048576
       
       ## 설정 값 적용
       $ sysctl -p
       
       
       ## 변경 설정값 확인
       $ sysctl -a | grep fs.file-max
       fs.file-max = 300000
       
       $ cat /proc/sys/fs/file-max
       300000
       
       $ cat /proc/sys/fs/file-nr
       3008    0       1048576

• 시스템 전체에 File Descriptors 수에 대한 제한이 있으며, OS의 sysctl fs.file-max 명령으로 설정 가능
• nginx를 시작하는 방법에 따라 다르지만, worker_rlimit_nofile은 nginx를 시작하는 방법에 작동
• 모든 nginx worker process가 사용할 수 있는 최대 파일 설명자 수(worker_rlimit_nofile * worker_processes)가 fs.file-max보다 훨씬 적은지 확인 필요
• nginx가 사용 가능한 모든 File Descriptors를 사용하는 경우(예: DoS 공격), 문제를 해결하기 위해 컴퓨터에 로그인하는 것조차 불가능해짐

※ File Descriptor(파일 디스크립터)

• 리눅스 혹은 유닉스 계열의 시스템에서 프로세스(process)가 파일(file)을 다룰 때 사용하는 개념
• 프로세스에서 특정 파일에 접근할 때 사용하는 추상적인 값
• File Descriptor(파일 디스크럽터)는 일반적으로 0이 아닌 정수값을 갖음

참고 자료 : 가장 많이 실수하는 NGINX 설정 에러 10가지 - NGINX STORE

참고 자료 : file open 확인 및 커널 설정 : 네이버 블로그 (naver.com)

• Nginx http hls 모듈 : Module ngx_http_hls_module (nginx.org)

• ngx_http_hls_module 모듈은 MP4 및 MOV 미디어 파일에 대한 HTTP 라이브 스트리밍(HLS) 서버 측 지원을 제공
• 파일의 파일 확장자는 일반적으로 .mp4, .m4v, .m4a, .mov, .qt
• ngx_http_hls_module 모듈은 H.264 비디오 코덱, AAC 및 MP3 오디오 코덱을 지원
  
  
• 각 미디어 파일에 대해 두 개의 URI가 지원
  1. 파일 이름 확장자가 .m3u8인 재생 목록 URI (URI는 아래 선택적 인수를 사용 가능)
     • start 및 end는 재생 목록 경계(playlist boundaries)를 초 단위로 정의
     • offset은 초기 재생 위치를 초 단위의 시간 오프셋(time offset)으로 이동
     • 양수 값은 재생 목록의 시작부터 시간 오프셋(offset)을 설정
     • 음수 값은 재생 목록의 마지막 조각 끝에서 시간 오프셋(offset)을 설정
     • len은 조각 길이를 초 단위로 정의
  2. 파일 이름 확장자가 ".ts"인 조각 URI (URI는 아래 선택적 인수를 사용 가능)
     • start 및 end는 조각 경계(fragment boundaries)를 초 단위로 정의
       
       
• 구성 예시

  location / {
      hls;
      hls_fragment            5s;
      hls_buffers             10 10m;
      hls_mp4_buffer_size     1m;
      hls_mp4_max_buffer_size 5m;
      root /var/video/;
  }

• 위 구성을 사용하면 "/var/video/test.mp4" 파일에 대해 다음 URI가 지원

  http://hls.example.com/test.mp4.m3u8?offset=1.000&start=1.000&end=2.200
  http://hls.example.com/test.mp4.m3u8?len=8.000
  http://hls.example.com/test.mp4.ts?start=1.000&end=2.200

hls 지시자

• HLS 스트리밍 설정
  
  
• 문맥 : location
• 사용 문법

  ## 문법
  hls;

hls_buffers 지시자

• 데이터 프레임 읽기 및 쓰기에 사용되는 버퍼의 최대 수와 크기를 설정
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  hls_buffers number size;

• 사용 예시

  ## 사용 예시(기본 설정)
  hls_buffers 8 2m;

hls_forward_args 지시자

• 재생 목록 요청(playlist request)의 인수(arguments)를 URI의 조각(fragments)에 추가
• 조각(fragments)을 요청하는 순간에 클라이언트 인증을 수행하거나 ngx_http_secure_link_module 모듈로 HLS 스트림을 보호할 때 유용하게 사용 가능
• 예시) 클라이언트가 http://example.com/hls/test.mp4.m3u8?a=1&b=2 재생 목록을 요청하는 경우, 인수가 시작되고 끝나는 부분 뒤에 인자 a=1 및 b=2가 조각의 URI에 추가

  #EXTM3U
  #EXT-X-VERSION:3
  #EXT-X-TARGETDURATION:15
  #EXT-X-PLAYLIST-TYPE:VOD
  
  #EXTINF:9.333,
  test.mp4.ts?start=0.000&end=9.333&a=1&b=2
  #EXTINF:7.167,
  test.mp4.ts?start=9.333&end=16.500&a=1&b=2
  #EXTINF:5.416,
  test.mp4.ts?start=16.500&end=21.916&a=1&b=2
  #EXTINF:5.500,
  test.mp4.ts?start=21.916&end=27.416&a=1&b=2
  #EXTINF:15.167,
  test.mp4.ts?start=27.416&end=42.583&a=1&b=2
  #EXTINF:9.626,
  test.mp4.ts?start=42.583&end=52.209&a=1&b=2 
  
  #EXT-X-ENDLIST

• HLS 스트림이 ngx_http_secure_link_module 모듈로 보호되는 경우, 조각을 요청할 때 오류가 발생할 수 있으므로 secure_link_md5 표현식에 $uri를 사용해서는 안 됨
• $uri 대신 Base URI를 사용해야 함(예시에서는 $hls_uri)

  http {
      ... 
      map $uri $hls_uri {
          ~^(?<base_uri>.*).m3u8$ $base_uri;
          ~^(?<base_uri>.*).ts$   $base_uri;
          default                 $uri;
      }
      
      server {
          ...
          location /hls/ {
              hls;
              hls_forward_args on; 
              alias /var/videos/;
              secure_link $arg_md5,$arg_expires;
              secure_link_md5 "$secure_link_expires$hls_uri$remote_addr secret";
              
              if ($secure_link = "") {
                  return 403;
              }
              
              if ($secure_link = "0") {
                  return 410;
              }
          }
      }
  }

• 문맥 : http, server, location
• 사용 문법

  ## 문법
  hls_forward_args on | off;

• 사용 예시

  ## 사용 예시(기본 설정)
  hls_forward_args off;

hls_fragment 지시자

• len 인수 없이 요청된 재생 목록 URI의 기본 조각 길이를 정의
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  hls_fragment time;

• 사용 예시

  ## 사용 예시(기본 설정)
  hls_fragment 5s;

hls_mp4_buffer_size 지시자

• MP4 및 MOV 파일 처리에 사용되는 버퍼의 초기 크기를 설정
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  hls_mp4_buffer_size size;

• 사용 예시

  ## 사용 예시(기본 설정)
  hls_mp4_buffer_size 512k

hls_mp4_max_buffer_size 지시자

• 메타데이터(metadata)를 처리하는 동안 더 큰 버퍼가 필요할 수 있음
• 버퍼의 크기가 지정된 크기를 초과할 수 없으며, 그렇지 않으면 nginx에서 서버 오류 500(내부 서버 오류)을 반환
  
  
• 발생 에러

  "/some/movie/file.mp4" mp4 moov atom is too large:
  12583268, you may want to increase hls_mp4_max_buffer_size

   
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  hls_mp4_max_buffer_size size;

• 사용 예시

  ## 사용 예시(기본 설정)
  hls_mp4_max_buffer_size 10m;