NGINX Plus R25 발표

NGINX Plus R25 의 새로운 기능은 다음과 같습니다.

• 추가적이고 더욱 고급 JSON 웹 토큰 사용 사례  – NGINX Plus R25는 NGINX Plus R24 에 도입된 암호화된 JSON 웹 토큰(JWE) 지원을 기반으로 구축됩니다.
• HTTP 응답 코드에 대한 보다 세부적인 보고  – NGINX Plus API는 이제 HTTP 응답 코드를 개별적으로 계산할 뿐만 아니라 클래스별로 집계합니다. 메모리 할당을 늘려야 할 수도 있습니다 . 시작 실패를 방지하기 위해 충분한 메모리 할당을 참조하세요 .
• 프록시 연결을 위한 동적 SSL/TLS 클라이언트 인증서 로딩  – 변수를 사용하여 NGINX Plus와 백엔드 서버 간 mTLS 연결을 위한 인증서를 동적으로 선택할 수 있습니다.
• HTTP 요청 처리를 위한 강화된 보안  – NGINX Plus는 HTTP 요청에 대해 여러 가지 추가 검사를 수행하여 잠재적인 공격으로부터 애플리케이션을 보호합니다.
• TCP/UDP 애플리케이션에 대한 다시 로드 시에도 상태 점검 상태 지속성  - TCP/UDP 서버에 대한 필수 상태 점검 결과는 이제 구성 다시 로드 시에도 지속될 수 있습니다.
• NGINX JavaScript 모듈 개선  – JavaScript ES6와의 호환성이 강화되었습니다.

행동의 중요한 변화

업스트림 존에 대한 메모리 요구 사항 증가

HTTP 응답 코드의 보다 세부적인 보고 에서 자세히 설명된 대로 , NGINX Plus R25는 개별 상태 코드의 개수와 클래스별 집계 개수를 제공합니다. NGINX Plus가 역방향 프록시 또는 로드 밸런서로 구성된 경우, 피어가 20개가 넘으면 업스트림 "피어"(백엔드 서버)를 모니터링하는 데 사용되는 공유 메모리 영역의 크기를 늘려야 할 수 있습니다.

공유 메모리 영역이 프로비저닝이 부족하여 업그레이드가 실패하면 NGINX Plus R25가 시작되지 않습니다. 업그레이드하기 전에 각 업스트림 영역의 메모리 사용률을 확인하는 것이 중요합니다. 메모리 할당을 확인하고 조정하는 방법에 대한 지침은 시작 실패를 방지하기 위한 충분한 메모리 할당을 참조하세요 .

NGINX Plus Repo 구성 및 설치 절차 변경

NGINX Plus R24 가 출시되면서 모든 NGINX 소프트웨어의 패키지 저장소가 재구성되어 NGINX Plus 설치 절차가 변경되었습니다.

NGINX Plus를 설치하거나 업그레이드할 때 운영 체제의 패키지 관리자( apt, yum, 또는 이와 동등한 것)는 NGINX Plus용 소프트웨어 저장소로 구성됩니다. 이전 저장소를 사용하도록 구성된 기존 시스템( NGINX Plus R23 또는 이전 버전을 실행하는 시스템)에서는 패키지 관리자를 업데이트하여 새 저장소를 참조해야 합니다. F5 Knowledge Base 의 지침을 참조하세요 .

NGINX Plus R25 의 초기 설치를 수행하는 경우 NGINX Plus 관리자 가이드 의 NGINX Plus 설치를 참조하세요 .

참고: 새 소프트웨어 리포지토리를 사용해야 합니다. 이전 리포지토리는 더 이상 업데이트되지 않으며 향후 설치 및 업그레이드에 오류가 발생할 수 있습니다.

더 이상 사용되지 않는 쿠키 플래그 모듈

NGINX Plus R23 출시 시 발표된 대로 타사 Cookie‑Flag 모듈은 더 이상 사용되지 않으며 NGINX Plus R26 의 동적 모듈 리포에서 제거됩니다 . set_cookie_flag해당 모듈에서 정의된 지시문은 내장 지시문으로 대체됩니다 . 가능한 한 빨리 구성의 proxy_cookie_flags모든 지시문을 지시문으로 대체하는 것이 좋습니다 .set_cookie_flagproxy_cookie_flags

플랫폼 지원 변경

