Jump to content

QUIC

This is a fully translated article. Click here for more information.
From DawoumWiki, the free Mathematics self-learning
Original article: w:QUIC
QUIC
Communication protocol
PurposeGeneral Purpose
Developer(s)IETF, Google
IntroducedOctober 12, 2012; 11 years ago (2012-10-12)
Based onUDP
OSI layerTransport layer
Port(s)443[1]
RFC(s)RFC 9000, RFC 8999, RFC 9001, RFC 9002
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

QUIC ("퀵"으로 발음)은 일반적인-목적[2] 전송 계층[3] 네트워크 프로토콜로서, 구글에서 Jim Roskind에 의해 처음 설계되어,[4] 2012년에 구현되고 배포되었으며,[5] 실험이 확대됨에 따라 2013년에 공개적으로 발표되었고,[6][7][8] IETF 회의에서 설명되었습니다.[9] QUIC은 크롬 웹 브라우저에서 구글 서버로의 연결되는 모든 연결의 절반 이상에서 사용됩니다.[10] 마이크로소프트 엣지(Microsoft Edge, 오픈-소스 크로미엄 브라우저의 파생물)[11][12][13] 및 파이어폭스가[14] 그것을 지원합니다. 사파리(Safari)는 프로토콜을 구현하지만, 기본적으로 활성화되어 있지 않습니다.[15]

비록 그 이름은 처음에 "Quick UDP Internet Connections"의 약자로 제안되었지만,[4][9] 단어 QUIC의 IETF의 사용은 약어가 아닙니다; 그것은 단순히 프로토콜의 이름입니다.[2] QUIC은 현재 TCP를 사용하는 연결-지향 웹 응용 프로그램의 성능을 향상시킵니다.[3][10] 그것은 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)을 사용하여 두 끝점 사이에 다수의 다중화된(multiplexed) 연결을 설정함으로써 이를 수행하고 많은 응용 프로그램에 대해 전송 계층에서 TCP를 폐기하도록 설계되어, 가끔 프로토콜에 "TCP/2"라는 별칭이 붙습니다.[16]

QUIC은 HTTP/2의 다중화된 연결과 함께 작동하여, 다중 데이터의 스트림을 모든 끝점에 독립적으로 도달하도록 허용하고, 따라서 다른 스트림과 관련된 패킷 손실과 무관합니다. 반대로, 전송 제어 프로토콜(Transmission Control Protocol, TCP)에서 호스팅되는 HTTP/2는 만약 TCP 패킷의 어떤 것이 지연되거나 손실되면 모든 다중화된 스트림의 HOL 차단(head-of-line-blocking) 지연을 겪을 수 있습니다.

QUIC의 두 번째 목표는 감소된 연결과 전송 지연 시간을 포함하고, 혼잡을 피하기 위해 각 방향에서 대역폭 추정을 포함합니다. 그것은 역시 혼잡 제어 알고리듬을 커널 공간이 아닌 두 끝점의 사용자 공간으로 이동하며, 이는 이들 알고리듬을 보다 빠르게 개선할 수 있다고 주장합니다. 대안적으로, 그 프로토콜은 오류가 예상될 때 성능을 더욱 향상시키기 위해 순방향 오류 수정(forward error correction, FEC)으 확장될 수 있고, 이것은 프로토콜 진화의 다음 단계로 봅니다. 그것은 상당한 골화를 겪은 TCP와 달리 진화-가능한 상태를 유지하도록 프로토콜 골화를 방지하도록 설계되어 왔습니다.

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

Background

전송 제어 프로토콜(Transmission Control Protocol, 또는 TCP)는 두 끝점 사이에 데이터의 스트림을 보내기 위한 인터페이스를 제공하는 것을 목표로 합니다. 데이터는 TCP 시스템으로 전달되어, 데이터가 정확하게 같은 형식으로 상대방에게 전달되도록 보장하거나, 그 연결은 오류 조건이 있음을 나타낼 것입니다.[22]

