NGINX Plus 릴리스 29(R29)가 출시되었음을 기쁘게 알려드립니다. NGINX Open Source를 기반으로 하는 NGINX Plus는 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이를 모두 하나로 제공하는 유일한 솔루션입니다.
NGINX Plus R29의 새로운 기능과 향상된 기능은 다음과 같습니다:
- MQTT 프로토콜 지원– 메시지 큐 텔레메트리 전송(MQTT)은 사물 인터넷(IoT) 기기 간 통신에 사용되는 경량 프로토콜입니다. NGINX Plus R29는 Preread 및 Filter 모듈을 통해 MQTT 프로토콜을 지원합니다. 이러한 모듈에는 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 이후 업데이트되지 않았으므로, pkgs.nginx.com 패키지 리포지토리를 사용하실 것을 강력히 권장합니다. 이 리포지토리는 NGINX Plus R24에서 도입되었습니다.
플랫폼 지원 변경 사항
새롭게 지원되는 운영 체제:
- Amazon Linux 2023
지원이 종료된 이전 운영 체제:
- 2022년 11월 1일에 지원 종료(EOL)된 Alpine 3.13
지원 중단되었으며 NGINX Plus R30에서 제거될 예정인 이전 운영 체제:
- 2023년 6월에 지원이 종료(EOL)되는 Ubuntu 18.04
- 2023년 5월에 지원이 종료되는 Alpine 3.14
ModSecurity 지원 종료 발표에 대응하기
In line with the 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 클라이언트 식별자로 사용하지 않는 것이 좋습니다.
stream { mqtt on;
server {
listen 1883;
proxy_pass 10.0.0.8:1883;
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 메시지의 심층 파싱이 포함될 수 있습니다:
- 추가 인증 및 액세스 제어 메커니즘
- 요청이 지나치게 많은 클라이언트의 요청 속도를 제한하여 브로커 보호
- 메시지 텔레메트리 및 연결 메트릭
여러분이 가장 중요하게 생각하는 기능에 대한 의견을 듣고 싶습니다. 댓글로 여러분의 생각을 알려주세요.
인증 및 권한 부여를 위한 SAML 지원
SAML(Security Assertion Markup Language)은 ID 공급자(IdP)가 리소스에 액세스하려는 사용자를 인증하여 최종 사용자가 실제로 본인이 주장하는 사람인지 확인하고, 해당 인증 정보와 리소스에 대한 사용자의 액세스 권한을 서비스 공급자(SP)에 전달하여 권한을 부여할 수 있도록 하는 개방형 페더레이션 표준입니다.
ID 데이터 교환을 위한 안전한 수단으로 오랫동안 사용되어 온 SAML은 IdP와 SP 간에 인증 및 권한 부여 정보를 교환하는 데 널리 채택된 프로토콜입니다.
기업과 정부 기관이 SAML을 도입하는 주요 이유는 다음과 같습니다:
- 대규모 ID의 효과적인 관리
- 고객과 직원에게 향상되고 일관된 통합 ID 보안 제공
- ID 관리 프로세스 표준화를 통한 운영 효율성 향상
- 규제 준수 요건의 효율적인 관리
SAML은 다음과 같은 여러 이점도 제공합니다:
- 향상된 사용자 경험: SAML은 SSO 통합과 IdP의 단일 인증 확인 지점을 통해 한 번의 인증만으로 연결된 모든 서비스에 액세스할 수 있도록 합니다. 따라서 사용자는 여러 애플리케이션의 다양한 자격 증명을 일일이 기억할 필요가 없어 사용자 경험이 향상되고 시간이 절약됩니다.
- 보안 강화: 조직의 보안 및 인증 정책에 따라 사용자는 SP 인터페이스(SP 시작 SSO) 또는 IdP 인터페이스(IdP 시작 SSO)에서 직접 SSO 인증 방식으로 로그인할 수 있습니다. 이를 통해 취약하거나 반복해서 사용하는 비밀번호로 인해 발생할 수 있는 보안 위험을 줄일 수 있습니다.
- 관리 비용 절감: SAML을 사용하면 조직은 ID 관리 책임을 신뢰할 수 있는 IdP에 위임하여 계정 정보 유지 관리 비용과 관련 지출을 줄일 수 있습니다.
- 표준화된 프로토콜: 보안을 애플리케이션 로직과 최대한 독립적으로 유지한다는 원칙에 따라 설계된 SAML은 거의 모든 IdP와 액세스 관리 시스템에서 지원되는 표준화된 프로토콜입니다. 보안 프레임워크를 플랫폼 아키텍처와 특정 공급업체의 구현 방식으로부터 추상화하여 시스템 간의 강력한 보안과 안정적인 통합을 지원합니다.
현재 SAML 참조 구현은 SAML 2.0을 사용하며 NGINX JavaScript(njs) 프레임워크를 기반으로 구축되었습니다. 이 구현에서 NGINX Plus는 SAML SP 역할을 하므로 SAML IdP를 사용하는 SSO 구성에 참여할 수 있습니다. 또한 현재 구현은 키-값 저장소에 의존합니다. 이는 NGINX Plus의 기존 기능이므로 추가 수정 없이는 NGINX Open Source에 적합하지 않습니다.
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 추적을 적용한 예입니다:
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;
}
}다음 예제에서는 수신 요청의 추적 컨텍스트를 상속하고, 부모 스팬이 샘플링된 경우에만 스팬을 기록합니다. 또한 추적 컨텍스트와 샘플링 결정을 업스트림 서버로 전파합니다.
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 엔드포인트를 통해 키-값 저장소를 조작하여 추적을 활성화합니다:
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;
}
}
}실험용 QUIC+HTTP/3 패키지
NGINX Open Source용 프리뷰 바이너리 패키지 출시 발표에 이어, NGINX Plus R29용 실험적 QUIC 패키지를 발표하게 되어 기쁘게 생각합니다. 이제 NGINX Plus에서 HTTP/3를 테스트하고 평가할 수 있습니다.
새로운 기반 프로토콜 스택을 사용하는 HTTP/3는 전송 계층에 UDP와 QUIC를 도입합니다. QUIC는 연결 다중화를 제공하고 HOL(Head-of-Line) 블로킹과 같은 문제를 해결하여 TCP를 개선하도록 설계된 암호화 전송 프로토콜입니다. 연결 설정, 혼잡 제어, 신뢰성 있는 전송 등 HTTP/1.1 및 HTTP/2에서 사용되는 여러 TCP 기능을 새롭게 구현하고 개선합니다. 또한 TLS를 별도 계층으로 사용하는 HTTP/1.1 및 HTTP/2와 달리, QUIC는 TLS를 핵심 구성 요소로 통합합니다. 따라서 HTTP/3 메시지는 기본적으로 암호화된 연결을 통해 전송되므로 본질적으로 안전합니다.
일반적으로 NGINX Plus는 보안 통신 및 암호화 기능을 위해 운영 체제와 함께 제공되는 SSL/TLS 라이브러리를 활용하는 OpenSSL에 의존합니다. 그러나 이 글을 작성하는 시점에는 OpenSSL이 QUIC의 TLS 인터페이스를 지원하지 않으므로, 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는 구현되지 않았습니다.
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';
}
}
}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는 다운스트림 애플리케이션으로 전송되는 모든 요청에 대해 HTTP Authorization 헤더에 해당 토큰을 Bearer Token으로 전달할 수 있습니다.
참고: NGINX Plus는 각 요청에서 액세스 토큰의 유효성을 확인하지 않으므로(ID 토큰의 경우에는 확인함), 액세스 토큰이 이미 만료되었는지 알 수 없습니다. 액세스 토큰의 수명이 ID 토큰보다 짧은 경우에는 proxy_intercept_errors 지시어를 on으로 설정해야 합니다. 그러면 401 Unauthorized 응답을 가로채 NGINX로 리디렉션하고 액세스 토큰을 갱신합니다.
NGINX Plus를 사용한 OpenID Connect 및 JSON Web Token(JWT) 검증에 대한 자세한 내용은 OpenID Connect 및 NGINX Plus를 사용하여 기존 애플리케이션의 사용자 인증하기를 참조하세요.
OIDC 인증 엔드포인트에 추가된 인수
일부 ID 공급자(예: Keycloak)에서는 추가 기능을 활성화하기 위해 인증 요청에 쿼리 문자열 인수를 추가할 수 있습니다. 예를 들어 Keycloak에서는 인증 요청에 kc_idp_hint 매개변수를 추가하여 기본 IdP를 지정할 수 있습니다. 이번 개선을 통해 사용자는 OIDC 권한 부여 엔드포인트에 추가 인수를 지정할 수 있습니다.
Prometheus-njs 모듈의 확장된 SSL 카운터
NGINX Plus R28에서는 클라이언트 측 및 서버 측 연결을 위한 HTTP 및 Stream 모듈 모두에 핸드셰이크 오류와 인증서 검증 실패에 대한 추가 SSL 카운터 지원을 도입했습니다. NGINX Plus 메트릭을 Prometheus 호환 형식으로 변환하는 Prometheus-njs 모듈에서도 이제 이러한 카운터를 지원합니다.
새로운 internal_redirect 지시어
새로운 internal_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;
}
}
}위 예시에서는 location 블록에서 JWT 인증이 수행되며, 토큰이 유효하면 요청이 내부 콘텐츠 핸들러 @rate_limited로 전달됩니다. 여기서는 sub 클레임 값을 기준으로 요청 속도 제한이 적용됩니다. 이 처리는 요청이 업스트림 서비스로 전달되기 전에 JWT에서 이루어집니다.
이 구성은 공격자가 특정 사용자를 sub 필드로 지정해 인코딩한, 판독 가능한 JWT가 포함된 요청을 대량으로 전송하는 서비스 거부(DoS) 공격을 방지합니다. 이러한 대량 요청은 인증을 통과하지 못하지만 요청 속도 제한에는 포함될 수 있습니다. 요청을 콘텐츠 핸들러로 전달하기 전에 JWT를 인증하면 유효한 요청만 요청 속도 제한에 포함되도록 할 수 있습니다.
NGINX Open Source에서 상속된 변경 사항
NGINX Plus R29는 NGINX Open Source 1.23.4를 기반으로 하며, NGINX Plus R28 출시 이후(NGINX 1.23.3부터 1.23.4까지) 적용된 기능 변경 사항과 버그 수정 사항을 상속합니다.
변경 사항
- The TLSv1.3 프로토콜은 이제 기본적으로 활성화되며 다음 지시문의 기본값으로 사용됩니다:
ssl_protocols(HTTP, 스트림, 메일)proxy_ssl_protocols(HTTP, Stream)grpc_ssl_protocolsuwsgi_ssl_protocolszone_sync_ssl_protocols- 이제 수신 대기 소켓의 프로토콜 매개변수가 재정의되면 NGINX가 경고를 표시합니다.
- 이제 클라이언트가 파이프라이닝을 사용한 경우 NGINX는 lingering 방식으로 연결을 종료합니다.
- data length too long, length too short, bad legacy version, no shared signature algorithms, bad digest length, missing sigalgs extension, encrypted length too long, bad length, bad key update, mixed handshake and non-handshake data, ccs received early, data between ccs and finished, packet length too long, too many warn alerts, record too small 및 got a fin before a ccs SSL 오류의 로깅 수준이 crit에서 info로 낮아졌습니다.
기능
- 이제
ngx_http_gzip_static_module에서 바이트 범위를 지원합니다.
버그 수정
- 작동하지 않던 listen 지시문의 포트 범위 문제를 수정했습니다.
- 구성에서 255자를 초과하는 접두사 location을 사용한 경우 요청을 처리할 잘못된 location이 선택될 수 있는 문제를 수정했습니다.
- Windows의 파일 이름에 포함된 비ASCII 문자가
ngx_http_autoindex_module,ngx_http_dav_module, 그리고 include 지시문에서 지원되지 않던 문제를 수정했습니다. - HTTP/2와
error_page지시어를 사용하여 코드가400인 오류를 리디렉션할 때 간헐적으로 발생하던 소켓 누수를 수정했습니다. - Fixed messages about logging to
syslog오류 로깅에 관한 메시지에 해당 오류가syslog에 로깅하는 동안 발생했다는 정보가 누락되던 문제를 수정했습니다. - proxy -r에서 차단된 클라이언트 읽기 이벤트 처리를 수정했습니다.
- 많은 수의 TLV가 포함된 PROXY 프로토콜 버전 2 헤더를 읽을 때 간혹 발생하던 오류를 수정했습니다.
- 다른 모듈에서 생성된 하위 요청을 SSI로 처리할 때 워커 프로세스에서 간헐적으로 발생하던 세그멘테이션 오류를 수정했습니다.
- 백엔드에 대한 SSL 연결을 사용할 때 버퍼링되지 않은 프록시 처리 중 NGINX가 CPU를 과도하게 점유할 수 있는 문제를 수정했습니다.
해결 방법
zip 필터가 사전 할당된 메모리를 사용하지 못했습니다경고가zlib-ng사용 시 로그에 표시되었습니다.- When a hostname used in the
listen지시어에 사용된 호스트 이름이 여러 주소로 확인되는 경우, 이제 NGINX는 해당 주소 중 중복된 주소를 무시합니다.
이 릴리스에서 상속된 새로운 기능, 변경 사항, 버그 수정 및 해결 방법의 전체 목록은 CHANGES 파일을 참조하세요.
NGINX JavaScript 모듈 변경 사항
NGINX Plus R29에는 NGINX JavaScript(njs) 모듈 버전 0.7.9부터 0.7.12까지의 변경 사항이 반영되었습니다. njs에는 다음을 비롯한 여러 가지 흥미로운 기능이 추가되었습니다:
- 확장된 Fetch API 지원
- 확장된 Web Crypto API
- XML 문서 지원
- XML 문서 파싱
- XML 문서를 수정하기 위한 XMLNode API
- Zlib 모듈 압축 지원
njs 버전 0.7.9부터 0.7.12까지의 모든 기능, 변경 사항 및 버그 수정에 대한 전체 목록은 njs 변경 로그를 참조하세요.
확장된 Fetch API 지원
Headers(), Request(), Response() 생성자가 기타 개선 사항과 함께 Fetch API에 추가되었습니다:
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);
}확장된 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']);
}
njs 0.7.10에는 generateKey() 및 exportKey() 메서드도 추가되었습니다. generateKey() 메서드를 사용하면 대칭 키 알고리즘용 새 키 또는 공개 키 알고리즘용 키 쌍을 생성할 수 있습니다. exportKey() 메서드는 CryptoKey 객체를 입력으로 받아 외부에서 사용할 수 있는 이식 가능한 형식으로 키를 반환합니다. 키를 JSON 객체로 내보내기 위한 JWK 형식을 지원합니다.
자세한 내용은 Web Crypto API를 참조하세요.
XML 문서 지원
XML 문서를 기본적으로 처리할 수 있도록 njs 0.7.10에 XML 모듈이 추가되었습니다.
XML 문서 파싱
이제 문자열이나 버퍼를 XML 문서로 파싱할 수 있으며, 그러면 파싱된 XML 문서를 나타내는 XMLDoc 래퍼 객체가 반환됩니다:
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
XML 문서를 수정하기 위한 XMLNode API가 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>' */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일 무료 평가판으로 시작해 보세요.
관련 블로그 게시물
시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.
F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.
진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.
NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.
Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.