HTTP/3이란 무엇인가 – 빠르고 새로운 UDP 기반 프로토콜에 대한 간략한 설명

TL;DR

2018년 11월, IETF(Internet Engineering Task Force)가 방콕에서 모임을 갖고 새로운 Internet-Draft가 채택되었습니다. HTTP/2의 후속인 QUIC 전송 프로토콜은 HTTP/3으로 이름이 변경되었습니다.

HTTP/3는 UDP(User Datagram Protocol)를 기반으로 하며 Google 및 Facebook과 같은 저명한 인터넷 회사에서 이미 사용하고 있습니다. Chrome을 사용 중이고 Google 서비스에 연결하는 경우 이미 QUIC를 사용 중일 수 있습니다.

HTTP 프로토콜의 새 버전은 베어메탈(bare-metal), 저수준 UDP 프로토콜의 이점을 제공하며 TCP 계층에서 이전 버전의 HTTP에 있던 많은 새로운 기능을 정의합니다. 이것은 기존 인터넷 인프라 내에서 제약을 해결하는 방법을 제공합니다.

첫 번째 결과는 유망하며 IETF의 Internet Draft가 만료되는 2021년 8월에 HTTP/3이 새로운 3세대 HTTP 표준으로 승격될 것으로 예상할 수 있습니다.

2022년 HTTP/3 진행 상황

일부에서는 더 빠른 속도와 더 낮은 대기 시간에 대한 웹 업계의 갈망이 더 많은 RAM에 대한 Google 크롬의 갈망과 일치한다고 말합니다.

몇 년 전에 우리는 W3Techs에 따르면 현재 세계 채택률이 약 45%에 달하는 HTTP/2 표준에 대한 기사를 게시했습니다. Can I Use에 따르면 모든 최신 웹 브라우저에서도 지원됩니다. 그러나 여기 우리는 다음 버전의 프로토콜인 HTTP/3에 대한 기사를 작성하고 있습니다.

이 글을 쓰는 시점에서 HTTP/3은 IETF Internet-Draft 또는 ID입니다. 즉, 정의를 담당하는 국제 인터넷 표준 기구 인 Internet Engineering Task Force에서 곧 있을 인터넷 표준에 대해 현재 고려 중입니다. TCP, IPv6, VoIP, 사물 인터넷 등과 같이 합의된 인터넷 프로토콜 표준을 촉진합니다.

웹 산업을 통합하고 인터넷의 방향에 대한 토론을 촉진하는 열린 기관입니다. 현재 HTTP/3의 "인터넷 초안" 단계는 제안이 모든 의도와 목적에 대해 공식 인터넷 프로토콜 정의를 고려할 수 있는 Request-for-Comments(또는 RFC) 수준으로 승격되기 전의 마지막 단계입니다.

HTTP/3가 아직 공식 인터넷 프로토콜은 아니지만 많은 회사와 프로젝트에서 이미 HTTP/3 지원을 제품에 추가하기 시작했습니다.

HTTP/3에 대한 웹 브라우저 지원

웹 브라우저 전면에서 Chrome v87, Firefox v88 및 Edge v87에는 모두 기본적으로 HTTP/3이 활성화되어 있습니다. Safari 사용자의 경우 HTTP/3 활성화 옵션이 Safari Technology Preview v104에 추가되었습니다. 그러나 HTTP/3 지원은 현재 Safari의 안정적인 버전에서 사용할 수 없습니다.

HTTP/3에 대한 라이브러리 지원

HTTP/3 기술을 활용하려는 개발자를 위해 많은 인기 있는 라이브러리에서 이미 HTTP/3에 대한 지원을 추가했습니다. HTTP/3은 아직 인터넷 초안 단계에 있으므로 아래 라이브러리 중 하나를 사용하여 작업할 때 최신 업데이트에 맞춰져 있는지 확인하는 것이 좋습니다.

• 파이썬 – http3 및 aioquic
• 러스트 – 키시, 네코, 퀸
• C – nghttp3 및 lsquic
• 가 - 빨리
• 자바스크립트 – Node.js

HTTP/3에 대한 인프라 지원

인프라 측면에서 Cloudflare는 전체 에지 네트워크에서 HTTP/3 지원을 통해 선두를 달리고 있습니다. 즉, Cloudflare가 활성화된 사이트는 추가 작업 없이 HTTP/3의 보안 및 성능 향상을 활용할 수 있습니다.