이를 위해, TCP는 데이터를 네트워크 패킷으로 나누고 각 패킷에 소량의 데이터를 추가합니다. 이 추가 데이터는 손실되거나 잘못된 순서로 도착한 패킷을 감지하는 데 사용되는 순서열 번호와 패킷 데이터 내의 오류를 감지할 수 있는 체크섬(checksum)을 포함합니다. 어떤 문제가 발생할 때, TCP는 자동 반복 요청(automatic repeat request, ARQ)을 사용하여 손실되거나 손상된 패킷을 다시 보내도록 발신자에게 알립니다.[22]

대부분의 구현에서, TCP는 연결의 임의의 오류를 차단 작업으로 보고, 오류가 해결되거나 연결이 실패한 것으로 고려될 때까지 추가적인 전송을 중지합니다. 만약 단일 연결이 HTTP/2 프로토콜의 경우와 같이 여러 데이터의 스트림을 보내기 위해 사용되는 것이면, 이들 스트림 중 하나만 문제가 있을 수 있지만 모든 스트림이 차단됩니다. 예를 들어, 파비콘에 사용되는 GIF 이미지를 다운로드하는 동안 단일 오류가 발생하면, 페이지의 나머지 전체가 해당 문제가 해결될 때까지 대기합니다.[22] 이 현상은 HOL 차단(head-of-line blocking)으로 알려져 있습니다.

TCP 시스템은 "데이터 파이프" 또는 스트림처럼 보이도록 설계되었기 때문에, 그것은 의도적으로 전송하는 데이터에 대한 이해가 거의 없습니다. 만약 해당 데이터가 TLS를 사용한 암호화와 같은 추가적인 요구 사항을 가지면, 이것은 TCP를 사용하여 연결의 다른 쪽 끝에 있는 유사한 소프트웨어와 통신하기 위해 TCP의 꼭대기에서 실행하는 시스템에 의해 설정되어야 합니다. 이들 종류의 각 설정 임무는 자체의 핸드셰이크 과정을 요구합니다. 이것은 종종 연결이 설립될 때까지 요청과 응답을 여러 번 왕복하도록 요구합니다. 장거리 통신의 고유한 지연 시간으로 인해, 이것은 전체 전송에 상당한 오버헤드를 더할 수 있습니다.[22]

TCP는 와이어 이미지가 일반-텍스트(cleartext)로 되어 있어 미들박스(middleboxes)에서 볼 수 있고 변경할 수 있기 때문에[23] 프로토콜 골화 문제(protocol ossification)를 겪었습니다.[24] 한 측정에 따르면 인터넷 경로의 1/3이 TCP 메타데이터를 수정하는 중개자를 하나 이상 만나고 경로의 6.5%는 중개자로부터 유해한 골화 효과를 경험합니다.[25] TCP에 대한 확장이 영향을 받아 왔습니다: MPTCP의 설계는 미들박스 동작에 의해 제한되었고,[26][27] TCP Fast Open의 배포도 마찬가지로 방해를 받아 왔습니다.[28][24]

Characteristics

Handshake of QUIC compared to TCP with TLS1.2

QUIC은 TCP 연결과 거의 동등하지만 훨씬 감소된 지연 시간을 갖는 것을 목표로 합니다. 그것은 주로 HTTP 트래픽의 동작에 대한 이해에 의존하는 두 가지 변경 사항을 통해 이를 수행합니다.[22]

첫 번째 변경 사항은 연결 설정 동안 오버헤드를 크게 줄이는 것입니다. 대부분의 HTTP 연결은 TLS를 요구할 것이므로, QUIC은 설정 키와 지원되는 프로토콜의 교환을 초기 핸드셰이크 과정의 일부로 만듭니다. 클라이언트가 연결을 열 때, 응답 재킷은 향후 패킷에 대해 암호화를 사용하는 데 필요한 데이터를 포함합니다. 이렇게 하면 TCP 연결을 설정하고 그런-다음 추가 패킷을 통해 보안 프로토콜을 협상할 필요가 없습니다. 다른 프로토콜은 여러 단계를 단일 요청-응답으로 결합하여 같은 방법에서 서비스될 수 있습니다. 그런-다음 이 데이터는 초기 설정에서 다음 요청과 별도의 연결로 협상되는 향후 요청 모두에 사용할 수 있습니다.[22]

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

