Het nieu­we in­ter­net­pro­to­col QUIC

Aan­pas­sin­gen in het in­ter­net­pro­to­col QUIC kun­nen gro­te ge­vol­gen heb­ben

C’t Magazine - - Inbound 6/2018 - Mo­ni­ka Er­mert

QUIC is een mo­dern trans­port­pro­to­col om in­ter­net­ver­keer te ver­snel­len. Het is bo­ven­dien stan­daard ver­sleu­teld en geeft nau­we­lijks met­a­da­ta prijs. Net­werk­be­heer­ders zijn daar niet blij mee en wil­len dat even­veel wordt prijs­ge­ge­ven als bij TCP. Maar dat was niet het doel van het oor­spron­ke­lij­ke ont­werp.

Ja­na Iy­en­gar is een van de hoofd­ont­wer­pers van het in­ter­net­pro­to­col QUIC (Quick UDP In­ter­net Con­nec­ti­ons). De van Goog­le naar cloud­aan­bie­der Fast­ly over­ge­stap­te 'dis­tin­guis­hed en­gi­neer' gaf ons in het ka­der van de 101.IETF­con­fe­ren­tie in Londen een toe­lich­ting op de ont­wik­ke­ling van QUIC.

Wat on­der­scheidt QUIC, waar­om is het be­ter dan het tot nu toe op in­ter­net ge­brui­ke­lij­ke trans­port­pro­to­col TCP?

Er zijn meer­de­re re­de­nen. Op de eerste plaats na­tuur­lijk de be­te­re per­for­man­ce. TCP kun je ook flink tu­nen, maar daar­voor zijn aan­pas­sin­gen no­dig in de be­stu­rings­sys­te­men van rou­ters en an­de­re net­werk­ap­pa­ra­ten. QUIC wordt in ap­pli­ca­ties ge­ïm­ple­men­teerd en kan snel­ler ge­dis­tri­bu­eerd wor­den.

Bo­ven­dien is QUIC ont­wor­pen als ver­sleu­teld, zo­dat bij­voor­beeld niet wil­le­keu­rig de he­a­der kan wor­den aan­ge­past, wat veel midd­le-boxes stil­zwij­gend doen bij TCP. Met TCP is er, an­ders dan de be­doe­ling, geen daad­wer­ke­lij­ke point-to-point­com­mu­ni­ca­tie meer tus­sen twee in­ter­ne­thosts. QUIC ge­bruikt daar­en­te­gen UDP als trans­port­pro­to­col en wordt daar over­heen ge­sluisd. Daar­door zet QUIC snel­le­re tij­den neer en be­te­re pres­ta­ties.

QUIC wordt vaak 'het nieu­we TCP' ge­noemd. Zal het in­der­daad TCP ver­van­gen?

Dat weet ik niet. Ik hoop dat het een be­lang­rijk trans­port­pro­to­col wordt. Maar TCP blijft be­staan en dat moet ook. De waar­de van TCP is dat het heel een­vou­dig is. En dat is juist wat be­paal­de toe­pas­sin­gen no­dig heb­ben. Te­ge­lij­ker­tijd wordt het ook door­ont­wik­keld. Ook bij TCP heb­ben we ge­werkt aan een snel­le­re hands­ha­ke en een be­te­re loss-re­co­ve­ry.

Hoe­veel ip-ver­keer gaat al over QUIC?

Bij het ei­gen ver­keer van Goog­le is dat meer dan 40 pro­cent. We­reld­wijd is het vol-