Kinsta에서 호스팅하는 모든 사이트는 무료 Cloudflare 통합으로 보호됩니다. 엔터프라이즈 수준의 방화벽 및 DDoS 보호 외에도 Kinsta 고객은 HTTP/3에 액세스할 수 있습니다!

사이트가 HTTP/3을 지원하는지 테스트하려면 Geekflare의 HTTP/3 테스트 도구를 사용할 수 있습니다. 귀하의 도메인을 입력하고 "HTTP/3 확인" 버튼을 누르기만 하면 도구가 귀하의 사이트가 HTTP/3를 지원하는지 여부를 알려줍니다.

사이트가 HTTP/3을 지원하는 경우 아래와 같은 메시지가 표시되어야 합니다. kinstalife.com은 Kinsta에서 호스팅되므로 Cloudflare 통합 덕분에 HTTP/3가 완벽하게 지원됩니다.

브라우저의 검사기를 사용하여 HTTP/3 지원을 확인할 수도 있습니다. 이 예에서는 HTTP/3를 지원하는 최신 버전의 Chrome을 사용합니다.

검사기를 열려면 페이지를 마우스 오른쪽 버튼으로 클릭하고 "검사"를 클릭하고 "네트워크" 탭으로 이동합니다. "프로토콜" 열에서 연결에 사용된 HTTP 프로토콜을 볼 수 있습니다. HTTP/2 연결은 "h2"로 표시되고 HTTP/3 연결은 "h3-XX"로 표시됩니다(XX는 특정 HTTP/3 초안을 나타냄). 아래 이미지에서 볼 수 있듯이 kinstalife.com은 "HTTP/3 Draft 29"를 의미하는 "h3-29"를 통한 연결을 지원합니다.

이제 HTTP/3의 현재 상태를 살펴보았으므로 HTTP/2와 HTTP/3의 차이점에 대해 자세히 살펴보겠습니다.

약간의 배경 – HTTP/2로 시작됨

HTTP/2는 기본 TCP 프로토콜의 몇 가지 제한 사항을 극복하는 데 도움이 되는 비차단 다운로드, 파이프라이닝 및 서버 푸시와 함께 몇 가지 심각한 개선을 가져왔습니다. 이를 통해 요청-응답 주기 및 핸드셰이크 수를 최소화할 수 있었습니다.

HTTP/2를 사용하면 단일 TCP 연결(다중화)에서 둘 이상의 리소스를 푸시할 수 있습니다. 또한 정적 다운로드 순서가 더 유연해졌으며 이제 페이지가 더 이상 다운로드의 선형 진행에 의해 제한되지 않습니다.

실제로 이것은 이제 하나의 큰 자바스크립트 리소스가 차례를 기다리는 다른 모든 정적 리소스에 대한 초크 지점과 반드시 ​​같지는 않다는 것을 의미합니다.

여기에 HTTP/2의 헤더 HPACK 압축과 데이터 전송의 기본 바이너리 형식을 추가하면 많은 경우에 훨씬 더 효율적인 프로토콜을 갖게 됩니다.

주요 브라우저 구현에서는 HTTP/2의 이점을 누릴 수 있도록 웹사이트가 암호화(SSL)를 구현해야 했으며 때로는 속도 향상이 눈에 띄지 않게 만드는 계산 오버헤드가 발생했습니다. 사용자가 HTTP/2로 전환한 후 속도 저하를 보고한 경우도 있었습니다.

이 버전의 초기 채택 시기는 심장이 약한 사람들을 위한 것이 아니었습니다.

Nginx 구현에는 모듈에 의존하는 서버 푸시 기능도 부족했습니다. 그리고 Nginx 모듈은 그냥 복사할 수 있는 일반적인 Apache 드롭인 모듈이 아닙니다. NGINX는 이러한 모듈로 다시 컴파일해야 합니다.

이러한 문제 중 일부는 이제 해결되었지만 전체 프로토콜 스택을 보면 HTTP/2가 감히 감히 시도할 수 있는 수준보다 낮은 수준에 주요 제약 조건이 있음을 알 수 있습니다.

이를 자세히 설명하기 위해 오늘날의 인터넷 프로토콜 스택을 맨 아래 계층에서 맨 위로 해부할 것입니다. HTTP/2의 배경에 대해 더 알고 싶다면 궁극적인 HTTP/2 가이드를 확인하십시오.