QUIC은 역시 전반적인 대기 시간과 처리량을 향상시키는 다른 많은 일상적인 변경 사항을 포함하고 있습니다. 예를 들어, 패킷은 부분 패킷을 기다리는 암호화된 데이터가 발생하지 않도록 개별적으로 암호화됩니다. 이것은 암호화 레코드가 바이트-스트림에 있고 프로토콜 스택이 이 스트림 내의 상위 계층 경계를 인식하지 못하는 TCP 아래에서 일반적으로 가능하지 않습니다. 이것들은 꼭대기에서 실행되는 계층에 의해 협상될 수 있지만, QUIC은 단일 핸드셰이크 과정에서 이 모든 작업을 수행하는 것을 목표로 합니다.[9]

QUIC 시스템의 또 다른 목표는 모바일 장치 사용자가 지역 와이파이 핫스팟에서 모바일 네트워크로 이동할 때 발생하는 것과 같은 네트워크-전환 이벤트 동안 성능을 개선하는 것이었습니다. 이것이 TCP에서 발생할 때, 모든 각 기존 연결이 하나씩 시간 초과되고 그런-다음 요청에 대한 다시-설립되는 긴 과정이 시작합니다. 이 문제를 해결하기 위해, QUIC은 출처에 관계없이 서버에 대한 연결을 고유하게 식별하는 연결 식별자를 포함하고 있습니다. 이렇게 하면 사용자의 IP 주소가 변경되더라도 원래 연결 ID가 여전히 유효하기 때문에 항상 이 ID를 포함하는 패킷을 전송하여 간단히 연결을 다시-설립할 수 있습니다.[30]

QUIC은 운영 시스템 커널에 있는 것이 아닌 응용 프로그램-공간에서 구현될 수 있습니다. 이것은 일반적으로 데이터가 응용 프로그램 사이에 이동할 때 컨텍스트 전환으로 인해 추가 오버헤드를 유발합니다. 어쨌든, QUIC의 경우에서, 프로토콜 스택은 단일 응용 프로그램에서 사용하도록 되어 있으며, 각 응용 프로그램은 UDP에서 호스팅되는 자체 연결을 갖는 QUIC을 사용합니다. 궁극적으로 전체 HTTP/2 스택의 많은 부분이 이미 응용 프로그램 (또는 더 일반적으로 해당 라이브러리)에 있기 때문에 그 차이는 매우 작을 수 있습니다. 그들 라이브러리에 남아있는 부분, 본질적으로 오류 수정을 배치하는 것은 HTTP/2 스택의 크기 또는 전체 복잡성에 거의 영향을 미치지 않습니다.[9]

이 조직은 업데이트를 위해 커널을 변경할 필요가 없기 때문에, 향후 변경을 보다 쉽게 수행할 수 있습니다. QUIC의 장기 목표 중 하나는 순방향 오류 수정(forward error correction, FEC) 및 혼잡 제어 개선을 위한 새로운 시스템을 추가하는 것입니다.[30]

TCP에서 UDP로의 이동에 대한 한 가지 우려 사항은 TCP가 널리 채택되고 인터넷 인프라에서 많은 "미들박스"가 TCP 및 속도-제한 또는 심지어 UDP 차단에 맞게 조정된다는 것입니다. 구글은 이를 특성화하기 위해 여러 탐색적 실험을 수행했으며 소수의 연결만 이러한 방식으로 차단되었음을 발견했습니다.[4] 이로 인해 TCP로의 빠른 폴백 시스템이 사용되었습니다; 크로미엄(Chromium)의 네트워크 스택은 QUIC 및 기존 TCP 연결을 동시에 열어 무시할 수 있는 대기 시간으로 대체할 수 있습니다.[31]

QUIC은 배치와 진화가 가능하고 골화 방지 특성을 갖도록 특별히 설계되었습니다;[32] 그것은 이들 목적을 위해 와이어 이미지를 의도적으로 최소화하기 위한 최초의 IETF 전송 프로토콜입니다.[33] 암호화된 헤더 외에도, 그것은 '기름칠'되어 있고 프로토콜 불변을 명시적으로 가집니다.[34]

