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

Permalänk
Melding Plague

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

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem
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.

Permalänk
Medlem

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

Permalänk
Medlem

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

Permalänk
Medlem

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

Visa signatur

Nätverksnörd

Permalänk
Medlem
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).

Visa signatur

Post-and-run foruming
GeForce GTX 1070 ;~; Intel 4790k ;~; ASUS Z97M-PLUS ;~; Cooler Master Hyper 212 EVO ;~; ADATA 16GB 1600MHz RAM ;~; 840 EVO 500GB + 1TB WD Blue + 4TB WD Green ;~; Seasonic Platinum 660w ;~; Fractal Design Define Mini ;~; G910 "Orion Spark" ;~; U2415 x2 ;~;

Permalänk
Medlem
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.

Visa signatur

Operativsystemet som löser nästan alla problem: Mint

Permalänk
Medlem

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.

Permalänk
Medlem

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...

Visa signatur

[ Fractal Design Define S Svart ] [ ASUS ProArt X670E-Creator WIFI ] [ Amd Ryzen 9 7950x3D ]
[ G.Skill Trident 64GB DDR5 6000MHz ] [ Noctua NH-D15 Chromax Black ]
[ Western Digital Black SN850X 1TB Gen4 ] [ Samsung 870 QVO 2TB MZ-77Q2T0BW ]
[ ASUS TUF GeForce RTX 3080 10GB Gaming OC ]
[ Corsair AX860 80 Plus Platinum ] [ Gigabyte 32" M32U IPS 4K 144 Hz HDMI 2.1 ]

Permalänk
Datavetare
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

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
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).

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Medlem
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

Permalänk
Medlem
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.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem

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

Visa signatur

Dator: FD Node 304 + GA-H97N-WIFI + i5 4590 + 8GB + AMD 280X + 256GB SSD + 1TB HDD.
Skärm: Philips 272C4Q 27" 2560x1440
Laptop: Macbook Pro 15" (2018)
Nätverk: Ubiquiti USG, Två UAP-AC-HD och Cloud Key
Ljud: Lyngdorf TDAI 2170 + PMC Twenty 26 + Thorens TD-190 II + Suprakablar.

Permalänk
Medlem
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

Permalänk
Medlem
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.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
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

Permalänk
Medlem
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.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem
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.

Permalänk
Medlem
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.

Visa signatur

Desktop: Ryzen 5800X3D || MSI X570S Edge Max Wifi || Sapphire Pulse RX 7900 XTX || Gskill Trident Z 3600 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Medlem

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

Permalänk
Medlem
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?

Visa signatur

WS: MSI B350M Mortar | AMD Ryzen 7 1700 | PH-TC14PE | 32GB DDR4 3000MHz | 120GB Intel 530 | 2*500GB HDD | Intel Arc A750 8GB | 2*BenQ G2420HDB
Router: Gigabyte GA-870-UD3 | AMD Phenom II x6 1055t @ 2600MHz, 1.25V | 12GB DDR3 | 2*250GB HDD @ RAID1 | 4TB HDD
Laptop: Thinkpad X220 4291-QF6

Permalänk
Medlem

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

Skickades från m.sweclockers.com

Permalänk
Medlem
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.

Visa signatur

Citera eller @philipborg om du vill att jag ska läsa dina svar.

Permalänk
Medlem
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.

Permalänk
Medlem
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.