히포

• 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)를 유지

• Nginx http slice 모듈 : Module ngx_http_slice_module (nginx.org)

• ngx_http_slice_module 모듈(1.9.8)은 요청을 하위 요청으로 분할하고 각각의 응답 범위를 반환
  대용량 응답의 더 효과적인 캐싱을 제공
• --with-http_slice_module 구성 매개변수로 활성화

slice 지시자

• slice 지시자를 통해 응답 조각의 크기를 설정
• slice 0 값은 응답을 조각으로 나누지 않음
• 너무 낮은 값은 과도한 메모리 사용 및 대량 파일 열기로 이어질 수 있음
• Range 요청 헤더 필드로 $slice_range 변수를 프록시 서버로 전달
• 캐싱이 활성화되어 있으면 $slice_range를 캐시 키에 추가하고 206 상태 코드를 가진 응답의 캐싱을 활성화
  
  
• 문맥 : http, server, location
• 사용 문법

  ## 문법
  slice size;

• 사용 예시

  ## 기본 설정
  slice 0;

slice 예제 구성

• 응답은 1MB 캐시 가능한 조각으로 설정

  location / {
      slice             1m;
      proxy_cache       cache;
      proxy_cache_key   $uri$is_args$args$slice_range;
      proxy_set_header  Range $slice_range;
      proxy_cache_valid 200 206 1h;
      proxy_pass        http://localhost:8000;
  }

ngx_http_slice_module 모듈의 내장 변수 → $slice_range

• HTTP 바이트 범위 형식의 현재 조각 범위
• 예시 : bytes=0-1048575.

• Nginx http split client 모듈 : Module ngx_http_split_clients_module (nginx.org)

• ngx_http_split_clients_module 모듈은 분할 테스트라고도 하는 A/B 테스트에 적합한 변수를 생성함

split_clients 지시자

• 구성 예시

  http {
      split_clients "${remote_addr}AAA" $variant {
                     0.5%               .one;
                     2.0%               .two;
                     *                  "";
      }
      server {
          location / {
              index index${variant}.html;
          }
      }
   }

• original 문자열의 값은 MurmurHash2를 사용하여 해시
  
  
• 예시)
  • 0에서 21474835(0.5%)의 해시 값은 $variant 변수의 값 ".one"에 해당
  • 21474836에서 107374180(2%)의 해시 값은 ".two"에 해당
  • 107374181에서 4294967295의 해시 값은 ""(빈 문자열)에 해당
    
    
• 문맥 : http
• 사용 문법

  ## 문법
  split_clients string $variable { ... }

• Nginx http sub 모듈 : Module ngx_http_sub_module (nginx.org)

• ngx_http_sub_module 모듈은 지정된 문자열을 다른 문자열로 대체하여 응답을 수정하는 필터
• ngx_http_sub_module 모듈은 기본적으로 빌드되지 않으며 --with-http_sub_module 구성 매개변수를 사용하여 사용할 수 있도록 설정 필요
  
  
• 구성 예시

    location / {
      sub_filter '<a href="http://127.0.0.1:8080/'  '<a href="https://$host/';
      sub_filter '<img src="http://127.0.0.1:8080/' '<img src="https://$host/';
      sub_filter_once on;
    }

sub_filter 지시자

• 바꿀 문자열과 대체 문자열을 설정
• 바꿀 문자열은 대소문자를 무시
• 대체할 문자열(The string to replace)과 대체 문자열(replacement string)은 변수를 포함할 수 있음
• 동일한 구성 수준(same configuration level)에서 여러 개의 sub_filter 지시어를 지정 가능
• sub_filter 지시어는 현재 수준(current level)에 정의된 sub_filter 지시어가 없는 경우에만 이전 구성 수준(previous configuration level)에서 상속됨
  
  
• 문맥 : http, server, location
• 사용 문법

    ## 문법
    sub_filter string replacement;

sub_filter_last_modified 지시자

• 응답 캐싱(response caching)을 용이하게 하기 위해 교체하는 동안 원본 응답(original response)의 "Last-Modified" 헤더 필드를 보존할 수 있음
• 기본적으로 헤더 필드(header field)는 처리 중에 응답의 내용(contents of the response)이 수정되면 제거됨
  
  
• 문맥 : http, server, location
• 사용 문법

    ## 문법
    sub_filter_last_modified on | off;

• 사용 예시

    ## 기본 설정
    sub_filter_last_modified off;

sub_filter_once 지시자

• 대체할 각 문자열(each string to replace)을 한 번만 찾을지 반복해서 찾을지 여부를 나타냄
  
  
• 문맥 : http, server, location
• 사용 문법

    ## 문법
    sub_filter_once on | off;

• 사용 예시

    ## 기본 설정
    sub_filter_once on;

sub_filter_types 지시자

• 응답(responses)에서 "text/html" 외에 지정된 MIME 유형으로 문자열을 대체할 수 있도록 함
• 특수 값(special value)인 "*"는 모든 MIME 유형과 일치
  
  
• 문맥 : http, server, location
• 사용 문법

    ## 문법
    sub_filter_types mime-type ...;

