Kortare laddningstider och förbättrad säkerhet med HTTP/3

Kortare laddningstider och förbättrad säkerhet med HTTP/3

Protokollet HTTP är en av nyckelkomponenterna bakom internet. Version tre ger ökad säkerhet och kortare laddningstider och får stöd av allt fler webbläsare till hösten.

Läs hela artikeln här

Citat:

Med HTTP3 tar protokollet till slut steget bort från TCP och anammar istället det mer moderna User Datagram Protocol (UDP).

Det här läses väldigt konstigt. Ja, UDP kan väl anses rent tekniskt sett vara _mer modernt_ än TCP, men den meningen får det att låta som att UDP skapades häromåret. Vi har ju haft det i runda slängar 40 år.

Om internet använder sig av Google teknik betyder inte det att vi blir beroende av dom och får större makt över internets infrastruktur?

Skickades från m.sweclockers.com

Det är väl snarare QUIC som är mer modernt...

En fråga blir då hur QUIC/UDP löser det som TCP gjort tidigare. Vilket verkar vara väldokumenterat här: https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html

Ja udp är varken modernare eller bättre, det är ett annat protokoll än tcp med sndrs egenskaper, varken bättre eller sämre än tcp. Rätt protokoll till rätt applikation.

Skickades från m.sweclockers.com

Skrivet av moire:

Ja udp är varken modernare eller bättre, det är ett annat protokoll än tcp med sndrs egenskaper, varken bättre eller sämre än tcp. Rätt protokoll till rätt applikation.

Det är ju rätt det du skriver (förutom att UDP inte är modernare, definierades 6 år efter så är per definition modernare) men det är ju ändå att dom har olika fördelar, t.ex. att UDP är snabbare i grund, TCP är mer pålitligt i grund. Eftersom dom tydligen med HTTP3 vill göra det snabbare så är det logiskt att dom vill byta till UDP-baserat, gäller bara att kompensera för dess nackdelar (vilket QUIC verkar göra).

Skrivet av jehuty:

Om internet använder sig av Google teknik betyder inte det att vi blir beroende av dom och får större makt över internets infrastruktur?

Skickades från m.sweclockers.com

Nä, detta är eller blir ju bara allmänt tillgängliga standarder. Så inget som kan användas vare sig för att besitta en teknisk fördel över andra företag eller binda användare på något vis.

Någon som kan förklara lite enkelt vad fördelarna och nackdelarna är med UDP över TCP?

Mina gamla och bristfälliga kunskaper säger typ att UDP är bra till strömmande saker osv men TCP bättre till saker där tappade paket är dumt.

Läste om QUIC vid 2018, ni som vill veta mer om hur det fungerar läs på Cloudflares blog.
https://blog.cloudflare.com/the-road-to-quic/

För mer info om hur http/3 fungerar läs nedan.
https://blog.cloudflare.com/http3-the-past-present-and-future...

Skrivet av Kilroy:

Någon som kan förklara lite enkelt vad fördelarna och nackdelarna är med UDP över TCP?

Mina gamla och bristfälliga kunskaper säger typ att UDP är bra till strömmande saker osv men TCP bättre till saker där tappade paket är dumt.

TCP
Abstraktionen är en sekvens av oktetter (som i praktiken är vad vi kallar "bytes") där bevarande av ordning garanteras. Så om jag skickar ABCD följt av 1234 kommer mottagaren ta emot data som sekvensen ABCD1234 eller få ett felmeddelande om leveransen misslyckades (då kan inget, eller delar av data levererats men den del som levererats är i rätt ordning)
UDP
Abstraktionen är egentligen bara att två ID-fält ("avsändarport" och "mottagarport") läggs direkt ovanpå IP-protokollet. Detta medför att data levereras som "paket" utan att någon speciell ordning garanteras mellan paketen. Så skickar jag ABCD i första paketet och 1234 i andra kommer ordningen inom varje paket behållas, men mottagaren kan få pakten i omvänd ordning, få bara ena paketet eller inget av dem utan att det ges någon feedback vare sig till mottagare eller sändare

QUIC ger tre stora fördelar över TCP

  • Det är fullt möjligt att skicka flera separata strömmar i samma TCP-ström, men med TCP kan man inte leverera någon data när det finns hål medan QUIC kommer leverera data från en ström så fort all data tillhörande den strömmen finns tillgängligt. Enda sättet att få motsvarande (och väldigt önskvärda) beteende med TCP är att hantera strömmarna som separata TCP-koppel (men finns massor med nackdelarna med det)

  • Även om TCP kan hanteras som ett bibliotek i applikationen är det i praktiken något som ligger i OS-kärnan. Trenden idag är att minska mängden kod i OS-kärnor då säkerhetsproblem där är katastrofala. Är också lättare att säkerställa interoperabilitet mellan olika OS om de använder samma kod för protokollet. QUIC är hanteras som ett bibliotek och referensimplementationen är fritt tillgänglig!

  • Artikeln om QUIC som denna artikel länkar till går igenom aspekt att handskakning även för kryptering/autentisering kan hanteras betydligt effektivare i QUIC, vinsten är en snabbare webbupplevelse

