블로그 | NGINX

NGINX Plus R29 발표

NGINX-F5-수평-검정-유형-RGB의 일부
프라바트 딕시트 썸네일
프라바트 딕시트
2023년 5월 2일 게시
마이클 베르닉 썸네일
마이클 베르닉
2023년 5월 2일 게시

NGINX Plus 릴리스 29(R29) 출시 소식을 알려드리게 되어 기쁩니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R29의 새롭고 향상된 기능은 다음과 같습니다.

  • MQTT 프로토콜 지원 – MQTT(Message Queuing Telemetry Transport)는 사물 인터넷(IoT)에서 장치 간 통신에 사용되는 경량 프로토콜입니다. NGINX Plus R29는 MQTT 트래픽을 관리하고 보호하는 데 도움이 되는 여러 가지 새로운 지침과 변수를 도입하는 Preread 및 Filter 모듈을 통해 MQTT 프로토콜을 지원합니다.
  • 인증 및 권한 부여를 위한 SAML 지원 – SAML(Security Assertion Markup Language)은 웹 애플리케이션에 SSO(Single Sign-On)를 제공하는 확립된 프로토콜입니다. 이제 NGINX Plus를 SAML 서비스 공급자(SP)로 구성하여 SAML ID 공급자(IdP)를 통해 사용자를 인증할 수 있습니다.
  • 네이티브 OpenTelemetry – OpenTelemetry(OTel)는 공급업체에 구애받지 않는 방식으로 원격 소스에서 원격 측정 데이터(추적, 메트릭, 로그)를 생성, 수집, 내보내는 프레임워크입니다. 새로운 NGINX OTel 동적 모듈은 NGINX Plus HTTP 요청 추적을 위한 고성능 OTel 구현을 제공합니다.
  • 실험적 QUIC+HTTP/3 패키지 – QUIC+HTTP/3를 탑재한 NGINX Plus R29의 미리보기 패키지가 출시되었습니다. NGINX Plus R29 QUIC 패키지는 HttpContext에 대한 지원과 QUIC 연결과 HTTP/3 트래픽을 관리하기 위한 다양한 새로운 지침을 제공합니다.

행동의 중요한 변화

메모 : NGINX Plus R28이 아닌 다른 릴리스에서 업그레이드하는 경우, 현재 버전과 이 버전 사이의 모든 릴리스에 대한 이전 발표 블로그 의 중요한 동작 변경 사항 섹션을 확인하세요.

패키징 저장소 변경

이전 패키지 저장소인 plus-pkgs.nginx.com은 NGINX Plus R29가 출시됨에 따라 즉시 사용이 중단됩니다. 이 저장소는 NGINX Plus R25 이후로 업데이트되지 않았으며 NGINX Plus R24에서 도입된 pkgs.nginx.com 패키지 저장소를 사용하는 것이 좋습니다.

플랫폼 지원 변경

지원되는 새로운 운영 체제:

  • 아마존 리눅스 2023

제거된 이전 운영 체제:

  • 2022년 11월 1일 EOL(End-Of-Life)에 도달한 Alpine 3.13

NGINX Plus R30에서 더 이상 지원되지 않고 제거 예정인 이전 운영 체제:

  • 2023년 6월에 EOL에 도달하는 Ubuntu 18.04
  • 2023년 5월 EOL에 도달하는 Alpine 3.14

ModSecurity 수명 종료 발표에 적응하기

ModSecurity EOL 발표 에 따라 NGINX Plus R29에서는 ModSecurity 패키지에 대한 지원이 중단됩니다. ModSecurity 패키지를 사용하는 NGINX Plus 고객인 경우 곧 ModSecurity와 NGINX App Protect 간의 트레이드인 프로그램에 참여할 수 있게 됩니다. 자세한 내용은 곧 공개될 예정이며, 자세한 내용을 알고 싶으시면 F5 담당자에게 문의하세요.

새로운 기능에 대한 자세한 정보

MQTT 프로토콜 지원

