쿼크

QUIC
쿼크
통신 프로토콜
목적범용
개발자IETF, 구글
서론2012년 10월 12일, 9년 전(2012년 10월 12일)
포트443[1]
RFC RFC9000, RFC8999, RFC9001, RFC9002
웹 사이트quicwg.org
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

QUIC('퀵'으로 발음)는 Google의 [4]Jim Roskind에 의해 처음 설계되어 [5]2012년에 구현 및 배포된 범용[2] 트랜스포트[3] 레이어 네트워크 프로토콜로, 2013년에 실험 [6][7][8]확대로 공개 발표되었으며 IETF [9]회의에서 설명되었습니다.QUIC는 크롬 웹 브라우저에서 구글 [10]서버로 연결되는 모든 연결의 절반 이상에서 사용됩니다.Microsoft Edge(오픈 소스 크롬 [11][12][13]브라우저의 파생 모델) 및 Firefox가[14] 이를 지원합니다.Safari는 프로토콜을 구현하지만 기본적으로 [15]활성화되지 않습니다.

그것의 이름은 처음에 "Quick UDP Internet Connections"[4][9]의 약자로 제안되었지만, IETF의 QUIC라는 단어의 사용은 약어가 아니라 단지 프로토콜의 [2]이름일 뿐이다.QUIC는 현재 [3][10]TCP를 사용하고 있는 접속 지향 웹 애플리케이션의 성능을 향상시킵니다.이는 UDP(User Datagram Protocol)를 사용하여 두 엔드포인트 간에 다수의 다중 접속을 확립함으로써 이루어지며, 많은 응용 프로그램에 대해 전송 계층에서 TCP가 사용되지 않도록 설계되어 프로토콜에 "TCP/2"[16]라는 별칭이 가끔 붙습니다.

QUIC는 HTTP/2의 멀티플렉스 접속과 연동하여 여러 데이터 스트림이 독립적으로 모든 엔드포인트에 도달할 수 있도록 하여 다른 스트림을 수반하는 패킷 손실과는 무관하게 동작합니다.반대로 TCP 패킷 중 하나가 지연되거나 손실된 경우 Transmission Control Protocol(TCP)에서 호스트되는 HTTP/2는 모든 멀티플렉스 스트림의 헤드오브라인 차단 지연이 발생할 수 있습니다.

QUIC의 2차 목표에는 접속과 전송 지연의 단축과 폭주를 피하기 위한 각 방향의 대역폭 예측이 포함됩니다.또한 congestion 제어 알고리즘을 커널 공간이 아닌 양쪽 엔드포인트의 사용자 공간으로 이동시키므로 이러한 알고리즘이 보다 빠르게 개선될 수 있다고 주장됩니다.또한 프로토콜은 오류가 예상될 때 성능을 더욱 향상시키기 위해 FEC(Forward Error Correction)로 확장할 수 있으며 이는 프로토콜 진화의 다음 단계로 간주됩니다.

2015년 6월,[17][18] 표준화를 위한 QUIC 규격의 인터넷 초안이 IETF에 제출되었다.QUIC 워킹 그룹은 2016년에 [19]설립되었습니다.2018년 10월, IETF의 HTTP와 QUIC 작업 그룹은 공동으로 QUIC를 통한 HTTP 매핑을 "HTTP/3"[20]로 부르기로 결정했습니다.2021년 5월에 IETF는 RFC 8999, RFC 9001 및 RFC 9002에 [21]의해 지원되는 RFC 9000에서 QUIC를 표준화했습니다.

배경

Transmission Control Protocol(TCP)은 두 엔드포인트 간에 데이터 스트림을 전송하기 위한 인터페이스를 제공하는 것을 목적으로 합니다.데이터가 TCP 시스템에 건네져 데이터가 완전히 같은 형식으로 상대편에 도달하도록 합니다.그렇지 않으면 접속은 에러 상태가 존재하는 [22]것을 나타냅니다.

