HTTP/3 webbisurffailun nopeampi tulevaisuus

[ztec]

Yleiskeskustelu aiheesta, joka varmaan tulee elämään pitkään.

Aktivoin juuri HTTP/3:n muutamalle sivustolleni Cloudflaren avustuksella. Myös Chromeen ja Firefoxiin on tuki kovasti tulossa.

HTTP/3:n pääasiallinen etu on siinä, että se siirtää tiedot UDP yhteyden yli, eikä käytä TCP:tä. Jolloin packet loss ei aiheuta samanlaista merkittävää hidastelua yhteydelle kuin TCP:llä. Nopeilla kiinteillä yhteyksillä vaikutus voi olla pieni, mutta varsinkin mobiilipuolella tuolla voi olla isompi merkitys. Sivustojen renderöinti ei blokkaa niin helposti kokonaan. Samalla tuo myös yhdistää TLS:n ja HTTPS:n yhteen pakettiin, jolloin myös yhteyksien avaus ja jatkaminen nopeutuu merkittävästi.

Varmaan myös tärkeimmät web-serverit, kuten Nginx, Apache ja IIS tulevat tuota tukemaan piakkoin.

Tässä hyvä artikkeli aiheesta HTTP/3 Cloudflaren blogissa.

Yleislinkki aiheeseen: HTTP/3 @ Wikipedia. (Vinkki, tuosta ei muuten ole vielä Suomenkielistä sivua)

Henkilökohtaisesti mietin hetken, että olisiko HTTPv3 pitänyt toteuttaa kokonaan omana OSI Layer 4 protokollana IP:n päälle, eikä UDP:n päälle. Mutta tuo olisi aiheuttanut varmasti merkittäviä ongelmia monien surkeiden kuluttajalaitteiden kanssa, joiden protokollatuki on vähintääkin kyseenalainen.

 

[olkitu]

Ehtisin itsekin CloudFlaren kautta enabloimaan sivulleni HTTP/3:sen ja testaamaan Chrome Canary-versiolla sitä. Kyllä huomaa että HTTP/3 on reilusti nopeampi vs HTTP/2 mitä testasin.

 

[ztec]

Ehtisin itsekin CloudFlaren kautta enabloimaan sivulleni HTTP/3:sen ja testaamaan Chrome Canary-versiolla sitä. Kyllä huomaa että HTTP/3 on reilusti nopeampi vs HTTP/2 mitä testasin.

Näin on, varsinkin mobiilissa. Kiinteillä yhteyksillä missä latenssi on muutaman millisekunnin 1 - 2 ja packet loss on käytännössä 0%, niin slow startin aiheuttama ero ei ole niin mullistava. mutta varsinkin mobiilissa, jossa latenssit on mitä on ~50ms ja sitten packet lossiakin on, sekä latenssissa vielä iso jitteri. Niin yksinkin kadonnut paketti varsinkin slow startin aikana aiheuttaa just sen, että sivun aukeamista saa sitten odotella useita sekunteja, ennen kuin yhteydet pääsee taas jaloilleen.

En ole tutustunut muuten täysin HTTP/3:n flow controlliin ja sen toimintalogiikkaan. Pitääkin lukea jossain vaiheessa tuo vielä kokonaan läpi. Onhan TCP:n kanssa myös mahdollista käyttää varsin erilaisia congestion control menetelmiä. Pistinkin saman tien bookmarkin mistä jatkaa.

Tällainen asetus SETTINGS_INITIAL_WINDOW_SIZE kyllä löytyy speksistä, mutta en lyötänyt täsmällistä algoritmiä millä sitä hallitaan yhteyden avauksen jälkee.

Tässä tämän hetkinen HTTP/3 draft v 23 speksi. Tässä viimeisin QUIC speksi jonka päällä HTTP/3 pyörii. Sieltä löytyy myös WINDOW_UPDATE frame, sekä myös CONGESTION_FEEDBACK Frame ja BLOCKED Frame:t. Eikä muuten sieltäkään löytynyt kuin "autotuning". Mä pidän tuolaisesta. Ehkä se on tarkoituksella jätetty auki?

Pitää muistaa itsekin kun kirjoittaa speksejä tai määrittelyjä, että hyvä kuvaus järjestelmän toiminnasta on, "järjestelmä toimii automaattisesti". - Tuohan kyllä pätee nykyjään aika moneen järjestelmään. Ja sitten jos ei toimi, niin gusessa olet. Mielelläni olisin lukenut tuon hieman kevyemmällä tasolla kuin sourcesta suoraan. Koska ainakin osa noista flow control menetelmistä on varsin monimutkaisia. Jos joku ei tiedä mistä puhutaan niin Cubic, Reno, Compound TCP, tuli ainakin muistista suoraan. Sekä muitaakseni Google taisi käyttää TCP BBR:ää joka kuulemma parantaa mm. YouTuben toimintaa olennaisesti. - Nää siis täysin mutuna, ei jaksa tarkistaa tähän aikaan. - Koska Google & QUIC, niin voisin arvata että algoritmi on aika lähellä BBR:ää.

 

