히포

• 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;

• Nginx http mp4 모듈 : http://nginx.org/en/docs/http/ngx_http_mp4_module.html

• ngx_http_mp4_module 모듈은 MP4 파일에 대한 pseudo-streaming 지원
• 일반적으로 .mp4, .m4v또는 .m4a파일 이름 확장자가 있음
• pseudo-streaming은 호환되는 미디어 플레이어와 함께 작동함
• 플레이어는 쿼리 문자열 인수(초 단위로 지정)에 지정된 시작 시간과 함께 서버에 HTTP 요청을 보냄
• start는 시작시간을 요청된 시간과 일치하도록 스트림으로 응답
• 언제든지 무작위 검색을 수행하거나 타임라인 중간에 재생을 시작 가능
• 재생을 시작하려면 플레이어가 먼저 메타데이터를 읽어야 함 → start=0 인수와 함께 특수 요청을 전송하여 수행
  
  
• start 사용 예시

  http://example.com/elephants_dream.mp4?start=238.88

• ngx_http_mp4_module 모듈 end은 재생의 끝점을 설정하는 HTTP 요청의 인수도 지원
• start가 0이 아니거나 인수가 있는 일치 요청의 end 경우 nginx는 파일에서 메타데이터를 읽고 요청된 시간 범위로 스트림을 준비하여 클라이언트에 보냄 → 오버헤드를 발생
• start 인수가 키가 아닌 비디오 프레임을 가리키는 경우 해당 비디오의 시작 부분이 깨짐 → 문제를 해결하기 위해 포인트 앞의 키 프레임과 그 사이의 모든 중간 프레임을 비디오 앞에 추가 가능
• start이 프레임은 편집 목록(1.21.4)을 사용하여 재생에서 숨김
• 일치하는 요청에 start 및 end 인수가 포함되지 않은 경우 오버헤드가 없으며 파일은 단순히 정적 리소스로 전송
  
  
• 인수 end와 함께 start를 지정하거나 별도로 지정 가능

  http://example.com/elephants_dream.mp4?start=238.88&end=555.55

※ 메타데이터

• 검색을 지원하기 위해 H.264 기반 포맷은 메타데이터를 "moov atom"에 저장 → 전체 파일에 대한 인덱스 정보를 저장하는 파일 일부
• 재생을 시작하려면 플레이어가 먼저 메타데이터를 읽어야함
• 많은 인코딩 소프트웨어는 파일 끝에 메타데이터를 삽입함 → 플레이어는 재생을 시작하기 전에 전체 파일을 다운로드해야 하기 때문에 pseudo-streaming에는 차선의 선택
• 메타데이터가 파일 시작 부분에 있으면 nginx가 파일 내용을 다시 보내기 시작하는 것으로 충분
• 메타데이터가 파일 끝에 있는 경우 nginx는 전체 파일을 읽고 미디어 데이터보다 메타데이터가 먼저 오도록 새 스트림을 준비해야 함
• CPU, 메모리 및 디스크 I/O 오버헤드가 수반되므로 nginx가 이러한 모든 요청에 대해 이 작업을 수행하도록 하기보다는 pseudo-streaming을 위한 원본 파일을 미리 준비하는 것이 좋음

ngx_http_mp4_module 모듈 지시문

• 일부 플레이어는 바이트 범위 요청도 지원하므로 ngx_http_mp4_module 모듈이 필요하지 않음
• --with-http_mp4_module 모듈은 기본적으로 빌드되지 않으며 구성 매개변수로 활성화해야 함
• 타사 mp4 모듈을 이전에 사용한 경우 비활성화해야 함
• FLV 파일에 대한 유사한 의사 스트리밍 지원은 ngx_http_flv_module 모듈에서 제공함
  
  
• 구성 예

  location /video/ {
       mp4;
       mp4_buffer_size       1m;
       mp4_max_buffer_size   5m;
       mp4_limit_rate        on;
       mp4_limit_rate_after  30s;
  }

mp4 지시어

