Názor k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od Filip Jirsák - Můžu se na něco zeptat? Na tohle jste...

Můžu se na něco zeptat? Na tohle jste přišel sám, přečetl jste si to tady v diskusi od spousty ostatních, nebo jste dostal nějaké instrukce? Připadá mi totiž nemožné, aby tolik lidí nezávisle na sobě napsalo takovou hloupost, která buď svědčí o tom, že vůbec netuší, jak vlastně funguje TCP/IP a vlastně ani IP, a nebo se při psaní svého komentáře porovnávajícího QUIC s TCP ani na milisekundu nezamysleli nad tím, jaký je mezi nimi rozdíl.

Pořád dokola se tu objevuje argument, že server přijme požadavek od klienta a začne na jeho základě odesílat bez jakékoli kontroly a limitů obrovské objemy dat. A protože zdrojová IP adresa paketu může být zfalšovaná, mohou ta data mířit na nic netušící oběť.

Hm. Tak si to zkusme představit s TCP. Klient začne navazovat spojení, pošle SYN paket serveru. Server na zdrojovou IP adresu toho SYN paketu (která může být zfalšovaná) začne chrlit obrovské množství dat. Úplně stejně, jako s tím QUIP protokolem. Technicky mu v tom vůbec nic nebrání. A proč by vlastně ten server musel čekat na nějaký SYN paket? Klidně může začít chrlit data do prostoru jen tak, bez vnější příčiny. Jenže servery to obvykle nedělají. Nedělají to bez příčiny, nedělají to na základě SYN paketů TCP, a nebudou to dělat ani na základě QUIC paketů navazujících spojení. Nedává to totiž z pohledu serveru žádný smysl, právě naopak.

Zájem serveru je doručit klientovi data. Server je zpravidla k internetu připojen mnohem tlustší linkou, než jednotlivý klient, zároveň se obvykle k jednomu serveru zároveň připojuje velké množství klientů. Pokud by server vychrlil data pro jednoho klienta jak nejrychleji umí, klient z toho většinu nepochytá a odpoví serveru „hm, dobrý, chytil jsem z toho tak 2 %, pošli mi zbytek znovu“. Server má zájem data klientovi doručit, takže začne znovu chrlit maximální rychlostí – a takhle by se to opakovalo do té doby, než by klient posbíral všechny části. A server by toho odeslal třeba desetkrát nebo stokrát víc, než kolik by bylo potřeba. Ano, server má sice tlustší linku, než klient, ale zase má těch klientů víc – a kdyby odeslal zbytečně stokrát víc dat, než bylo potřeba, potřeboval by také stokrát tlustší linku. Který pak provozovatel serveru by asi takovou implementaci serveru chtěl provozovat?

Takže je ve vlastním zájmu provozovatele serveru a tedy i implementace serveru, aby server odesílal data takovou rychlostí, jakou je dokáže klient přijímat. Jakékoli odeslání paketu, který klient nedokáže přijmout a vyžádá si ho znova, je pro server zbytečný náklad navíc. Takže jakýkoli protokol, který doručuje proud dat a server (resp. jeho provozovatel) má zájem na tom, aby byl doručen klientovi kompletní (protože bez toho se mu ta webová stránka nezobrazí, nebo zobrazí špatně), musí mít implementováno řízení toku dat. Takže ho musí mít i QUIC. Na to nepotřebujete číst ani specifikaci, ani zprávičku, na to stačí provést triviální úvahu předvedenou výše.

Chrlit data bez potvrzování by mohlo mít význam pro video, pokud se používá kodek, kde nějaký ztracený paket nevadí. Jenže i tam jsou pro server náklady navíc, pokud chrlí data, která klient zpracovat nedokáže, nebo je možná už vůbec nechce. Navíc pokud se ztratí půlka paketů, tak už se to na tom videu pozná. Takže i tam má server zájem na tom posílat data jenom tak rychle, jak je klient dokáže zpracovávat,a tak dlouho, dokud o ně má zájem. To povolení jisté ztrátovosti paketů znamená jenom to, že server může být lehce agresivnější při zjišťování limitů spojení.

A teď mi někdo vysvětlete, proč je tu 80 % diskutujících (na začátku diskuse to bylo dokonce 100 %), kteří takovouhle základní úvahu neudělají, a místo toho píšou do diskuse bláboly.