Senast redigerat 2019-09-28 16:53
Skrivet av Kilroy:

Någon som kan förklara lite enkelt vad fördelarna och nackdelarna är med UDP över TCP?

Mina gamla och bristfälliga kunskaper säger typ att UDP är bra till strömmande saker osv men TCP bättre till saker där tappade paket är dumt.

I det stora hela stämmer ju det du säger. TCP garanterar bland annat att du får varje paket (trasiga och borttappade paket skickas om) och i rätt ordning (ordnas efter sekvensnummer innan applikationen får dem), medan UDP bara garanterar att de paket som du får kommer till rätt port och är felfria (kontrolleras med checksumma).

Skrivet av TheSlicker:

Det är ju rätt det du skriver (förutom att UDP inte är modernare, definierades 6 år efter så är per definition modernare) men det är ju ändå att dom har olika fördelar, t.ex. att UDP är snabbare i grund, TCP är mer pålitligt i grund. Eftersom dom tydligen med HTTP3 vill göra det snabbare så är det logiskt att dom vill byta till UDP-baserat, gäller bara att kompensera för dess nackdelar (vilket QUIC verkar göra).

Jag kanske missförstår dig nu, men UDP är väl ändå inte på något sätt nyare än TCP?

UDP (1980): https://www.ietf.org/rfc/rfc768.txt

TCP (1981): https://www.ietf.org/rfc/rfc793.txt

Skrivet av BasseBaba:

Det är väl snarare QUIC som är mer modernt...

En fråga blir då hur QUIC/UDP löser det som TCP gjort tidigare. Vilket verkar vara väldokumenterat här: https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html

Skrivet av Kilroy:

Någon som kan förklara lite enkelt vad fördelarna och nackdelarna är med UDP över TCP?

Mina gamla och bristfälliga kunskaper säger typ att UDP är bra till strömmande saker osv men TCP bättre till saker där tappade paket är dumt.

Ja, om man fokuserar på det väsentliga här så handlar det om att man byter TCP mot QUIC.

QUIC är typ "nästa generations TCP", men när de designade QUIC så valde de att implementera QUIC som ett lager ovanpå UDP istället för ett helt separat protokoll. Detta handlar *inte* om att de ville åt UDP i sig, QUIC *borde* vara ett separat protokoll egentligen.
Dock ville kunna leverera lösningen i t.ex. en webbläsare utan att behöva få in stöd för ett nytt protokoll i IP-stacken på operativsystemnivå, och då passade UDP bra att bygga QUIC ovanpå eftersom UDP är mest som ett tomt skal utan egna beteenden, det bara skickar datan man säger utan att lösa felhantering, osv (till skillnad från t.ex. TCP).

Det betyder alltså att det är helt meningslöst att börja jämföra TCP med UDP om man ska förstå HTTP/3, det är en fullkomligt missvisande jämförelse!
Jämför TCP med QUIC, de är varandras närmaste motsvarigheter om man ska se till hur HTTP/3 fungerar jämfört tidigare HTTP-versioner.

Stämmer det verkligen att Opera 16 har stöd för detta med tanke på hur länge sedan den versionen lanserades?

Skickades från m.sweclockers.com

Skrivet av TheSlicker:

Det är ju rätt det du skriver (förutom att UDP inte är modernare, definierades 6 år efter så är per definition modernare) men det är ju ändå att dom har olika fördelar, t.ex. att UDP är snabbare i grund, TCP är mer pålitligt i grund. Eftersom dom tydligen med HTTP3 vill göra det snabbare så är det logiskt att dom vill byta till UDP-baserat, gäller bara att kompensera för dess nackdelar (vilket QUIC verkar göra).

Nåja. Bara för att det kanske är 6 år yngre så betyder det inte att det är modernare. Jag skulle kunna köpa nya kläder idag som är betydligt mer omoderna än de jag köpte igår. Tidsenlig är en bättre definition av ordet modern än ny.
Kram å trevlig helg, nu ska språkpolisen sova lite.

Skickades från m.sweclockers.com

Skrivet av nyllet83:

Stämmer det verkligen att Opera 16 har stöd för detta med tanke på hur länge sedan den versionen lanserades?

Skickades från m.sweclockers.com

Det kan nog vara sant i någon mening, Chrome inkluderade QUIC-stöd för första gången i version 29 vad jag kan se.

Att rent tekniskt ha stöd implementerat för ett ej färdigställt protokoll och att det är redo att användas på riktigt är ju dock två helt olika saker.

Det är nog mer relevant att se till att de säger att nuvarande Chrome Canary nu fått stöd än att det fanns stöd i Chrome 29, och detsamma gäller väl Opera.