• 사용 예시

    ## 기본 설정
    sub_filter_types text/html;

• Upstream Domain Resolve 참고 자료 : https://www.nginx.com/resources/wiki/modules/domain_resolve/

• ngx_upstream_jdomain 깃허브 : https://github.com/nicholaschiasson/ngx_upstream_jdomain

ngx_upstream_jdomain 모듈이란

• ngx_upstream_jdomain 모듈은 nginx 업스트림 도메인 네임을 비동기적으로 확인하는 업스트림 모듈
• 업스트림 블록에서 도메인 이름을 사용할 수 있으며 도메인 이름이 동적으로 확인 → 업스트림이 DNS 항목 업데이트에 탄력적으로 대응 가능
• ngx_upstream_jdomain 모듈은 일정 간격으로 DNS 확인을 자동으로 수행하지 않음 → 주어진 업스트림에 대한 요청에 따라 DNS 확인
• nginx가 jdomain 업스트림에 바인딩된 연결을 제공하고 구성된 간격(interval)이 경과한 경우 모듈은 DNS 조회를 수행함

• ngx_upstream_jdomain 모듈은 다른 업스트림 범위(upstream scope) 지시어와 호환
  1. 여러 jdomain 지시어(multiple jdomain directives)
  2. 여러 서버 지시어(multiple server directives)
  3. keepalive
  4. 로드 밸런싱 지시어(load balancing directives)
  5. 등등(etc.)

• 업스트림 블록에 다른 로드 밸런싱 방법을 지정하지 않는 한 ngx_upstream_jdomain 모듈은 nginx 코어에 내장된 기본 라운드 로빈 로드 밸런싱 알고리즘을 사용
• 버퍼에는 백엔드 도메인 이름(backend domain name)의 최신 IP가 구성되어 있으며, 로드 밸런싱 알고리즘(최소_conn, 해시 등) 또는 명시적으로 정의되지 않은 경우 내장된 라운드 로빈과 통합함
• 매 간격(기본값은 1초)마다 도메인 이름을 확인(질의)
• 도메인 네임을 확인하지 못하면 버퍼는 마지막으로 성공적으로 확인된 IP를 유지하거나 사용자가 지정한 백업 서버 IP를 사용

※ 대체 로드 밸런싱 알고리즘(alternate load balancing algorithm)을 지정하는 경우 업스트림 블록의 jdomain 지시어 앞에 지정 필요

• 앞에 지정하지 않는 경우 런타임 중에 nginx가 충돌 발생
• 많은 로드 밸런싱 모듈이 내장된 라운드 로빈을 명시적으로 확장
• jdomain 지시어 이후에 대체 로드 벨런싱 알고리즘을 지정하면, jdomain 초기화 핸들러를 방해 → jdomain은 로드 밸런서 모듈
• 단, 모든 로드 밸런서 모듈에 해당하는 것은 아니지만, 안전을 위해 jdomain을 뒤에 배치하는 것이 좋음(jdomain 앞에 대체 로드 밸런싱 알고리즘 취이 필요)

※ ngx_upstream_jdomain 모듈의 비차단 특성(non blocking nature)과 들어오는 요청에 의해 DNS resolve 트리거

• resolve를 요청하는 트리거는 실제로는 DNS 조회가 발생하기 전에 확인되어 캐시된 업스트림으로 전달
• 시나리오에 따라 업스트림의 상태를 변경할 때 일회성 장애가 발생할 수 있음
• 업스트림의 원활한 전환을 보장하기 위해 염두에 두어야 함

ngx_upstream_jdomain 시놉시스(Synopsis)

1. ngx_upstream_jdomain 문법

jdomain <domain-name> [port=80] [max_ips=4] [interval=1] [strict]

2. nginx_upstream_jdomain 위치

• Context: upstream

3. nginx_upstream_jdomain 속성 설명

ngx_upstream_jdomain 모듈 설치(Installation)

• https://github.com/nicholaschiasson/ngx_upstream_jdomain 리포지토리를 정적 또는 동적 모듈로 사용하여 nginx를 빌드

    $ ./configure --add-module=/path/to/this/directory
    $ make
    $ make install

ngx_upstream_jdomain 사용 예시

resolver 8.8.8.8; # Your Local DNS Server

# Basic upstream using domain name defaulting to port 80.
upstream backend_01 {
    jdomain example.com;
}

# Basic upstream specifying different port.
upstream backend_02 {
    jdomain example.com port=8080;
}

# Upstream with a backup server to use in case of host not found or format
# errors on DNS resolution.
upstream backend_03 {
    server 127.0.0.2 backup;
    jdomain example.com;
}

# Upstream which will use backup for any and all DNS resolution errors.
upstream backend_04 {
    server 127.0.0.2 backup;
    jdomain example.com strict;
}

# Upstream which will use backup for any and keepalive.
upstream backend_05 {
    server 127.0.0.2:55555 backup;
    jdomain example.com;
    keepalive 8;
}

server {
    listen 127.0.0.2:80;
    return 502 'An error.';
}