이를 위해 TCP는 데이터를 네트워크 패킷으로 분할하고 각 패킷에 소량의 데이터를 추가합니다.이 추가 데이터에는 손실 또는 잘못된 순서로 도착한 패킷을 검출하기 위해 사용되는 시퀀스 번호와 패킷 데이터 내의 오류를 검출할 수 있는 체크섬이 포함됩니다.어느 하나의 문제가 발생하면, TCP 는 Automatic Repeat Request(ARQ; 자동 반복 요구)를 사용해, 분실 또는 파손된 [22]패킷을 재발송신하도록 송신자에게 지시합니다.

대부분의 실장에서는 TCP는 접속상의 에러를 블로킹 조작으로서 인식해, 에러가 해결되거나 접속이 실패했다고 간주될 때까지 이후의 전송을 정지합니다.HTTP/2 프로토콜의 경우와 같이 단일 연결을 사용하여 여러 데이터 스트림을 전송하는 경우 이러한 스트림이 모두 차단됩니다. 단, 이러한 스트림 중 하나에 문제가 있을 수 있습니다.예를 들어 favicon에 사용되는 GIF 이미지를 다운로드하는 동안 오류가 하나 발생해도 해당 문제가 [22]해결될 때까지 페이지 전체가 대기합니다.이 현상을 헤드 오브 라인 블로킹이라고 합니다.

TCP 시스템은 "데이터 파이프" 또는 스트림처럼 보이도록 설계되었기 때문에 의도적으로 전송하는 데이터에 대한 이해가 거의 없습니다.이 데이터에 TLS를 사용한 암호화와 같은 추가 요건이 있는 경우 TCP 상단에서 실행 중인 시스템에서 TCP를 사용하여 접속 반대편에서 유사한 소프트웨어와 통신하도록 설정해야 합니다.이러한 종류의 셋업 작업에는 각각 독자적인 핸드쉐이크 프로세스가 필요합니다.이를 위해서는 연결이 확립될 때까지 여러 번의 요청과 응답이 필요합니다.장거리 통신의 고유한 지연으로 인해, 이는 전체 [22]전송에 상당한 오버헤드를 추가할 수 있습니다.

특성.

TLS 1.2를 사용한TCP와 비교한QUIC 핸드쉐이크

QUIC는 TCP 접속과 거의 동등하지만 지연 시간이 크게 단축되는 것을 목표로 합니다.이것은 주로 HTTP [22]트래픽의 동작을 이해하는 것에 의존하는2개의 변경을 통해 이루어집니다.

첫 번째 변경은 접속 셋업 중 오버헤드를 대폭 줄이는 것입니다.대부분의 HTTP 접속은 TLS를 요구하기 때문에 QUIC는 초기 핸드쉐이크 프로세스의 일부로 셋업 키와 지원되는 프로토콜을 교환합니다.클라이언트가 접속을 열면 응답 패킷에는 향후 패킷이 암호화를 사용하는 데 필요한 데이터가 포함됩니다.이것에 의해, TCP 접속을 설정해, 추가의 패킷을 개입시켜 시큐러티 프로토콜을 네고시에이트 할 필요가 없어집니다.다른 프로토콜도 여러 단계를 하나의 요청-응답으로 결합하여 동일한 방식으로 서비스할 수 있습니다.이 데이터는 초기 셋업에서 다음 요구뿐만 아니라 별도의 [22]연결로 네고시에이트되는 향후 요구에도 모두 사용할 수 있습니다.