MQTT(Message Queuing Telemetry Transport)는 널리 사용되는 가벼운 게시-구독 메시징 프로토콜로, 인터넷을 통해 IoT 기기와 애플리케이션(클라이언트)을 연결하는 데 이상적입니다. 이를 통해 클라이언트는 특정 주제에 메시지를 게시하고 다른 주제를 구독할 수 있습니다. 구독한 클라이언트는 해당 주제에 게시된 모든 메시지를 수신하여 다양한 장치와 서비스 간에 효율적이고 장애 방지적인 데이터 교환이 가능해집니다.

MQTT 아키텍처의 핵심은 브로커입니다. 브로커는 클라이언트와 클라이언트가 구독한 모든 주제를 추적하고, 메시지를 처리하고, 해당 메시지를 적절한 시스템으로 라우팅하는 역할을 하는 서버입니다. NGINX Plus R29는 MQTT 3.1.1 및 MQTT 5.0을 지원합니다. 이는 클라이언트와 브로커 사이의 프록시 역할을 하여 시스템 아키텍처를 단순화하고, 작업 부담을 덜어주고, 비용을 절감합니다.

초기 MQTT 기능 세트는 다음을 가능하게 합니다.

  • MQTT 브로커 로드 밸런싱
  • 세션 지속성(클라이언트를 동일한 브로커에 다시 연결)
  • TLS 종료
  • 클라이언트 인증서 인증
  • CONNECT 메시지 구문 분석 및 다시 쓰기

MQTT 프로토콜은 CONNECT, PUBLISH, SUBSCRIBE를 포함한 여러 메시지 유형을 정의합니다. NGINX Plus R29는 MQTT CONNECT 메시지의 일부를 적극적으로 구문 분석하고 다시 쓸 수 있어 이전에는 사용자 지정 스크립트로만 가능했던 구성 시나리오를 지원합니다.

MQTT 메시지 구문 분석 및 재작성은 NGINX 구성 파일의 Stream 컨텍스트에서 정의되어야 하며 ngx_stream_mqtt_preread_module 을 통해 가능해집니다.
및 ngx_stream_mqtt_filter_module 모듈.

MQTT 예제

MQTT 장치에서 보낸 기본 클라이언트 식별자를 수정하면 NGINX에서 장치의 일련 번호와 같은 중요한 정보를 숨길 수 있습니다. 첫 번째 예에서 식별자는 장치의 IP 주소로 다시 작성됩니다.

메모: 프로덕션 환경에서는 장치의 IP 주소를 MQTT 클라이언트 식별자로 사용하는 것이 권장되지 않습니다. 

스트림 { mqtt 켜짐;
 서버 { 수신 1883; proxy_pass 10.0.0.8:1883; mqtt_set_connect 클라이언트 ID '$remote_addr'; } }

MQTT 클라이언트의 일시적인 특성을 감안할 때 단순히 장치의 호스트 이름이나 IP 주소에만 의존하여 로드 밸런싱 브로커에 대한 스티키 세션을 설정할 수 없습니다. 이 예에서 장치의 MQTT 클라이언트 식별자는 부하 분산 클러스터의 개별 MQTT 브로커에 대한 연결을 유지하기 위한 해시 키 역할을 합니다. 