Google QUIC (gQUIC)

구글에 의해 만들어졌었고 QUIC (이미 2012년에 QUIC 버전 20을 중심으로)라는 이름으로 IETF에 도입된 프로토콜은 IETF 내에서 계속 발전하고 개선되어 온 QUIC와는 상당히 다릅니다. 원래 구글 QUIC은 일반적인 목적 프로토콜로 설계되었지만, 처음에는 크로미엄에서 HTTP(S)를 지원하는 프로토콜로 배포되었습니다. IETF QUIC 프로토콜의 현재 진화는 일반적인 목적 전송 프로토콜입니다. 크로미엄 개발자는 크로미엄의 QUIC에 대한 최신 인터넷 표준을 채택하고 완전히 준수하기 위한 IETF QUIC의 표준화 노력의 진화를 계속 추적했습니다.

Adoption

Browser support

QUIC 코드는 2012년에 시작하여 구글 크롬(Google Chrome)에서 실험적으로 개발되었고,[5] 크로미엄 버전 29 (2013년 8월 20일 출시)의 일부로 발표되었습니다.[20] 그것은 현재 크로미엄과 크롬에서 기본적으로 활성화되어 있습니다.[35]

파이어폭스(Firefox)에서 지원은 2021년 5월에 이루어졌습니다.[36][14]

애플(Apple)은 2020년 4월 Safari Technology Preview 104를 통해 WebKit 엔진에 실험적 지원을 추가했습니다.[37] macOS Big Sur 및 iOS 14에 포함된 사파리(Safari) 14에 공식 지원이 추가되었지만,[38] 이 기능은 수동으로 켜야 합니다.[39]

Client support

QUIC 및 기타 프로토콜에 대해 cronet 라이브러리는 구글 플레이 서비스를 통해 적재될 수 있는 모듈로 안드로이드 응용 프로그램에서 사용할 수 있습니다.[40]

cURL 7.66은, 2019년 9월 11에 출시되었으며, HTTP/3 (및 따라서 QUIC)를 지원합니다.[41][42]

2020년 10월에, Facebook은 인스타그램을 포함한 앱과 서버 인프라를 QUIC으로 성공적으로 마이그레이션했고, 이미 인터넷 트래픽의 75%가 QUIC을 사용하고 있다고 발표했습니다.[43] 구글의 모든 모바일 앱은 YouTube와 Gmail을 포함하여 QUIC을 지원합니다.[44][44] Uber의 모바일 앱도 QUIC을 사용합니다.[45]

Server support

2017년 당시, 몇 가지 적극적으로 유지 관리되는 구현이 있습니다. 구글 서버는 QUIC를 지원하고 구글은 프로토타입 서버를 게시했습니다.[46] Akamai Technologies는 2016년 7월이래로 QUIC를 지원해 왔습니다.[47][48] quic-go라는 Go 구현도 사용할 수 있고,[49] Caddy 서버에서 실험적인 QUIC 지원을 강화합니다.[50] 2017년 7월 11일에, LiteSpeed Technologies는 공식적으로 로드 밸런서 (WebADC) 및 LiteSpeed 웹 서버 제품에서 QUIC를 지원하기 시작했습니다.[51] 2019년 10월 당시, QUIC 웹사이트의 88.6%가 LiteSpeed를 사용했고 10.8%가 엔진엑스(Nginx)를 사용했습니다.[52] 비록 처음에는 구글 서버만 HTTP-over-QUIC 연결을 지원했지만, Facebook도 2018년에 이 기술을 출시했고,[20] Cloudflare는 2018년부터 베타 기반으로 QUIC 지원을 제공하고 있습니다.[53] 2021년 3월 당시, 모든 웹사이트의 5.0%가 QUIC를 사용합니다.[54] Microsoft Windows Server 2022는 MsQuic을 통해 HTTP/3[55] 및 SMB over QUIC[56][11] 프로토콜을 모두 지원합니다. Citrix의 Application Delivery Controller (Citrix ADC, NetScaler)는 버전 13이래로 QUIC 프록시로 작동할 수 있습니다.[57][58]