두 번째 변경은 TCP가 아닌 UDP를 기반으로 사용하는 것입니다.이러한 변경에는 손실 복구가 포함되지 않습니다.대신 각 QUIC 스트림은 개별적으로 흐름 제어되며 손실된 데이터는 UDP가 아닌 QUIC 수준에서 재전송됩니다. 이는 위의 favicon 예시와 같이 한 스트림에서 오류가 발생할 경우 프로토콜 스택은 다른 스트림에 독립적으로 서비스를 계속할 수 있음을 의미합니다.대부분의 경우 TCP가 패킷의 누락 또는 파손을 감지하기 전에 상당한 추가 데이터를 수신하고 오류를 수정하는 동안 이 모든 데이터가 차단되거나 플러시되기 때문에 오류 발생 가능성이 높은 링크의 성능을 향상시키는데 매우 유용합니다.QUIC에서는 단일 다중 스트림이 [23]복구되는 동안 이 데이터를 무료로 처리할 수 있습니다.

또한 QUIC에는 전체적인 지연과 스루풋을 개선하는 기타 일상적인 변경도 다수 포함되어 있습니다.예를 들어 패킷은 개별적으로 암호화되므로 암호화된 데이터가 부분 패킷을 대기하지 않습니다.이것은 일반적으로 암호화 레코드가 bytestream에 있고 프로토콜 스택이 이 스트림 내의 상위 계층 경계를 인식하지 못하는 TCP에서는 가능하지 않습니다.이것들은 위에서 실행되고 있는 레이어에 의해서 네고시에이트 할 수 있습니다만, QUIC는 이 모든 것을 단일 핸드쉐이크 [9]프로세스로 실행하는 것을 목표로 하고 있습니다.

QUIC 시스템의 또 다른 목표는 모바일 기기 사용자가 로컬 WiFi 핫스팟에서 모바일 네트워크로 이동할 때 발생하는 것과 같은 네트워크 전환 이벤트 시 성능을 향상시키는 것이었습니다.TCP에서 이 문제가 발생하면 기존의 모든 접속이1개씩 타임아웃 되어 필요에 따라 재정립되는 장황한 프로세스가 시작됩니다.이 문제를 해결하기 위해 QUIC에는 소스에 관계없이 서버로의 접속을 일의로 식별하는 접속 식별자가 포함되어 있습니다.이것에 의해, 유저의 IP 주소가 [24][better source needed]변경되어도 원래의 접속 ID 는 유효하기 때문에, 항상 이 ID 를 포함한 패킷을 송신하는 것만으로 접속을 재정립할 수 있습니다.

QUIC는 운영체제 커널이 아닌 애플리케이션 공간에서 구현할 수 있습니다.이 경우 일반적으로 애플리케이션 간에 데이터가 이동될 때 컨텍스트스위치로 인해 추가적인 오버헤드가 발생합니다.그러나 QUIC의 경우 프로토콜 스택은 단일 응용 프로그램에서 사용하도록 설계되어 있으며, 각 응용 프로그램은 UDP에서 호스트되는 자체 연결을 가지고 있습니다. 궁극적으로 전체 HTTP/2 스택의 대부분이 응용 프로그램(또는 일반적으로 라이브러리)에 이미 있기 때문에 차이가 매우 작을 수 있습니다.이러한 라이브러리에 나머지 부분(기본적으로 오류 수정)을 배치하는 것은 HTTP/2 스택의 크기나 [9]전체 복잡성에는 거의 영향을 미치지 않습니다.

이 조직에서는 업데이트를 위해 커널을 변경할 필요가 없으므로 향후 변경을 보다 쉽게 수행할 수 있습니다.QUIC의 장기적인 목표 중 하나는 Forward Error Correction(FEC; 전방 오류 정정) 및 congestion [24]제어 개선을 위한 새로운 시스템을 추가하는 것입니다.

TCP에서 UDP로의 이행에 관한 한 가지 우려되는 점은 TCP가 널리 채택되고 있으며 인터넷 인프라스트럭처의 많은 "중간 상자"가 TCP와 환율 제한 또는 UDP 차단에 맞춰져 있다는 것입니다.구글은 이를 특징짓기 위해 여러 가지 탐색 실험을 실시했고, 이러한 [4]방식으로 차단된 접속은 극히 일부에 불과하다는 것을 발견했습니다.이를 통해 신속한 TCP 폴백 시스템을 사용할 수 있게 되었습니다.Chromium의 네트워크 스택은 QUIC와 기존 TCP 연결을 동시에 열어서 대기 [25]시간을 무시할 수 있습니다.

