Tysk forskning: Ny HTTP-protokol er ikke nævneværdigt hurtigere end forgængeren

Illustration: Bigstock/Gino Santa Maria
Ikke desto mindre baner den nye QUIC-protokol vejen for en fuldt krypteret transportprotokol, der kan udvikles løbende og omgå forstening, lyder vurderingen.

Protokollen HTTP-over-QUIC blev i november sidste år forfremmet til HTTP/3, den tredje version af internettets vigtigste transportstandard. HTTP får browsere og webservere til at snakke sammen og benyttes i en lang række andre sammenhænge.

Det meddelte formanden for arbejdsgruppen for HTTP- og QUIC-protokollerne hos IETF på en mailingliste, hvor udviklingsarbejdet drøftes. IETF (Internet Engineering Task Force) er den organisation, der forvalter internettets grundlæggende protokoller.

QUIC-protokollen, som har sin oprindelse hos Google, bryder med en tradition for at bruge TCP (Transmission Control Protocol) som transportlag.

TCP etablerer et 'virtuelt kredsløb' mellem afsender og modtager og er en meget pålidelig protokol. QUIC benytter i stedet UDP (User Datagram Protocol) til transport, hvor endepunkterne selv skal holde styr på, at data er kommet frem i hel tilstand.

Til gengæld reduceres transporttiden, ligesom ressourceforbruget nedsættes.

QUIC har indbygget kryptering, som på mange punkter følger den seneste udgave af SSL, TLS 1.3-standarden.

I starten af november sidste år meddelte udvikleren Dmitri Tikhonov fra firmaet Litespeed, at det og Facebook med succes havde skabt forbindelse mellem to HTTP/3-implementeringer.

Men nu sætter tysk forskning spørgsmålstegn ved, om QUIC-protokollen rent faktisk er hurtigere end en ‘tunet’ udgave af HTTP.

Det sker i en videnskabelig artikel, som er udgivet i forbindelse med en konference afholdt af Association for Computing Machinery, den internationale organisation for datalogisk forskning.

De fire forskere bag artiklen, Konrad Wolsing, Jan Rüth, Klaus Wehrle og Oliver Hohlfeld fra RWTH Aachen University, har også fremlagt resultaterne i et nemmere tilgængeligt blogindlæg, der har den førstnævnte forsker som forfatter.

QUIC lover at forbedre den historisk fremdyrkede TCP+TLS+HTTP web-stak. Ved at kombinere disse funktionaliteter oven på den effektive, men løsagtige ​​UDP-protokol, kan QUIC overvinde problemer såsom ‘head-of-line blocking’, hvor en række pakker står i kø og venter på, at den første pakke kommer frem.

QUIC kan også forbedre anvendelsen af faciliteter som ‘TCP FastOpen’, der gør det hurtigere at åbne flere TCP-forbindelser i rækkefølge. Det er svært i dag, på grund af netværks-hardware, som ikke spiller med.

Sammenligninger tager ikke højde for gængs optimering

De tyske forskere er altså positivt stemt over for QUIC, men hvordan ser det ud med det centrale salgsargument for protokollen: Bliver transporttiden sat ned i væsentlig grad i forhold til dagens HTTP-stak?

Det er velkendt, at de store udbydere benytter optimerede netværksstakke, skriver forskerne, og tidligere sammenligninger har ikke taget højde for dette forhold, lyder synspunktet.

De tyske forskere har sammenlignet ydelsen af dagens TCP+TLS1.3+HTTP/2-stak med QUIC ved at optage og genafspille 38 websites indlæsning i Chrome.

Det er udført i et testmiljø med en modificeret udgave af frameworket Mahimahi, som kan replikere den opførsel, der kendes fra dagens websites, som afvikles samtidig fra mere end én enkeltstående webserver.

Forskernes TCP-stak krævede de gængse to ‘round trip times (RTT)’ i forbindelse med ‘handshake’ i TCP- og TLS-protokollerne. I testmiljøet krævede QUIC altid én RTT. Det mener forskerne er den mest realistiske opsætning af testmiljøet.

Forskerne testede med disse netværksprofiler:

NetværkUplink (Mbps)Downlink (Mpbs)Forsinkelse (ms)Tab (%)
DSL525240
LTE2.810.5740
MSS1,891,897606
DA2GC0,4680,4682623.3

De to første netværk efterligner de hurtige og stabile links, som privatbrugere benytter, såsom DSL eller mobilt internet (LTE). De sidste to indstillinger efterligner udfordrende netværk, hvor data stammer fra målinger på et fly. Teknologien MSS er baseret på satellitter og Direct Air to Ground Control (DA2GC) på almindeligt mobilt internet.

Som et første trin testede forskerne, om justering af TCP-parametre forbedrer ydeevnen, ved at øge det såkaldt indledende vindue (IW) fra 10 til 32, samt aktivere ‘packet pacing’, øge størrelsen på buffere større og 'indstille ingen langsom start efter inaktiv tilstand'.

