Module ngx_http_v2_module

Module ngx_http_v2_module The ngx_http_v2_module module (1.9.5) provides support for HTTP/2. This module is not built by default, it should be enabled with the --with-http_v2_module configuration parameter. Known Issues Before version 1.9.14, buffering of

nginx.org

 

  • 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 > Nginx 모듈 학습' 카테고리의 다른 글

ngx_http_auth_basic_module 모듈  (1) 2024.12.15
ngx_http_autoindex_module 모듈  (0) 2024.12.15
ngx_http_dav_module 모듈  (1) 2024.12.11
ngx_http_hls_module 모듈  (0) 2023.09.24
ngx_http_mp4_module 모듈  (0) 2023.09.24
 

Module ngx_http_auth_basic_module

Module ngx_http_auth_basic_module The ngx_http_auth_basic_module module allows limiting access to resources by validating the user name and password using the “HTTP Basic Authentication” protocol. Access can also be limited by address, by the result of

nginx.org

 

  • ngx_http_auth_basic_module 모듈은 "HTTP Basic Authentication" 프로토콜을 사용하여 user name과 password를 검증함으로써 리소스에 대한 접근을 제한 가능
  • 주소(address), subrequest의 결과 또는 JWT에 의해 액세스를 제한
  • 주소(address)와 비밀번호(password)에 의한 접근 제한을 동시에 적용하려면 satisfy 지시어로 제어

auth_basic 지시자

  • “HTTP Basic Authentication” 프로토콜을 사용하여 user name과 password 의 유효성 검사를 활성화 
  • 지정된 매개변수는 영역(realm)으로 사용
  • off는 configuration level에서 상속된 auth_basic 지시어의 효과를 취소

  • 문맥 : http, server, location, limit_except
  • 사용 문법 
  • ## 문법 auth_basic string | off;
  • 사용 예시
    ## 기본 설정
    auth_basic off;

 

auth_basic_user_file 지시자

  • user name과 password를 저장하는 파일을 지정
  • 파일 이름에는 변수를 포함 가능
    # comment
    name1:password1
    name2:password2:comment
    name3:password3
     
  • 아래와 같은 password 유형이 지원
    1. crypt() 함수로 암호화된 비밀번호 → Apache HTTP Server의 htpasswd나 openssl passwd 명령어로 생성 가능
    2. Apache 버전의 MD5 기반 비밀번호 알고리즘(apr1)으로 해시된 비밀번호 → Apache HTTP Server의 htpasswd openssl passwd 명령어로 생성 가능
    3. RFC 2307에 설명된 대로 “{scheme}data” 구문으로 지정 → 구현된 스키마에는 PLAIN, SHA(SHA-1 hashing, 추천 X) 및 SSHA(salted SHA-1 hashing, 일부 소프트웨어 패키지, 특히 OpenLDAP 및 Dovecot에서 사용)
 
  • 문맥 : http, server, location, limit_except
  • 사용문법
    ## 기본 설정
    auth_basic_user_file file;

 

'Nginx > Nginx 모듈 학습' 카테고리의 다른 글

ngx_http_v2_module 모듈  (0) 2025.01.18
ngx_http_autoindex_module 모듈  (0) 2024.12.15
ngx_http_dav_module 모듈  (1) 2024.12.11
ngx_http_hls_module 모듈  (0) 2023.09.24
ngx_http_mp4_module 모듈  (0) 2023.09.24
 

Module ngx_http_autoindex_module

Module ngx_http_autoindex_module The ngx_http_autoindex_module module processes requests ending with the slash character (‘/’) and produces a directory listing. Usually a request is passed to the ngx_http_autoindex_module module when the ngx_http_index

nginx.org

 

  • ngx_http_autoindex_module 모듈은 슬래시 문자('/')로 끝나는 요청을 처리하고 디렉토리 목록을 생성
  • 요청은 ngx_http_index_module 모듈이 인덱스 파일을 찾을 수 없을 때, ngx_http_autoindex_module 모듈로 전달

 

autoindex 지시자

  • 디렉터리 목록(listing) 출력을 활성화 또는 비활성화

  • 문맥 : http, server, location
  • 사용 문법
    ## 문법
    create_full_put_path on | off;
  • 사용 예시
    ## 기본 설정
    autoindex on | off;

 