게다가, 몇 가지 오래된 공동체 프로젝트가 있습니다: libquic은[59] QUIC의 크로미엄 구현을 추출하고 종속성 요구 사항을 최소화하기 위해 수정함으로써 만들어졌고, goquic은[60] libquic의 Go 바인딩을 제공합니다. 마지막으로 quic-reverse-proxy는[61] 역방향 프록시 서버 역할을 하는 Docker 이미지로, QUIC 요청을 원본 서버에서 이해할 수 있는 일반 HTTP로 변환합니다.

.NET 5는 MsQuic 라이브러리를 사용하여 QUIC에 대한 실험적 지원을 도입합니다.[62]

Source code

The following implementations of QUIC or gQUIC are available in source form:
Implementation License Language Description
Chromium BSD License C++ This is the source code of the Chrome web browser and the reference gQUIC implementation. It contains a standalone gQUIC and QUIC client and server programs that can be used for testing. Browsable source code. This version is also the basis of LINE's stellite and Google's cronet.
MsQuic MIT License C A cross platform QUIC implementation from Microsoft designed to be a general purpose QUIC library. Used in Windows and cross platform by .NET. Rust and C# interop layers available.
QUIC Library (mvfst) MIT License C++ mvfst (Pronounced move fast) is a client and server implementation of IETF QUIC protocol in C++ by Facebook.
LiteSpeed QUIC Library (lsquic) MIT License C This is the QUIC and HTTP/3 implementation used by LiteSpeed Web Server and OpenLiteSpeed.
ngtcp2 MIT License C This is a QUIC library that's crypto library agnostic and works with OpenSSL or GnuTLS. For HTTP/3, it needs a separate library like nghttp3.
Quiche BSD-2-Clause License Rust Socket-agnostic and exposes a C API for use in C/C++ applications.
quicly MIT License C This library is the QUIC implementation for the H2O web server.
quic-go MIT License Go This library provides QUIC support in Caddy web server. Client functionality is also available.
Quinn Apache License 2.0 Rust
Neqo Apache License 2.0 Rust This implementation from Mozilla is planned to be integrated in Necko, a network library used in the Firefox web browser
aioquic BSD-3-Clause License Python This library features an I/O-free API suitable for embedding in both clients and servers.
picoquic BSD-3-Clause License C A minimal implementation of QUIC aligned with the IETF specifications
pquic MIT License C An extensible QUIC implementation that includes an eBPF virtual machine that is able to dynamically load extensions as plugins
QUANT BSD-2-Clause License C Quant supports traditional POSIX platforms (Linux, MacOS, FreeBSD, etc.) as well as embedded systems.
quic BSD-3-Clause License Haskell This package implements QUIC based on Haskell lightweight threads.
netty-incubator-codec-quic Apache License 2.0 Java This package implements QUIC in netty based on the Quiche implementation.
nodejs-quic MIT License NodeJs This experimental package implements QUIC for Nodejs.
s2n-quic Apache License 2.0 Rust Open-source Rust implementation from Amazon Web Services
swift-quic Apache License 2.0 Swift Swift implementation pitched for incubation at the Swift Server Workgroup.

See also