Google QUIC(gQUIC)

구글에 의해 개발되어 QUIC라는 이름으로 IETF에 채택된 프로토콜(2012년에 이미 QUIC 버전 20 전후)은 IETF 내에서 계속 진화하고 개량된 QUIC와는 상당히 다르다.원래 구글 QUIC는 범용 프로토콜로 설계되었지만 초기에는 크롬에서 HTTP(S)를 지원하는 프로토콜로 배치되었다.IETF QUIC 프로토콜의 현재 진화는 범용 전송 프로토콜입니다.크롬 개발자들은 크롬의 QUIC에 대한 최신 인터넷 표준을 채택하고 완전히 준수하기 위한 IETF QUIC의 표준화 노력의 발전을 계속 추적했다.

도입

브라우저 지원

QUIC 코드는 [5]2012년부터 구글 크롬에서 실험적으로 개발되었으며 크롬 버전 29(2013년 [20]8월 20일 출시)의 일부로 발표되었다.현재 Chromium과 [26]Chrome에서 기본적으로 활성화되어 있습니다.

파이어폭스의 지원은 2021년 [27][14]5월에 제공되었습니다.

애플은 2020년 [28]4월 사파리 테크놀로지 프리뷰 104를 통해 웹킷 엔진에 실험적인 지원을 추가했다.MacOS Big Sur 및 iOS [29]14에 포함된 Safari 14에 공식 지원이 추가되었지만 이 기능은 수동으로 [30]켜야 합니다.

클라이언트 지원

QUIC 및 기타 프로토콜용 크로넷 라이브러리는 Google Play Services를 [31]통해 로드 가능한 모듈로 Android 애플리케이션에서 사용할 수 있습니다.

2019년 9월 11일에 출시된 cURL 7.66은 HTTP/3(즉, QUIC)[32][33]를 지원합니다.

2020년 10월 페이스북은[34] Instagram을 포함한 앱과 서버 인프라스트럭처를 QUIC로 이행하는 데 성공했다고 발표했으며, 이미 인터넷 트래픽의 75%가 QUIC를 사용하고 있으며, 구글의 모든 모바일 앱은 유튜브와 [35][36]Gmail을 포함한 QUIC를 지원하고 있다.우버의 모바일 앱도 [36]QUIC를 사용한다.

서버 지원

2017년 현재, 몇 가지 적극적으로 유지 보수되고 있는 구현이 있습니다.구글 서버는 QUIC를 지원하며 구글은 시제품 [37]서버를 공개했습니다.아카마이 테크놀로지스는 2016년 [38][39]7월부터 QUIC를 지원하고 있습니다.Quic-go라고[40] 불리는 Go 구현도 사용할 수 있으며 Caddy 서버에서 [41]실험적인 QUIC 지원을 제공합니다.2017년 7월 11일 LiteSpeed Technologies는 로드밸런서(WebADC)[42] 및 LiteSpeed Web Server [43]제품에서 QUIC 지원을 공식적으로 시작했습니다.2019년 10월 현재 QUIC 웹사이트의 88.6%가 LiteSpeed, 10.8%가 Nginx를 [44]사용하고 있다.단, 처음에는 구글 서버만이 HTTP-over-Q를 지원했습니다.UIC 커넥션즈, 페이스북도 2018년 [20]이 기술을 출시했으며,[45] Cloudflare는 2018년부터 QUIC 지원을 베타 기반으로 제공하고 있다.2021년 3월 현재 전체 웹사이트의 5.0%가 QUIC를 [46]사용하고 있습니다.Microsoft Windows Server 2022는 MsQuic을 통해 HTTP/3[47] 및 SMB over[48][49] QUIC 프로토콜을 지원합니다.Citrix의 Application Delivery Controller(Citrix ADC, NetScaler)는 버전 [50][51]13부터 QUIC 프록시로서 기능할 수 있습니다.