gens re­cen­te schat­tin­gen 9 tot 10 pro­cent. Dat per­cen­ta­ge is af­han­ke­lijk van waar je het meet. Die 10 pro­cent we­reld­wijd volgt uit Goog­les aan­deel in het to­ta­le in­ter­net­ver­keer. Dat is mo­men­teel rond 20 pro­cent. Dat is ver­waar­loos­baar. Dat komt om­dat tot nu toe al­leen de Goog­le-im­ple­men­ta­tie daad­wer­ke­lijk wordt ge­bruikt. En dat is dan weer om­dat er nog wordt ge­werkt aan de spe­ci­fi­ca­ties. Ik hoop dat het nooit tot zo'n clas­si­fi­ca­tie komt. QUIC is nieuw, maar niet de eerste in zijn soort. Neem bij­voor­beeld het Stream Con­trol Trans­mis­si­on Pro­to­col. Als je te­gen­woor­dig ie­mand belt, wordt daar­bij SCTP ge­bruikt. Als al­ge­meen trans­port­pro­to­col strandt het ech­ter op midd­le-boxes en om­dat het niet in be­stu­rings­sys­te­men geim­ple­men­teerd is. QUIC heeft ge­leerd van de er­va­rin­gen van de voor­gan­ger. Goog­le is in­der­daad oor­spron­ke­lijk QUIC ge­start. Maar het is ook ge­bo­ren uit idee­ën die al lan­ger be­staan. Na­tuur­lijk heb­ben ont­wik­ke­laars bij Goog­le zich la­ten lei­den door de be­hoef­ten van de ei­gen dien­sten. Maar de stan­daar­di­se­ring bij de IETF heeft als doel om QUIC ook op an­de­re ei­sen af te stem­men. Het moet een pro­to­col voor ie­der­een wor­den. Maar de im­ple­men­ta­tie is veel­ei­send en dat kan een hin­der­nis zijn. Des­on­danks zijn er al ver­schil­len­de opens­our­ce-im­ple­men­ta­ties, zo­als Qui­cly, QuicGo en na­tuur­lijk Mo­zil­la en Chro­mi­um. We ho­pen dat ui­t­ein­de­lijk niet al­leen Goog­le en Fa­ce­book QUIC im­ple­men­te­ren.

We heb­ben met QUIC een re­duc­tie van vi­deo­buf­fer­tij­den ge­me­ten van 13 tot 18 pro­cent. Dat is op­mer­ke­lijk als re­sul­taat van al­leen een pro­to­col. Daar­bij moet ik be­na­druk­ken dat voor­al re­gio's met ho­ge la­ten­ties en ver­lies­ra­tio's pro­fi­te­ren, zo­als In­dia. We heb­ben daar zelfs een kwa­li­teits­ver­be­te­ring ge­me­ten van meer dan 22 pro­cent. Dat be­te­kent dat ge­brui­kers met een slech­te in­ter­net­ver­bin­ding er meer van pro­fi­te­ren. Dat geldt voor­al voor net­wer­ken in ont­wik­ke­lings­lan­den. Ja, mo­men­teel al­leen voor Goog­le-con­tent. Maar Aka­mai ge­bruikt ook QUIC. Dat is een am­bi­ti­eu­ze doel­stel­ling. Maar we wer­ken er hard aan en het zou knap zijn als we die dead­line ha­len.

Wordt het dan toch iets voor 2019?

Dat zou heel mooi zijn. Ik hoop dat in 2019 de RFC ge­pu­bli­ceerd wordt. De laat­ste har­de no­ten kra­ken we ho­pe­lijk voor de IETF-con­fe­ren­tie in Montre­al in juli.

Wel­ke zijn dat?

Dat is de hands­ha­ke. Daar zijn nog pro­ble­men mee.

De Spin­bit, de bit in het open­ba­re deel van de he­a­der die als re­fe­ren­tie voor snel­heids­me­tin­gen zou moe­ten wor­den ge­bruikt, is dat on­der­werp nu de­fi­ni­tief van ta­fel?

Nee. De con­sen­sus was om het Spin­bit­voor­stel he­le­maal uit te wer­ken en in no­vem­ber te be­slis­sen of we het wil­len door­voe­ren.

Jij hebt je daar te­gen uit­ge­spro­ken. Van­we­ge de mo­ge­lij­ke ver­tra­ging, om­dat de ver­trou­we­lijk­heid mo­ge­lijk wordt ge­schaad of om an­de­re re­de­nen?