• 지원되는 새로운 운영 체제:
  • 데비안 11(x86_64, aarch64)
  • 알파인 리눅스 3.14(x86_64, aarch64)
• 제거된 이전 운영 체제:
  • Alpine Linux 3.10; 지원되는 가장 오래된 버전은 3.11입니다.
  • Amazon Linux 1(2018.03+); Amazon Linux 2 LTS로 전환
  • FreeBSD 11.4+; 지원되는 가장 오래된 버전은 12.1+입니다.
  • Ubuntu 16.04 LTS; 지원되는 가장 오래된 버전은 18.04 LTS입니다.
• NGINX Plus R26 에서 더 이상 지원되지 않고 제거될 예정인 이전 운영 체제 :
  • 알파인 리눅스 3.11

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

추가 JSON 웹 토큰 사용 사례 및 기능

NGINX Plus R24는 암호화된 JSON 웹 토큰(JWE)에 대한 초기 지원을 도입하여 데이터 기밀성을 갖춘 가장 인기 있는 클라이언트 인증 방법 중 하나를 확장했습니다. NGINX Plus R25는 해당 기능을 기반으로 하여 서명(JWS) 및 암호화(JWE) 사용 사례 모두에 대한 JWT 기반 인증의 보안을 개선하는 데 도움이 되는 추가적이고 더욱 고급 인증 사용 사례에 대한 지원을 도입합니다. 이러한 개선 사항은 개인 식별 정보(PII) 유출 위험을 줄이고 더 많은 유연성을 제공합니다. NGINX Plus의 새로운 JWT 기능과 개선 사항은 다음과 같습니다.

• 복호화된 JWE 암호문에 대한 새로운 변수
• 중첩된 JWT 지원
• JWE에 대한 비대칭 암호화
• 다중 소스 JSON 웹 키 지원
• 추가 사용자 정의 JWT 검증 규칙

복호화된 JWE 암호문에 대한 변수

JWT는 HTTP 요청의 상태 없는 인증(즉, 토큰 기반 인증)에 널리 사용되고 신뢰받는 방법입니다. 토큰 페이로드에서 최종 사용자 속성을 전송함으로써 JWT는 요청을 보다 안전하게 만드는 데 도움이 됩니다. 그러나 보안 연구원과 DevSecOps 실무자는 웹 클라이언트에 암호화되지 않은 PII를 저장함으로써 발생하는 위험이 시급한 문제라는 데 동의합니다. 따라서 암호화 된 토큰을 구현하기 위한 지침을 제공하는 JSON 웹 암호화 표준(RFC 7516) 이 개발되었습니다 .

NGINX Plus R24는 JWE에 대한 지원을 도입하여 전체 클레임 세트에 대한 데이터 무결성과 기밀성을 제공합니다. 암호화된 토큰 내에서 PII를 인코딩하면 JWT를 사용할 때 데이터 유출 위험이 크게 줄어듭니다.

NGINX Plus R25는 NGINX Plus가 JWE와 암호문을 복호화한 다음 HTTP 요청을 처리하는 동안 일반 텍스트에 액세스할 수 있도록 하는 새로운 변수인 를 사용하여 초기 JWE 지원을 기반으로 구축합니다 $jwt_payload. 이 새로운 기능은 고급 액세스 제어 정책과 요청 라우팅 결정을 구현하는 데 사용할 수 있으며, 사용자가 NGINX Plus를 백엔드 애플리케이션의 JWE 복호화 계층으로 배포할 수 있도록 합니다.

중첩된 JWT 지원

JWE 토큰은 PII를 보호하는 데 효과적이며, 암호문은 CDN 및 기타 TLS 종료 프록시에서도 기밀성을 유지하는 데 도움이 됩니다. 하지만 암호화는 양날의 검입니다. JWE는 애플리케이션 환경에 복잡성을 도입할 수 있기 때문입니다. 이 문제를 해결하는 한 가지 방법은 중첩된 JWT를 사용하는 것입니다.

중첩된 JWT는 JWE의 암호문으로 JWS를 내장합니다. NGINX Plus R25는 JWS와 JWE를 동시에 지원하여 중첩된 JWT를 HTTP 요청을 인증하는 방법으로 사용할 수 있습니다. 한 번의 작업으로 NGINX Plus는 이제 JWE의 암호문을 해독하고, 결과 평문을 JWS로 검증하고, 포함된 토큰의 exp(만료 시간) 및 nbf(이전 아님) 클레임을 사용하여 유효한지 확인할 수 있습니다. 이를 통해 기존 JWS 환경을 JWE로 래핑하여 페이로드 암호화로 업그레이드할 수 있습니다.

