Firefox & http/3

Címsorba: about:config
Majd rákeresni http3 -ra és át kell állítani:
network.http.http3.enabled  true

És lőn (tcpdump):
08:33:32.849274 IP6 2a00:1450:400d:803::200a.443 > 2a01:36d:103:27af:6375:d343:2a13:1a02.39378: UDP, length 1337

Működik (Firefox 81.0.1, Ubuntu 20.10 beta).

 

Most már csak a szerver oldal a kérdés: apache2 és nginx mely verziói támogatják a http/3-at?

Hozzászólások

Szerkesztve: 2020. 10. 11., v - 10:41

Apache még a wiki szerint nem, nginx 1.19-ről regél a wikipedia-oldal :-) Böngészőt itt tesztelheted: https://quic.nginx.org/

Köszi a tesztoldalt: Congratulations! You're connected over QUIC.

A changelogot elnézve 1.17.9-től van http/3 bejegyzés, de az 1.19.1-3 között az utóbbi 3 hónapban megindult rendesen. És ugyebár a párosak a stabil kiadások.
Ezek szerint az áprilisban várható Ubuntu 21.04 és a nyáron várható Debian-11 (Bullseye) része lehet az 1.20, ahogy reményeim szerint a PHP8 is.
 

En hiaba allitottam at, akkor is azt mondja, h nem OK.

Fantasztikus, hol tart már a tudomány, viszont nekem még egy vacak IPv6-ot sem ad a szolgáltatóm.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Off: Ennek valami konkrét előnye is van, vagy pusztán az újdonság öröme miatt jó?

Ha sok kiegészítő tartalmat kell betölteni (CSS, JS, képek, betűtípusok, stb.) HTTP-streaming nélkül, akkor gyorsan összeadódnak azok a századmásodpercek az első betöltésnél, ami az egyik legfontosabb. De abban mindenképp igazad van, hogy a backendet is optimalizálni kell (+ ezerrel cachelni). Azonban ha a transport rétegben "ingyen" lehet megspórolni pár tized-század mp-et, akkor miért ne tennénk?

Bizonyos oldalak főleg amit nem közelről ér el azok fürgébben töltenek majd be, ha a szerver támogatja. YouTube ami mondjuk nagyon közel cachelt a felhasználóhoz gyorsabban rebufferel seekelés után. Otthoni gigabites kapcsolatnál nem feltétlenül fog ez előjönni, mobilon rossz lefedettségnél vagy gyenge jelű wifin viszont nagyon látványos. 

Maga a QUIC protokoll egyébként nagyjából 5 éve támogatott chrome-ban, FF-ba csak azért került be most mert az IETF szabványosítási folyamat és a szabványos verziónak az implementálása most jutott idáig. 

Valóban támogatott a Chrome-ban, de a https://quic.nginx.org/ oldal azt mondja rá, hogy nem működik, chrome://flags/#enable-quic "Enabled" beállítás ide, vagy oda; csak ha:

--enable-quic --quic-version=h3-29 --origin-to-force-quic-on=quic.nginx.org:443

paraméterekkel indítom, akkor mondja az oldal, hogy működik.

Igen, de ez azért van mert a google nem szabványos QUIC implementációt használ alapból, hanem a sajátját. Talán négy éve néztem utoljára ezt és akkor már UDP-n kommunikált a youtube-al meg más google-ös szolgáltatásokkal a Chrome böngésző. Minden bizonnyal ha lesz végleges HTTP3 szabvány akkor remélhetőleg a Google is áttér rá. Elég szövevényes ez az egész nekem, pár hónapja egy konferencián Daniel Stenberg a curl tool írója tartott erről egy hosszú előadást, onnét rémlik halványan mi most a helyzet a HTTP3 körül. 

HTTP/2 bezette a tobb sub stream -et egytlen tcp kapcsolaton,
de ha tcp elhagy egy csomagot akkor minden megall
amig ujra nem lesz kuldve.

HTTP/3 nal (udp) ha egy csomak eltunik akkor csak az egyik
stream hal el egy darabig, a tobbit kapod.

HTTP/1.1 tobb kapcsolat kiepites szugseges tobb streamhez,
a cliensenk ez nem nagy gond, a szerverek eseteben nem felteltetlen
orom es boldogsag ..

Is mint irtak TLS:
https://blog.cloudflare.com/the-road-to-quic/

HTTP/1.1 ssl nelkul es nincs gond ;-) Nagy kapcsolat szamra vannak trukkok,
azok akiknek tenyleg kell, meg tudjak oldani..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Továbbá ha a HTTP/1.1 esetén sok stream van, nagyobb objektumokkal, a kliens meg valami lassú kapcsolatról (pl. mobil) csatlakozik, akkor a sok TCP kapcsolat szinkronban kezd küldeni a szerveren, exponenciálisan növelve az ablakméretet, ami szűk keresztmetszetnél egy nagy burstben jelenik meg, megtelnek a sorok, dobás lesz, aztán (nagy RTTs mobil kapcsolatnál) szépen újra kell küldözgetni a kiesett csomagokat. 

Ahogy nezem megha van az embernek gyors nete, a szolgaltatok akkor sem toljak maxon.
A szolgaltato kepes lehet, a tobb kapcsolatot figyelmbe venni, ahogy az HTTP/3 -nal is kell,
es nem maxon tolni minden streamet egyetlen kliens fele.
A kliens is kezdhet kisebb windowal, ha tudja hogy nem al a bandwith magaslatan.

"mobil kapcsolatnál" mekkora buffer jelemzo a 4G masik oldalan, per cliens ?

Ha sok nagy objektumot kersz egy  szuk savon, akkor az alacsony valaszidot akkor
is feljetheted, ha nincs dobas.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.