NGINX Plus R29 릴리즈 새로운 기능 살펴보기
NGINX Plus R29 (R29)을 발표하게 되어 기쁩니다. NGINX Plus는 NGINX 오픈소스를 기반으로 한 올인원 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API Gateway입니다.
NGINX Plus R29의 새로운 기능 및 향상된 기능은 다음과 같습니다.
- MQTT 프로토콜 지원 – MQTT(Message Queuing Telemetry Transport)는 사물 인터넷(IoT)의 장치 간 통신에 사용되는 경량 프로토콜입니다. NGINX Plus R29는 MQTT 프로토콜을 Preread 및 Filter 모듈과 함께 지원하며, MQTT 트래픽을 관리하고 보안하는 데 도움이 되는 여러 개의 새로운 지시문과 변수를 도입합니다.
- 인증 및 권한 부여를 위한 SAML 지원 – SAML(Security Assertion Markup Language)은 웹 애플리케이션에 대한 단일 로그인(SSO)을 제공하는 잘 알려진 프로토콜입니다. NGINX Plus는 이제 SAML 서비스 제공자(SP)로 구성될 수 있어 SAML 신원 제공자(IdP)에 대해 사용자를 인증할 수 있습니다.
- Native 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 트래픽을 관리하기 위한 다양한 새로운 지시문을 지원합니다.
목차
1. NGINX Plus R29 의 중요한 변화
1-1. NGINX Plus R29 부터 패키징 저장소 변경
1-2. 플랫폼 지원 변경
1-3. ModSecurity 지원 종료
2. NGINX Plus R29 새로운 기능 살펴보기
2-1. MQTT 프로토콜 지원
2-1-1. MQTT 예시
2-2. 인증 및 승인을 위한 SAML 지원
2-2-1. SAML이 제공하는 이점
2-3. Native OpenTelemetry
2-3-1. OTel Tracing 예시
2-4. 실험적인 QUIC+HTTP/3 패키지
2-4-1. QUIC+HTTP/3 예시
3. NGINX Plus R29 의 기타 개선 사항
3-1. OpenID Connect의 변경 사항
3-2. Prometeus-njs 모듈의 확장 SSL 카운터
3-3. NGINX Plus R29 새 internal_redirect 지시문
3-4. NGINX 오픈소스에서 상속된 변경 사항
3-5. NGINX JavaScript 모듈의 변경 사항
3-6. Zlib 모듈 압축 지원
4. 업그레이드 또는 NGINX Plus 사용해보기
1. NGINX Plus R29 의 중요한 변화
1-1. NGINX Plus R29 부터 패키징 저장소 변경
NGINX Plus R29 버전의 출시와 함께 이전의 패키지 저장소인 plus-pkgs.nginx.com은 즉시 폐기되었습니다. 이 저장소는 NGINX Plus R25 이후로 업데이트되지 않았으며, pkgs.nginx.com 패키지 저장소를 사용하는 것이 강력히 권장됩니다.
1-2. 플랫폼 지원 변경
지원되는 새로운 운영 체제는 다음과 같습니다.
- Amazon Linux 2023
제거된 이전 운영 체제는 다음과 같습니다.
- Alpine 3.13은 2022년 11월 1일에 지원 종료 (EOL)되었습니다.
NGINX Plus R30에서 제거 예정인 이전 운영 체제는 다음과 같습니다.
- Ubuntu 18.04는 2023년 6월에 지원 종료 (EOL)될 예정입니다.
- Alpine 3.14는 2023년 5월에 지원 종료 (EOL)될 예정입니다.
1-3. ModSecurity 지원 종료
ModSecurity의 EOL 발표에 따라, NGINX Plus R29에서는 ModSecurity 패키지의 지원이 제거됩니다. ModSecurity 패키지를 사용하는 NGINX Plus 고객이라면 곧 ModSecurity와 NGINX App Protect 간의 교환 프로그램에 참여할 수 있게 될 것입니다. 이에 대한 자세한 내용은 곧 제공될 예정이며, 자세한 정보를 얻기 위해 NGINX STORE의 담당자에게 문의하실 수 있습니다.
2. NGINX Plus R29 새로운 기능 살펴보기
2-1. MQTT 프로토콜 지원
MQTT (Message Queuing Telemetry Transport)는 인터넷을 통해 IoT 장치와 애플리케이션(클라이언트)을 연결하는 데 이상적인 인기있고 가벼운 publish-subscribe 메시징 프로토콜입니다. 이 프로토콜은 클라이언트가 특정 주제에 메시지를 발행하고 다른 주제에 대해 구독할 수 있도록 합니다. 구독한 클라이언트는 해당 주제에 발행된 모든 메시지를 수신하여 많은 장치와 서비스 간의 효율적이고 장애 허용성 있는 데이터 교환을 가능하게 합니다.
QTT 아키텍처의 핵심은 브로커입니다. 브로커는 클라이언트와 그들이 구독한 주제를 추적하고 메시지를 처리하며 해당 메시지를 적절한 시스템으로 라우팅하는 서버입니다. NGINX Plus R29 은 MQTT 3.1.1 및 MQTT 5.0을 지원합니다. 이는 클라이언트와 브로커 사이에서 프록시 역할을 하여 시스템 아키텍처를 단순화하고 작업을 분산 시키며 비용을 절감합니다.
초기 MQTT 기능 세트는 다음을 가능하게 합니다.
- MQTT 브로커 로드 밸런싱
- 세션 지속성 (클라이언트를 동일한 브로커에 다시 연결)
- TLS Termination
- 클라이언트 인증서 인증
- CONNECT 메시지 파싱 및 재작성
MQTT 프로토콜은 CONNECT, PUBLISH 및 SUBSCRIBE를 포함한 여러 메시지 유형을 정의합니다. NGINX Plus R29는 MQTT CONNECT 메시지의 일부를 Active parsing하고 Rewrite하여 이전에 사용자 정의 스크립트로만 가능했던 구성 시나리오를 가능하게 합니다.
MQTT 메시지 파싱 및 재작성은 NGINX 구성 파일의 Stream 컨텍스트에서 정의되어야 하며, ngx_stream_mqtt_preread_module 및 ngx_stream_mqtt_filter_module 모듈을 사용하여 가능합니다.
2-1-1. MQTT 예시
MQTT 장치가 보내는 기본 클라이언트 식별자를 수정하면 NGINX가 장치의 일련 번호와 같은 민감한 정보를 숨길 수 있습니다. 첫 번째 예제에서는 식별자가 장치의 IP 주소로 재작성됩니다.
참고: MQTT 클라이언트 식별자로 장치의 IP 주소를 사용하는 것은 운영 환경에서 권장되지 않습니다.
stream {
mqtt on;
server {
listen 1883;
proxy_pass 10.0.0.8:1883;
mqtt_rewrite_buffer_size 16k;
mqtt_set_connect clientid '$remote_addr';
}
}MQTT 클라이언트의 일시적인 특성을 고려하면, 로드 밸런싱된 브로커에 대한 지속적인 연결을 설정하기 위해 단순히 장치의 호스트 이름이나 IP 주소에 의존할 수 없습니다.
이 예시에서는 장치의 MQTT 클라이언트 식별자가 로드 밸런싱된 클러스터 내 개별 MQTT 브로커에 대한 연결을 유지하기 위한 해시 키로 작동합니다.
stream {
mqtt_preread on;
upstream brokers{
zone tcp_mem 64k;
hash $mqtt_preread_clientid consistent;
server 10.0.0.7:1883; # mqtt broker 1
server 10.0.0.8:1883; # mqtt broker 2
server 10.0.0.9:1883; # mqtt broker 3
}
server {
listen 1883;
proxy_pass brokers;
proxy_connect_timeout 1s;
}
}NGINX Plus에서 MQTT에 대한 미래 개발 사항에는 다른 MQTT 메시지 유형의 파싱 및 CONNECT 메시지의 깊은 파싱을 통한 다음과 같은 기능이 포함될 수 있습니다.
- 추가 인증 및 액세스 제어 메커니즘
- 활발한 클라이언트의 속도 제한을 통한 브로커 보호
- 메시지 원격 분석 및 연결 메트릭
2-2. 인증 및 승인을 위한 SAML 지원
SAML (Security Assertion Markup Language)은 신원 제공자 (IdP, Identity Providers)가 사용자를 인증하여 리소스에 대한 액세스를 허용하고 (최종 사용자가 자신이 주장하는 대로 실제로 누구인지 확인) 해당 인증 정보와 사용자의 리소스에 대한 액세스 권한을 서비스 제공자 (SP)에게 전달하는 오픈 페더레이션 표준입니다.
신원 데이터를 안전하게 교환하는 데 오랜 역사를 가진 SAML은 IdP와 SP 간에 인증 및 권한 부여 정보를 교환하기 위한 널리 사용되는 프로토콜입니다.
기업 및 정부 기관이 SAML을 채택하는 주요 이유는 다음과 같습니다.
- 대량의 신원을 효과적으로 관리할 수 있음
- 고객 및 직원에게 향상된, 일관된 및 통합된 신원 보안 제공
- 신원 관리 프로세스를 표준화하여 운영 효율성 향상
- 규정 준수를 효율적으로 처리함
2-2-1. SAML이 제공하는 이점
또한 SAML은 다음과 같은 여러 이점을 제공합니다.
- 더 나은 사용자 경험: SAML은 SSO 통합과 IdP에서의 단일 인증 검증을 통해 사용자가 모든 연결된 서비스에 액세스하는 데 사용하는 단일 인증을 제공합니다. 이는 사용자 경험을 향상시키고 시간을 절약할 수 있으며, 사용자는 더 이상 다양한 애플리케이션에 대한 여러 자격 증명을 기억할 필요가 없습니다.
- 보안 강화: 조직의 보안 및 인증 정책에 따라 사용자는 SP 인터페이스 (SP-initiated SSO) 또는 IdP 인터페이스 (IdP-initiated SSO)에서 SSO 인증 체계를 사용하여 로그인할 수 있습니다. 이는 취약한 암호 및 반복되는 암호로 인한 보안 위험을 줄입니다.
- 관리 비용 절감: SAML은 조직이 신뢰할 수 있는 IdP에게 신원 관리 책임을 할당하여 계정 정보 유지 및 관련 비용을 줄이는 데 도움을 줍니다.
- 표준화된 프로토콜: SAML은 보안을 애플리케이션 논리와 독립적으로 만드는 원칙으로 설계된 표준화된 프로토콜입니다. 거의 모든 IdP 및 액세스 관리 시스템에서 지원되며, 플랫폼 아키텍처 및 특정 공급업체 구현에서 보안 프레임워크를 추상화하여 시스템 간의 견고한 보안 및 신뢰할 수 있는 통합을 가능하게 합니다.
현재 SAML의 참조 구현은 SAML 2.0을 사용하며 NGINX JavaScript (njs) 프레임워크를 사용하여 구축되었습니다. 이 구현에서 NGINX Plus는 SAML SP로 작동하여 SAML IdP와의 SSO 설정에 참여할 수 있습니다. 현재 구현은 Key-value 저장소에 의존하며, 이는 기존의 NGINX Plus 기능이므로 추가 수정 없이는 NGINX 오픈소스에는 적합하지 않습니다.
NGINX Plus에서의 SAML 지원은 GitHub의 참조 구현으로 제공됩니다. GitHub 저장소에는 특정 사용 사례에 대한 설치, 구성 및 세부 조정 지침이 포함된 샘플 구성이 포함되어 있습니다.
2-3. Native OpenTelemetry
OpenTelemetry (OTel)은 애플리케이션의 모니터링, 추적, 문제 해결 및 최적화에 사용할 수 있는 기술과 표준입니다.
OTel은 프록시, 애플리케이션 또는 배포된 애플리케이션 스택의 다른 서비스와 같은 다양한 소스에서 Telemetry 데이터를 수집하여 작동합니다.
프로토콜을 인식하는 리버스 프록시 및 로드 밸런서로서, NGINX는 애플리케이션 요청 및 응답의 추적을 위한 Telemetry 호출을 시작하기에 이상적으로 위치해 있습니다. 일부 제 3자 OTel 모듈은 이전부터 사용 가능했지만, 새로운 동적 모듈을 통해 NGINX Plus에서 OTel을 Native로 지원하는 것을 자랑스럽게 발표하게 되었습니다.
새로운 ngx_otel_module 모듈은 nginx-plus-module-otel 패키지를 사용하여 설치할 수 있으며, 다음과 같은 몇 가지 주요 개선 사항을 제공합니다.
- 더 나은 성능 – 대부분의 OTel 구현은 추적이 활성화되면 요청 처리 성능을 최대 50%까지 감소시킵니다. 우리의 새로운 네이티브 모듈은 이 영향을 약 10-15%로 제한합니다.
- 쉬운 Provisioning – 텔레메트리 수집의 설정 및 구성은 NGINX 구성 파일에서 직접 수행할 수 있습니다.
- Full-Dynamic 변수 기반 샘플링 – 쿠키/토큰별로 특정 세션을 추적하고 NGINX Plus API 및 Key-value 저장소 모듈을 통해 모듈을 동적으로 제어할 수 있는 기능을 제공합니다.
2-3-1. OTel Tracing 예시
다음은 NGINX를 통해 직접 제공되는 애플리케이션의 기본 OTel 추적 예시입니다.
load_module modules/ngx_otel_module.so;
events {}
http {
otel_exporter {
endpoint localhost:4317;
}
server {
listen 127.0.0.1:8080;
otel_trace on;
otel_span_name app1;
}
}다음 예시에서는 들어오는 요청으로부터 추적 컨텍스트를 상속받고, 부모 span이 샘플링된 경우에만 span을 기록합니다. 또한 추적 Context와 샘플링 결정을 Upstream 서버로 전파합니다.
load_module modules/ngx_otel_module.so;
http {
server {
location / {
otel_trace $otel_parent_sampled;
otel_trace_context propagate;
proxy_pass http://backend;
}
}
}이 비율 기반 예제에서는 추적이 트래픽의 일부분에 대해 구성되었습니다 (이 경우 10%입니다).
http {
# trace 10% of requests
split_clients "$otel_trace_id" $ratio_sampler {
10% on;
* off;
}
# or we can trace 10% of user sessions
split_clients "$cookie_sessionid" $session_sampler {
10% on;
* off;
}
server {
location / {
otel_trace $ratio_sampler;
otel_trace_context inject;
proxy_pass http://backend;
}
}
}이 API 제어 예제에서는 /api 엔드포인트를 통해 Key-value 저장소를 조작하여 추적을 활성화합니다.
http {
keyval "otel.trace" $trace_switch zone=name;
server {
location / {
otel_trace $trace_switch;
otel_trace_context inject;
proxy_pass http://backend;
}
location /api {
api write=on;
}
}
}2-4. NGINX Plus R29 의 실험적인 QUIC+HTTP/3 패키지
NGINX 오픈소스용 Preview binary 패키지 발표에 이어, NGINX는 NGINX Plus R29 용 실험적인 QUIC 패키지를 발표하게 되어 기쁩니다. 이를 통해 NGINX Plus에서 HTTP/3를 테스트하고 평가할 수 있습니다.
새로운 기본 프로토콜 스택을 통해 HTTP/3은 UDP 및 QUIC를 전송 계층으로 가져옵니다. QUIC는 연결 다중화를 제공하고 HOL 차단과 같은 문제를 해결하여 TCP를 개선하도록 설계된 암호화된 전송 프로토콜입니다. HTTP/1.1 및 HTTP/2의 여러 TCP 기능(연결 설정, 정체 제어 및 안정적인 전달 포함)을 다시 구현하고 향상시킵니다.
또한 QUIC은 TLS를 별도의 레이어로 사용하는 HTTP/1.1 및 HTTP/2와 달리 TLS를 통합 구성 요소로 통합합니다. 즉, HTTP/3 메시지는 기본적으로 암호화된 연결을 통해 전송되므로 본질적으로 안전합니다.
일반적으로 안전한 통신과 암호화 기능을 위해 NGINX Plus는 운영 체제와 함께 제공되는 SSL/TLS 라이브러리를 사용하는 OpenSSL에 의존합니다. 그러나 현재 QUIC의 TLS 인터페이스는 OpenSSL에서 지원되지 않기 때문에, HTTP/3에서 필요한 누락된 TLS 기능을 제공하기 위해 타사 라이브러리가 필요합니다.
이 문제를 해결하기 위해 우리는 QUIC용 OpenSSL 호환성 레이어를 개발했습니다. 이를 통해 quictls, BoringSSL 및 LibreSSL과 같은 타사 TLS 라이브러리를 빌드하고 제공할 필요가 없습니다. 이는 사용자 정의 TLS 구현의 부담이나 타사 라이브러리의 일정 및 로드맵에 대한 의존성 없이 NGINX에서 엔드 투 엔드 QUIC+HTTP/3 경험을 관리하는 데 도움이 됩니다.
참고: OpenSSL 호환성 레이어는 실험적인 NGINX Plus QUIC+HTTP/3 패키지에 포함되어 있으며, QUIC 프로토콜에서 필요한 TLSv1.3을 제공하기 위해 OpenSSL 1.1.1 이상이 필요합니다. 아직 0-RTT를 구현하지는 않았습니다.
2-4-1. 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 logs/access.log quic;
server {
# for better compatibility it's recommended
# to use the same port for quic and https
listen 8443 quic reuseport;
listen 8443 ssl;
ssl_certificate certs/example.com.crt;
ssl_certificate_key certs/example.com.key;
location / {
# required for browsers to direct them into quic port
add_header Alt-Svc 'h3=":8443"; ma=86400';
}
}
}NGINX Plus가 프록시로 작동할 때 HTTP/2를 구현한 것과 유사하게, QUIC+HTTP/3 연결은 클라이언트 측에서 이루어지고 Backend 서버 및 업스트림 서비스에 연결할 때 HTTP/1.1로 변환됩니다.
NGINX Plus QUIC+HTTP/3 실험적인 패키지는 별도의 저장소에서 사용 가능하며, 기존의 NGINX Plus 인증서와 키로 액세스할 수 있습니다. 실험적인 QUIC 패키지의 설치는 표준 NGINX Plus 설치와 유사합니다. 설치 단계에서 강조된 대로 QUIC 저장소를 사용하도록 주의하십시오.
QUIC+HTTP/3를 구성하는 방법에 대한 자세한 내용은 “NGINX QUIC+HTTP/3 구현에 사용 가능한 패키지“를 참조하십시오.
가까운 미래에 우리는 QUIC+HTTP/3 코드를 NGINX Main branch에 통합할 계획입니다.
QUIC+HTTP/3 지원이 포함된 최신 버전의 NGINX Mainline은 이후의 NGINX Plus 릴리스에 통합될 것입니다.
NGINX Plus에서 QUIC+HTTP/3 지원이 공식적으로 제공될 예정이며, 이에 대한 공지는 추후 이루어질 것입니다.
3. NGINX Plus R29 의 기타 개선 사항
3-1. OpenID Connect의 변경 사항
OpenID Connect (OIDC) 지원은 NGINX Plus R15에서 도입되었으며, 이후 버전에서 크게 향상되었습니다. NGINX Plus R29에서는 OIDC를 계속해서 향상시키고 있으며, 다음과 같은 추가 기능이 있습니다.
액세스 토큰 지원
액세스 토큰은 토큰 기반 인증에서 사용되며, OIDC 클라이언트가 사용자를 대신하여 보호된 리소스에 액세스할 수 있도록 합니다. 사용자가 성공적으로 인증 및 액세스 권한을 부여한 후, NGINX Plus는 액세스 토큰을 받아서 Key-value 저장소에 저장합니다. NGINX Plus는 해당 토큰을 HTTP Authorization 헤더의 Bearer Token으로 전달하여 Downstream 애플리케이션에 보내지는 모든 요청에 대해 사용할 수 있습니다.
참고: NGINX Plus는 각 요청마다 액세스 토큰의 유효성을 확인하지 않으며 (ID 토큰과는 다르게), 액세스 토큰이 이미 만료되었는지 여부를 알 수 없습니다. 액세스 토큰의 수명이 ID 토큰보다 짧은 경우, proxy_intercept_errors on 지시문을 사용해야 합니다. 이렇게 하면 401 Unauthorized 응답을 NGINX로 가져오고 Redirect하여 액세스 토큰을 새로 고칠 수 있습니다.
NGINX Plus에서 OpenID Connect 및 JSON Web Token (JWT) 유효성 검사에 대한 자세한 정보는 “OpenID Connect 및 NGINX Plus를 사용하여 앱 인증하기“을 참조하십시오.
OIDC 인증 Endpoint에 추가된 인수
Keycloak과 같은 일부 ID 공급자는 추가 기능을 사용하도록 인증 요청에 추가 쿼리 문자열 인수를 추가할 수 있습니다. 예를 들어 Keyclock을 사용하면 kc_idp_hint 매개 변수를 인증 요청에 추가하여 기본 IdP를 지정할 수 있습니다. 이 향상된 기능의 일부로 사용자는 OIDC 권한 부여 Endpoint에 추가 인수를 지정할 수 있습니다.
3-2. Prometeus-njs 모듈의 확장 SSL 카운터
NGINX Plus R28에서는 HTTP 및 Stream 모듈의 클라이언트 및 서버 연결에 대한 handshake 오류 및 인증서 유효성 검증 실패에 대한 추가 SSL 카운터 지원이 추가되었습니다.
NGINX Plus 메트릭을 Prometheus 호환 형식으로 변환하는 Prometheus-njs 모듈은 이제 이러한 카운터를 지원합니다.
3-3. NGINX Plus R29 새 internal_redirect 지시문
새로운 internal_redirect Directive 및 모듈은 요청 처리 제한, 연결 처리 제한 및 액세스 제한을 확인한 후 내부 Redirect를 허용합니다.
다음은 internal_redirect 구성의 예입니다.
http {
limit_req_zone $jwt_claim_sub zone=jwt_sub:10m rate=1r/s;
server {
location / {
auth_jwt "realm";
auth_jwt_key_file key.jwk;
internal_redirect @rate_limited;
}
location @rate_limited {
internal;
limit_req zone=jwt_sub burst=10;
proxy_pass http://backend;
}
}
}위의 예제에서는 JWT 인증이 위치 블록에서 수행되며, 토큰이 유효한 경우 요청이 내부 콘텐츠 핸들러 @rate_limited로 전달되어 sub 클레임 값에 기반한 요청 Rate limit이 적용됩니다. 이는 요청이 Upstream 서비스로 전달되기 전에 JWT에서 발생합니다.
이 특정 구성은 공격자가 하위 필드로 특정 사용자로 인코딩된 읽을 수 있는 JWT가 포함된 대량의 요청을 보내는 서비스 거부(DoS) 공격을 방지합니다. 이러한 대량 요청은 인증을 통과하지 못하지만 Rate limit에 포함됩니다. 요청을 콘텐츠 핸들러에 전달하기 전에 JWT를 인증하면 유효한 요청만 Rate limit에 포함되도록 할 수 있습니다.
3-4. NGINX 오픈소스에서 상속된 변경 사항
NGINX Plus R29는 NGINX 오픈소스 1.23.4를 기반으로 하며 NGINX Plus R28이 출시된 이후(NGINX 1.23.3에서 1.23.4까지) 기능 변경 사항 및 버그 수정 사항을 상속합니다.
변경사항
- TLSv1.3 프로토콜이 이제 기본적으로 활성화되며 다음 지시문의 기본값으로 설정됩니다.
- ssl_protocols (HTTP, Stream, Mail)
- proxy_ssl_protocols (HTTP, Stream)
- grpc_ssl_protocols
- uwsgi_ssl_protocols
- zone_sync_ssl_protocols
- NGINX는 이제 수신 소켓의 프로토콜 매개변수가 재정의되는 경우 경고 메시지를 출력합니다.
- 이제 NGINX는 클라이언트에서 파이프라인을 사용한 경우 연결을 대기 상태로 닫습니다.
- 데이터 길이가 너무 길거나 너무 짧은 경우, 잘못된 레거시 버전, 공유 서명 알고리즘이 없는 경우, 잘못된 다이제스트 길이, sigalgs 확장이 누락된 경우, 암호화된 길이가 너무 긴 경우, 잘못된 길이, 잘못된 키 업데이트, 혼합된 핸드셰이크 및 비-핸드셰이크 데이터, ccs가 일찍 수신된 경우, ccs와 finished 사이의 데이터, 패킷 길이가 너무 긴 경우, 경고 알림이 너무 많은 경우, 레코드가 너무 작은 경우, ccs 이전에 fin을 받은 경우에 대한 SSL 오류의 로깅 레벨이 crit에서 info로 낮아졌습니다.
기능
- ngx_http_gzip_static_module에서 바이트 범위가 이제 지원됩니다.
버그 수정
- 동작하지 않았던 listen 지시문의 포트 범위가 수정되었습니다.
- 구성에서 255자보다 긴 접두사 위치가 사용된 경우 잘못된 위치가 선택될 수 있는 문제가 수정되었습니다.
- Windows에서 ngx_http_autoindex_module, ngx_http_dav_module 및 include 지시문에서 지원되지 않았던 파일 이름에 비 ASCII 문자가 수정되었습니다.
- HTTP/2를 사용하고 error_page 지시문을 사용하여 코드 400의 오류를 Redirect하는 경우에 가끔씩 발생하는 소켓 누수가 수정되었습니다.
- syslog에 로깅하는 동안 발생한 오류에 대한 정보가 포함되지 않았던 syslog 오류에 대한 메시지가 수정되었습니다.
- proxy -r에서 차단된 클라이언트 읽기 이벤트 처리가 수정되었습니다.
- 많은 수의 TLV가 있는 PROXY 프로토콜 버전 2 Header를 읽을 때 가끔 발생하는 오류를 수정했습니다.
- 다른 모듈에서 생성된 하위 요청을 처리하는 데 SSI를 사용한 경우 작업자 프로세스에서 때때로 발생하는 세그먼트 오류를 수정했습니다
- 백엔드에 대한 SSL 연결이 사용된 경우 버퍼링 되지 않은 프록시 중에 잠재적으로 NGINX가 CPU를 독차지하는 문제를 수정했습니다.
해결 방법
- zip 필터가 zlib-ng을 사용할 때 로그에 표시되는 미리 할당된 메모리 경고를 사용하지 못했습니다.
- 수신 지시에 사용된 호스트 이름이 여러 주소로 확인되면 NGINX는 이제 이러한 주소 내의 중복을 무시합니다.
3-5. NGINX JavaScript 모듈의 변경 사항
NGINX Plus R29는 NGINX JavaScript (njs) 모듈 버전 0.7.9에서 0.7.12까지의 변경 사항을 포함하고 있습니다. njs에는 몇 가지 흥미로운 기능이 추가되었습니다.
- 확장된 Fetch API 지원
- 확장된 Web Crypto API
- XML 문서 지원
- XML 문서 parsing
- XML 문서 수정을 위한 XMLNode API
- Zlib 모듈 압축 지원
3-5-1. 확장된 Fetch API 지원
Fetch API에는 Headers(), Request(), 및 Response() 객체가 추가되었으며, 다른 개선 사항도 있습니다.
async function makeRequest(uri, headers) {
let h = new Headers(headers);
h.delete("bar");
h.append("foo", "xxx");
let r = new Request(uri, {headers: h});
return await ngx.fetch(r);
}3-5-2. 확장된 Web Crypto API
Web Crypto API는 JSON Web Key (JWK) 형식을 지원하도록 확장되었으며, importKey()는 이제 JWK 형식의 키를 입력으로 받습니다.
async function importSigningJWK(jwk) {
return await crypto.subtle.importKey('jwk', jwk,
{name: "RSASSA-PKCS1-v1_5"},
true, ['sign']);
}3-5-3. XML 문서 지원
XML 모듈은 njs 0.7.10에 추가되어 XML 문서 작업에 대한 기본 지원을 제공합니다.
3-5-4. XML 문서 parsing
이제 문자열이나 버퍼를 XML 문서로 파싱할 수 있으며, 이후 파싱된 XML 문서를 나타내는 XMLDoc wrapper 객체를 반환합니다.
const xml = require("xml");
let data = `<note><to b="bar" a= "foo">Tove</to><from>Jani</from></note>`;
let doc = xml.parse(data);
console.log(doc.note.to.$text) /* 'Tove' */
console.log(doc.note.to.$attr$b) /* 'bar' */
console.log(doc.note.$tags[1].$text) /* 'Jani' */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');
delete doc.$root.to.$attr$a;
console.log(xml.serializeToString(doc.$root.to))
/* '<to b="bar2" c="baz">Tove</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.$tags = [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>' */3-6. Zlib 모듈 압축 지원
zlib 모듈은 njs 0.7.12에 추가되었으며 deflate 및 inflate 알고리즘을 사용하여 압축 기능을 제공합니다.
Const zlib = require('zlib');
zlib.deflateRawSync('αβγ').toString('base64')
/* "O7fx3KzzmwE=" */
zlib.inflateRawSync(Buffer.from('O7fx3KzzmwE=', 'base64')).toString()
/* "αβγ" */4. 업그레이드 또는 NGINX Plus 사용해보기
NGINX Plus를 사용 중이라면, 가능한 빠른 시일 내에 NGINX Plus R29로 업그레이드하는 것을 강력히 권장합니다. 새로운 기능들 뿐만 아니라 여러 가지 추가적인 수정과 개선 사항도 함께 제공되며, 최신 버전을 사용하면 기술 지원이 필요할 때에 NGINX STORE가 도움을 드릴 수 있습니다.
NGINX Plus를 아직 사용해보지 않았다면, 보안, 로드 밸런싱, API Gateway 또는 강화된 모니터링 및 관리 API를 갖춘 완전히 지원되는 웹 서버로서 시도해보기를 권장합니다. 30일 무료 평가판으로 오늘부터 시작해보세요.
아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.