다음 구성 스니펫은 프로세스를 보여줍니다. 지시문 nested에 대한 새 매개변수는 auth_jwt_typeNGINX Plus에 JWE 복호화와 JWS 검증을 모두 수행하도록 지시합니다. 또한 JWT 헤더와 JWT 클레임에 대한 변수가 평가되는 방식에도 영향을 미칩니다.

• 해당 auth_jwt_header_set지시문은 외부 JWE 헤더에서 작동합니다.
• 해당 auth_jwt_claim_set지시문은 중첩된 JWS 클레임에 적용됩니다.
• $jwt_header_name변수에는 외부 JWE 헤더 속성이 포함됩니다.
• $jwt_claim_name변수에는 중첩된 JWS 클레임이 포함되어 있습니다.

다음 구성을 사용하면 NGINX Plus는 백엔드 애플리케이션에 추가 HTTP 요청 헤더를 구성하여 전송합니다. JWE 헤더(변수 $jwt_header_enc)의 암호화 알고리즘과 JWS 페이로드(변수)의 JWT 주체 클레임은 $jwt_claim_sub원래 요청으로 프록시됩니다. 즉, 애플리케이션은 암호화 코드나 라이브러리를 구현할 필요 없이 HTTP 헤더를 소비하기만 하면 JWE 기반 인증을 활용할 수 있습니다.

제로 트러스트 아키텍처에서 운영하는 사용자의 경우, 다음 구성을 통해 백엔드 애플리케이션이 변수에 캡처된 JWS 토큰을 검증할 수 있습니다 $jwt_payload. 변수에는 JWE 암호문의 복호화된 일반 텍스트 버전이 포함됩니다. 중첩된 JWT가 있는 경우 JWS를 베어러 토큰으로 백엔드 애플리케이션에 전달할 수 있습니다.

본질적으로 중첩된 JWT는 NGINX Plus가 보안 토큰을 동시에 해독하고 검증할 수 있도록 하여 운영을 간소화하고 애플리케이션 보안을 개선하며, 백엔드 애플리케이션에 대한 "일반 JWT" 서명 토큰을 구문 분석하거나 프록시합니다.

JWE를 위한 비대칭 암호화

NGINX Plus R24는 AES 표준을 사용하여 토큰의 대칭 암호화를 지원합니다. NGINX Plus R25는 RSA 키 쌍을 사용할 때 비대칭 암호화를 지원합니다. 비대칭 암호화는 암호화 및 복호화에 서로 다른 키(공개 및 비공개)를 사용하며, 이는 RSA(Rivest–Shamir–Adleman) 알고리즘을 사용하여 수학적으로 서로 연결됩니다. 이는 클라이언트와 서버 간 HTTPS 트래픽의 SSL/TLS 암호화에 사용되는 메커니즘과 동일합니다.

NGINX Plus R25는 NGINX Plus 측에서 명시적 구성이 필요하지 않은 키 관리 알고리즘으로 RSA with Optimal Asymmetric Encryption Padding(OEAP)을 지원합니다. JWS alg(알고리즘) 헤더에 지원되는 값은 RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384, 및 입니다 RSA-OAEP-512.

다음 구성은 JWE에 대한 비대칭 암호화를 구현하는 데 필요한 모든 것이 RSA 개인(언래핑) 키가 포함된 JSON 웹 키(JWK) 파일을 지시문의 매개변수로 지정하는 것임을 보여줍니다 auth_jwt_key_file( auth_jwt_key_request지시문도 사용할 수 있음).

다중 소스 JWK 지원

중첩된 JWT를 활용한다는 것은 연관된 JWK가 둘 이상의 소스에서 나올 가능성이 높다는 것을 의미합니다. NGINX Plus R25는auth_jwt_key_file 동일한 컨텍스트에서 여러 개의 및 지시문을 지원합니다 auth_jwt_key_request. NGINX Plus는 지정된 모든 소스에서 키를 로드하고 결합된 키 세트 중에서 일치하는 검증 키를 찾습니다. 이는 외부 ID 공급자가 발급하고 JWE 내부에 중첩되어 별도의 프로세스에서 암호화가 수행된 JWS로 작업할 때 매우 유용합니다.