autoindex_exact_size 지시자

  • HTML 형식의 경우 디렉토리 목록에 정확한 파일 크기를 출력할지 아니면 킬로바이트, 메가바이트, 기가바이트로 반올림하여 출력할지 지정

  • 문맥 : http, server, location
  • 사용 문법
    ## 문법
    autoindex_exact_size on | off;
  • 사용 예시
    ## 기본 설정
    autoindex_exact_size on;

 

autoindex_format 지시자

  • 디렉토리 목록의 형식을 설정
  • JSONP 형식이 사용될 때, 콜백 함수(callback function)의 이름은 콜백 요청 인수(callback request argument)로 설정
  • 만약 인수가 없거나 값이 비어 있으면 JSON 형식이 사용
  • XML 출력은 ngx_http_xslt_module 모듈을 사용하여 변환 가능

     
  • 문맥 : http, server, location
  • 사용 문법
    ## 문법
    autoindex_format html | xml | json | jsonp;
  • 사용 예시
    ## 기본 설정
    autoindex_format html;

 

autoindex_localtime 지시자

  • HTML 형식에서는 디렉터리 목록(listing)의 시간이 로컬 시간대( local time zone)또는 UTC로 출력될지 여부를 지정
     
  • 문맥 : http, server, location
  • 사용 문법
    ## 문법
    autoindex_localtime on | off;
 
  • 사용 예시
    ## 기본 설정
    autoindex_localtime off;

 

 

'Nginx > Nginx 모듈 학습' 카테고리의 다른 글

ngx_http_v2_module 모듈  (0) 2025.01.18
ngx_http_auth_basic_module 모듈  (1) 2024.12.15
ngx_http_dav_module 모듈  (1) 2024.12.11
ngx_http_hls_module 모듈  (0) 2023.09.24
ngx_http_mp4_module 모듈  (0) 2023.09.24
 

Module ngx_http_dav_module

Module ngx_http_dav_module The ngx_http_dav_module module is intended for file management automation via the WebDAV protocol. The module processes HTTP and WebDAV methods PUT, DELETE, MKCOL, COPY, and MOVE. This module is not built by default, it should be

nginx.org

 

  • 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 > Nginx 모듈 학습' 카테고리의 다른 글

ngx_http_auth_basic_module 모듈  (1) 2024.12.15
ngx_http_autoindex_module 모듈  (0) 2024.12.15
ngx_http_hls_module 모듈  (0) 2023.09.24
ngx_http_mp4_module 모듈  (0) 2023.09.24
ngx_http_referer_module 모듈  (0) 2023.09.23

Transfer-Encoding 헤더

  • 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에게 알려줌
  • Transfer-Encoding 헤더는 hop-by-hop 헤더로, 리소스 자체가 아닌 두 노드 사이에 메시지를 적용 
  • 다중 노드 연결의 각각의 세그먼트는 Transfer-Encoding의 값을 다르게 사용 가능

    ※ 참고
    • 전체 연결에 있어 데이터를 압축하고자 한다면, Content-Encoding 헤더를 대신 사용하는 것을 추천
    • HEAD 요청에 대한 응답은 GET 요청에 적용될 값을 출력해줌

 

Transfer-Encoding 헤더 지시자

1. chunked

  • Chunked 인코딩 전송방식은 HTTP 1.1에서 사용가능한 스트리밍 데이터 전송 방식
  • 데이터가 일련의 청크(Chunked Message) 내에서 전송
  • Content-Length 헤더는 생략
  • 각 청크의 앞부분에 현재 청크의 길이가 16진수 형태로 오고 그 뒤에는 '\r\n'이 오고 그 다음에 청크 자체가 오며, 그 뒤에는 다시 '\r\n'이 옮
  • 종료 청크는 길이가 0인 것을 제외하면 일반적인 청크와 다르지 않음
  • (비어있을수도 있는) 연속된 엔티티 헤더 필드로 구성된 트레일러(Trailer)가 옮

 

