HTTP/3 Kommer QUIC, Här är Vad Du Behöver Veta

0
253
Shutterstock/Robert Avgustin

HTTP/3 är nästa generation av HTTP-protokollet. Den drivs av QUIC, som ersätter TCP vid transport layer och skär ner på antalet resor runt en kund måste göra för att upprätta en anslutning.

Vad Är Det Som Gör Det Bättre?

Om du inte kan säga från förkortningen “QUIC” HTTP/3 är mycket snabbare.

HTTP är bara en del av OSI-modellen, som driver internet som vi känner det. Varje lager av modell tjänar olika ändamål, med hög nivå Api: er som HTTP sitter på toppen (application layer), hela vägen ner till den fysiska kablar och anslutningar för att koppla in routrar:

Men det finns en flaskhals i denna modell—och trots det nya namnet HTTP-standarden i sig är inte problemet.

TCP (transport layer) som är boven i dramat här, det var utformade tillbaka på 70-talet, och som sådan var inte byggd för att hantera kommunikation i realtid mycket bra. HTTP över TCP har nått sin gräns. Google och resten av den tekniska utrymme har jobbat på en ersättare för TCP.

Under 2012 Google har skapat SPDY, ett protokoll som bygger på toppen av TCP och fixar en hel del gemensamma frågor. SPDY själv är föråldrat, men delar av det har gjort sin väg in på HTTP/2, som för närvarande används av 40% av webben.

QUIC är en ny standard, mycket som SPDY, men det är byggt på toppen av UDP-snarare än TCP. UDP är mycket snabbare än TCP, men är generellt sett mindre tillförlitliga eftersom det inte har samma felkontroll och skadeförebyggande som TCP gör. Det är vanligen används i applikationer som inte kräver paket till vara på exakt rätt ordning, men bryr sig om latens (som direktsänd video calling).

QUIC är fortfarande tillförlitlig, men det genomför sin felkontroll och tillförlitlighet på toppen av UDP, så det får det bästa av båda protokollen. Första gången en användare ansluter till en QUIC-aktiverad webbplats, kommer de att göra så via TCP.

Det största problemet med TCP som QUIC fixar är head-of-line blockering. När en anslutning mellan klient och server, servern skickar datapaket till kunden. Om anslutningen är dålig och ett paket förloras, kunden undanhållanden alla paket som tas emot efter detta tills servern skickar den förlorade paket. HTTP/2 fixar denna fråga något, genom att låta flera överföringar under samma TCP-anslutning, men det är inte perfekt och det kan faktiskt vara långsammare än HTTP – /1 med hög förlust anslutningar.

QUIC löser det här problemet, och tar med hög förlust anslutningar mycket bättre. Tidiga tester från Google visade förbättringar av runt 15% i hög latens scenarier, och upp till 30% förbättring i video-buffring på mobila anslutningar. Eftersom QUIC skär ner på antalet handskakningar som måste göras, det kommer att vara fördröjning förbättringar över hela linjen.

Är Det Svårt Att Genomföra?

Samtidigt som QUIC är en ny standard, det är byggt på toppen av UDP, som är en redan stött nästan överallt. Det kommer inte att kräva några nya kärnan uppdateringar, vilket kan vara problematiskt för servrar. QUIC bör fungera out of the box på alla system som stöder UDP

HTTP-över-QUIC bör vara en drop-in ersättning för HTTP-över-TCP när det är lätt tillgängliga. I skrivande stund, Chrome har stöd för QUIC, men det är inaktiverat som standard. Du kan aktivera det för att testa genom att gå till:

chrome://flaggor

och vrida på den “Experimentella QUIC protokoll” – flagga. Firefox kommer att lägga till stöd senare i höst, och med Kanten flyttar till Krom, kommer de att plocka upp snart också.

På servern, Om du använder CloudFlare som din CDN, kommer du att kunna aktivera alternativet redan på instrumentpanelen, även om du inte har många kunder som faktiskt använder det tills mobil webbläsare har det som standard. Fastly arbetar aktivt för att stödja. Om du vill aktivera det på din webbserver behöver du dock vänta lite—tidigt stöd för QUIC är tänkt att anlända under nginx 1.17 utveckling cykel, men Apache stöd är inte i sikte ännu.

När nginx och Apache är uppdaterat för att stödja den, lägga till en QUIC till din webbsida eller web app kommer att vara så enkelt som att uppdatera din webbserver och som gör det möjligt alternativ. Du kommer inte att behöva göra några ändringar i din app eller på din kod, eftersom allt sköts på infrastruktur. Det är inte här ännu, men det kommer mycket snart, och du kommer definitivt vill göra det när det är som stöds som standard.