이 기능은 API 게이트웨이로 배포된 NGINX Plus에 더 많은 유연성, 보안 및 성능을 추가합니다.

사용자 정의 JWT 검증 규칙

NGINX Plus가 API 게이트웨이로 배포되면 JWT 클레임을 검사하여 세분화된 액세스 제어를 구현하는 것이 일반적입니다. 이는 복잡한 구성으로 이어질 수 있습니다. 이전 NGINX Plus 릴리스에서는 if구성 블록을 사용하여 JWT 클레임을 평가할 수 있었지만 이 접근 방식은 다소 제한적이었고 암호화된 토큰에는 작동하지 않았습니다.

NGINX Plus R25는 JWT 검증 프로세스 중에 토큰에 대한 추가 검사를 수행하는 기본 방식을 제공하여 이러한 제한을 해결합니다. 이 auth_jwt_require지시문은 JWT 검증 프로세스에 선택적이고 사용자 정의 가능한 단계를 추가합니다. 공백으로 구분된 문자열 목록을 허용하며, JWT 검증이 성공하려면 모든 문자열이 비어 있지 않고 0(0)과 같지 않아야 합니다. 이를 통해 JWT 검증 프로세스에 엄청난 유연성이 추가됩니다.

JWT 표준은 어떤 클레임이 필수인지 규정하지 않으므로, 를 사용하여 auth_jwt_require각 환경에 적합한 클레임을 나열할 수 있습니다.

다음 구성은 exp및 sub클레임이 모든 토큰에 모두 존재하도록 보장합니다.

map블록이나 NGINX Plus 키-값 저장소를 사용하여 지시문에 부울 값을 전달하여 보다 복잡한 사용 사례를 구성할 수 있습니다 . NGINX JavaScript 모듈을 사용하여 상호 TLS(mTLS) 클라이언트 인증서 바인딩 액세스 토큰( RFC 8705auth_jwt_require 에 정의됨)과 같은 풍부한 인증 솔루션을 구현할 수도 있습니다 .

다음 구성은 클라이언트 인증서 인증(mTLS)과 JWT 검증을 모두 수행합니다. auth_jwt_require14번째 줄의 지시문은 변수가 평가되도록 요구하고 $thumbprint_match, JWT 검증은 0이 아닌 값을 갖는 경우에만 성공합니다. 이 변수는 2번째 줄에서 호출된 JavaScript 함수를 실행하여 평가됩니다.

 validate이전 스니펫의 2번째 줄에서 호출된 함수 의 코드는 다음과 같습니다 .

HTTP 응답 코드에 대한 보다 세부적인 보고

모니터링과 가시성은 애플리케이션 성능, 가용성 및 보안의 초석입니다. HTTP 응답 코드는 애플리케이션 상태에 대한 가장 중요한 통찰력 소스 중 하나입니다. NGINX Plus API는 NGINX와 클라이언트 간, 그리고 NGINX와 업스트림 서버 간의 상호 작용에 대한 HTTP 응답 코드를 추적합니다. 해당 수는 NGINX Plus 라이브 활동 모니터링 대시보드 의 관련 탭에 보고됩니다 .

이전 버전의 NGINX Plus API는 클래스별로 HTTP 응답 코드 수를 집계했습니다( 2xx, 4xx, 등). 이제 코드는 개별적으로도 계산됩니다( 200, 404, 503,403 등). 이를 통해 실패한 인증( ) 의 급증과 누락된 콘텐츠( )와 같이 매우 다른 원인을 가진 오류를 구별하여 애플리케이션에서 정확히 무슨 일이 일어나고 있는지에 대한 더 깊은 통찰력 을 얻을 404수 있습니다. 메트릭 수집 구성에 대한 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요 .

NGINX Plus R25 와 함께 출시된 최신 버전의 NGINX Plus API ( 버전 7)에는 개체 내에 개체가 포함되어 개별 HTTP 응답 코드를 계산할 수 있습니다. 집계된 응답은 여전히 사용할 수 있으며, 개체가 포함되지 않은 이전 버전의 NGINX Plus API 는  여전히 NGINX Plus R25 와 함께 사용할 수 있습니다 . 다음은 새로운 메트릭 세트의 예입니다.codesresponsescodes

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq{
  "processing": 31,
  "requests": 63192,
  "responses": {
    "1xx": 0,
    "2xx": 54368,
    "3xx": 8454,
    "4xx": 330,
    "5xx": 9,
    "codes": {
      "200": 54368,
      "302": 8454,
      "401": 30,
      "404": 200,
      "429": 100,
      "503": 9
    },
    "total": 63161
  },
  "discarded": 0,
  "received": 693436,
  "sent": 13843478
}