또한 오래된 커뮤니티 프로젝트도 몇 가지 있습니다.libquic은[52] QUIC의 Chromium 구현을 추출하여 의존성 요건을 최소화하도록 수정함으로써 생성되었으며 goquic은[53] libquic의 Go 바인딩을 제공합니다.마지막으로 quic-reverse-proxy는[54] 리버스 프록시 서버로서 동작하는 도커 이미지이며, QUIC 요구를 오리진서버가 인식할 수 있는 플레인 HTTP로 변환합니다.

.NET 5에서는 MsQuic [55]라이브러리를 사용한QUIC의 실험적인 지원이 도입되었습니다.

소스 코드

다음 구현의 QUIC 또는 gQUIC는 소스 형식으로 사용할 수 있습니다.
실행 면허증. 언어 묘사
크롬 BSD 라이선스 C++ Chrome 웹 브라우저의 소스 코드와 참조 gQ입니다.UIC의 실장.테스트에 사용할 수 있는 스탠드아론의 gQUIC 및 QUIC 클라이언트와 서버 프로그램이 포함되어 있습니다.참조 가능한 소스 코드.이 버전은 LINE의 스텔라이트와 Google의 크로넷의 기반이기도 합니다.
MsQuic MIT 라이선스 C 범용 QUIC 라이브러리로 설계된 Microsoft의 크로스 플랫폼 QUIC 구현.Windows 및 크로스플랫폼에서 에 의해 사용됩니다.NET. Rust 레이어와 C# 인터오퍼레이어 사용 가능.
QUIC 라이브러리(mvfst) MIT 라이선스 C++ mvfst(빠른 이동으로 발음됨)는 Facebook에 의해 C++에서 IETF QUIC 프로토콜의 클라이언트 및 서버 구현입니다.
LiteSpeed QUIC 라이브러리 (lsquic) MIT 라이선스 C 이것은 LiteSpeed Web Server 및 OpenLiteSpeed에서 사용되는QUIC 및 HTTP/3 구현입니다.
ngtcp2 MIT 라이선스 C 이것은 암호화 라이브러리에 의존하지 않고 OpenSSL 또는 GnuTLS에서 작동하는 QUIC 라이브러리입니다.HTTP/3의 경우 nghttp3와 같은 별도의 라이브러리가 필요합니다.
키체 BSD-2-Clause 라이선스 녹 소켓에 의존하지 않고 C/C++ 어플리케이션에서 사용하기 위한 C API를 제공합니다.
퀼리 MIT 라이선스 C 이 라이브러리는 H2O 웹 서버용 QUIC 구현입니다.
퀵고 MIT 라이선스 가세요 이 라이브러리는 Caddy 웹 서버에서 QUIC를 지원합니다.클라이언트 기능도 사용할 수 있습니다.
퀸 Apache 라이센스 2.0 녹
니코 Apache 라이센스 2.0 녹 Mozilla로부터의 이 실장은 파이어폭스 웹 브라우저에서 사용되는 네트워크 라이브러리인 Necko에 통합될 예정입니다.
아오키 BSD-3-Clause 라이선스 파이썬 이 라이브러리는 I/O가 필요 없는 API를 클라이언트와 서버 모두에 내장하기에 적합합니다.
피코쿠쿠 BSD-3-Clause 라이선스 C IETF 사양에 따른 최소한의 QUIC 구현
키보드 MIT 라이선스 C 확장 기능을 플러그인으로 동적으로 로드할 수 있는 eBPF 가상 머신을 포함하는 확장 가능한 QUIC 구현
수량 BSD-2-Clause 라이선스 C Quant는 기존 POSIX 플랫폼(Linux, MacOS, FreeBSD 등) 및 임베디드 시스템을 지원합니다.
퀵 BSD-3-Clause 라이선스 하스켈 이 패키지는 Haskell 경량 스레드를 기반으로 QUIC를 구현합니다.
넷티-스파이프-스파이프-스파이크 Apache 라이센스 2.0 자바 이 패키지는 키체 구현에 기반하여 넷티에서 QUIC를 구현합니다.
nodejs-quic MIT 라이선스 노드 JS 이 실험 패키지는 Nodejs용 QUIC를 구현합니다.
s2n-quic Apache 라이센스 2.0 녹 Amazon Web Services에서 제공하는 오픈 소스 Rust 구현