인터넷 프로토콜(IP)

인터넷 프로토콜(IP)은 전체 인터넷 토폴로지의 맨 아래 부분을 정의합니다. 그것은 인터넷 스택의 일부입니다. 라우터에서 서버, 심지어 최종 사용자의 기계까지 전체 하드웨어 인프라를 교체하는 것을 포함하여 모든 것을 변경하지 않고는 실제로 협상할 수 없다고 안전하게 말할 수 있습니다.

따라서 프로토콜 점검이 예정되어 있을 수 있지만 현재로서는 이러한 광범위한 노력이 예정되어 있지 않습니다. 주로 실행 가능하고 혁신적이지만 이전 버전과 호환되는 대안을 찾지 못했기 때문입니다.

우리는 IP 프로토콜의 시작을 1974년으로 거슬러 올라가 전기전자공학회에서 발행하고 Vint Cerf와 Bob Cahn이 저술한 논문을 볼 수 있습니다. 네트워크를 통해 전송되는 패킷에 대해 자세히 설명하고 IP 주소를 통해 라우팅하고 네트워크/네트워크에 있는 노드의 숫자로 정의된 주소를 통해 라우팅합니다. 프로토콜은 이러한 패킷 또는 데이터그램의 형식(헤더 및 페이로드)을 정의했습니다.

1980년부터 RFC 760 정의 이후 IETF는 Request For Comments 791에서 오늘날까지 널리 사용되는 정의로 정착했습니다. 이것은 프로토콜의 네 번째 버전이지만 첫 번째 프로덕션 버전이라고 말할 수 있습니다.

32비트 주소를 사용하므로 주소 수를 약 40억으로 제한합니다. 이 제한은 비즈니스가 아닌 인터넷 사용자가 ISP에서 "동적 IP 주소"를 얻는 이유에 대한 설명이며 고정 IP는 "부가가치"로 간주되어 종종 추가 요금이 부과됩니다.

배급하고 있습니다.

오래지 않아 32비트 주소로는 충분하지 않고 그 부족이 임박하여 이를 처리하기 위해 많은 RFC가 발표되었습니다. 이러한 솔루션이 오늘날 널리 사용되고 있으며 일상 생활의 일부이지만 해킹에 해당한다고 해도 과언이 아닙니다.

인터넷 프로토콜 버전 6 또는 IPv6은 이전 버전보다 점진적으로 채택되는 것을 포함하여 이러한 제한 사항을 해결하는 방법으로 제공되었습니다. 1998년 IETF의 표준 초안 문서가 되었고 2017년 인터넷 표준으로 승격되었습니다.

IPv4 주소 공간은 32비트 주소 길이로 제한되었지만 IPv6 표준에는 128비트 또는 3.4 * 10 ^ 38개의 가능한 주소가 제공되었습니다. 이것은 꽤 오랫동안 우리를 지속시키기에 충분해야 합니다.

Google 및 사용자 간의 IPv6 연결에 따르면 IPv6 채택은 2021년 6월 기준으로 35%를 약간 넘습니다.

IP는 배달, 데이터 무결성 또는 전송된 패킷의 순서에 대한 보장 없이 가장 기본적인 것을 정의하는 인터넷 스택의 기본 계층입니다. 그 자체로는 신뢰할 수 없습니다. IPv4의 헤더 형식은 전송 노드가 헤더의 무결성을 확인하는 데 사용하는 헤더 체크섬을 제공합니다. 이것은 아래의 링크 계층에 의존하는 IPv6 버전과 차별화되어 속도가 더 빠릅니다.

TCP와 UDP의 역할 이해

이제 HTTP/3이 TCP 및 UDP에 적합한 위치를 탐색할 때입니다.

TCP

IP가 오늘날 모든 온라인 통신의 기본 계층인 반면 TCP(전송 제어 프로토콜)는 인터넷 프로토콜 제품군의 상위 수준 부분으로 웹, 메일, 파일 전송(FTP)에 필요한 안정성을 제공합니다. 인터넷의 애플리케이션 계층/프로토콜용.

여기에는 핸드셰이크를 통한 다단계 연결 설정, 패킷 순서 보장, 손실된 패킷 재전송이 포함됩니다. 발신자 등에게 전달에 대한 피드백(Acks)을 제공합니다. 오류를 감지하는 체크섬 계산도 있습니다.