Als ont­wer­per voor­al van­we­ge het eerste. Het is pre­cair iets in te bou­wen dat nog niet vol­le­dig uit­ge­werkt is. Men­sen die den­ken dat het maar een een­vou­dig me­cha­nis­me is, be­sef­fen niet wat voor ge­vol­gen het voor het pro­to­col kan heb­ben. Na­tuur­lijk, het he­le QUIC is een ex­pe­ri­ment, maar bij de Spin­bit ligt het an­ders. Het eni­ge doel daar­van is dat middle­boxes het kun­nen be­nut­ten. En dat is in de prak­tijk niet ge­test.

Met be­trek­king tot de ver­trou­we­lijk­heid wordt op het rand­je ge­ba­lan­ceerd. Mijn per­soon­lij­ke me­ning is: we we­ten niet pre­cies wat de Spin­bit ui­t­ein­de­lijk kan prijs­ge­ven. We heb­ben lang en hard na­ge­dacht over wat we bij QUIC wil­len prijs­ge­ven. Een ont­werp­team heeft de Spin­bit on­der­zocht wat be­treft pri­va­cyin­breuk en niets kri­tisch kun­nen vin­den. Maar we we­ten niet wat er even­tu­eel nog op de loer ligt. Het ont­breekt wat mij be­treft voor­al aan een mo­ti­va­tie van de net­werk­ope­ra­tors wat de Spin­bit hen op­le­vert. Die heb­ben we nog niet mo­gen ont­van­gen. Na­tuur­lijk ha­len ze meer in­for­ma­tie uit TCP en na­tuur­lijk ont­breekt dat in QUIC. Maar het doel zou niet moe­ten zijn om meer mo­ge­lijk­he­den er­in te stop­pen. Je zou in plaats daar­van moe­ten vast­leg­gen wat echt dwin­gend nood­za­ke­lijk is om een net­werk te run­nen.

De TLS-spe­ci­fi­ca­tie 1.3 is on­der­tus­sen ge­reed (zie pa­gi­na 12 in de­ze c't). Ver­wacht de QUIC-werk­groep een soort­ge­lij­ke strijd als bij TLS over het moe­ten kun­nen in­zien door be­heer­ders van ip­ver­keer om­wil­le van de vei­lig­heid?

Dat zou kun­nen. Maar we heb­ben het bij QUIC over iets min­der in­grij­pends. Bij TLS gaat het om het in­spec­te­ren van de inhoud van pak­ket­ten. Als daar­naar wordt ge­vraagd, stu­ren we men­sen door naar de TLS-werk­groep. Die heb­ben dat al af­ge­we­zen.

Om­dat TLS is ge­ïn­te­greerd in QUIC …

In­der­daad. Als ze bij ons ko­men, is dat van­we­ge de met­a­da­ta.

We heb­ben bij de IETF-con­fe­ren­tie in Londen een strijd ge­zien om der­ge­lij­ke toe­gangs­rech­ten. Ik snap dat het een las­tig pro­bleem is voor net­werk­ope­ra­tors. Ze zijn ge­wend aan TCP en heb­ben ja­ren­lang ge­pro­fi­teerd van hoe vrij­ge­vig dat is wat met­a­da­ta be­treft. Maar dat is nooit het doel ge­weest van het oor­spron­ke­lij­ke ont­werp. Ver­sleu­te­ling was ge­woon nog niet zo be­lang­rijk toen TCP ont­wik­keld werd. Te­gen­woor­dig le­ven we in een an­de­re we­reld. En we ma­ken een machts­strijd mee. Je geeft macht aan de­ge­ne die je bij het pro­to­col­de­sign de sleu­tel toe­ver­trouwt. En je ont­neemt die macht als je die sleu­tel niet af­geeft. Wie de sleu­tel heeft, heeft de macht. (mdt)

"Ge­brui­kers met een slech­te in­ter­net­ver­bin­ding pro­fi­te­ren er meer van"

Ja­na Iy­en­gar is soft­wa­re-ont­wer­per bij Ed­ge-cloud­aan­bie­der Fast­ly en edi­tor bij de In­ter­net En­gi­nee­ring Task For­ce. Hij werk­te on­der an­de­re voor Goog­le en aan pro­jec­ten als Mi­ni­on en SCTP. In dit in­ter­view ant­woordt hij van­uit zijn rol als...

Newspapers in Dutch

Newspapers from Netherlands

© PressReader. All rights reserved.