Google utvecklar HTTP-over-QUIC – efterträdare till internetprotokollet HTTP

"User Datagram Protocol (UDP) [...] används för moderna applikationer"

Nja, att använda UDP har inget med "modernt" att göra, annars var det nätverksspel jag var med och skrev för 20 år sedan också "modernt".

"ersätta [...] UDP med QUIC"

Nja, QUIC ersätter inte UDP, det bygger på UDP.

Att jag är lite petig beror på att mitt exjobb (också för snart 20 år sedan) bestod av att skriva ett UDP-baserat protokoll att användas istället för TCP när det gällde att flytta data med så låg latens och overhead som möjligt, men med vissa av TCP:s fördelar bibehållna (t.ex. korrekt ordning på paketen).

Vad mer än "det ger dig snabbare surf" är relevant att veta

I grunden är QUIC en hyfsat likt SCTP. Problemet med SCTP är att det, likt TCP och UDP, i praktiken behöver implementeras av OS-kärnan och det har inte hänt i ett hyfsat välanvänt OS med namnet "Windows 10"...

Fördelarna med QUIC är att dagens infrastruktur stödjer redan UDP, så man har garanterat OS-stöd + port-abstraktionen i UDP möjliggör saker som NAT (ett helvete, men det är ett krav idag då IPv6 verkar dröja).

QUIC träffar i princip alla rutorna i buzz-word-bingo

• säkerhet är en standardfiness

• data kan levereras med lägre latens jämfört med TCP. TCP kan i teorin kan leverera data redan i handskakningen (specifikationen tillåter explicit detta), men i praktiken lär det inte fungera då få implementationer och infrastruktur kommer acceptera detta

• QUIC har explicit stöd för att köra flera strömmar i samma session (vilket var en av huvudingrediens i SCTP), något man går implementera för hand i TCP. Att det är inbyggt betyder att ett paket som kommer på avvägar inte leder till att alla strömmar stannar upp

• QUIC har möjlighet för t.ex. en videoström att säga: jag bryr mig inte längre om paket X och Y för de är numera så gamla att de inte fyller något funktion. TCP kräver att alla hål fylls i, innan det händer kan ingen ström göra "forward-progress".

• QUIC har funktioner som implicit nedstängning av sessioner, en TCP session kan i teorin vara öppen i oändlighet då det inte krävs någon information för att session ska ses som levande (hack som "TCP keep-alive" finns så klart). Detta betyder att QUIC kan stänga ned sessioner utan att skicka någon information alls -> bra för enheter som t.ex. mobiler då det sparar ström

• TCP-sessioner identifieras av två portar och två IP-adresser, dessa kommer normal ändras när en enhet hoppar mellan olika LAN (mobile-IP finns, men är på många sätt ett hack). QUIC använder UDP, som är tillståndslöst, och flyttar sessionsinformationen ovanpå UDP -> är trivialt att hoppa mellan LAN då byte av IP-adress på din enhet inte spelar någon roll när sessionen identifieras i lagret ovanför och kan därför enkelt hoppa mellan nät

Kör man Chrome kan man få lite information kring aktiva QUIC-sessioner via chrome://net-internals/#quic

OSI-modellen säger ingenting om var något ska implementeras. Har skrivit ett par TCP/IP-stackar genom åren, är ju full möjligt att köra även dessa helt i "user-land". Det är typiskt också precis vad man vill göra under utveckling då det är väldigt mycket enklare att utveckla saker i user-land jämfört med att köra i kernel-space.

Även sedan finns ju poänger med att köra något som TCP/IP i user-space för olika former av tester och simuleringar.

Skulle säga att QUIC egentligen renodlar stacken mer då TCP i viss mån mixar ihop transport-lager och sessions-lager. Med QUIC är UDP transport-lager medan QUIC sköter sessions-lagret.

Nackdelen med att ha ett så pass komplex protokoll som QUIC utanför OSet är risken att man får flera inkompatibla versioner. Fast det kan även bli en fördel, om en eller några få vältestade implementationer blir de som i praktiken används så kommer ju samma QUIC-stack används oavsett OS!