이 모든 것은 TCP를 신뢰할 수 있는 프로토콜로 만들어 오늘날 우리가 사용하는 가장 악명 높은 인터넷 서비스의 기반이 되도록 하는 많은 단계를 나타냅니다.

1974년(RFC 675) 및 1981년(RFC 793)으로 거슬러 올라가는 사양은 오늘날까지 크게 변경되지 않았습니다.

그러나 TCP가 제공하는 안정성에는 비용이 들지 않습니다. 약하고 중복되는 것으로 간주될 수 있는 핸드셰이크, 배달 피드백, 주문 보증 및 체크섬에 필요한 모든 왕복의 오버헤드. 그것은 TCP를 현대 프로토콜 스택의 병목 현상으로 만들었습니다. HTTP/2는 TCP 위에서 달성할 수 있는 속도 향상의 정체기에 도달했습니다.

UDP

UDP(사용자 데이터그램 프로토콜)는 1980년(RFC 768)으로 거슬러 올라가는 사양을 가진 인터넷 프로토콜 제품군의 일부이기도 합니다.

이름에서 알 수 있듯이 데이터그램 기반 비연결형 프로토콜입니다. 즉, 악수도 없고 주문이나 배달에 대한 보장도 없습니다. 이는 전달, 데이터 무결성 및 기타 사항을 보장하기 위한 가능한 모든 단계가 애플리케이션 계층에 남아 있음을 의미합니다. 즉, UDP 위에 구축된 애플리케이션은 구체적인 사례에 따라 채택할 전략을 선택하거나 오버헤드를 피하기 위해 체크섬과 같은 링크 계층 요소를 활용할 수 있습니다.

UDP는 TCP와 마찬가지로 널리 퍼져 있기 때문에 인터넷에 연결된 다양한 장치에 대한 펌웨어 업데이트나 운영 체제의 중대한 변경 없이 개선을 달성할 수 있습니다.

새로운 프로토콜의 배포는 사용자와 사용자가 도달해야 하는 서버 사이에 배포되는 TCP 또는 UDP만 허용하는 많은 방화벽, NAT, 라우터 및 기타 미들박스에 의해 방해를 받습니다. – HTTP/3 설명

Hacker News의 이 스레드는 새로운 HTTP 버전을 재창조하기 보다는 기존 네트워크 스택 위에 새 HTTP 버전을 빌드하는 이유를 이해하는 데 도움이 됩니다.

UDP 패킷 형식 사양은 다소 최소이며 해당 헤더는 소스 포트, 대상 포트, 패킷 헤더 및 패킷 데이터의 길이(바이트), 체크섬으로 구성됩니다. 체크섬은 패킷의 헤더와 데이터 부분 모두에 대한 데이터 무결성을 확인하는 데 사용할 수 있습니다.

체크섬은 기본 프로토콜 레이어가 IPv4인 경우 선택 사항이고 IPv6의 경우 필수입니다. 지금까지 UDP는 컴퓨터 시스템 클록 동기화(NTP), VoIP 애플리케이션, 비디오 스트리밍, DNS 시스템 및 DHCP 프로토콜과 같은 용도로 사용되었습니다.

QUIC 및 HTTP/3

QUIC(빠른 UDP 인터넷 연결)는 2012년 Google에서 처음 배포했습니다. 하위 수준 UDP 프로토콜에 의존하여 네트워크 계층의 경계를 재정의하고 "사용자 공간"에서 핸드셰이크, 안정성 기능 및 보안 기능을 재정의하여 인터넷 전체 시스템의 커널 업그레이드.

Google의 SPDY 또는 speedy가 주도한 발전인 HTTP/2와 마찬가지로 HTTP/3도 이러한 성과를 바탕으로 다시 구축될 것입니다.

HTTP/2는 멀티플렉싱을 제공하고 헤드 오브 라인 차단을 완화했지만 TCP에 의해 제한됩니다. 데이터를 전송하기 위해 함께 다중화된 여러 스트림에 대해 단일 TCP 연결을 사용할 수 있지만 이러한 스트림 중 하나가 패킷 손실을 겪을 때 전체 연결(및 모든 스트림)이 인질로 잡혀 TCP가 작동할 때까지( 손실된 패킷을 재전송함).

