QUIC 프로토콜은 제안된 표준의 상태를 받았습니다.

인터넷 프로토콜 및 아키텍처 개발을 담당하는 IETF(Internet Engineering Task Force)는 QUIC 프로토콜에 대한 RFC를 완성하고 RFC 8999(버전 독립적 프로토콜 속성), RFC 9000(전송 식별자)로 관련 사양을 발표했습니다. UDP를 통해), RFC 9001(QUIC 통신 채널의 TLS 암호화) 및 RFC 9002(데이터 전송 중 혼잡 제어 및 패킷 손실 감지).

RFC는 "제안된 표준" 상태를 받은 후 RFC에 표준 초안(초안 표준) 상태를 부여하는 작업이 시작됩니다. 이는 실제로 프로토콜이 완전히 안정화되고 작성된 모든 의견을 고려함을 의미합니다. HTTP/3의 전송으로 QUIC 프로토콜의 사용을 정의하는 HTTP/2 프로토콜은 아직 사양 초안 단계에 있지만 곧 IETF에 의해 최종적으로 표준화될 예정입니다.

QUIC의 표준화는 이 프로토콜의 광범위한 채택뿐만 아니라 WebTransport(브라우저와 서버 간에 데이터를 주고받는 기술) 및 MASQUE와 같은 이를 기반으로 하는 확장 개발에 자극을 줄 것으로 예상됩니다. (SOCKS 및 HTTP CONNECT의 기능을 확장하고 QUIC를 통한 HTTPS를 전송으로 사용하는 연결 프록시 기술)

QUIC(빠른 UDP 인터넷 연결) 프로토콜은 웹용 TCP+TLS 조합의 대안으로 2013년부터 Google에서 개발하여 TCP 연결의 긴 설정 및 협상 시간 문제를 해결하고 다음 작업 시 지연을 제거한다는 점을 상기해 보겠습니다. 데이터 전송 중에 패킷이 손실됩니다. QUIC는 다중 연결의 다중화를 지원하고 TLS/SSL과 동등한 암호화 방법을 제공하는 UDP 프로토콜의 확장입니다. IETF 표준을 개발하는 동안 프로토콜이 변경되어 두 개의 병렬 분기가 등장하게 되었습니다. 하나는 HTTP/3용이고 다른 하나는 Google에서 지원합니다(Chrome은 두 옵션을 모두 지원하고 Firefox는 IETF 버전을 지원함). .

QUIC의 주요 기능:

• TLS와 유사한 높은 보안(기본적으로 QUIC는 UDP를 통해 TLS를 사용하는 기능을 제공합니다)
• 흐름 무결성 제어, 패킷 손실 방지
• 즉시 연결을 설정하고(0-RTT, 약 75%의 경우 연결 설정 패킷을 보낸 후 즉시 데이터를 전송할 수 있음) 요청 전송과 응답 수신 사이의 지연을 최소화하는 기능(RTT, 왕복 시간)
• 패킷을 재전송할 때 다른 시퀀스 번호를 사용하면 수신된 패킷 식별의 모호성을 방지하고 시간 초과를 제거할 수 있습니다.
• 패킷 손실은 해당 패킷과 관련된 스트림의 전달에만 영향을 미치며 현재 연결을 통해 전송되는 병렬 스트림의 데이터 전달을 중단하지 않습니다.
• 손실된 패킷의 재전송으로 인한 지연을 최소화하는 오류 수정 기능입니다. 손실된 패킷 데이터의 재전송이 필요한 상황을 줄이기 위해 패킷 수준에서 특수 오류 수정 코드를 사용합니다.
• 암호화 블록 경계는 QUIC 패킷 경계와 정렬되어 후속 패킷의 내용을 디코딩할 때 패킷 손실이 미치는 영향을 줄입니다.
• TCP 대기열 차단에는 문제가 없습니다.
• 모바일 클라이언트에 대한 재연결을 설정하는 데 걸리는 시간을 줄이는 연결 식별자 지원
• 고급 연결 정체 제어 메커니즘 연결 가능성
• 방향별 처리량 예측 기술을 사용하여 패킷이 최적의 속도로 전송되도록 보장하여 패킷이 정체되거나 패킷 손실이 발생하는 것을 방지합니다.
• TCP에 비해 성능과 처리량이 크게 증가합니다. YouTube와 같은 동영상 서비스의 경우 QUIC은 동영상 시청 시 리버퍼링 작업을 30%까지 줄이는 것으로 나타났습니다.

출처 : opennet.ru