[Tuke]

Tässä olisi curl:n tekijän selostus HTTP/3:sta Introduction · HTTP/3 explained

 

[ztec]

Tässä olisi curl:n tekijän selostus HTTP/3:sta Introduction · HTTP/3 explained

Tuollahan se tulikin heti vastaan, mitä olen jo mielessäni pyöritellyt hetken:
Non-HTTP over QUIC · HTTP/3 explained

Ei sinänsä mikään uusi trendi. Että kaikki muut protokollat paitsi HTTP katoaa. HTTP korvaa TCP:n protokollana, jolle sovellukset rakennetaan. Mukavasti oli myös viitattu SCTP:n tuolla haxx:n sivuilla. Tuo että tiedonsiirto sallitaan muilla kuin HTTP protokollalla QUIC:n yli on varmasti mielenkiintoinen optio tulevaisuudessa. Tuosta onkin ollut paljon puhetta kehittäjien piirissä, onko se sitten hyvä vai huono asia.

Tuntuu siltä, että monet devaajat ei nykyjään osaa edes mitään muuta kuin RESTfulia. Eräässä projektissa piti tehdä ihan perusprotokolla, joka siirteli ennaltamääriteltyjä pakettirakenteita puhtaan TCP:n yli. Suurin osa kehittäjistä sanoi, että se on mahdotonta. Tietysti monella on nykyjään jo sellaiset kehitys frameworkit ja plattarit käytössä, jotka ei edes tue muuta vaihtoehtoa. - Monesti olen hymyillyt mm. palveluille jotka tarjoavat mailin lähetystä RESTful API:lla, koska SMTP on "niin vaikeaa". Heh.

 

[ztec]

Tässä olisi curl:n tekijän selostus HTTP/3:sta Introduction · HTTP/3 explained

Luin tuon kokonaan uudestaan. Pari kohtaa oli siellä jotka jäi mietityttämään, vaikka olen niistä kyllä aikaisemminkin lukenut ja myös kirjoittanut blogiin etc.
1. Server Push - Tästä voidaan varmasti olla montaa mieltä, onko hyvä vai huono asia.
2. Prioriteetti - Miksi suhteellinen prioriteetti, miksei absoluuttinen? Henkilökohtaisesti olisin tykännyt absoluuttisesta prioriteetista enemmän. Ihan vain tunne pohjalta. Suhteellisella prioriteetilla vähemmän tärkeä tavara valuu siellä seassa. Tietysti tähän voidaan ylipäätään vaikuttaa sillä, missä järjestyksessä streameja avataan.

Kuten kirjoitin joskus jo h2:n osalta niin h3 tulee tuomaan kyllä sellaisen optimointi-viidakon joka tasolle, ettei mitään rajaa. Mutta onhan se hyvä, että töitä riittää. Samoin näiden perusprotokollien massiivinen monimutkaistuminen jatkuvasti johtaa varmasti siihen, että kelvollisia implementaatioita ei tule olemaan kovin montaa.

Aina hymyilyttää kun multiplexing streams tulee uutena juttuna. Se oli jo vanha juttu silloin kun se implementointiin Smodemiin (MSLP). Joka kyllä teki sen paremmin kuin kipailijat ei Hydra tai Bimodem.

Tuolta loppupäästä muuten löytyi juuri se tieto, mitä kaipailinkin. Eli vuonohjaus:
https://tools.ietf.org/html/draft-ietf-quic-recovery-23

Pitänee lukea tuo kuin piru raamattua.

Toinen osuus joka on hyvä kerrata oli tämä QPACK, HPACK:n luinkin ja mietiskelin joskus läpi huolellisesti:
https://tools.ietf.org/html/draft-ietf-quic-qpack-10

 

[ztec]

Vihdoinkin virallinen HTTP/3 RFC 9114 on ulkona:
Information on RFC 9114 » RFC Editor

Tuolla sitten tullaan menemään jonkin aikaa tulevaisuudessa.
Toinen asia joka liittyy tähän on DoH3 eli DNS-over-HTTP/3, joka on mielestäni hyvä ratkaisu. En oikein koskaan lämminnyt DoT:lle tai DoH:lle, niissä kummassakin olevien eri haasteiden / heikkouksien takia.