NGINX Plus 릴리스 29(R29)의 출시를 발표하게 되어 기쁘게 생각합니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R29의 새롭고 향상된 기능은 다음과 같습니다:
- MQTT 프로토콜 지원- 메시지 큐 원격 측정 전송(MQTT)은 사물 인터넷(IoT)에서 장치 간 통신에 사용되는 경량 프로토콜입니다. NGINX Plus R29는 여러 새로운 지시어와 변수를 도입하여 MQTT 트래픽을 관리하고 보호하는 데 도움이 되는 Preread 및 Filter 모듈을 통해 MQTT 프로토콜을 지원합니다.
- 인증 및 권한 부여를 위한 SAML 지원 - SAML(보안 어설션 마크업 언어)은 웹 애플리케이션에 싱글 사인온(SSO)을 제공하는 잘 정립된 프로토콜입니다. 이제 NGINX Plus를 SAML 서비스 공급자(SP)로 구성하여 SAML ID 공급자(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 트래픽을 관리합니다.
동작의 중요한 변경 사항
주: NGINX Plus R28 이외의 릴리스에서 업그레이드하는 경우, 현재 버전과 이 버전 사이의 모든 릴리스에 대해 이전 공지 블로그의 동작의 중요한 변경 사항 섹션을 확인하세요.
패키지 리포지토리 변경
이전 패키지 리포지토리 plus-pkgs.nginx.com는 NGINX Plus R29의 출시와 함께 즉시 폐기됩니다. 이 리포지토리는 NGINX Plus R25 이후 업데이트되지 않았으며, NGINX Plus R24에 도입된 pkgs.nginx.com 패키지 리포지토리를 사용할 것을 강력히 권장합니다.
플랫폼 지원 변경 사항
새로운 운영 체제가 지원됩니다:
이전 운영 체제가 제거됩니다:
- 2022년 11월 1일에 지원 종료(EOL)에 도달한 Alpine 3.13
구형 운영 체제는 더 이상 사용되지 않으며 NGINX Plus R30에서 제거될 예정입니다:
- Ubuntu 18.04(2023년 6월에 EOL)
- 2023년 5월에 EOL이 도래하는 Alpine 3.14
ModSecurity 수명 종료 발표에 적응하기
ModSecurity EOL 발표에 따라 NGINX Plus R29는 ModSecurity 패키지에 대한 지원을 제거합니다. ModSecurity 패키지를 사용하는 NGINX Plus 고객인 경우, 곧 ModSecurity와 NGINX App Protect 간의 보상 판매 프로그램을 선택할 수 있게 될 것입니다. 이에 대한 자세한 내용은 곧 제공될 예정이며 자세한 내용은 F5 담당자에게 문의하실 수 있습니다.
새로운 기능 상세 정보
MQTT 프로토콜 지원
MQTT(메시지 큐 텔레메트리 전송)는 대중적이고 가벼운 게시-구독 메시징 프로토콜로, 인터넷을 통해 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;
}
}
다음 단계
향후에는 다른 MQTT 메시지 유형에 대한 구문 분석과 CONNECT 메시지의 심층 구문 분석을 통해 다음과 같은 기능을 사용할 수 있도록 NGINX Plus에서 MQTT를 개발할 예정입니다:
- 추가 인증 및 액세스 제어 메커니즘
- "채팅이 많은" 클라이언트의 속도를 제한하여 브로커 보호하기
- 메시지 텔레메트리 및 연결 지표
가장 중요한 기능에 대한 여러분의 의견을 듣고 싶습니다. 댓글로 여러분의 의견을 알려주세요.
인증 및 권한 부여를 위한 SAML 지원
SAML(보안 어설션 마크업 언어)은 ID 공급자(IdP)가 리소스에 대한 액세스를 위해 사용자를 인증하고(최종 사용자가 실제로 자신이 주장하는 사람인지 확인), 해당 인증 정보와 함께 해당 리소스에 대한 사용자의 액세스 권한을 서비스 공급자(SP)에게 전달하여 권한을 부여할 수 있도록 하는 개방형 페더레이션 표준입니다.
신원 데이터를 교환하는 안전한 수단을 제공해온 오랜 역사를 가진 SAML은 IdP와 SP 간의 인증 및 권한 부여 정보 교환을 위해 널리 채택된 프로토콜입니다.
기업과 정부 기관이 SAML을 채택하는 주요 이유는 다음과 같습니다:
- 대량의 ID를 효과적으로 관리하기
- 고객과 직원에 대한 일관되고 향상된 통합 ID 보안 제공
- ID 관리 프로세스 표준화를 통한 운영 효율성 향상
- 효율적인 규정 준수 처리
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 오픈 소스용 프리뷰 바이너리 패키지를 발표한 데 이어, 이번에는 NGINX Plus R29용 실험용 QUIC 패키지를 발표하게 되어 기쁘게 생각합니다. 이를 통해 NGINX Plus로 HTTP/3을 테스트하고 평가할 수 있습니다.
새로운 기본 프로토콜 스택을 통해 HTTP/3는 UDP와 QUIC을 전송 계층으로 가져옵니다. QUIC은 연결 멀티플렉싱을 제공하고 헤드 오브 라인 차단과 같은 문제를 해결함으로써 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 플러스 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 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 리포지토리를 사용해야 합니다.
QUIC+HTTP/3용 NGINX를 구성하는 방법에 대한 자세한 내용은 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는 다운스트림 애플리케이션으로 전송되는 모든 요청에 대해 해당 토큰을 HTTP 권한 부여 헤더에 Bearer Token으로 전달할 수 있습니다.
주: NGINX Plus는 ID 토큰과 마찬가지로 각 요청에 대해 액세스 토큰의 유효성을 확인하지 않으며 액세스 토큰이 이미 만료되었는지 여부를 알 수 없습니다. 액세스 토큰의 수명이 ID 토큰의 수명보다 짧은 경우, proxy_intercept_errors 지시어를 사용해야 합니다. 이렇게 하면 401 권한 없음 응답을 가로채서 NGINX로 리디렉션하고 액세스 토큰을 새로 고칩니다.
NGINX Plus를 사용한 OpenID Connect 및 JWT(JSON 웹 토큰) 유효성 검사에 대한 자세한 내용은 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 지시어와 모듈은 request 처리 제한, connection 처리 제한 및 access 제한을 확인한 후 내부 리디렉션을 허용합니다.
Here is an example internal_redirect configuration:
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로 전달되어 하위 클레임 값에 따라 요청 속도 제한이 적용됩니다. 이는 요청이 업스트림 서비스로 전달되기 전에 JWT에서 발생합니다.
이 특정 구성은 공격자가 특정 사용자를 하위 필드로 인코딩하여 읽기 가능한 JWT를 포함하는 요청을 대량으로 전송하는 서비스 거부(DoS) 공격을 방지합니다. 이러한 요청의 홍수는 인증을 통과하지 못하지만 속도 제한에 포함됩니다. 요청을 콘텐츠 핸들러에 전달하기 전에 JWT를 인증하면 유효한 요청만 속도 제한에 포함되도록 할 수 있습니다.
NGINX 오픈 소스에서 상속된 변경 사항
NGINX Plus R29는 NGINX 오픈 소스 1.23.4를 기반으로 하며 NGINX Plus R28 출시 이후(NGINX 1.23.3~1.23.4) 이루어진 기능 변경 및 버그 수정을 상속받습니다.
변경 사항
- TLSv1.3 프로토콜이 이제 기본적으로 활성화되며 이 지시어의 기본값입니다:
- ssl_-protocols (HTTP, 스트림, 메일)
- proxy_ssl_-protocols (HTTP, 스트림)
- grpc_ssl_-protocols
- uwsgi_ssl_-protocols
- zone_sync_ssl_-protocols
- 이제 수신 소켓의 프로토콜 파라미터가 재정의된 경우 NGINX가 경고를 표시합니다.
- 이제 클라이언트에서 파이프라이닝을 사용한 경우 NGINX는 연결을 지연 상태로 닫습니다.
- 데이터 길이 너무 길음, 길이 너무 짧음, 잘못된 레거시 버전, 공유 서명 알고리즘 없음, 잘못된 다이제스트 길이, 시그널 확장 누락, 암호화 길이 너무 길음, 잘못된 길이, 잘못된 키 업데이트, 핸드셰이크 및 비핸드셰이크 데이터 혼합, 일찍 수신된 CC, CC와 완료된 데이터, 패킷 길이 너무 길음, 너무 많은 경고 알림, 너무 작은 기록, CC 이전에 핀을 받은 SSL 오류의 로그 수준이 비판에서 정보로 낮춰졌습니다.
기능
- 이제 ngx_http_gzip_static_module에서 바이트 범위가 지원됩니다.
버그 수정
- listen 지시어에서 작동하지 않던 포트 범위를 수정했습니다.
- 구성에 255자보다 긴 접두사 위치가 사용된 경우 요청을 처리하기 위해 잘못된 위치가 선택될 수 있는 문제를 수정했습니다.
- Windows에서 파일 이름에 ASCII가 아닌 문자가 포함될 때 ngx_http_autoindex_module, ngx_http_dav_module 및 include 지시어가 지원되지 않던 문제를 수정했습니다.
- HTTP/2 및 오류 페이지 지시문을 사용하여 코드 400으로 오류를 리디렉션할 때 가끔 발생하던 소켓 누수를 수정했습니다.
- syslog에 로깅하는 동안 오류가 발생했다는 정보가 포함되지 않는 오류 로깅 관련 메시지를 수정했습니다.
- proxy -r에서 차단된 클라이언트 읽기 이벤트의 처리를 수정했습니다.
- 많은 수의 TLV가 포함된 PROXY 프로토콜 버전 2 헤더를 읽을 때 가끔 발생하던 오류를 수정했습니다.
- 다른 모듈에서 생성한 하위 요청을 처리하기 위해 SSI를 사용하는 경우 작업자 프로세스에서 가끔 발생하는 세그먼트 분할 오류를 수정했습니다.
- 백엔드에 대한 SSL 연결이 사용되는 경우 버퍼링되지 않은 프록시 중에 NGINX가 잠재적으로 CPU를 독점할 수 있는 문제를 수정했습니다.
해결 방법
- zip 필터가 미리 할당된 메모리를 사용하지 못하여 zlib-ng를 사용할 때 로그에 경고가 나타납니다.
- listen 지시어에 사용된 호스트 이름이 여러 주소로 확인되는 경우 이제 NGINX는 이러한 주소 내에서 중복을 무시합니다.
이번 릴리스에서 상속된 새로운 기능, 변경 사항, 버그 수정 및 해결 방법의 전체 목록은 CHANGES 파일을 참조하세요.
NGINX JavaScript 모듈 변경 사항
NGINX Plus R29에는 NGINX JavaScript(njs) 모듈 버전 0.7.9에서 0.7.12까지의 변경 사항이 통합되어 있습니다. njs에는 다음과 같은 몇 가지 흥미로운 기능이 추가되었습니다:
- 확장된 가져오기 API 지원
- 확장 웹 암호화 API
- XML 문서 지원
- XML 문서 구문 분석
- XML 문서 수정을 위한 XMLNode API
- Zlib 모듈 압축 지원
njs 버전 0.7.9부터 0.7.12까지의 모든 기능, 변경 사항 및 버그 수정에 대한 전체 목록은 njs 변경 로그를 참조하세요.
확장된 가져오기 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);
}
Extended Web Crypto API
Web Crypto API는 JSON 웹 키(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 형식을 지원합니다.
자세한 내용은 웹 암호화 API를 참조하세요.
XML 문서 지원
XML 문서 작업에 대한 기본 지원을 제공하기 위해 njs 0.7.10에 XML 모듈이 추가되었습니다.
XML 문서 구문 분석
이제 XML 문서의 문자열 또는 버퍼를 구문 분석하여 구문 분석된 XML 문서를 나타내는 XMLDoc 래퍼 객체를 반환할 수 있습니다:
const xml = require("xml"); let data = `ToveJani`;
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 문서를 수정하기 위해 njs 0.7.11에 XMLNode API가 추가되었습니다:
Const xml = require("xml"); let data = `ToveJani`;
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))
/* 'Tove' */
doc.$root.to.removeAllAttributes();
doc.$root.from.$text = 'Jani2';
모든 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에서 도움을 받을 수 있습니다.
보안, 로드 밸런싱, API 게이트웨이 또는 향상된 모니터링 및 관리 API를 통해 완벽하게 지원되는 웹 서버로 NGINX Plus를 사용해 보지 않으셨다면 꼭 사용해 보시기 바랍니다. 지금 바로 시작하세요.
NGINX Plus 릴리스 29(R29)의 출시를 발표하게 되어 기쁘게 생각합니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R29의 새롭고 향상된 기능은 다음과 같습니다:
동작의 중요한 변경 사항
주: NGINX Plus R28 이외의 릴리스에서 업그레이드하는 경우, 현재 버전과 이 버전 사이의 모든 릴리스에 대해 이전 공지 블로그의 동작의 중요한 변경 사항 섹션을 확인하세요.
패키지 리포지토리 변경
이전 패키지 리포지토리 plus-pkgs.nginx.com는 NGINX Plus R29의 출시와 함께 즉시 폐기됩니다. 이 리포지토리는 NGINX Plus R25 이후 업데이트되지 않았으며, NGINX Plus R24에 도입된 pkgs.nginx.com 패키지 리포지토리를 사용할 것을 강력히 권장합니다.
플랫폼 지원 변경 사항
새로운 운영 체제가 지원됩니다:
이전 운영 체제가 제거됩니다:
구형 운영 체제는 더 이상 사용되지 않으며 NGINX Plus R30에서 제거될 예정입니다:
ModSecurity 수명 종료 발표에 적응하기
ModSecurity EOL 발표에 따라 NGINX Plus R29는 ModSecurity 패키지에 대한 지원을 제거합니다. ModSecurity 패키지를 사용하는 NGINX Plus 고객인 경우, 곧 ModSecurity와 NGINX App Protect 간의 보상 판매 프로그램을 선택할 수 있게 될 것입니다. 이에 대한 자세한 내용은 곧 제공될 예정이며 자세한 내용은 F5 담당자에게 문의하실 수 있습니다.
새로운 기능 상세 정보
MQTT 프로토콜 지원
MQTT(메시지 큐 텔레메트리 전송)는 대중적이고 가벼운 게시-구독 메시징 프로토콜로, 인터넷을 통해 IoT 디바이스와 애플리케이션(클라이언트)을 연결하는 데 이상적입니다. 이를 통해 클라이언트는 특정 주제에 메시지를 게시하고 다른 주제를 구독할 수 있습니다. 구독한 클라이언트는 해당 토픽에 게시된 모든 메시지를 수신하여 많은 디바이스와 서비스 간에 효율적이고 내결함성 있는 데이터 교환을 가능하게 합니다.
MQTT 아키텍처의 핵심은 브로커입니다. 브로커는 클라이언트와 클라이언트가 구독하는 모든 주제를 추적하고, 메시지를 처리하고, 해당 메시지를 적절한 시스템으로 라우팅하는 역할을 담당하는 서버입니다. NGINX Plus R29는 MQTT 3.1.1 및 MQTT 5.0를 지원합니다. 클라이언트와 브로커 사이에서 프록시 역할을 수행하여 시스템 아키텍처를 간소화하고 작업을 오프로드하며 비용을 절감합니다.
초기 MQTT 기능 세트가 활성화됩니다:
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; } }다음 단계
향후에는 다른 MQTT 메시지 유형에 대한 구문 분석과 CONNECT 메시지의 심층 구문 분석을 통해 다음과 같은 기능을 사용할 수 있도록 NGINX Plus에서 MQTT를 개발할 예정입니다:
가장 중요한 기능에 대한 여러분의 의견을 듣고 싶습니다. 댓글로 여러분의 의견을 알려주세요.
인증 및 권한 부여를 위한 SAML 지원
SAML(보안 어설션 마크업 언어)은 ID 공급자(IdP)가 리소스에 대한 액세스를 위해 사용자를 인증하고(최종 사용자가 실제로 자신이 주장하는 사람인지 확인), 해당 인증 정보와 함께 해당 리소스에 대한 사용자의 액세스 권한을 서비스 공급자(SP)에게 전달하여 권한을 부여할 수 있도록 하는 개방형 페더레이션 표준입니다.
신원 데이터를 교환하는 안전한 수단을 제공해온 오랜 역사를 가진 SAML은 IdP와 SP 간의 인증 및 권한 부여 정보 교환을 위해 널리 채택된 프로토콜입니다.
기업과 정부 기관이 SAML을 채택하는 주요 이유는 다음과 같습니다:
현재 SAML의 참조 구현은 SAML 2.0을 사용하며 NGINX JavaScript(njs) 프레임워크를 사용하여 구축되었습니다. 이 구현에서 NGINX Plus는 SAML SP로 작동하여 SAML IdP를 사용한 SSO 설정에 참여할 수 있습니다. 현재 구현은 또한 기존 NGINX Plus 기능인 키-값 저장소에 의존하므로 추가 수정 없이는 NGINX 오픈 소스에는 적합하지 않습니다.
NGINX Plus의 SAML 지원은 GitHub에서 참조 구현으로 사용할 수 있습니다. GitHub 리포지토리에는 특정 사용 사례에 대한 설치, 구성 및 미세 조정에 대한 지침이 포함된 샘플 구성이 포함되어 있습니다.
네이티브 오픈 텔레메트리
OTel은 애플리케이션 모니터링, 추적, 문제 해결 및 최적화에 사용할 수 있는 기술 및 표준입니다. OTel은 배포된 애플리케이션 스택의 프록시, 애플리케이션 또는 기타 서비스 등 다양한 소스에서 원격 분석 데이터를 수집하는 방식으로 작동합니다.
프로토콜 인식 리버스 프록시 및 로드 밸런서인 NGINX는 애플리케이션 요청 및 응답 추적을 위한 원격 측정 호출을 시작하는 데 이상적인 위치에 있습니다. 한동안 타사 OTel 모듈을 사용할 수 있었지만, 새로운 동적 모듈을 통해 NGINX Plus에서 OTel에 대한 기본 지원을 발표하게 되어 기쁘게 생각합니다.
새로운 모듈 ngx_otel_module은 nginx-plus-module-otel 패키지를 사용하여 설치할 수 있으며 다음과 같은 몇 가지 주요 개선 사항을 타사 모듈에 제공합니다:
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 오픈 소스용 프리뷰 바이너리 패키지를 발표한 데 이어, 이번에는 NGINX Plus R29용 실험용 QUIC 패키지를 발표하게 되어 기쁘게 생각합니다. 이를 통해 NGINX Plus로 HTTP/3을 테스트하고 평가할 수 있습니다.
새로운 기본 프로토콜 스택을 통해 HTTP/3는 UDP와 QUIC을 전송 계층으로 가져옵니다. QUIC은 연결 멀티플렉싱을 제공하고 헤드 오브 라인 차단과 같은 문제를 해결함으로써 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 플러스 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 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 리포지토리를 사용해야 합니다.
QUIC+HTTP/3용 NGINX를 구성하는 방법에 대한 자세한 내용은 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는 다운스트림 애플리케이션으로 전송되는 모든 요청에 대해 해당 토큰을 HTTP 권한 부여 헤더에 Bearer Token으로 전달할 수 있습니다.
주: NGINX Plus는 ID 토큰과 마찬가지로 각 요청에 대해 액세스 토큰의 유효성을 확인하지 않으며 액세스 토큰이 이미 만료되었는지 여부를 알 수 없습니다. 액세스 토큰의 수명이 ID 토큰의 수명보다 짧은 경우, proxy_intercept_errors 지시어를 사용해야 합니다. 이렇게 하면 401 권한 없음 응답을 가로채서 NGINX로 리디렉션하고 액세스 토큰을 새로 고칩니다.
NGINX Plus를 사용한 OpenID Connect 및 JWT(JSON 웹 토큰) 유효성 검사에 대한 자세한 내용은 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 지시어와 모듈은 request 처리 제한, connection 처리 제한 및 access 제한을 확인한 후 내부 리디렉션을 허용합니다.
Here is an example internal_redirect configuration:
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로 전달되어 하위 클레임 값에 따라 요청 속도 제한이 적용됩니다. 이는 요청이 업스트림 서비스로 전달되기 전에 JWT에서 발생합니다.
이 특정 구성은 공격자가 특정 사용자를 하위 필드로 인코딩하여 읽기 가능한 JWT를 포함하는 요청을 대량으로 전송하는 서비스 거부(DoS) 공격을 방지합니다. 이러한 요청의 홍수는 인증을 통과하지 못하지만 속도 제한에 포함됩니다. 요청을 콘텐츠 핸들러에 전달하기 전에 JWT를 인증하면 유효한 요청만 속도 제한에 포함되도록 할 수 있습니다.
NGINX 오픈 소스에서 상속된 변경 사항
NGINX Plus R29는 NGINX 오픈 소스 1.23.4를 기반으로 하며 NGINX Plus R28 출시 이후(NGINX 1.23.3~1.23.4) 이루어진 기능 변경 및 버그 수정을 상속받습니다.
변경 사항
기능
버그 수정
해결 방법
이번 릴리스에서 상속된 새로운 기능, 변경 사항, 버그 수정 및 해결 방법의 전체 목록은 CHANGES 파일을 참조하세요.
NGINX JavaScript 모듈 변경 사항
NGINX Plus R29에는 NGINX JavaScript(njs) 모듈 버전 0.7.9에서 0.7.12까지의 변경 사항이 통합되어 있습니다. njs에는 다음과 같은 몇 가지 흥미로운 기능이 추가되었습니다:
njs 버전 0.7.9부터 0.7.12까지의 모든 기능, 변경 사항 및 버그 수정에 대한 전체 목록은 njs 변경 로그를 참조하세요.
확장된 가져오기 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); }Extended Web Crypto API
Web Crypto API는 JSON 웹 키(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 형식을 지원합니다.
자세한 내용은 웹 암호화 API를 참조하세요.
XML 문서 지원
XML 문서 작업에 대한 기본 지원을 제공하기 위해 njs 0.7.10에 XML 모듈이 추가되었습니다.
XML 문서 구문 분석
이제 XML 문서의 문자열 또는 버퍼를 구문 분석하여 구문 분석된 XML 문서를 나타내는 XMLDoc 래퍼 객체를 반환할 수 있습니다:
const xml = require("xml"); let data = `ToveJani`; 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 문서를 수정하기 위해 njs 0.7.11에 XMLNode API가 추가되었습니다:
Const xml = require("xml"); let data = `ToveJani`; 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)) /* 'Tove' */ doc.$root.to.removeAllAttributes(); doc.$root.from.$text = 'Jani2';모든 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에서 도움을 받을 수 있습니다.
보안, 로드 밸런싱, API 게이트웨이 또는 향상된 모니터링 및 관리 API를 통해 완벽하게 지원되는 웹 서버로 NGINX Plus를 사용해 보지 않으셨다면 꼭 사용해 보시기 바랍니다. 지금 바로 시작하세요.
Web Crypto API는 JSON 웹 키(JWK) 형식을 지원하도록 확장되었으며, 이제 importKey()는 JWK 형식의 키를 입력으로 받습니다:
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요.
전문가에게 상담받기