이는 이미 전송되어 대기 중인 모든 패킷이 대상 노드의 버퍼에 있더라도 손실된 패킷이 재전송될 때까지 차단된다는 의미입니다. Daniel Stenberg는 http/3에 대한 그의 책에서 이것을 "TCP 기반 헤드 오브 라인 블록"이라고 부릅니다. 그는 2%의 패킷 손실로 사용자가 이 위험을 헤지하기 위해 6개의 연결을 사용하여 HTTP/1을 더 잘 사용할 수 있다고 주장합니다.

QUIC는 이에 제한되지 않습니다. 연결 없는 UDP 프로토콜을 기반으로 하는 QUIC를 사용하면 연결 개념에 TCP의 제한이 없으며 한 스트림의 오류가 나머지에 영향을 줄 필요가 없습니다.

Cloudflare의 Lucas Pardue는 다음과 같이 말했습니다.

UDP 스트림 에 중점을 둔 QUIC는 하나의 TCP 연결에 피기백하지 않고도 다중화를 달성합니다. QUIC는 TCP보다 높은 수준에서 연결 을 구축합니다. QUIC 연결 내의 새 스트림은 다른 스트림이 완료될 때까지 강제로 기다리지 않습니다. 또한 QUIC 연결은 TCP 핸드셰이크 오버헤드를 제거하여 대기 시간을 줄이는 이점이 있습니다.

Cisco의 사람들은 TCP의 3방향 핸드셰이크를 설명하는 흥미로운 비디오를 만들었습니다.

QUIC는 TCP 안정성 기능을 없애지만 UDP 계층 위에서 이를 보완하여 패킷 재전송, 순서 지정 등을 제공합니다. Google Cloud Platform은 2018년에 로드 밸런서에 대한 QUIC 지원을 도입 했으며 평균 페이지 로드 시간이 전 세계적으로 8%, 지연 시간이 더 긴 지역에서 최대 13% 개선된 것을 확인했습니다.

Google 크롬, YouTube, Gmail, Google 검색 및 기타 서비스 사이에서 Google은 IETF를 기다리지 않고도 인터넷의 좋은 부분에 QUIC를 배포할 수 있었습니다. Google 엔지니어는 2017년에 인터넷 트래픽의 7%가 이미 QUIC를 통해 수행되었다고 주장합니다.

Google의 QUIC 버전은 HTTP/2 구문을 사용하여 HTTP 전송에만 중점을 두었습니다. IETF(QUIC 표준화 담당)의 사람들은 QUIC의 IETF 버전이 HTTP 이상을 전송할 수 있어야 한다고 결정했습니다. 그러나 당분간 QUIC를 통한 비 HTTP 프로토콜에 대한 작업은 보류됩니다.

IETF의 작업 그룹이 결정한 또 하나의 사항은 표준화된 버전이 Google의 사용자 지정 솔루션 대신 TLS 1.3 암호화를 사용한다는 것입니다. TLS 1.3은 이전 버전과 비교하여 핸드셰이크에 필요한 왕복 횟수가 적기 때문에 프로토콜 속도에도 기여합니다. Kinsta는 모든 서버와 Kinsta CDN에서 TLS 1.3을 지원합니다.

현재 Google은 제품에 자체 버전의 QUIC를 계속 사용하면서 IETF 표준에 대한 개발 노력을 기울이고 있습니다. 대부분의 다른 인터넷 플레이어는 IETF 버전을 기반으로 구축됩니다(두 개는 암호화 외에 다른 측면에서 다릅니다).

Chrome 개발자 도구를 열고 네트워크 탭의 프로토콜 열에서 Gmail과 같은 일부 Google 제품을 로드하면 Google 버전의 QUIC 프로토콜을 통해 로드되는 많은 리소스를 볼 수 있습니다. 애널리틱스, Google 태그 관리자 등과 같은 Google 제품의 경우에도 마찬가지입니다.

Cloudflare는 표준화 진행 상황에 대한 광범위한 업데이트를 게시했습니다.

UDP는 QUIC 및 HTTP/3에 몇 가지 고유한 이점을 제공하지만 몇 가지 문제도 수반합니다.

TCP는 수년간 주류 프로토콜이었으나 UDP는 그렇지 않았기 때문에 일반적으로 이를 위한 운영 체제와 소프트웨어 스택은 최적화되지 않았습니다. 결과적으로 QUIC의 CPU 로드/요구사항은 HTTP/2보다 두 배나 더 높습니다.