2. compress

  • Lempel-Ziv-Welch (LZW) 알고리즘을 사용하는 형식
  • compress 값의 이름은 알고리즘을 구현한 UNIX compress 프로그램에서 차용된 것
  • compress는 대부분의 UNIX 배포판에서 제외된 압축 프로그램
  • content-encoding에서 compress는 특허 문제로 인해 오늘날 거의 대부분의 브라우저에서 사용되지 않고 있


3. deflate

  • (RFC 1951에 정의된) deflate 압축 알고리즘과 함께 (RFC 1950에서 정의된) zlib 구조체를 사용

 

4. gzip

  • 32비트 CRC를 이용한 Lempel-Ziv coding (LZ77)을 사용하는 형식
  • gzip은 근본적으로 UNIX gzip 프로그램의 형식
  • HTTP/1.1 표준에서 gzip을 content-encoding을 지원하는 서버는 호환성 목적을 위해 x-gzip을 별칭으로 인지할 것을 권고

 

5. identity

  • 압축이나 수정이 없는 정체성 기능을 나타냄 
  • 명시적으로 지정되는 경우를 제외하고 항상 허용 가능한 것으로 간주

 

 

Transfer-Encoding: chunked 헤더 사용 설명

  • Chunked 방식은 전달하려는 컨텐츠의 사이즈가 큰 경우 서버의 처리 지연을 보완할수 있는 방법
  • Transfer-Encoding 헤더는 Chunked 전송방식으로 데이터를 전달하려 할때 주로 사용되는 헤더
  • HTTP 1.1에서는 Content-Length라는 헤더로 전달하고자 하는 컨텐츠의 사이즈 표시 필요
  • 하나의 TCP 커넥션에 여러개의 요청이 가능하기 때문에 클라이언트는 요청마다 전달될 컨텐츠의 데이터 사이즈를 미리 알고 있어야 함 

 

  • Content-Length 헤더로 웹서버에 데이터 처리 과정 → 컨텐츠의 사이즈가 엄청 큰 경우 문제가 발생
    1. 웹서버가 클라이언트의 요청을 받음
    2. 웹서버는 클라이언트에게 전달해 줄 컨텐츠의 사이즈를 먼저 계산 
    3. 계산된 컨텐츠의 전체 사이즈와 함께 데이터를 전달

      ※ 주의
      • 2번 과정에서 컨텐츠의 사이즈가 엄청 큰 경우 문제가 발생 가능
      • 컨텐츠가 큰 경우 전체 사이즈를 계산하는 과정이 오래 걸림 → 클라이언트가 느끼는 지연시간에 반영됨
      • 컨텐츠 사이즈가 큰 경우, 더 효율적인 다른 방식이 필요

 

  • 컨텐츠의 사이즈가 매우 큰 경우 Content-Length 헤더 문제가 발생 가능 → "Chunked" 전송(청크 인코딩; Chunked transfer encoding))
    • Chunked 전송 방식 개념
      • 전체 Chunk를 한번에 주지 않고, Chunked 방식으로 조금씩 조금씩 전송하는 방식
      • 웹서버는 Chunked 방식으로 데이터를 전송하는 경우에는 전체 사이즈를 한번에 계산할 필요가 없음 
      • 보내려는 Chunked만 먼저 클라이언트에게 알리고 데이터를 보냄 → 본문이 동적으로 생성됨에 따라, 서버는 일부를 버퍼에 담은 뒤 한 청크를 크기와 함께 청크 메시지 전송
          
    • Chunked 전송 방식 설명
      • 클라이언트가 이미지를 요청하면, 웹서버는 전체 이미지의 일부분을 전달
      • 전체 이미지의 일부분 사이즈만 알려주면 되기 때문에 전체 사이즈를 계산하지 않아도 됨으로 기존 전송방식의 단점을 극복한 방식
      • 컨텐츠의 마지막 부분을 전송하고 나서는 "0" 을 보내어 데이터가 모두 전송되었음을 알림
      • Chunked 전송방식에는 Content-Length 헤더가 존재하지 않음
         
    • Chunked 방식의 장점
      • 큰 데이터 전송에도 HTTP 연결이 중간에 끊어지지 않게 유지할 수 있음 → HTTP 1.1 연결 유지(Connection: keep-alive, 지속 커넥션)가 활성화
      • Content-Length가 필요 없음 → 크기가 가변적인 데이터 전송에 유리(DB 쿼리 결과를 출력하는 HTML 테이블 / 큰 이미지 등에 사용)
      • 전체 컨텐츠를 생성할 때까지 대기하지 않음
         
    • Chunked 방식을 통해 데이터 전송 과정
      1. Transfer-Encoding: Chunked를 통해 Chunked 전송 방식으로 데이터를 전송할 것을 알림 
      2. Transfer-Encoding: Chunked를 보낸 이후 전송하려는 데이터의 부분적인 사이즈를 16진수로 표시하여 알림
      3. 실제 데이터에 16진수로 표시한 데이터양만큼 보냄 
      4. 위 2~3번 과정을 반복하여 전체 데이터를 전송
      5. 데이터의 마지막 끝부분에 "0" 을 표시하여 데이터 전송이 완료되었음을 알림 
        ### HTTP 응답
        HTTP/1.1 200 OK\r\n
        Content-type: text/plain\r\n
        Transfer-encoding: chunked\r\n
        \r\n
        
        ### 청크 #1
        9\r\n
        HI, Hippo\r\n
        
        ### 청크 #2
        25\r\n
        My name is Hippo. byebye~\r\n
        
        ### 마지막 청크
        0\r\n
        \r\n​
 

 

 