• mp4 모듈 처리를 킴
  
  
• 문맥 : location
• 사용 문법과 사용 예시

  # 문법 : mp4;
  mp4;

mp4_buffer_size size 지시어

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

  # 문법
  mp4_buffer_size size;

• 사용 예시

  # 사용 예시
  mp4_buffer_size 512K;

mp4_max_buffer_size 지시자

• 메타데이터 처리 중에 더 큰 버퍼가 필요한 경우가 있음
• 메타데이터 처리 중에 버퍼 크기는 지정된 크기를 초과할 수 없음
• 버퍼 크기보다 초과하는 경우, nginx가 500(내부 서버 오류) 서버 오류를 반환하고 아래 메시지 출력

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

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

  # 문법
  mp4_max_buffer_size size;

• 사용 예시

  # 사용 예시
  mp4_max_buffer_size 10M;

※ mp4_max_buffer_size가 작아 500 에러 발생 예시

• 500 에러 발생 화면 (참고 URL : http://도메인/a.mp4?start=100)
  

  

• 500 에러 발생 error 로그

  날짜 시간 [error] 24042404: *94087966 "a.mp4" mp4 moov atom is too large:5448131, 
  you may want to increase mp4_max_buffer_size, client: 111.111.111.111,
  ### 생략

• 500 에러 발생 시 mp4_max_buffer_size 값을 올려주면 해결할 수 있음

mp4_limit_rate 지시자

• 클라이언트에 대한 응답 전송 속도를 제한
• 전송 속도는 제공되는 MP4 파일의 평균 비트 전송률에 따라 제한
  
  
• mp4_limit_rate 사용 값
  1. factor → 전송률을 계산하려면 비트 전송률(bitrate)에 지정된 factor를 곱함
  2. on → on을 설정하면 속도 제한을 활성화하며, factor는 1.1에 해당
  3. off → 속도 제한을 비활성화
     
     

• limit는 요청별로 설정이 됨 → 클라이언트가 동시에 두 개의 연결을 열면 전체 속도는 지정된 제한의 두 배가됨
  
  

• 문맥: http, server, location
• 사용 문법과 기본 사용 예시

  # 문법
  mp4_limit_rate on | off | factor;
  
  # 사용 예시
  mp4_limit_rate off;

mp4_limit_rate_after 지시자

• 초기 미디어 데이터 양(재생 시간으로 측정)을 설정. 이후 클라이언트로의 응답 전송 속도가 제한
  
  
• 문맥: http, server, location
• 사용 문법

  # 문법
  mp4_start_key_frame on | off;

• 기본 사용 예시

  mp4_start_key_frame off;

mp4_start_key_frame 지시자

• 출력 비디오가 항상 키 비디오 프레임으로 시작하도록 함
• start 인수가 키 프레임을 가리키지 않으면, 초기 프레임은 mp4 편집 목록을 사용하여 숨겨짐.
• 편집 목록은 Firefox에서 부분적으로 지원
• 편집 목록은 Chrome, Safari, QuickTime 및 ffmpeg와 같은 주요 플레이어 및 브라우저에서 지원됨
  
  
• 문맥: http, server, location
• 해당 지시자는 nginx 1.21.4 버전 이후부터 사용 가능
• 사용 문법

  # 문법
  mp4_start_key_frame on | off;

• 기본 사용 예시

  mp4_start_key_frame off;

참고 자료

• https://lhb.kr/mobile/article.html?no=2678

• Nginx http referer 모듈 참고 : Module ngx_http_referer_module (nginx.org)

• ngx_http_referer_module 모듈은 "Referer" 헤더 필드에 잘못된 값을 가진 요청에 대한 사이트 액세스를 차단하는 데 사용
• 적절한 "Referer" 필드 값을 사용하여 요청을 조작하는 것은 매우 쉬움
• ngx_http_referer_module 모듈의 목적은 요청을 완전히 차단하는 것이 아니라 일반 브라우저에서 전송되는 요청의 대량 흐름을 차단하는 것을 염두에 두어 사용
• 일반 브라우저는 유효한 요청에 대해서도 "Referer" 필드를 보내지 않을 수 있다는 점도 고려
  
  
• 사용 예시

  valid_referers none blocked server_names
                 *.example.com example.* www.example.org/galleries/
                 ~\.google\.;
  
  if ($invalid_referer) {
      return 403;
  }

referer_hash_bucket_size 지시자

• 유효한 레퍼러(valid referers) 해시 테이블(hash tables)의 버킷 크기(bucket size)를 설정
• 해시 테이블(hash tables) 설정에 대한 자세한 내용은 옆 URL 확인 → http://nginx.org/en/docs/hash.html
  
  
• 문맥 : server, location
• 사용 문법

  ## 문법
  referer_hash_bucket_size size;

• 사용 예시

  ## 기본 설정
  referer_hash_bucket_size 64;

referer_hash_max_size 지시자

• 유효한 참조(valid referers) 해시 테이블(hash tables)의 최대 크기를 설정
• 해시 테이블(hash tables) 설정에 대한 자세한 내용은 옆 URL 확인 → http://nginx.org/en/docs/hash.html
  
  
• 문맥 : server, location
• 사용 문법

  ## 문법
  referer_hash_max_size size;

• 사용 예시

  ## 기본 설정
  referer_hash_max_size 2048;

valid_referers 지시자

• embedded(내장된) $invalid_referer 변수가 빈 문자열(empty string)로 설정되도록 하는 "Referer" 요청 헤더 필드 값(request header field values을 지정
• "Referer" 요청 헤더 필드 값(request header field value)이 유효하지 않은 것으로 간주되면 $invalid_referer 변수가 "1"로 설정
• 일치 검색(Search for a match)은 대소문자(case-insensitive)를 구분하지 않음
  
  
• 문맥 : server, location
• 사용 문법

  ## 문법
  valid_referers none | blocked | server_names | string ...;

valid_referers 지시자의 매개변수

1. none

• 요청 헤더(request header) 안에 "Referer" 필드가 없는 경우

2. blocked

• 요청 헤더(request header)에 "Referer" 필드가 있지만, 방화벽(firewall) 또는 프록시 서버(proxy server)에 의해 해당 값이 삭제되는 경우
• 값은 "http://" 또는 "https://"로 시작하지 않는 문자열

3. server_names

• 요청 헤더 필드(request header field)에 서버 이름(server names) 중 하나가 포함된 경우

4. arbitrary string

• 임의의 문자열(arbitrary string)은 서버 이름(server name)과 선택적 URI 접두사(optional URI prefix)를 정의
• 서버 이름(server name)은 시작 또는 끝에 "*"가 올 수 있음
• 검사하는 동안 "Referer" 필드에 있는 서버의 포트는 무시됨

5. regular expression

• 정규식(regular expression)의 경우 첫 번째 기호는 "~"여야 함
• 정규식(regular expression)은 "http://" 또는 "https://" 뒤에 시작하는 텍스트에 대해 일치하는지 확인

ngx_http_referer_module 모듈의 내장 변수 → $invalid_referer

• "Referer" 요청 헤더 필드 값(request header field value)이 유효한 것으로 간주되는 경우 빈 문자열, 그렇지 않으면 "1"

• --with-http_secure_link_module 모듈은 기본적으로 빌드되지 않으며 구성 매개변수로 활성화 필요
• nginx http secure link 참고 : http://nginx.org/en/docs/http/ngx_http_secure_link_module.html

• ngx_http_secure_link_module 모듈 사용 용도
  1. 요청된 링크의 진위를 확인
  2. 무단 액세스로부터 리소스를 보호
  3. 링크 수명을 제한
     
     

• 검사의 상태는 $secure_link 변수에서 사용
• 요청된 링크의 신뢰성은 요청에 전달된 체크섬 값과 요청에 대해 계산된 값을 비교하여 확인
• 링크의 수명이 제한되어 있고 시간이 만료된 경우 해당 링크는 오래된 것으로 간주
  
  

• ngx_http_secure_link_module 모듈은 두 가지 대체 작동 모드를 제공
  1. secure_link_secret 지시문에 의해 활성화→ 요청된 링크의 신뢰성을 확인하고 무단 액세스로부터 리소스를 보호하는 데 사용
  2. secure_link 및 secure_link_md5 지시문에 의해 활성화되며 링크 수명을 제한하는 데에도 사용

secure_link 지시어

• secure_link 지시어는 링크의 체크섬 값과 수명을 추출할 변수가 있는 문자열을 정의
• secure_link 지시어는 일반적으로 요청과 연결됨
  
  
• 문맥: http, server, location
• 사용 문법

  # 문법 : secure_link 표현법
  secure_link expression;

• 문자열에서 추출한 체크섬 값은 secure_link_md5 지시문에서 정의한 표현식의 MD5 해시 값과 비교
  1. 체크섬이 다른 경우 $secure_link 변수는 빈 문자열로 설정
  2. 체크섬이 같으면 링크 수명을 확인
     
     

• 링크의 수명이 제한되어 있고 시간이 만료된 경우에도 $secure_link 변수 설정
  1. 링크의 수명이 제한되어 있고 시간이 만료된 경우 $secure_link 변수는 "0"으로 설정
  2. 그렇지 않은 경우 $secure_link 변수는 "1"로 설정
     
     

• 요청에 전달된 MD5 해시 값은 base64url로 인코딩
  1. 링크의 수명이 제한된 경우 만료 시간은 Epoch(1970년 1월 1일 00:00:00 GMT) 이후 초 단위로 설정
  2. MD5 해시 다음에 표현식에 지정되며 쉼표로 구분
  3. 요청에 전달된 만료 시간은 secure_link_md5 지시문에서 사용하기 위해 $secure_link_expires 변수를 통해 사용 가능
     만료 시간이 지정되지 않은 경우 링크의 수명은 무제한임

2. secure_link_md5 지시어

• MD5 해시 값이 계산되고 요청에 전달된 값과 비교되는 식을 정의
• 식에는 링크(리소스)의 보안 부분과 비밀 요소가 포함되어야함
  
  
• 문맥: http, server, location
• 사용 문법

  # 문법 : secure_link_md5 표현법
  secure_link_md5 expression;

• 링크의 수명이 제한된 경우 표현식에 $secure_link_expires도 포함되어야함
• 무단 액세스를 방지하기 위해 식에는 주소 및 브라우저 버전과 같은 클라이언트에 대한 일부 정보가 포함될 수 있음

  location /s/ {
      secure_link $arg_md5,$arg_expires;
      secure_link_md5 "$secure_link_expires$uri$remote_addr secret";
      
      if ($secure_link = "") {
          return 403;
      }
      
      if ($secure_link = "0") {
          return 410;
      }
      ...
  }

• "/s/link?md5=_e4Nc3iduzkWRm01TBBNYw&expires=2147483647" 링크는 IP 주소가 127.0.0.1인 클라이언트의 "/s/link"에 대한 액세스를 제한
  링크의 수명은 2038년 1월 19일(GMT)까지 제한

• UNIX에서 md5요청 인수 값은 다음과 같이 얻을 수 있음

  $ echo -n '2147483647/s/link127.0.0.1 secret' | openssl md5 -binary | openssl base64 | tr +/ -_ | tr -d =

3. secure_link_secret 지시어

• 요청된 링크의 진위 여부를 확인하는 데 사용되는 암호를 정의
  
  
• 문맥: location
• 사용 문법

  # 문법 : secure_link_secret 표현법
  secure_link_secret word;

• 요청된 링크의 전체 URI은 아래와 같음
  1. hash → 링크와 secret 단어의 연결을 위해 계산된 MD5 해시의 16진수 표현
  2. prefix → 슬래시가 없는 임의의 문자열
  3. link → 요청 url

     # /접두사/해시/링크
     /prefix/hash/link

• 요청된 링크가 진위 확인을 통과하면 $secure_link 변수가 요청 URI에서 추출된 링크로 설정
• 그렇지 않으면 $secure_link 변수가 빈 문자열로 설정됨

  location /p/ {
      secure_link_secret secret;
   
      if ($secure_link = "") {
          return 403;
      }
   
      rewrite ^ /secure/$secure_link;
  }
   
  location /secure/ {
      internal;
  }

• "/p/5e814704a28d9bc1914ff19fa0c4a00a/link" 요청은 내부적으로 "/secure/link"로 리디렉션
• UNIX에서 예제의 해시 값은 아래와 같이 얻을 수 있음

  $ echo -n 'linksecret' | openssl md5 -hex

• Nginx http realip 모듈 : https://nginx.org/en/docs/http/ngx_http_realip_module.html
• ngx_http_realip_module 모듈은 클라이언트 주소와 선택적 포트를 지정된 헤더 필드에 전송된 주소로 변경하는 데 사용
• ngx_http_realip_module 모듈은 기본적으로 빌드되지 않으며, --with-http_realip_module 구성 매개변수를 사용하여 활성화
  
  
• 구성 예시

  set_real_ip_from  192.168.1.0/24;
  set_real_ip_from  192.168.2.1;
  set_real_ip_from  2001:0db8::/32;
  real_ip_header    X-Forwarded-For;
  real_ip_recursive on;

set_real_ip_from 지시자

• nginx가 지정된 범위 내의 프록시 서버에서 실제 방문자의 IP를 가져 오도록 지시
• 올바른 대체 주소를 전송하는 것으로 알려진 신뢰할 수 있는 주소를 정의
• 특수 값인 unix:를 지정하면 모든 UNIX 도메인 소켓이 신뢰
• 호스트 이름(1.13.1)을 사용하여 신뢰할 수 있는 주소를 지정 가능
• IPv6 주소는 버전 1.3.0 및 1.2.1부터 지원
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  set_real_ip_from address | CIDR | unix:;

real_ip_header 지시자

• nginx는 주어진 주소에서 클라이언트의 IP 주소를 선택
• 클라이언트 주소를 대체하는 데 사용될 request 헤더 필드 값을 정의
• 선택적 포트가 포함된 request 헤더 필드 값은 클라이언트 포트(1.11.0)를 대체하는 데에도 사용
• 주소와 포트는 RFC 3986에 따라 지정 → 참고 자료 : RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax (ietf.org)
• proxy_protocol 매개변수(1.5.12)는 클라이언트 주소를 프록시 프로토콜 헤더(PROXY protocol header)의 주소로 변경
• listen 지시어에 proxy_protocol 파라미터를 설정하여 PROXY 프로토콜을 활성화
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  real_ip_header field | X-Real-IP | X-Forwarded-For | proxy_protocol;

• 사용 예시

  ## 기본 설정
  real_ip_header X-Real-IP;

real_ip_recursive 지시자

• 프록시 서버의 IP가 방문자의 IP 주소로 대체
• 재귀 검색(recursive search)을 사용하지 않으면 신뢰할 수 있는 주소 중 하나와 일치하는 원래 클라이언트 주소가 real_ip_header 지시어로 정의된 request 헤더 필드에 전송된 마지막 주소로 대체
• 재귀 검색(recursive search)이 활성화된 경우 신뢰할 수 있는 주소 중 하나와 일치하는 원본 클라이언트 주소는 request 헤더 필드에 전송된 마지막 신뢰할 수 없는 주소로 대체
• real_ip_recursive 지시어는 버전 1.3.0과 1.2.1에 등장
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  real_ip_recursive on | off;

• 사용 예시

  ## 기본 설정
  real_ip_recursive off;

ngx_http_realip_module모듈의 내장 변수

1. $realip_remote_addr 변수

• keeps the original client address (1.9.7)
• 원래 클라이언트 주소 유지 (1.9.7)

2. $realip_remote_port 변수

• keeps the original client port (1.11.0)
• 원래 클라이언트 포트(1.11.0)를 유지