최적화는 운영 체제의 커널, 다양한 라우터 및 장치 펌웨어까지 깊숙이 진행됩니다. 이 Red Hat 튜닝 가이드는 기술적인 경향이 있는 사람들을 위해 주제에 대해 더 많은 정보를 제공할 수 있습니다.

우리는 QUIC가 보다 작고 유연한 프로토콜 위에 TCP 기능을 재설계하려고 시도한다고 말할 수 있습니다.

앞서 언급한 QUIC 연결은 TLS와 전송 핸드셰이크를 결합합니다. 일단 설정되면 고유한 CID(연결 ID)로 식별됩니다. 이러한 ID는 IP 변경 시 지속되며 예를 들어 4G에서 WiFi로 전환할 때 중단 없는 다운로드를 보호하는 데 도움이 될 수 있습니다. 이것은 특히 점점 더 많은 인터넷 트래픽이 모바일 장치에서 수행되기 때문에 관련이 있습니다. 이 요소가 Google에서 다양한 연결 및 인터넷 제공업체에서 더 나은 사용자 추적을 용이하게 하기 위해 고안한 것인지 여부에 대한 질문이 제기될 수 있습니다.

TLS는 필수이며 중간에 있는 장치가 트래픽을 변조하거나 스니핑하기 어렵게 만듭니다. 그렇기 때문에 Cisco와 같은 방화벽 제공업체 및 공급업체에서 UDP 프로토콜을 문제로 보고 이를 비활성화하는 방법을 제공하는 경우가 드물지 않습니다. 중개인이 QUIC 트래픽을 검사하고 감독하거나 필터링하기가 더 어렵습니다.

QUIC 스트림은 단방향 또는 양방향 QUIC 연결을 통해 전송됩니다. 스트림에는 이니시에이터와 스트림이 단방향인지 양방향인지 식별하는 ID가 있으며 스트림 내 흐름 제어도 제공합니다.

QUIC가 전송 계층 프로토콜인 반면 HTTP는 그 위의 계층인 응용 프로그램 계층 프로토콜 또는 응용 프로그램 프로토콜입니다.

이전 버전과의 호환성이 가장 중요하기 때문에 IETF는 HTTP/3의 구현을 촉진하고 응답에 이전 버전(HTT1 또는 HTTP/2)을 포함할 것입니다. 여기에는 RFC 7838에 설명된 대로 포트/호스트 정보와 함께 HTTP/3을 사용할 수 있음을 클라이언트에 알리는 헤더가 포함됩니다.

이것은 TLS 핸드셰이크 내에서 전송이 협상될 수 있는 HTTP/2와 다릅니다. 그러나 IETF는 QUIC 기반 HTTP/3를 차기 표준으로 채택하지 않고 있기 때문에 웹 클라이언트가 HTTP/3 지원을 점점 더 기대할 수 있습니다. 클라이언트가 이전 HTTP/3 연결의 데이터를 캐시하고 동일한 호스트에 대한 후속 방문 시 직접(제로 왕복 또는 0-RTT) 연결할 수 있습니다.

요약

HTTP/2 표준이 아직 완전히 채택되지 않았기 때문에 HTTP/3에 대한 광범위한 추진을 하기에는 너무 이르다고 생각하는 사람들이 있습니다. 이것은 유효한 지적이지만, 우리가 언급했듯이 이 프로토콜은 이미 대규모 테스트와 구현을 보았습니다. 구글은 이미 2015년에 테스트를 시작했고 페이스북은 2017년에 테스트를 시작했습니다.

2022년에는 Google Chrome 및 Brave와 같은 주요 브라우저에서 HTTP/3를 지원합니다. 인프라 측면에서 Litespeed 및 Nginx와 같은 웹 서버는 모두 HTTP/3의 작동하는 구현을 가지고 있는 반면 Cloudflare와 같은 네트워크 공급자는 이미 HTTP/3에 대한 완전한 지원을 배포했습니다.

현재 HTTP/3은 아직 인터넷 초안 단계에 있으며 가장 최근의 개정판은 2021년 8월에 만료될 예정입니다. 올해는 주요 소프트웨어 공급업체에서 새 버전을 구현하려는 움직임을 볼 수 있기 때문에 흥미진진할 것입니다. 기준.