참고 자료 : 분도랑: [HTTP 프로토콜 강좌]#20 HTTP 일반 헤더 II - Transfer-Encoding, Upgrade, Warning, Trailer (withbundo.blogspot.com)

참고 자료 : Transfer-Encoding - HTTP | MDN (mozilla.org)

참고 자료 : 청크 인코딩(Chunked transfer e.. : 네이버블로그 (naver.com)

 

'HTTP > HTTP 헤더' 카테고리의 다른 글

HTTP 프로토콜 Vary 헤더  (0) 2022.06.25
HTTP 프로토콜 server 헤더  (0) 2022.06.25
HTTP 프로토콜 Range 헤더  (0) 2022.06.25
HTTP 프로토콜 Pragma 헤더  (0) 2022.06.25
HTTP 프로토콜 Last-Modified 헤더  (0) 2022.06.25

1. openSSL 사이트에 들어가서 원하는 버전을 다운로드

1.1. 다운로드 경로 : https://www.openssl.org/source/

 

[ Downloads ] - /source/index.html

Downloads The master sources are maintained in our git repository, which is accessible over the network and cloned on GitHub, at https://github.com/openssl/openssl. Bugs and pull patches (issues and pull requests) should be filed on the GitHub repo. Please

www.openssl.org

 

1.2. 원하는 버전에 tar.gz 파일이 다운로드

 

 

2. 다운로드 받은 openssl-X.X.X.tar.gz 파일을 압축 해제(openssl-3.0.13)

## openssl 3.0.13 버전 다운로드
## 형식 tar -xvf openssl-X.X.X.tar.gz
$ tar xvfz openssl-3.0.13.tar.gz

 

 

3. 압축 해체 이후, openssl-X.X.X 폴더 진입(openssl-3.0.13)

## 형식 : cd openssl-X.X.X
$ cd openssl-3.0.13;

 

 

4. openssl-X.X.X 폴더로 진입하여 ls 명령어를 입력, config 실행

4.1. 사용 가능한 패키지들 업데이트 및 필수 패키지 설치

$ sudo apt-get update;
$ sudo apt-get install build-essential -y;​

 

4.2. openssl-X.X.X 폴더 내 ls 명령어 확인

$ ~/openssl-3.0.13# ls
ACKNOWLEDGEMENTS.md  demos        ms                 README-FIPS.md
apps                 doc          NEWS.md            README.md
AUTHORS.md           engines      NOTES-ANDROID.md   README-PROVIDERS.md
build.info           e_os.h       NOTES-DJGPP.md     ssl
CHANGES.md           external     NOTES-NONSTOP.md   SUPPORT.md
config               FAQ.md       NOTES-PERL.md      test
config.com           fuzz         NOTES-UNIX.md      tools
configdata.pm        HACKING.md   NOTES-VALGRIND.md  util
configdata.pm.in     include      NOTES-VMS.md       VERSION.dat
Configurations       INSTALL.md   NOTES-WINDOWS.md   VMS
Configure            LICENSE.txt  os-dep             wycheproof
CONTRIBUTING.md      Makefile     providers
crypto               Makefile.in  README-ENGINES.md

 

4.3. openssl-X.X.X 폴더 내 config 명령어 실행

$ ./config
Configuring OpenSSL version 3.0.13 for target linux-x86_64
Using os-specific seed configuration
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile

**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL.md file first)      ***
***                                                                ***
**********************************************************************

 

 