References

  1. ^ "A quick look at QUIC". blog.apnic.net. 2022-01-12. Retrieved 2022-01-12.{{cite web}}: CS1 maint: url-status (link)
  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. ^ a b Mackie, Kurt; August 26, 2021. "Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser". Redmond Magazine. Retrieved 2022-05-08.{{cite web}}: CS1 maint: numeric names: authors list (link)
  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 (link)
  22. ^ a b c d e f Bright, Peter (12 November 2018). "The next version of HTTP won't be using TCP". Arstechnica.
  23. ^ Fairhurst & Perkins 2021, 4. Encryption and Authentication of Transport Headers.
  24. ^ a b Thomson & Pauly 2021, A.5. TCP.
  25. ^ Edeline & Donnet 2019, p. 175-176.
  26. ^ Raiciu et al. 2012, p. 1.
  27. ^ Hesmans et al. 2013, p. 1.
  28. ^ Rybczyńska 2020.
  29. ^ Behr, Michael; Swett, Ian. "Introducing QUIC support for HTTPS load balancing". Google Cloud Platform Blog. Retrieved 16 June 2018.
  30. ^ a b Simon, Clayton (May 2021). "QUIC: A UDP-Based Multiplexed and Secure Transport". IETF.org.{{cite web}}: CS1 maint: url-status (link)
  31. ^ "Applicability of the QUIC Transport Protocol". IETF Network Working Group. Oct 22, 2018.
  32. ^ Corbet 2018.
  33. ^ Trammell & Kuehlewind 2019, p. 2.
  34. ^ Thomson 2021, 2. Fixed Properties of All QUIC Versions.
  35. ^ Liebetrau, Etienne (2018-06-22). "How Google's QUIC Protocol Impacts Network Security and Reporting". Fastvue - Simple Internet Usage Reporting. Retrieved 2022-04-02.
  36. ^ Cimpanu, Catalin (Sep 26, 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved Sep 27, 2019.
  37. ^ "Release Notes for Safari Technology Preview 104". webkit.org. 8 April 2020. Retrieved 7 August 2020.
  38. ^ "Safari 14 Release Notes". developer.apple.com. Retrieved 4 December 2020.
  39. ^ "How to enable HTTP3 in Chrome / Firefox / Safari". bram.us. April 8, 2020.
  40. ^ "Perform network operations using Cronet". Android Developers. Retrieved 2019-07-20.
  41. ^ "curl - Changes". curl.haxx.se. Retrieved 2019-09-30.
  42. ^ "curl 7.66.0 – the parallel HTTP/3 future is here | daniel.haxx.se". Retrieved 2019-09-30.
  43. ^ "How Facebook is bringing QUIC to billions". Facebook Engineering. 2020-10-21. Retrieved 2020-10-23.
  44. ^ a b "How Google's QUIC Protocol Impacts Network Security and Reporting". Fastvue. 2020-10-21. Retrieved 26 June 2021.
  45. ^ Green, Emily (30 September 2020). "This is what you need to know about the new QUIC protocol". NordVPN. Retrieved 26 June 2021.
  46. ^ "QUIC server". 2012. Retrieved 2022-08-17.
  47. ^ QUIC support by Akamai, Retrieved 20 May 2020.
  48. ^ QUIC in the Wild, Passive Active Measurements Conference (PAM), 2018, Retrieved 20 May 2020.
  49. ^ "lucas-clemente/quic-go". Aug 7, 2020. Retrieved Aug 7, 2020 – via GitHub.
  50. ^ QUIC support in Caddy, Retrieved 13 July 2016.
  51. ^ LiteSpeed Technologies QUIC Blog Post, Retrieved July 11, 2017.
  52. ^ "Distribution of Web Servers among websites that use QUIC". w3techs.com. Retrieved Aug 7, 2020.
  53. ^ "Get a head start with QUIC". 2018-09-25. Retrieved 2019-07-16.
  54. ^ "Usage Statistics of QUIC for Websites, March 2021". w3techs.com. Retrieved 2021-03-04.
  55. ^ "Enabling HTTP/3 support on Windows Server 2022". 24 August 2021.
  56. ^ "SMB over QUIC".
  57. ^ "Policy configuration for HTTP/3 traffic | Citrix ADC 13.0".
  58. ^ "Need for speed? – Just an other Citrix ADC Blog".
  59. ^ "devsisters/libquic". Aug 5, 2020. Retrieved Aug 7, 2020 – via GitHub.
  60. ^ "devsisters/goquic". Aug 5, 2020. Retrieved Aug 7, 2020 – via GitHub.
  61. ^ "Docker Hub". hub.docker.com. Retrieved Aug 7, 2020.
  62. ^ ".NET 5 Networking Improvements". .NET Blog. 2021-01-11. Retrieved 2021-01-26.

Bibliography

External links

Retrieved from "https://dawoum.duckdns.org/w/index.php?title=QUIC&oldid=79818"