스트림 { mqtt_preread 켜짐;
 상류 브로커{ zone tcp_mem 64k; 해시 $mqtt_preread_clientid 일관성 있음;
 서버 10.0.0.7:1883; # mqtt 브로커 1 서버 10.0.0.8:1883; # mqtt 브로커 2 서버 10.0.0.9:1883; # mqtt 브로커 3 }
 서버 { 청취 1883; proxy_pass 브로커; proxy_connect_timeout 1초; } }

다음 단계

NGINX Plus에서 MQTT에 대한 향후 개발에는 다른 MQTT 메시지 유형의 구문 분석과 다음과 같은 기능을 활성화하기 위한 CONNECT 메시지의 심층 구문 분석이 포함될 수 있습니다.

  • 추가 인증 및 액세스 제어 메커니즘
  • "채팅" 클라이언트의 요금을 제한하여 브로커 보호
  • 메시지 원격 측정 및 연결 메트릭

여러분에게 가장 중요한 기능에 대한 피드백을 들려주시기 바랍니다. 여러분의 의견을 댓글로 알려주세요.

인증 및 권한 부여를 위한 SAML 지원

SAML(Security Assertion Markup Language)은 ID 공급자(IdP)가 리소스에 액세스하기 위해 사용자를 인증하고(최종 사용자가 실제로 주장하는 사람인지 확인) 해당 인증 정보와 해당 리소스에 대한 사용자 액세스 권한을 승인을 위해 서비스 공급자(SP)에게 전달할 수 있도록 하는 개방형 페더레이션 표준입니다.

SAML은 신원 데이터를 교환하는 안전한 수단을 제공한 오랜 역사를 가지고 있으며, IdP와 SP 간에 인증 및 권한 부여 정보를 교환하는 데 널리 채택된 프로토콜입니다.

기업과 정부 기관이 SAML을 채택하기로 선택하는 주요 이유는 다음과 같습니다.

  • 대량의 ID를 효과적으로 관리합니다.
  • 고객과 직원에게 강화되고 일관되고 통합된 ID 보안 제공
  • ID 관리 프로세스 표준화를 통해 운영 효율성 향상
  • 규정 준수의 효율적인 처리

 
SAML은 또한 다음과 같은 여러 가지 이점을 제공합니다.

  • 더 나은 사용자 경험 : SAML은 SSO 통합과 IdP의 단일 인증 검증 지점을 통해 사용자가 연결된 모든 서비스에 액세스할 수 있는 단일 인증을 사용할 수 있도록 해줍니다. 이를 통해 사용자는 다양한 애플리케이션에 대한 여러 자격 증명을 기억할 필요가 없으므로 사용자 경험이 향상되고 시간이 절약됩니다.
  • 보안 강화 : 조직의 보안 및 인증 정책에 따라 사용자는 SP 인터페이스(SP에서 시작한 SSO) 또는 IdP 인터페이스에서 직접(IdP에서 시작한 SSO) SSO 인증 체계를 사용하여 로그인할 수 있습니다. 이렇게 하면 비밀번호가 약하거나 반복되는 경우 발생할 수 있는 보안 위험을 줄일 수 있습니다.
  • 관리 비용 절감 : SAML은 조직이 신뢰할 수 있는 IdP에 ID 관리 책임을 전가하여 계정 정보 유지 관리 비용과 관련 경비를 줄이는 데 도움이 됩니다.
  • 표준화된 프로토콜 : SAML은 보안을 가능한 한 애플리케이션 로직에 의존하지 않도록 하는 원칙에 따라 설계된 표준화된 프로토콜로, 거의 모든 IdP와 액세스 관리 시스템에서 지원됩니다. 이는 플랫폼 아키텍처와 특정 공급업체 구현으로부터 보안 프레임워크를 추상화하여 강력한 보안과 시스템 간의 안정적인 통합을 구현합니다.

SAML의 현재 참조 구현은 SAML 2.0을 사용하며 NGINX JavaScript (njs) 프레임워크를 사용하여 구축되었습니다. 이 구현에서 NGINX Plus는 SAML SP 역할을 하여 SAML IdP와 함께 SSO 설정에 참여할 수 있습니다. 현재 구현은 키-값 저장소 에 따라 달라지는데, 이는 기존 NGINX Plus 기능이므로 추가 수정 없이는 NGINX 오픈 소스에 적합하지 않습니다.

NGINX Plus의 SAML 지원은 GitHub에서 참조 구현으로 제공됩니다. GitHub 저장소 에는 특정 사용 사례에 대한 설치, 구성 및 미세 조정에 대한 지침이 포함된 샘플 구성이 포함되어 있습니다.

네이티브 OpenTelemetry

OpenTelemetry(OTel)는 애플리케이션 모니터링, 추적, 문제 해결 및 최적화에 사용할 수 있는 기술 및 표준입니다. OTel은 배포된 애플리케이션 스택의 프록시, 애플리케이션 또는 기타 서비스와 같은 다양한 소스에서 원격 측정 데이터를 수집하여 작동합니다.

프로토콜 인식 역방향 프록시 및 부하 분산 장치인 NGINX는 애플리케이션 요청과 응답을 추적하기 위한 원격 측정 호출을 시작하는 데 이상적인 위치에 있습니다. 타사 OTel 모듈은 꽤 오랫동안 제공되었지만, 새로운 동적 모듈 을 통해 NGINX Plus에서 OTel을 기본적으로 지원한다는 소식을 전해드리게 되어 기쁩니다.

새로운 모듈 ngx_otel_module은 nginx-plus-module-otel 패키지를 사용하여 설치할 수 있으며 다음을 포함하여 타사 모듈에 대한 여러 가지 주요 개선 사항을 제공합니다.

  • 더 나은 성능 – 대부분의 OTel 구현은 추적이 활성화된 경우 요청 처리 성능을 최대 50%까지 낮춥니다. 우리의 새로운 네이티브 모듈은 이런 영향을 10-15% 정도로 제한합니다.
  • 간편한 프로비저닝 – 원격 측정 수집을 설정하고 구성하는 작업은 NGINX 구성 파일에서 바로 수행할 수 있습니다.
  • 완전 동적 변수 기반 샘플링 - 쿠키/토큰을 사용하여 특정 세션을 추적하는 기능 NGINX Plus API 와 키-값 저장 모듈을 통해 모듈을 동적으로 제어합니다.

OTel 동적 모듈에 대한 자세한 내용은 NGINX 설명서 에서 확인할 수 있습니다.

OTel 추적 예

다음은 NGINX에서 직접 제공하는 애플리케이션의 기본 OTel 추적 예입니다.

로드_모듈 모듈/ngx_otel_module.so;
 이벤트 {}
 http { 호텔_수출자 { 엔드포인트 로컬호스트:4317; }
 서버 { 수신 127.0.0.1:8080;
 otel_trace 켜기;        otel_span_name app1;    } }

다음 예제에서는 부모 스팬이 샘플링된 경우에만 들어오는 요청과 레코드 스팬에서 추적 컨텍스트를 상속합니다. 또한 추적 컨텍스트와 샘플링 결정을 업스트림 서버로 전파합니다. 

로드_모듈 모듈/ngx_otel_module.so;
 http { 서버 { 위치 / { otel_trace $otel_parent_sampled; otel_trace_context 전파; proxy_pass http://backend; } } }

이 비율 기반 예에서 추적은 트래픽의 일정 비율(이 경우 10%)에 대해 구성됩니다.

http { # 요청의 10% 추적 split_clients "$otel_trace_id" $ratio_sampler { 10% 켜짐; * 꺼짐; }
 # 또는 사용자 세션의 10%를 추적할 수도 있습니다.
 split_clients "$cookie_sessionid" $session_sampler { 10% 할인; * 할인; }
 서버 { 위치 / { otel_trace $ratio_sampler; otel_trace_context 주입;
 프록시_패스 http://백엔드; } } }

이 API 제어 예제에서는 /api 엔드포인트를 통해 키-값 저장소를 조작하여 추적이 활성화됩니다.

http { keyval "otel.trace" $trace_switch 영역=이름;
 서버 { 위치 / { otel_trace $trace_switch; otel_trace_context 주입; proxy_pass http://backend; }
 위치 /api { api write=on; } } }

실험적 QUIC+HTTP/3 패키지

NGINX 오픈 소스를 위한 프리뷰 바이너리 패키지 발표 에 이어, NGINX Plus R29를 위한 실험적 QUIC 패키지를 발표하게 되어 기쁩니다. 이를 통해 NGINX Plus로 HTTP/3를 테스트하고 평가할 수 있습니다.

새로운 기본 프로토콜 스택을 통해 HTTP/3는 UDP와 QUIC를 전송 계층에 적용합니다. QUIC는 연결 다중화를 제공하고 HOL(Head-of-Line) 차단과 같은 문제를 해결함으로써 TCP를 개선하도록 설계된 암호화된 전송 프로토콜입니다. HTTP/1.1 및 HTTP/2의 여러 TCP 기능(연결 설정, 혼잡 제어, 안정적인 전달 등)을 다시 구현하고 향상시킵니다. QUIC은 TLS를 필수 구성 요소로 통합하는 반면, HTTP/1.1 및 HTTP/2는 TLS를 별도 계층으로 포함합니다. 즉, HTTP/3 메시지는 기본적으로 암호화된 연결을 통해 전송되므로 본질적으로 안전합니다.

일반적으로 보안 통신과 암호화 기능을 위해 NGINX Plus는 OpenSSL을 사용하고 운영 체제와 함께 제공되는 SSL/TLS 라이브러리를 활용합니다. 그러나 이 글을 쓰는 시점에서 QUIC의 TLS 인터페이스는 OpenSSL에서 지원되지 않으므로 HTTP/3에 필요한 누락된 TLS 기능을 제공하기 위해 타사 라이브러리가 필요합니다.

이러한 문제를 해결하기 위해 우리는 QUIC용 OpenSSL 호환성 계층을 개발해 quictls, BoringSSL, LibreSSL과 같은 타사 TLS 라이브러리를 빌드하고 제공할 필요성을 제거했습니다. 이를 통해 사용자 정의 TLS 구현이나 타사 라이브러리의 일정 및 로드맵에 대한 종속성 없이 NGINX에서 종단 간 QUIC+HTTP/3 환경을 관리할 수 있습니다.

메모 : OpenSSL 호환성 계층은 실험적 NGINX Plus QUIC+HTTP/3 패키지에 포함되어 있으며 TLSv1.3 (QUIC 프로토콜에 필요함)을 제공하기 위해 OpenSSL 1.1.1 이상이 필요합니다. 아직 0-RTT가 구현되지 않았습니다.

QUIC+HTTP/3 샘플 구성

NGINX Plus에서 QUIC+HTTP/3의 샘플 구성을 살펴보겠습니다.

http { log_format quic '$remote_addr - $remote_user [$time_local]' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$http3"';
 access_log 로그/access.log quic;
 server { # 더 나은 호환성을 위해 quic과 https에 동일한 포트를 사용하는 것이 좋습니다. listen 8443 quic reuseport; listen 8443 ssl;
 ssl_certificate 인증서/example.com.crt; ssl_certificate_key 인증서/example.com.key;
 location / { # 브라우저가 quic port로 직접 연결하도록 하는 데 필요 add_header Alt-Svc 'h3=":8443"; ma=86400'; } } }

HTTP/2 구현 과 유사하게 NGINX Plus가 프록시 역할을 하는 경우 클라이언트 측에서 QUIC+HTTP/3 연결이 이루어지고 백엔드 및 업스트림 서비스에 연결될 때 HTTP/1.1로 변환됩니다.

NGINX Plus QUIC+HTTP/3 실험 패키지는 기존 NGINX Plus 인증서와 키로 접근할 수 있는 별도의 저장소에서 제공됩니다. 실험적 QUIC 패키지를 설치하는 방법은 표준 NGINX Plus 설치 와 비슷합니다. 설치 단계에서 강조된 대로 QUIC 저장소를 사용하세요.

NGINX를 QUIC+HTTP/3에 맞게 구성하는 방법 에 대한 자세한 내용은 QUIC+HTTP/3에 맞게 NGINX 구성을 참조하세요. 모든 새로운 지침과 변수에 대한 자세한 내용은 nginx-quic README 의 구성 섹션을 참조하세요.

다음 단계

가까운 미래에 QUIC+HTTP/3 코드를 NGINX 메인라인 브랜치에 병합할 계획입니다. QUIC+HTTP/3를 지원하는 NGINX 메인라인의 최신 버전은 다음 NGINX Plus 릴리스에 병합될 예정입니다. 올해 말에 NGINX Plus에서 QUIC+HTTP/3를 공식적으로 지원한다는 발표가 있을 것으로 예상됩니다.

NGINX Plus R29의 기타 개선 사항

OpenID Connect에 대한 변경 사항

OpenID Connect(OIDC) 지원은 NGINX Plus R15에서 도입되었으며 이후 버전에서 크게 향상되었습니다. NGINX Plus R29는 다음과 같은 추가 기능을 통해 OIDC를 지속적으로 향상시킵니다.

액세스 토큰 지원

액세스 토큰은 토큰 기반 인증에서 사용되어 OIDC 클라이언트가 사용자를 대신하여 보호된 리소스에 액세스할 수 있도록 합니다. NGINX Plus는 사용자가 성공적으로 인증하고 액세스를 승인하면 액세스 토큰을 수신한 다음 이를 키-값 저장소에 저장합니다. NGINX Plus는 다운스트림 애플리케이션에 전송되는 모든 요청에 대한 Bearer 토큰 으로 HTTP 인증 헤더에 해당 토큰을 전달할 수 있습니다.

메모 : NGINX Plus는 각 요청에 대해 액세스 토큰의 유효성을 확인하지 않으며(ID 토큰의 경우와 다름) 액세스 토큰이 이미 만료되었는지 알 수 없습니다. 액세스 토큰의 수명이 ID 토큰의 수명보다 짧은 경우, 지시문에서 proxy_intercept_errors를 사용해야 합니다. 이렇게 하면 NGINX에 대한 401 Unauthorized 응답을 가로채서 리디렉션하고 액세스 토큰을 새로 고칩니다.

NGINX Plus를 사용한 OpenID Connect 및 JSON 웹 토큰(JWT) 검증에 대한 자세한 내용은 OpenID Connect 및 NGINX Plus를 사용하여 기존 애플리케이션에 대한 사용자 인증을 참조하세요.

OIDC 인증 엔드포인트에 인수 추가

Keycloak 과 같은 일부 ID 공급자는 추가 기능을 활성화하기 위해 인증 요청에 추가 쿼리 문자열 인수를 추가하는 것을 허용합니다. 예를 들어, Keycloak을 사용하면 인증 요청에 kc_idp_hint 매개변수를 추가하여 기본 IdP를 지정할 수 있습니다. 이 향상된 기능의 일부로 사용자는 OIDC 인증 엔드포인트에 추가 인수를 지정할 수 있습니다.

Prometheus-njs 모듈의 확장된 SSL 카운터

NGINX Plus R28에서는 클라이언트 측과 서버 측 연결에 대한 HTTP와 스트림 모듈 모두에서 핸드셰이크 오류와 인증서 검증 실패에 대한 추가적인 SSL 카운터 지원을 추가했습니다. NGINX Plus 메트릭을 Prometheus 호환 형식으로 변환하는 Prometheus-njs 모듈이 이제 이러한 카운터를 지원합니다.

새로운 internal_redirect 지시문

새로운 internal_redirect 지시문과 모듈은 요청 처리 제한, 연결 처리 제한 및 액세스 제한을 확인한 후 내부 리디렉션을 허용합니다.

다음은 internal_redirect 구성의 예입니다. 

http { limit_req_zone $jwt_claim_sub zone=jwt_sub:10m 요금=1r/s;
 서버 { 위치 / { auth_jwt "영역"; auth_jwt_키_파일 key.jwk;
 내부 리다이렉션 @rate_limited; }
 위치 @rate_limited { 내부; 제한_요청 영역=jwt_sub 버스트=10;
 프록시_패스 http://백엔드 ; } } }

위의 예에서 JWT 인증은 위치 블록에서 수행되고 토큰이 유효한 경우 요청은 내부 콘텐츠 핸들러 @rate_limited로 전달됩니다. 여기서 하위 클레임 값에 따라 요청 속도 제한이 적용됩니다. 이 작업은 요청이 업스트림 서비스로 전달되기 전에 JWT에서 발생합니다.

이 특정 구성은 공격자가 특정 사용자를 하위 필드로 인코딩한 읽을 수 있는 JWT가 포함된 대량의 요청을 보내는 서비스 거부(DoS) 공격을 방지합니다. 그러한 요청 홍수는 인증을 통과하지 못하지만 속도 제한에는 포함됩니다. 콘텐츠 핸들러에 요청을 전달하기 전에 JWT를 인증하면 유효한 요청만 속도 제한에 포함되도록 할 수 있습니다.

NGINX 오픈 소스에서 상속된 변경 사항

NGINX Plus R29는 NGINX Open Source 1.23.4를 기반으로 하며 NGINX Plus R28이 출시된 이후(NGINX 1.23.3~1.23.4) 기능 변경 사항과 버그 수정을 계승했습니다.

변화

  • TLSv1.3 프로토콜은 이제 기본적으로 활성화되어 있으며 다음 지침의 기본값입니다.
  • 이제 NGINX는 수신 소켓의 프로토콜 매개변수가 다시 정의되는 경우 경고를 표시합니다.
  • 이제 NGINX는 클라이언트에서 파이프라인을 사용한 경우 지연된 연결을 닫습니다.
  • 데이터 길이가 너무 길거나, 길이가 너무 짧거나, 레거시 버전이 잘못되었거나, 공유 서명 알고리즘이 없거나, 다이제스트 길이가 잘못되었거나, sigalgs 확장자가 없거나, 암호화된 길이가 너무 길거나, 길이가 잘못되었거나, 키 업데이트가 잘못되었거나, 핸드셰이크와 비핸드셰이크 데이터가 혼합되었거나, CCS가 일찍 수신되었거나, CCS와 완료 간의 데이터이거나, 패킷 길이가 너무 길거나, 경고 알림이 너무 많거나, 레코드가 너무 작거나, CCS SSL 오류가 발생하기 전에 fin을 받았다는 로깅 수준이 crit에서 info로 낮아졌습니다.

특징

  • 이제 ngx_http_gzip_static_module 에서 바이트 범위가 지원됩니다.

버그 수정

  • 작동하지 않는 listen 지시어의 고정 포트 범위를 수정했습니다.
  • 구성에서 255자를 넘는 접두사 위치가 사용된 경우 요청을 처리할 때 잘못된 위치가 선택될 수 있는 문제를 해결했습니다.
  • Windows에서 파일 이름에 사용되는 ASCII가 아닌 문자가 ngx_http_autoindex_module , ngx_http_dav_module 및 include 지시문에서 지원되지 않는 문제를 수정했습니다.
  • HTTP/2와 error_page 지시문을 사용하여 코드로 오류를 리디렉션할 때 가끔 발생하는 소켓 누수를 수정했습니다.400 .
  • syslog 에 로깅하는 동안 오류가 발생했다는 정보가 포함되지 않은 syslog 오류에 대한 고정 메시지를 수정했습니다.
  • proxy -r에서 차단된 클라이언트 읽기 이벤트의 고정 처리를 수정했습니다.
  • TLV 수가 많은 PROXY 프로토콜 버전 2 헤더를 읽을 때 가끔 발생하는 오류를 수정했습니다.
  • SSI가 다른 모듈에서 생성된 하위 요청을 처리하는 데 사용된 경우 작업자 프로세스에서 가끔 발생하는 세그먼테이션 오류를 수정했습니다.
  • 백엔드에 SSL 연결을 사용하는 경우 버퍼링되지 않은 프록싱 중에 NGINX가 CPU를 독점할 가능성이 있는 문제를 수정했습니다.

해결 방법

  • zlib-ng를 사용할 때 zip 필터가 미리 할당된 메모리 경고를 사용하지 못했다는 내용 이 로그에 나타났습니다.
  • listen 지시어에서 사용된 호스트 이름이 여러 주소로 확인되는 경우, NGINX는 이제 이러한 주소 내의 중복을 무시합니다.

이번 릴리스에서 상속받은 새로운 기능, 변경 사항, 버그 수정 및 해결 방법의 전체 목록을 보려면 CHANGES 파일을 참조하세요.

NGINX JavaScript 모듈의 변경 사항

NGINX Plus R29는 NGINX JavaScript(njs) 모듈 버전 0.7.9부터 0.7.12까지의 변경 사항을 통합합니다. njs에는 다음과 같은 몇 가지 흥미로운 기능이 추가되었습니다.

  • 확장된 Fetch API 지원
  • 확장된 웹 암호화 API
  • XML 문서 지원
  • XML 문서 파싱
  • XML 문서를 수정하기 위한 XMLNode API
  • Zlib 모듈 압축 지원

njs 버전 0.7.9부터 0.7.12까지의 모든 기능, 변경 사항 및 버그 수정의 포괄적인 목록은 njs 변경 로그를 참조하세요.

확장된 Fetch API 지원

Headers() , Request() , Response() 생성자가 Fetch API에 추가되었으며, 기타 개선 사항도 추가되었습니다.

비동기 함수 makeRequest(uri, 헤더) {     let h = new Headers(헤더);
    h.delete("bar");
    h.append("foo", "xxx");
    let r = new Request(uri, {헤더: h});
    return await ngx.fetch(r);
}

확장된 웹 암호화 API

Web Crypto API는 JSON Web Key(JWK) 형식을 지원하도록 확장되었으며 이제 importKey()는 JWK 형식의 키를 입력으로 받습니다.

비동기 함수 importSigningJWK(jwk) {    return await crypto.subtle.importKey('jwk', jwk,
                                          {name: "RSASSA-PKCS1-v1_5"},
                                       참, ['sign']);
}

njs 0.7.10에는 generateKey() 및 exportKey() 메서드도 추가되었습니다. generateKey() 메서드를 사용하면 대칭 알고리즘에 대한 새 키 또는 공개 키 알고리즘에 대한 키 쌍을 생성할 수 있습니다. exportKey() 메서드는 CryptoKey 객체를 입력으로 받아서 외부의 이식 가능한 형식으로 키를 반환합니다. 키를 JSON 객체로 내보내기 위해 JWK 형식을 지원합니다.

자세한 내용은 Web Crypto API를 참조하세요.

XML 문서 지원

XML 모듈은 XML 문서 작업에 대한 기본 지원을 제공하기 위해 njs 0.7.10에 추가되었습니다.

XML 문서 파싱

이제 XML 문서의 문자열이나 버퍼를 구문 분석할 수 있으며, 구문 분석된 XML 문서를 나타내는 XMLDoc 래퍼 개체가 반환됩니다.

const xml = require("xml"); let data = `<note><to b="bar" a= "foo">토브</to><from>자니</from></note>`;
let doc = xml.parse(데이터);
   

  console.log(doc.note.to.$text) /* '토브' */
console.log(doc.note.to.$attr$b) /* '바' */
console.log(doc.note.$tags[1].$text) /* '자니' */

XML 문서를 수정하기 위한 XMLNode API

XMLNode API는 XML 문서를 수정하기 위해 njs 0.7.11에 추가되었습니다.

Const xml = require("xml"); let data = `<note><to b="bar" a="foo">Tove</to><from>Jani</from></note>`;
let doc = xml.parse(data);
   

  doc.$root.to.$attr$b = 'bar2';
doc.$root.to.setAttribute('c', 'baz');
doc.$root.to.$attr$a 삭제;
   

  console.log(xml.serializeToString(doc.$root.to))
/* '<to b="bar2" c="baz">토브</to>' */
   

  doc.$root.to.removeAllAttributes();
doc.$root.from.$text = 'Jani2';
   

  console.log(xml.serializeToString(doc))
/* '<note><to>Tove</to><from>Jani2</from></note>' */
   

  doc.$root.to.$태그 = [xml.parse(`<a/>`), xml.parse(`<b/>`)];
doc.$root.to.addChild(xml.parse(`<a/>`));

  console.log(xml.serializeToString(doc.$root.to))
/* '<to><a></a><b></b><a></a></to>' */
   

  doc.$root.to.removeChildren('a');
   

  console.log(xml.serializeToString(doc.$root.to))
/* '<to><b></b></to>' */

모든 XML 관련 개선 사항에 대한 자세한 내용은 XML 문서를 참조하세요.

Zlib 모듈 압축 지원

zlib 모듈은 njs 0.7.12에 추가되었으며 deflate 및 inflate 알고리즘을 사용하여 압축 기능을 제공합니다. 

Const zlib = require('zlib'); zlib.deflateRawSync('αβγ').toString('base64') /* "O7fx3KzzmwE=" */
 zlib.inflateRawSync(Buffer.from('O7fx3KzzmwE=', 'base64')).toString() /* "αβγ" */

zlib에 대한 자세한 내용은 zlib 문서 를 참조하세요.

업그레이드 또는 NGINX Plus를 사용해 보세요

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R29로 업그레이드하는 것을 적극 권장합니다. 모든 훌륭한 새로운 기능 외에도 여러 가지 추가 수정 사항과 개선 사항을 얻을 수 있으며, 최신 상태를 유지하면 지원 티켓을 제출해야 할 경우 NGINX에서 도움을 드릴 수 있습니다.

NGINX Plus를 사용해보지 않으셨다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용해보시기 바랍니다. 오늘 무료 30일 체험판을 시작해 보세요.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."