5. make 명령어를 사용해 소스를 컴파일

5.1. 컴파일(소스파일을 사용자가 실행 가능한 파일로 만들어 주는 과정) 진행(대략 5분 정도 소요)

$ make
...생략...

 

5.2. 컨파일 완료 후 실행 가능한 파일 생성 확인 → 완료 시 아래와 같이 출력

$ make
...생략...
make[1]: Leaving directory '/home/~/openssl-3.0.13'

 

 

6. 실행 가능한 파일 생성 후 설치 진행

$ make install
...생략...
install doc/html/man7/provider-rand.html -> /usr/local/share/doc/openssl/html/man7/provider-rand.html
install doc/html/man7/provider-signature.html -> /usr/local/share/doc/openssl/html/man7/provider-signature.html
install doc/html/man7/provider-storemgmt.html -> /usr/local/share/doc/openssl/html/man7/provider-storemgmt.html
install doc/html/man7/provider.html -> /usr/local/share/doc/openssl/html/man7/provider.html
install doc/html/man7/proxy-certificates.html -> /usr/local/share/doc/openssl/html/man7/proxy-certificates.html
install doc/html/man7/ssl.html -> /usr/local/share/doc/openssl/html/man7/ssl.html
install doc/html/man7/x509.html -> /usr/local/share/doc/openssl/html/man7/x509.html



7. 설치한 openssl 명령어 버전 확인 후 조치

7.1. openssl 명령어 버전 조회 시 에러 메시지 발생

$ openssl version
openssl: /lib/x86_64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.0.9' not found (required by openssl)

 

7.2. 조치 사항

$ echo "/usr/local/lib64" > /etc/ld.so.conf.d/openssl-3-0-13.conf
$ openssl version
OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)

 

 

참고 자료 : [Linux] OpenSSL을 Ubuntu에서 설치하고 업데이트하는 방법 — hyun 공부 학습 공간 (tistory.com)

 

 

  • Ubuntu에서 /etc/resolv.conf 파일이 초기화되는 현상이 발생 → Ubuntu 기본 세팅
  • /etc/resolv.conf 초기화되지 않도록 하기 위해 조치사항

 

1. apt install 패키지 설치를 위해 /etc/resolve.conf에 nameserver 8.8.8.8 추가

$ vi /etc/resolv.conf
...생략...
nameserver 8.8.8.8

 

 

2. resolvconf 패키지 설치

$ apt install resolvconf -y

 

 

3. resolvconf 확인

  • /etc/resolvconf 디렉토리 확인
  • /run/resolveconf/resolv.conf 파일에 소프트링크
    $ ls -al /etc/resolv.conf
    lrwxrwxrwx 1 root root 29 Apr  1 02:44 /etc/resolv.conf -> ../run/resolvconf/resolv.conf​

 

4. head 파일 수정

  • resolve.conf 파일은 위에서부터 읽어들임
  • nameserver 8.8.8.8이 /etc/resolv.conf 파일의 최하단에 위치하면 다른 nameserver 설정의 IP을 먼저 DNS 서버로 사용하고, 위 DNS가 비정상일 경우에 8.8.8.8을 통해 질의함
    $ vi /etc/resolv.conf
    ...생략...
    nameserver 8.8.8.8​

 

5. 서버 재부팅 후 재확인 → 정상적으로 유지 확인

$ vi /etc/resolv.conf
...생략...
nameserver 8.8.8.8​

 

 

참고 자료 : [Solved][Ubuntu18.04] 서버 재부팅시 resolv.conf 초기화되는 문제 해결 :: Devader (tistory.com)

 

  • 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

 

+ Recent posts