시작 실패를 방지하기 위해 충분한 메모리 할당

중요 참고 사항: NGINX Plus가 역방향 프록시 또는 로드 밸런서로 구성된 경우 개별 코드를 계산하면 각 업스트림 그룹의 공유 메모리 영역에서 메모리 사용량이 증가합니다. 업스트림 그룹에 피어가 20개가 넘는 경우 지시문 으로 구성된 대로 메모리 크기를 늘려야 할 수 있습니다 .

업스트림 영역에 충분한 프로비저닝이 없으면 NGINX Plus R25가 시작되지 않아 업그레이드가 실패합니다.

상위 그룹의 공유 메모리 영역에 대한 일반적인 구성은 다음과 같습니다.

NGINX Plus R25 로 업그레이드하기 전에 기존 업스트림 존의 메모리 사용량을 확인하는 것이 중요합니다. 이를 위해 다음 방법 중 하나를 사용하기 전에 NGINX Plus API가 활성화되어 있는지 확인하십시오.

• 이 demo.nginx.com 의 예와 같이 사용률이 54%인 라이브 활동 모니터링 대시보드의 HTTP 업스트림 탭을 확인하세요 .

  

• 다음 명령을 실행하여 호스트에서 직접 NGINX Plus API를 사용합니다 . 먼저:

  • 필요한 경우 jq유틸리티를 설치하세요
  • 변수를 지시문이 활성화된 API위치로 설정합니다.api

• $ API=http://localhost:8080/api; for i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; do echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; done
  

현재 사용률이 40%를 넘으면(스크린샷과 같이) 지시문의 두 번째(크기) 매개변수를 zone최소 2.5배로 늘립니다. 예를 들어,  위의 구성 스니펫에서 64k를  늘리는 것이 좋습니다.160k

프록시를 위한 동적 SSL/TLS 클라이언트 인증서 로딩

상호 TLS(mTLS)는 클라이언트와 서버 모두의 신원을 확인하는 일반적인 인증 관행입니다. NGINX Plus를 사용하면 업스트림 그룹의 서버를 동적으로 그리고 변수와 함께 정의할 수 있습니다. 즉, NGINX Plus가 업스트림 서버에 자신을 확인하는 데 사용하는 TLS 인증서를 동적으로 선택할 수 있어야 할 수도 있습니다.

NGINX Plus R25는 mTLS에 사용되는 구성 지침을 백엔드 서버로 확장하여 인증서를 나타내는 변수를 허용합니다. 변수는 다음 중 하나를 참조할 수 있습니다.

• 디스크에 있는 파일
• PEM 형식의 원시 데이터, 접두사 포함data:

이를 통해 NGINX Plus는 인증서와 개인 키를 동적으로 선택할 수 있습니다. 이는 지속적으로 변경되는 최신 애플리케이션 환경에 유용합니다. 인증서와 개인 키를 NGINX Plus 키-값 저장소 에 저장할 수 있으며 , 개인 키가 디스크가 아닌 메모리에 저장되므로 보안이 강화됩니다. 또 다른 사용 사례는 자동화된 인증서 회전으로, API 호출을 사용하여 키-값 저장소에서 인증서를 업데이트합니다.

다음 구성에서 NGINX Plus는 호스트 이름에 따라 다른 업스트림 그룹으로 요청을 라우팅합니다. 프록시 연결은 mTLS를 사용하여 만들어지고 각 업스트림에 대한 적절한 클라이언트 인증서가 동적으로 선택됩니다.

다음 지침은 업스트림 서버를 사용한 mTLS에 대한 동적 인증서 로딩을 지원합니다.

• grpc_ssl_certificate
• grpc_ssl_certificate_key
• proxy_ssl_certificate
• proxy_ssl_certificate_key
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_key

HTTP 요청 처리를 위한 강화된 보안

NGINX 철학의 핵심 교리 중 하나는 지속적인 개선이며, 특히 보안과 관련하여 그렇습니다. 보안 연구원과의 협업, F5의 업계를 선도하는 보안 기술을 당사 제품에 통합, 내부 개발 노력을 포함하여 사용 가능한 모든 리소스를 사용합니다.