Det giver i de fleste tilfælde en forbedring på op til 10 procent, i forhold til almindelig TCP. Sammenlignet med QUIC giver den tunede stak i visse tilfælde bedre resultater. Det gælder for DSL-scenariet, mens QUIC slår den tunede udgave, når det gælder LTE samt de to udfordrende netværk.

Hvis forskerne kombinerer QUIC og den tunede TCP-stak med BBR, som er en ny anti-forstoppelsesprotokol fra Google, er forskellene små.

Kun med det specielle MSS-netværk, der altså bygger på satellitter, er der en væsentlig forskel. Med de øvrige netværkstyper er forskellen i størrelse omkring 5 til 15 procent.

Ydelsesmæssige fordele ved QUIC er ganske minimale

Under de nuværende forhold drager slutbrugerne stadig fordel af QUIC, mener forskerne.

Men det er ikke klart, om denne forbedring udelukkende stammer fra RTT-forskellen mellem begge protokoller i målingerne.

Så forskerne valgte to websites, der kun er afhængige af ressourcer fra en enkelt server. Her kan man se bort fra RTT for TCP, fordi der kun skal oprettes en forbindelse. Dermed er QUIC og den tunede TCP på samme niveau, som udgangspunkt.

Forskerne finder denne forskel mellem QUIC og den tunede TCP, når man benytter én RTT. Værdier mindre end nul angiver, at QUIC var hurtigere:

NetværkWebsiteForskel [ms]Forskel [RTT]
DSLgnu.org1.60,066
DSLwikipedia.org-3,1-0,128
LTEgnu.org-30-0,412
LTEwikipedia.org-13-0,175
DA2GCgnu.org390,15
DA2GCwikipedia.org-1005-3,834
MSSgnu.org-1100-1,447
MSSwikipedia.org-529-0,696

Forskellen mellem QUIC og den tunede TCP er nu for det meste under varigheden af ​​én RTT. Der er også tilfælde, hvor TCP-versionen er lidt hurtigere.

Set med et menneskes øjne og opfattelse er fordelene ved QUIC ganske minimale, konkluderer de tyske forskere. Det gælder især for hurtige netværk. Den rækkefølge, elementerne på en webside renderes i, har større betydning end de små forskelle i transporttid for de to protokoller.

I blogindlægget viser de tyske forskere med video en side-ved-side-sammenligning af websitet Etsy.com. QUIC indlæser skrifttyper på et sent tidspunkt, mens den tunede TCP tager sin tid med at afslutte indlæsningen af ​​et banner.

Etablerede metoder er mere rentable

Tidligere er ydelsen af QUIC måske blevet overdrevet, mener forskerne. QUIC behøver således ikke at være en høj prioritet for dem, der drifter websites. Andre og mere etablerede metoder til at øge ydelsen kan være mere rentable, lyder synspunktet.

De tyske forskeres resultater har dog også været udsat for kritik. Tidligere nævnte Dmitri Tikhonov, der altså har medvirket til at skrive en QUIC-implementering, påpeger på sociale medier, at den Google-udviklede QUIC-server ikke er særlig hurtig.

Til Version2 uddyber han således:

»Jeg har ikke dykket ned i detaljerne i forskernes artikel, så jeg har ikke en dybere pointe. Jeg mener blot, at der nu er mulighed for at benytte samme software-stak til at afvikle både QUIC og HTTP, og det ville i højere grad være en ‘æble-til-æble’-sammenligning end at benytte Nginx til HTTP og Chromiums legetøjs-server til QUIC,« siger han med henvisning til den software, der er anvendt i eksperimentet.

De tyske forskere er dog som tidligere nævnt ikke fjendtligt stemt overfor QUIC og HTTP/3. Konrad Wolsing slutter sit blogindlæg således efter at have fremført den tidligere nævnte kritik:

»Ikke desto mindre baner QUIC vejen for en fuldt krypteret transportprotokol, der kan udvikles løbende og omgå forstening, og som også er den mest passende mulighed for fremtidig protokoludvikling. Og især i dårlige netværk synes QUIC at give en betydelig fordel i forhold til TCP.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kenn Nielsen

Er det nogen overraskelse, at et reklamefirma udvikler en protokol, som venter med at vise den information, som læseren virkeligt kom efter, indtil alle bimle-bamle-larme-larme opmærksomhedssøgende reklamer er blevet vist ?
På dén måde sikrer 'man' sig at læseren ikke har låst sin opmærksomhed på den reelle info, når reklamerne kommer.

QUIC indlæser skrifttyper på et sent tidspunkt, mens den tunede TCP tager sin tid med at afslutte indlæsningen af et banner.

K

  • 3
  • 1
Joe Sørensen

Er der nogen der har læst sig dybt nok i artiklen til at finde hvilke 36 sider vi snakker om?
wikipedia.org og gnu.org indlæses ret hurtig i forvejen. Det er mere interessant what protokol stakken kan køre ved den almindelige slamkode, som de fleste hjemmesider består af.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize