Er QUIC hurtigere end TCP?

For reelle arbejdsbelastninger, normalt ja - typisk 10-30 % hurtigere på mobilnetværk og netværk med tab, mindre fordel på rene kablede links. Forbedringen kommer fra multipleksing uden head-of-line blokering, hurtigere håndtryk og forbindelsesmigrering. På et perfekt netværk uden tab mindskes kløften.

Krypterer QUIC trafik?

Ja, obligatorisk og ende-til-ende. Hver QUIC-pakke efter håndtrykket er krypteret med TLS 1.3-nøgler. Der er ingen "almindelig QUIC"-tilstand. Netværksobservatører ser krypteret UDP med QUICs forbindelses-id; de kan ikke læse vandløbene indeni.

Hvorfor kører QUIC på UDP, ikke på sin egen IP-protokol?

Deployerbarhed. En ny IP-protokol ville kræve opdateringer til hver NAT, firewall og ISP-router på internettet - årtiers arbejde. UDP er allerede universelt understøttet. QUIC implementerer sin egen pålidelighed, overbelastningskontrol og bestilling oven på UDP's bedste indsats-datagrammer.

Kan en VPN-tunnel QUIC?

Ja - QUIC er bare UDP-pakker til VPN'en, som indkapsler dem i sin egen tunnel, som den gør med enhver anden trafik. WireGuard håndterer det rent; OpenVPN også fint. QUIC-trafikken inde i tunnelen er dobbeltkrypteret (QUIC-lag + VPN-lag), med mindre overhead.

Ja, per definition. HTTP/3 er HTTP over QUIC; der er ingen HTTP/3-over-TCP. Navngivningen er lidt forvirrende, fordi HTTP/2 også har "over QUIC"-prototyper (gQUIC), men IETF-versionen af HTTP/3 er det, der blev leveret i 2021.

QUIC forklaret: Den moderne transportprotokol, der erstattede TCP+TLS

QUIC er den transportprotokol, som Google byggede for at gøre internettet hurtigere, derefter afleveret til IETF og derefter rullet ud over halvdelen af internettet under navnet HTTP/3. Den kører på UDP i stedet for TCP, integrerer kryptering fra den første pakke og eliminerer flere årtiers frustrationer fra TCP-æraen i et enkelt design.

Hele artiklens krop findes på engelsk nedenfor.

QUIC (oprindeligt "Quick UDP Internet Connections") er en generel transportprotokol designet af Google med start omkring 2012 og standardiseret af IETF som RFC 9000 i 2021. Den kører over UDP, transporterer datastrømme, håndterer sin egen kryptering og tjener som kontrol af HTTP-fundering/3 overbelastning. Fra slutningen af 2025 bærer QUIC mere end 30 % af internettrafikken efter volumen på større netværk.

Hvorfor var TCP ikke nok

TCP blev designet i 1981 og har ikke ændret sig i sin kerne siden. Tre problemer blev mere og mere smertefulde:

Head-of-line blokering. En enkelt droppet pakke standser alle data bag sig i den samme TCP-forbindelse, selvom den tabte pakke tilhører én stream, og andre streams er i orden. HTTP/2 multipleksede mange streams over én TCP-forbindelse, hvilket gjorde head-of-line-blokeringen værre, ikke bedre.
Langsomt håndtryk. TCP har brug for 1,5 rundrejser, før nogen datastrømme; tilføjelse af TLS på toppen gør det til 2,5+ rundrejser. På mobilforbindelser var denne latenstid synlig for brugerne.
Connection-migrering. TCP-forbindelser identificeres af 5-tuple (kilde-IP, kildeport, dest IP, dest port, protokol). Når din telefon skifter fra Wi-Fi til mobil, ændres IP-adressen, og hver TCP-forbindelse afbrydes.

QUIC blev designet til at reparere alle tre.

Streams uden head-of-line blokering

QUIC bærer flere forbindelsesuafhængige streams. Hver strøm har sin egen rækkefølge og pålidelighed. Hvis en pakke går tabt, er det kun den berørte stream, der går i stå - andre streams fortsætter. Dette er overskriftsfunktionen, og det er egenskaben, der gør HTTP/3 mærkbart hurtigere end HTTP/2 på forbindelser med tab.

Encryption baged in

Hver QUIC-pakke efter det første håndtryk er krypteret med TLS 1.3-nøgler, inklusive headere på transportniveau. Hvor TCP eksponerer sekvensnumre og flag for mellembokse, krypterer QUIC dem. Håndtrykket fuldføres på én rundtur, eller nul, hvis klienten har cachelagret sessionstilstand (0-RTT, med forbehold for genafspilningsbeskyttelse).

Dette har en betydelig bivirkning: mellembokse – inklusive DPI-systemer, gennemsigtige proxyer og virksomhedsfirewalls – kan ikke længere ændre QUIC-trafik, som de gjorde TCP. De kan se , at QUIC-trafik flyder, men de kan ikke afkode den. For netværksoperatører har dette været forstyrrende; for slutbrugere er det en klar gevinst for privatlivets fred.

Connection-migrering

A QUIC-forbindelse er identificeret af et 64-bit forbindelses-id, der er indlejret i hver pakke, ikke af netværkets 5-tuple. Når din IP ændrer sig - telefonen bevæger sig mellem celler, bærbare computere skifter netværk, NAT-genbinding - fortsætter QUIC-forbindelsen problemfrit. Biblioteket beviser over for serveren, at den nye IP/port stadig er den samme klient ved at fuldføre et lille valideringshåndtryk, og trafikken genoptages.

For mobile brugere på pendlertog og fly Wi-Fi eliminerer dette en hel klasse af "mit videoopkald faldt, fordi jeg rundede et hjørne"-fejl.XXCongestion control

QUIC-implementeringer leverer deres egen overbelastningskontrol - typisk Reno, Cubic eller BBR. Fordi QUIC er en brugerrumsprotokol (ikke i OS-kernen som TCP), implementeres forbedringer af overbelastningskontrol som applikationsopdateringer i stedet for OS-opgraderinger. Google har brugt dette til at udrulle BBRv2 på tværs af Chrome+QUIC-forbindelser hurtigere, end den samme algoritme kunne have været implementeret via OS-opgraderinger.

Hvor QUIC er og ikke bruges

QUIC dominerer browser-til-server-trafik for HTTP/3-kompatible destinationer: Akflare, Cloud, Meta, Google, Meta. Browsere falder tilbage til HTTP/2 over TCP, hvis QUIC fejler (nogle netværk blokerer UDP/443, nogle firewalls dropper ukendt UDP, og QUIC-pakketab kan være perverst højt på netværk tunet til TCP). DNS-over-QUIC. QUIC er grundlaget for WebTransport - en lav-niveau API for browseren til at udføre tovejs streaming over QUIC. På lang sigt, forvent, at flere applikationsprotokoller bliver porteret til QUIC.

Operational caveats

QUIC komplicerer netværksoperationer:

DPI-baseret trafikformning fungerer ikke på samme måde. Internetudbydere, der hastighedsbegrænser YouTube via DPI, finder ud af, at QUIC-trafik er uigennemsigtig.
NAT-timeoutadfærd adskiller sig — UDP-NAT'er har typisk 30-sekunders timeouts i forhold til TCP's minutter, så QUIC sender keepalives mere aggressivt.
Nogle firewalls dropper QUIC; klienter skal opdage dette og falde tilbage. Fallback-forsinkelsen er begrænset, men synlig.
Debugging QUIC kræver andre værktøjer end tcpdump; qlog output og Wireshark med TLS-nøgler er den moderne opsætning.

Ofte stillede spørgsmål

Er QUIC hurtigere end TCP?: For reelle arbejdsbelastninger, normalt ja - typisk 10-30 % hurtigere på mobilnetværk og netværk med tab, mindre fordel på rene kablede links. Forbedringen kommer fra multipleksing uden head-of-line blokering, hurtigere håndtryk og forbindelsesmigrering. På et perfekt netværk uden tab mindskes kløften.
Krypterer QUIC trafik?: Ja, obligatorisk og ende-til-ende. Hver QUIC-pakke efter håndtrykket er krypteret med TLS 1.3-nøgler. Der er ingen "almindelig QUIC"-tilstand. Netværksobservatører ser krypteret UDP med QUICs forbindelses-id; de kan ikke læse vandløbene indeni.
Hvorfor kører QUIC på UDP, ikke på sin egen IP-protokol?: Deployerbarhed. En ny IP-protokol ville kræve opdateringer til hver NAT, firewall og ISP-router på internettet - årtiers arbejde. UDP er allerede universelt understøttet. QUIC implementerer sin egen pålidelighed, overbelastningskontrol og bestilling oven på UDP's bedste indsats-datagrammer.
Kan en VPN-tunnel QUIC?: Ja - QUIC er bare UDP-pakker til VPN'en, som indkapsler dem i sin egen tunnel, som den gør med enhver anden trafik. WireGuard håndterer det rent; OpenVPN også fint. QUIC-trafikken inde i tunnelen er dobbeltkrypteret (QUIC-lag + VPN-lag), med mindre overhead.
Kræver HTTP/3 QUIC?: Ja, per definition. HTTP/3 er HTTP over QUIC; der er ingen HTTP/3-over-TCP. Navngivningen er lidt forvirrende, fordi HTTP/2 også har "over QUIC"-prototyper (gQUIC), men IETF-versionen af HTTP/3 er det, der blev leveret i 2021.