마지막의 예로, NGINX Plus R25는 HTTP 요청에 대해 여러 가지 추가 검사를 수행하여 요청 밀수 와 같은 잠재적 공격으로부터 애플리케이션을 보호합니다 . 다음 조건에 대해 오류를 반환합니다.

• HTTP/1.0 요청에는 Transfer-Encoding다음 헤더가 포함됩니다.
• 및 헤더가 모두 존재합니다 Transfer-Encoding.Content-Length
• 요청 줄이나 헤더 이름에 공백이나 제어 문자가 있습니다.
• Host헤더 에 공백이나 제어 문자가 있습니다.
• 이 CONNECT방법은 사용됩니다

또한, 다음 문자는 이제 프록시 URI에서 항상 이스케이프됩니다: ", <, >, \, ^, `, {, |, }.

이러한 변경 사항은 사전 예방적 보안 강화 조치이며 알려진 취약점에 대응하여 이루어진 것이 아닙니다.

TCP/UDP 애플리케이션에 대한 재로드 시 필수 상태 검사 상태의 지속성

NGINX Plus는 필수 상태 검사를 사용하여 업스트림 그룹에 추가된 새 서버가 클라이언트 요청이 프록시되기 전에 테스트되고 정상인지 확인합니다. NGINX Plus R23 및 이전 버전에서는 업스트림 서버는 재로드 전 상태와 관계없이 구성 재로드 후에 비정상으로 간주되었습니다. 그 결과 NGINX Plus는 첫 번째 필수 검사가 통과될 때까지 서버에 요청을 보내지 않았습니다.

NGINX Plus R24는 HTTP 애플리케이션에 대해 리로드 간에 필수 상태 검사 상태의 선택적 지속성을 도입했습니다. 리로드 전 마지막 필수 상태 검사가 성공적이었다면 NGINX Plus는 리로드 후 필수 상태 검사가 성공할 때까지 기다릴 필요 없이 즉시 서버에 요청을 보낼 수 있습니다.

NGINX Plus R25는 이 기능을 TCP/UDP 애플리케이션( stream컨텍스트 내)으로 확장합니다. HTTP의 경우 매개변수 와 함께 persistent매개변수를 지시문에 추가합니다 .health_checkmandatory

NGINX JavaScript 모듈의 향상

NGINX JavaScript 모듈(njs)이 여러 버그 수정과 JavaScript ES6 와의 호환성을 강화하는 몇 가지 기능 향상을 통해 버전 0.6.2로 업데이트되었습니다 .

let및 const키워드를 사용한 변수 선언

letNGINX JavaScript는 이제 및 키워드를 사용하여 범위가 지정된 변수의 선언을 지원합니다 const. 이전 버전의 NGINX Plus와 njs는 var변수를 선언하고 할당하기 위한 키워드만 지원했습니다. 이는 서로 다른 프로젝트, 프로그래밍 언어 및 엔지니어링 팀이 공유 코드베이스 또는 라이브러리에서 협업할 때 종종 발생하는 복잡성을 처리하는 데 필요한 특정 명령문의 범위로 제한된 변수 block를 제공하지 않았습니다.

JavaScript ES6는 범위 변수를 정의하기 위한 키워드를 let제공 합니다.const

• let변수는 변수가 사용되는 문장이나 표현식의 범위로 제한됩니다 block. 반면 var키워드는 전역적으로 또는 블록 범위와 관계없이 전체 함수에 로컬로 변수를 선언합니다.
• const변수는 키워드를 사용하여 선언된 변수와 매우 유사한 블록 범위입니다 let. 상수의 값은 재할당을 통해 변경할 수 없으며 다시 선언할 수 없습니다.

Promise모든 생성자 메서드 지원

Promise.all(), Promise.allSettled(), Promise.any(), 및 생성자 메서드 가 추가되어 Promise.race()이제 njs는 JavaScript ES6 표준에 정의된 전체 생성자 메서드 세트를 지원합니다.

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

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R25 로 업그레이드하는 것을 강력히 권장합니다 . 또한 여러 가지 추가 수정 사항과 개선 사항을 얻을 수 있으며, 지원 티켓을 제기해야 할 때 NGINX가 도움을 줄 수 있습니다.