Skrivet av evil penguin:

Det kan nog vara sant i någon mening, Chrome inkluderade QUIC-stöd för första gången i version 29 vad jag kan se.

Att rent tekniskt ha stöd implementerat för ett ej färdigställt protokoll och att det är redo att användas på riktigt är ju dock två helt olika saker.

Det är nog mer relevant att se till att de säger att nuvarande Chrome Canary nu fått stöd än att det fanns stöd i Chrome 29, och detsamma gäller väl Opera.

Opera 16 släpptes 2013.

Edit: Opera har varit först med en hel del, men så mycket före är de definitivt inte

Skrivet av filbunke:

Opera 16 släpptes 2013.

Edit: Opera har varit först med en hel del, men så mycket före är de definitivt inte

Google Chrome 29 släpptes 2013. Opera från och med version 15 är baserat på Chromium, dvs de behövde inte implementera något själva, de fick stödet "på köpet" när Google implementerade det i Chrome.

Skrivet av evil penguin:

Google Chrome 29 släpptes 2013. Opera från och med version 15 är baserat på Chromium, dvs de behövde inte implementera något själva, de fick stödet "på köpet" när Google implementerade det i Chrome.

Det vet jag, har använt Opera i många år.

Men Opera version 16 hade det defintivt inte, vilket var poängen.

Skrivet av filbunke:

Det vet jag, har använt Opera i många år.

Men Opera version 16 hade det defintivt inte, vilket var poängen.

Beror kanske på vad du avser med "det".

Om "det" betyder "stöd för en tidig implementation av HTTP över QUIC, ett förstadium till HTTP/3" så hade ju Chrome 29 detta (endast aktivt för begränsat test).

Chrome 29 och Opera 16 är samtida, Opera 16 var baserat på Chromium (grunden för Chrome-kodbasen). Jag ser ingen anledning att misstro påståendet att motsvarande fanns i Opera 16.

Bakåtsträvare som man är, kan jag få stöd för http/3 i form av en plugin till Firefox 56?

Skickades från m.sweclockers.com

Skrivet av grönbladh:

Bakåtsträvare som man är, kan jag få stöd för http/3 i form av en plugin till Firefox 56?

Skickades från m.sweclockers.com

I teorin är det väl möjligt. Frågan är varför du vill sitta med en gammal och osäker webläsare?

För de ändrade plugin-stödet iom quantum (v57).

Skickades från m.sweclockers.com

Skrivet av grönbladh:

För de ändrade plugin-stödet iom quantum (v57).

Skickades från m.sweclockers.com

Helt fel lösning däremot. Jag antar att du har behov av NPAPI plugins, isf så bör du gå över till exempelvis Waterfox eller Pale Moon som båda är forks av Firefox med NPAPI stöd och får säkerhetsuppdatteringar. Ingen bör sitta kvar på en webbläsare som inte får säkerhetsuppdatteringar, speciellt efter alla hårdvarufel som uppmärksammats som löses med bland annat fixar i webbläsaren.

Skrivet av evil penguin:

Beror kanske på vad du avser med "det".

Om "det" betyder "stöd för en tidig implementation av HTTP över QUIC, ett förstadium till HTTP/3" så hade ju Chrome 29 detta (endast aktivt för begränsat test).

Chrome 29 och Opera 16 är samtida, Opera 16 var baserat på Chromium (grunden för Chrome-kodbasen). Jag ser ingen anledning att misstro påståendet att motsvarande fanns i Opera 16.

Får hålla med om det.

Skrivet av Soir:

Det här läses väldigt konstigt. Ja, UDP kan väl anses rent tekniskt sett vara _mer modernt_ än TCP, men den meningen får det att låta som att UDP skapades häromåret. Vi har ju haft det i runda slängar 40 år.

Den stora skillnaden (som i viss mån beskrivits tidigare) är att TCP är ett "felsäkert" protokoll, d.v.s. protokollet i sig säkerställer att data har nått mottagaren medan UDP inte har detta stöd utan det är upp till applikationen att hantera eventuellt borttappade paket och paketens ordning. Så jag vill inte påstå att UDP är tekniskt sett mer modernt än TCP utan att UDP uppfyller ett helt annat syfte än TCP.

För strömmar som bild och ljud så är UDP bättre än TCP eftersom ett borttappat bildpaket kan bli en kort glitch men om det sker enstaka gånger är det inget man reagerar på. När det är frågan om att inte tappa något data så är det TCP som man bör välja.

Men när jag nu kollar på HTTP/3 så ser det mera ut som om det är QUIC (Quick UDP Internet Connections) som det är frågan om.

Sedan är frågan om hur länge det dröjer innan allt detta realiseras i stor utsträckning på webben.

Litet förvånande är dock att inte SCTP har tagits upp som möjligt protokoll för HTTP.