「 」를 참조해 주세요.

레퍼런스

  1. ^ "A quick look at QUIC". blog.apnic.net. 2022-01-12. Retrieved 2022-01-12.{{cite web}}: CS1 maint :url-status (링크)
  2. ^ a b RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport. IETF. doi:10.17487/RFC9000. RFC 9000. Retrieved 2022-02-08.
  3. ^ a b Nathan Willis. "Connecting on the QUIC". Linux Weekly News. Retrieved 2013-07-16.
  4. ^ a b c "QUIC: Design Document and Specification Rationale". Jim Roskind, Chromium Contributor.
  5. ^ a b "First Chromium Code Landing: CL 11125002: Add QuicFramer and friends". Retrieved 2012-10-16.
  6. ^ "Experimenting with QUIC". Chromium Official Blog. Retrieved 2013-07-16.
  7. ^ "QUIC, Google wants to make the web faster". François Beaufort, Chromium Evangelist.
  8. ^ "QUIC: next generation multiplexed transport over UDP". YouTube. Retrieved 2014-04-04.
  9. ^ a b c d "QUIC: IETF-88 TSV Area Presentation" (PDF). Jim Roskind, Google. Retrieved 2013-11-07.
  10. ^ a b Lardinois, Frederic. "Google Wants To Speed Up The Web With Its QUIC Protocol". TechCrunch. Retrieved 2016-10-25.
  11. ^ Mackie, Kurt; August 26, 2021. "Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser". Redmond Magazine. Retrieved 2022-05-08.
  12. ^ Christopher Fernandes (April 3, 2018). "Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5". Retrieved 2020-05-08.
  13. ^ "Chromium (web browser)", Wikipedia, 2022-05-14, retrieved 2022-05-31
  14. ^ a b Dragana Damjanovic (2021-04-16). "QUIC and HTTP/3 Support now in Firefox Nightly and Beta". Mozilla. Retrieved 2021-10-11.
  15. ^ "The state of QUIC and HTTP/3 2020". www.fastly.com. Retrieved 2020-10-21.
  16. ^ Tatsuhiro Tsujikawa. "ngtcp2". GitHub. Retrieved 2020-10-17.
  17. ^ "Google Will Propose QUIC As IETF Standard". InfoQ. Retrieved 2016-10-25.
  18. ^ "I-D Action: draft-tsvwg-quic-protocol-00.txt". i-d-announce (Mailing list). 17 Jun 2015.
  19. ^ "QUIC - IETF Working Group". datatracker.ietf.org. Retrieved 2016-10-25.
  20. ^ a b c Cimpanu, Catalin (12 November 2018). "HTTP-over-QUIC to be renamed HTTP/3". ZDNet.
  21. ^ "QUIC is now RFC 9000". www.fastly.com. 2021-05-27. Retrieved 2021-05-28.{{cite web}}: CS1 maint :url-status (링크)
  22. ^ a b c d e f Bright, Peter (12 November 2018). "The next version of HTTP won't be using TCP". Arstechnica.
  23. ^ Behr, Michael; Swett, Ian. "Introducing QUIC support for HTTPS load balancing". Google Cloud Platform Blog. Retrieved 16 June 2018.
  24. ^ a b Simon, Clayton (May 2021). "QUIC: A UDP-Based Multiplexed and Secure Transport". IETF.org.{{cite web}}: CS1 maint :url-status (링크)
  25. ^ "Applicability of the QUIC Transport Protocol". IETF Network Working Group. Oct 22, 2018.
  26. ^ Liebetrau, Etienne (2018-06-22). "How Google's QUIC Protocol Impacts Network Security and Reporting". Fastvue - Simple Internet Usage Reporting. Retrieved 2022-04-02.
  27. ^ Cimpanu, Catalin (Sep 26, 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved Sep 27, 2019.
  28. ^ "Release Notes for Safari Technology Preview 104". webkit.org. 8 April 2020. Retrieved 7 August 2020.
  29. ^ "Safari 14 Release Notes". developer.apple.com. Retrieved 4 December 2020.
  30. ^ "How to enable HTTP3 in Chrome / Firefox / Safari". bram.us. April 8, 2020.
  31. ^ "Perform network operations using Cronet". Android Developers. Retrieved 2019-07-20.
  32. ^ "curl - Changes". curl.haxx.se. Retrieved 2019-09-30.
  33. ^ "curl 7.66.0 – the parallel HTTP/3 future is here daniel.haxx.se". Retrieved 2019-09-30.
  34. ^ "How Facebook is bringing QUIC to billions". Facebook Engineering. 2020-10-21. Retrieved 2020-10-23.
  35. ^ "How Google's QUIC Protocol Impacts Network Security and Reporting". Fastvue. 2020-10-21. Retrieved 26 June 2021.
  36. ^ a b Green, Emily (30 September 2020). "This is what you need to know about the new QUIC protocol". NordVPN. Retrieved 26 June 2021.
  37. ^ https://code.google.com/p/chromium/codesearch#chromium/src/net/tools/quic/quic_server.cc
  38. ^ Akamai의 QUIC 지원, 2020년 5월 20일 회수.
  39. ^ 야생 수동 능동 측정 회의(PAM)의 QUIC, 2018, 2020년 5월 20일 회수.
  40. ^ "lucas-clemente/quic-go". Aug 7, 2020. Retrieved Aug 7, 2020 – via GitHub.
  41. ^ 2016년 7월 13일 캐디의 QUIC 지원.
  42. ^ "LiteSpeed Web ADC - Load Balancer - LiteSpeed Technologies". www.litespeedtech.com. Retrieved Aug 7, 2020.
  43. ^ Lite Speed Technologies QUIC 블로그 포스트, 2017년 7월 11일 취득.
  44. ^ "Distribution of Web Servers among websites that use QUIC". w3techs.com. Retrieved Aug 7, 2020.
  45. ^ "Get a head start with QUIC". 2018-09-25. Retrieved 2019-07-16.
  46. ^ "Usage Statistics of QUIC for Websites, March 2021". w3techs.com. Retrieved 2021-03-04.
  47. ^ "Enabling HTTP/3 support on Windows Server 2022". 24 August 2021.
  48. ^ "SMB over QUIC".
  49. ^ https://redmondmag.com/articles/2021/08/26/native-quic-in-windows-edge.aspx
  50. ^ "Policy configuration for HTTP/3 traffic Citrix ADC 13.0".
  51. ^ "Need for speed? – Just an other Citrix ADC Blog".
  52. ^ "devsisters/libquic". Aug 5, 2020. Retrieved Aug 7, 2020 – via GitHub.
  53. ^ "devsisters/goquic". Aug 5, 2020. Retrieved Aug 7, 2020 – via GitHub.
  54. ^ "Docker Hub". hub.docker.com. Retrieved Aug 7, 2020.
  55. ^ ".NET 5 Networking Improvements". .NET Blog. 2021-01-11. Retrieved 2021-01-26.

외부 링크