QUIC (Quick UDP Internet Connections) er en eksperimentell transportlagsnettverksprotokoll designet av Jim Roskind hos Google , opprinnelig implementert i 2012, og annonsert som et utvidet eksperiment i 2013. QUIC støtter et sett med forbindelser multiplekset mellom to ender over UDP (User Datagram) Protocol), og ble designet for å gi sikkerhet tilsvarende TLS/SSL , sammen med redusert tilkoblings- og transportforsinkelse, og båndbreddeestimering i hver retning for å unngå overbelastning. Hovedmålet med QUIC er å forbedre den opplevde ytelsen tiltilkoblingsorienterte nettapplikasjoner som for tiden bruker TCP . Det gir også et miljø for rask iterasjon av algoritmer for unngåelse av overbelastning, og etablerer kontroll i applikasjonsområdet i begge ender, i stedet for i (sakte å oppdatere på klientnivå) kjerneområdet .
I juni 2015 ble [ 1 ] et Internett-utkast til en spesifikasjon for QUIC sendt til IETF for standardisering. [ 2 ] I 2016 [ 3 ] ble det etablert en QUIC arbeidsgruppe.
Du ønsker å redusere ventetiden over Internett ved å tilby et mer responsivt sett med brukerinteraksjoner. Ettersom tiden går, vil båndbredden vokse, men tidspunktet for utveksling av meldinger, siden det avhenger av lysets hastighet , vil ikke kunne variere av seg selv. [ 4 ] [ 5 ] Derfor er det nødvendig med en protokoll slik at forespørsler, svar og interaksjoner på Internett har lavere ventetid med lavere retransmissionstider, noe QUIC klarer å tilnærme. IP-adressepar og sockets er endelige ressurser. En multiplekset transport har potensialet til å forene trafikk og redusere portbruk, for å forene rapport- og svarmeldinger, og også redusere overflødig informasjon (for eksempel i overskrifter). Oppsummert, utvikle en protokoll som oppfyller:
QUIC har som mål å være ekvivalent med en frittstående TCP-tilkobling, men med mye lavere ventetid (mål 0 RTT ved etablering av tilkobling) og bedre støtte for SPDY -multipleksing . Hvis QUIC-funksjonene viser seg effektive, kan disse funksjonene migrere til en senere versjon av TCP og TLS (som begge har en merkbart lengre distribusjonssyklus).
Svært få protokoller på Internett fungerer uten minst én utveksling av initialiseringsmeldinger. [ 6 ] De fleste protokoller har en meldingsrunde for TCP og en annen for de som også bruker TLS før data kan begynne å sendes. Med QUIC, når klienten har bufret informasjonen på serveren, kan serveren etablere en kryptert tilkobling uten å utveksle meldinger. QUIC løser de to vanligste problemene der en forbindelsesetablering krever flere håndtrykk.
For det første løses IP-adresseforfalskning ved at serveren sender et kilde -IP-adressetoken . Det er ikke noe mer enn en ugjennomsiktig byte-streng fra klientens synspunkt. Fra serverens synspunkt er det en autentisert kryptert blokk som inneholder minst klientens IP-adresse og et tidsstempel fra serveren. Dette tokenet kan sees på som sekvensnummeret i en TCP-forbindelse. Så lenge klienten ikke endrer IP-adressen eller tokenet ikke er for gammelt, kan det fortsatt brukes til informasjonsutveksling.
For det andre beskyttelse mot et gjentaksangrep (Replay-beskyttelse). På klientsiden kan klienten sende et unikt tilfeldig tall (nonce) inkludert i nøkkelavledningen på samme måte som TLS gjør. På den annen side, for å opprettholde en tilkobling uten tidligere utvekslingsrunder, kan ikke serveren utføre den samme prosessen, derfor tilbyr QUIC beskyttelse mot denne typen angrep først etter det første svaret fra serveren. Før er det opp til applikasjonen å verifisere at informasjonen er sikker. For eksempel, i Chrome sendes bare GET- forespørsler før en håndtrykkbekreftelse .
Kort sagt, første gang en QUIC-klient kobler seg til en server, må klienten utføre en meldingsutveksling ved å sende en tom hello-melding (CHLO) for å få den nødvendige informasjonen. Serveren sender deretter et avvisningssvar (REJ) med informasjonen klienten trenger, inkludert kildeadressetokenet og serverens sertifikater. Neste gang klienten sender en CHLO, kan den bruke den bufrede legitimasjonen fra den forrige tilkoblingen til umiddelbart å sende krypterte forespørsler til serveren.
QUIC tilbyr en mer komplett overbelastningskontrollmekanisme enn den som opprinnelig ble tilbudt av TCP, noe som betyr mer verdifull informasjon. Foreløpig bruker QUIC en reimplementering av TCP Cubic, men siden det er en eksperimentell protokoll, søkes det fortsatt etter forskjellige tilnærminger. [ 7 ]
Et eksempel på denne ekstra informasjonen som QUIC tilbyr er at hver pakke, både original og retransmittert, har et nytt sekvensnummer. Dette gjør at QUIC-senderen kan skille mellom ACK-er for overføringer og ACK-er for reoverføringer, noe som unngår tvetydighetsproblemet som TCP lider av i sine reoverføringer. En QUIC ACK bærer også eksplisitt forsinkelsen fra mottak av en pakke og mottakerens egen bekreftelse av pakken. Sistnevnte sammen med de økende sekvensnumrene tillater en nøyaktig beregning av meldingsutvekslingstiden (RTT).
QUIC støtter opptil 256 NACK- områder , noe som gjør den mer motstandsdyktig mot byte-omorganisering enn TCP, i tillegg til å beholde flere byte i overføringen når det er omorganisering eller tap av byte. Både klient og server har en mer nøyaktig oversikt over hvilke pakker de har mottatt.
QUIC implementerer tilkoblingsnivå og pakkeflytkontroll omtrent som det etterfulgt av HTTP/2 . Det fungerer på følgende måte; mottakeren rapporterer det totale antallet byte som den er i stand til å støtte i hver mottatt datapakke. Under sending og mottak av individuelle pakker, sender mottakeren WINDOWS_UPDATE-pakker som øker bytegrensen for den strømmen, slik at mottageren kan sende flere data i en enkelt strøm.
I tillegg til dette første kontrollmålet implementerer QUIC strømningskontroll på tilkoblingsnivå for å tillate litt fleksibilitet i endene. Det vil si at hvis den ene enden har en buffer med en viss minnekapasitet for forbindelsen, gir denne flytkontrollen informasjonsstrømmene som mottas med tilstrekkelige minnevinduer for deres størrelse innenfor den fastsatte grensen. Eksempel: Hvis en server har 5 MB tilgjengelig for hver tilkobling, kan den begrenses til å tillate 5 x 1 MB strømmer eller 500 x 10 KB strømmer. Takket være denne flytkontrollen kan denne konfigurasjonen være dynamisk og variere avhengig av strømmene den mottar.
I likhet med TCP-mottaksvinduautotuning implementerer QUIC flytvinduautotuning for både tilkobling og sending av informasjon. Denne automatiske justeringen øker størrelsen på datavinduet hvis det oppfattes en begrensning i sendingshastigheten, noe som forårsaker en økning i hastigheten på dataoverføringen.
HTTP/2 og TCP lider av den velkjente head-of-line blokkeringen. Fordi HTTP/2 multiplekser mange informasjonsstrømmer på en enkelt TCP-strøm, fører tapet av et TCP-segment til at alle påfølgende segmenter blir blokkert inntil en reoverføring skjer, uavhengig av HTTP/2-strømmen som er innkapslet i disse segmentene. [ 8 ]
Fordi QUIC er designet fra grunnen av for multipleksingsoperasjoner, vil tapte datapakker fra en individuell strøm vanligvis bare påvirke den aktuelle strømmen. Hver bitstrøm kan sendes umiddelbart ved ankomst til den tilsvarende destinasjonen, slik at de tapsfrie strømmene kan fortsette å bli satt sammen og videre inn i applikasjonen. Bare QUIC HTTP - header-bitene kan forårsake head-of-line-blokkering siden de håndteres av HPACK-header-komprimering.
QUIC-pakker er alltid kryptert. Selv om noen deler av pakkehodet ikke er kryptert, fortsetter de å bli autentisert av mottakeren, som nekter muligheten til å injisere eller manipulere data fra tredjeparter. QUIC beskytter forbindelser fra bevisst eller ubevisst manipulering av informasjon i mellompunktene mellom ytterpunktene i en kommunikasjon. Som et unntak er det bare PUBLIC_RESET-pakker, hvis funksjon er å tilbakestille en tilkobling, som ikke er autentisert. [ 9 ]
For å gjenopprette tapte pakker uten å vente på en reoverføring, fungerer QUIC for tiden med et enkelt FEC (Forward Error Correction)-skjema basert på XOR . I pakkestrømmen sendes en FEC-pakke som inneholder pariteten til pakkene i en gitt gruppe. Hvis en av pakkene i gruppen går tapt, kan innholdet gjenopprettes fra analyse av FEC-pakken og resten av pakkene i gruppen. Avsenderen bestemmer når FEC-pakker skal sendes for å optimalisere overføringen i forskjellige scenarier. For eksempel i begynnelsen og slutten av en forespørsel. [ 10 ]
QUIC-tilkoblinger identifiseres av en 64-bits tilkoblings-ID, tilfeldig generert av klienten. QUIC kan overleve endringer i IP-adresser (i motsetning til TCP) og NAT -oversettelsesendringer siden tilkoblings-IDen forblir den samme under disse migreringene. QUIC gir også automatisk kryptografisk verifisering av en migrert klient siden denne klienten fortsetter å bruke den samme øktnøkkelen for å kryptere og dekryptere pakker. [ 11 ]
QUIC har spesialpakker og normale pakker. Det finnes to typer spesialpakker: versjonsforhandlingspakker og offentlige tilbakestillingspakker. Det er også to typer pakker: Datapakker og FEC-pakker. Alle QUIC-pakker bør dimensjoneres for å passe inn i én MTU for å unngå IP-fragmentering. IPv4 implementerer maksimalt 1370 byte per pakke mens det i IPv6 er 1350 byte. [ 12 ]
De er autentisert og kryptert, bortsett fra den offentlige overskriften som er autentisert, men ikke kryptert. Etter å ha dekryptert innholdet i pakken, begynner klarteksten med en privat overskrift. FEC-informasjonen (Forward Error Correction) finnes i denne private overskriften. Etter denne overskriften har vi typen melding og nyttelasten.
Tilkoblingene forblir åpne til de blir inaktive i en forhåndsforhandlet tidsperiode. Når en server bestemmer seg for å avslutte en inaktiv tilkobling, varsler den ikke klienten. Det er to måter å fullføre: [ 13 ]
Det er også mulig for ett av endepunktene å sende en PUBLIC_RESET- pakke når som helst i forbindelsen, noe som vil føre til at en aktiv forbindelse avsluttes. Det tilsvarer en TCP RST .
Håndtrykket er ansvarlig for å forhandle en rekke transportparametere for en forbindelse [ 14 ]
Nødvendige parametere
Valgfrie parametere
QUIC bruker HTTP/2-prioritetsmekanismen. En strøm kan avhenge av en annen strøm. I denne situasjonen bør «overordnet» -strømmen ha forrang fremfor «barnestrømmen» . Dessuten har "overordnede" strømmer en eksplisitt prioritet, men bør ikke prioriteres opp mot andre strømmer i samme kategori. [ 16 ]
Både QUIC og HTTP/2 inneholder funksjoner og mekanismer som de deler med hverandre, så QUIC lar HTTP/2-mekanismer erstatte sistnevnte med de implementert av transportprotokollen, noe som reduserer kompleksiteten i HTTP/2-protokollen. [ 17 ]
[ 18 ] QUIC-koden ble utviklet eksperimentelt i Google Chrome i 2012, og ble annonsert som en del av Chromium i Chrome versjon 29 (20. august 2013). Den er for øyeblikket aktivert som standard i Chromium, og aktive økter kan sees på chrome://net-internals/#quic. Det er også en nettleserutvidelse for å indikere hvilke nettsider som bruker QUIC.
På samme måte har QUIC blitt introdusert i Opera 16, og kan aktiveres på opera://flags/#enable-quic og opera://flags/#enable-quic-https. Tilsvarende aktive økter kan sees på opera://net-internals/#quic.
Google-servere støtter QUIC. Google har også publisert en prototypeserver. I tillegg er det flere prosjekter i fellesskapet: libquic ble opprettet ved å trekke ut Chromium-implementeringen av QUIC og modifisere den for å minimere avhengighetskravene; goquic gir libquic-kompatibilitet i Go . En implementering av Go kalt quic-go er også tilgjengelig som driver eksperimentell QUIC-støtte på Caddy-serveren . [ 19 ] Til slutt har vi quic-reverse-proxy , en nettverkskanal som fungerer som en omvendt proxy -server , og oversetter QUIC-forespørsler til vanlig HTTP som kan forstås av opprinnelsesserveren.
Microsoft utvikler msquic som en åpen og tverrplattformplattform, i tillegg til implementeringen i .NET 6 i forhåndsvisningsmodus for testing frem til den endelige versjonen som er planlagt for .NET 7
| Gjennomføring | Språk | Beskrivelse |
|---|---|---|
| krom | C++ | Dette er kildekoden for Chrome-nettleseren og referansen gQUIC-implementeringen. Den inneholder en frittstående gQUIC- og QUIC-klient- og serverprogrammer som kan brukes til testing. Lesbar kildekode . Denne versjonen er også basen for Googles LINE og cronet stellite . |
| QUIC Library (mvfst) | C++ | mvfst (uttales move fast) er en klient- og serverimplementering av IETF QUIC-protokollen i C++ av Facebook. |
| LiteSpeed QUIC Library (lsquic) | C | Dette er implementeringen av QUIC og HTTP/3 brukt av LiteSpeed Web Server og OpenLiteSpeed . |
| Quiche | rust | Socket agnostic og avslører en C API for bruk i C/C++-applikasjoner. |
| raskt | C | Dette biblioteket er QUIC-implementeringen for H2O-nettserveren . |
| raskt i gang | Gå | Dette biblioteket gir støtte for QUIC på Caddy-nettserveren . Klientfunksjonalitet er også tilgjengelig. |
| Quinn | rust | |
| Neqo | rust | Denne Mozilla -implementeringen er planlagt integrert i Necko, et nettverksbibliotek som brukes i nettleseren Firefox. |
| aioquic | python | Dette biblioteket har en I/Oless API som er egnet for innebygging i både klienter og servere. |
| pikoquic | C | En minimal implementering av QUIC i samsvar med IETF-spesifikasjonene |
| pquic | C | En utvidbar QUIC-implementering som inkluderer en eBPF virtuell maskin som dynamisk kan laste utvidelser som plugins |
| msquic | C | Åpen distribusjon på tvers av plattformer fra Microsoft |