Dost se mi nelíbí ten nešvar co se nám tu poslední dobou rozmohl a to nasazování nehotových protokolů. Jak je zmíněno v článku i sám Google používá dvě (nekompatibilní) verze. Koncovému uživateli je to asi jedno, protože "Chrome si to stejně nějak dohodne", ale co chudáci vývojáři, správci a nadšenci.
Pokud první spuštění v novém prostředí považujete za testování, pak byste nikdy nic nespustil. Protože před tím, než byste něco na produkci spustil na ostro, byste to musel na produkci otestovat. Ale to se nesmí.
Za skvělý nápad považuju něco otestovat v reálném světě před tím, než se na to nalepí nálepka, že je to finální standard. Jsou totiž dvě možné situace. Buď se to při testování osvědčilo a ta nálepka se nalepí na to samé, co se před tím testovalo. Podle vás se ta testovaná věc nějak zázračně zlepší tím, že ji prohlásíme za standard? Asi těžko. Druhá možnost je, že se v reálném světě ukáže, že navržené řešení má nějaké problémy. Pak je ovšem možné je opravit ještě dřív, než vznikne finální standard, který pak implementují všichni. Podle vás by bylo lepší, kdyby ta testovaná verze měla už nálepku finálního standardu a implementovaly by jí všichni? Takže ty problémy by se místo testování na pár serverech týkaly úplně všech?
Ono je totiž potřeba alespoň malinko vědět, jak funguje testování (že to není jednorázová záležitost, ale s tím, jak se produkt dokončuje, zapojuje se do testování víc a víc subjektů a prostředí, kde se to provozuje, jsou stále kritičtější). Opakování větiček zaslechnutých někde na internetu nestačí.
Jen tak pro pobavení, jaký by tedy byl správný postup podle vás? Současnou verzi HTTP over QUIC prohlásit za finální standard HTTP/3? Nebo jak a kde byste ji chtěl dál testovat, aby se postupně dostala do stavu, kdy může být prohlášena za finální verzi standardu?
Nemám nic proti testování.
Nelíbí se mi situace, kdy velký subjekt, který dnes víceméně diktuje co se používá nasadí veřejně nehotovou věc. Vytváří to pak jistý dojem, že je hotová. Chytnou se toho pak ostatní a implementují ji tak jak je v draftu, který se může ještě 10x změnit, ale my pak budeme řešit důsledky těch špatných implementací, jelikož ne všichni nasadí změny a opravy (zvláště v SOHO sféře).
třeba zrovna u HTTP/2 alias SPDY od Googlu, různé implementace, různé verze prohlížečů to různě podporující, různé snahy firem to také nějak umět. Důsledek takovéhoto postupu je třeba nefunkční Server Push, kvůli chybné implenentaci na klientech a serverech.
V HTML5 rodině je zase důsledek neustálého proudu novinek snížení konkurence na straně vykreslovacích enginů, většina nezvládla držet krok.
...deleted zbytečná reakce na ad hominem argumenty které si laskavě nechte od cesty, na to není nikdo zvědavý...
Možná byste si místo nich mohl taky nastudovat standard, zamyslet se kde primárně může být v reálném provozu zakopaný pes (případně to ověřit na reálných příkladech přípojení) a třeba byste zjistil, že případné ladění nemusí znamenat změnu samotné specifikace, ale v konkrétním ladění parametrů. Client i server side. https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html
ad poslední odstavec - třeba tak jak to dělá Firefox s opt-inem. Čemuž by měl předcházet dostatečně rozsáhlý test v labu na prověření nejen nejčastějších, ale i okrajových use cases, který alespoň v minulosti (viz můj příspěvek na začátku) evidentně minimálně v jednom případě neproběhl a/nebo byl naprosto odfláklý.
Ostatně celou absurdnost situace dokreslují dvě různé implementace.
Edit: A jak byste to řešil Vy zavedení nové technologie, pokud byste nebyl technologický gigant, který má kromě arogance k dispozici i několik miliard (ne)dobrovolných testerů?
10. 10. 2020, 21:00 editováno autorem komentáře
Jenom jste zapomněl napsat, jak si představujete to testování na reálných připojeních bez reálných připojení.
Implementace HTTP/3 v Chrome byla rozsáhle testována v labu, pak to bylo opt-in v prohlížeči, pak to bylo defaultně zapnuté v Chromiu, a teď se to postupně zapíná v Chrome. Vaše přání jsou splněna dříve, než je vyslovíte. Škoda, že jste si nepřečetl alespoň druhou větu zprávičky, pod kterou diskutujete.
A opravdu takové testování stačí ? Ono dokud jsme přecházeli z HTTP 1.1 na 2.0, tak asi ok ... protože to byly protokoly které neovlivňovaly nic kolem.
Ale teď tu najednou přecházíme z TCP na UDP ... ptal se někdo operátorů, jak se zachovají jejich síťové prvky, pokud jim bude v budoucnu třeba více jak polovina provozu běhat po UDP? Budou fungovat stávající AntiDDOS ochrany ?
11. 10. 2020, 13:36 editováno autorem komentáře
To je právě ten důvod, proč se to zapíná postupně. Operátoři o tom dopředu samozřejmě mohou vědět, pokud se zajímají. Situaci „je potřeba udělat takovéhle změny, připravte se na to a dejte vědět, až budete připraveni“ známe ze zavádění IPv6. To se takhle zavádí už dvacet let, a jsou stále tací operátoři, kteří to neřeší, protože to údajně nikdo nepoužívá. Takže jediná reálná možnost, jak něco nového zavést, je po otestování to pustit v malém do běžného provozu a postupně přidávat.
Mimochodem, antoDDoS ochrana musí především ustát velký objem příchozích paketů. Sledovat v takové situaci každé jednotlivé TCP/IP spojení mi nepřipadá jako dobrý nápad, jak se s tím vypořádat. Takže bych si tipnul, že antiDDoS ochrana bude pracovat spíš na úrovni IP paketů než na úrovni TCP spojení.
Testovat na produkci považujete za skvělý nápad?
To není testování. Je hotová specifikace. Po zkušenostech z provozu se nezmění, nebo trochu změní a následně se standardizuje. Tímto způsobem vznikají standardy. Ostatně i na webu většina technologí nejdříve vznikla, někdo je prosadil a pak se kodifikovaly do standardů. Představa, že se dá standard připravit od "rýsovacího prkna" a z laboratoře, je naivní.
@Miroslav Šilhavý
Ono spíš bude záležet/záleží na tom, jak se to nasadí do produkce. Obecně, pokud je to napůl dodělané a jediný důvod k nasazení je nějaké datum v manažerském grafu, je to špatně a pak má tady odpůrce pravdu. Pokud je to řádně připraveno, mnohokráte úspěšně otestováno, není důvod plácat o testování v produkci. Ostatně, rozjet novou feature pouze pro určitý segment, doladit a pak uvolnit úplně je běžná praxe a zde je s tím tedy odpůrce naprosto mimo - pravděpodobně proto, protože nezohledňuje reálný stav implementace zatímco pouze žongluje se slovy "testovat" a "produkce".
10. 10. 2020, 21:18 editováno autorem komentáře
@87vdf4vg82
Díváte se na to optikou doktríny plánovaného hospodářství. Samozřejmě, lokálně mají firmy, oddělení a lidé své cíle, které musejí plnit. Nicméně, to je samoregulační proces. Přijdete s něčím moc brzy - a pohoříte. Nu což, nic se nestane, přijde někdo jiný s něčím lepším. A tím "lepším" nemyslím, že se to bude víc líbit technikům-odborníkům. Myslím tím, že lepší je ta technologie, která prokáže svoji životaschopnost. (Stalo se nejednou, že se uchytila technicky méně dokonalá norma, ale životaschopnější).
Nevzrušoval bych se tedy z toho, že začali používat HTTP/3. Prostě se uvidí, jaké to bude mít výsledky. Dokonce si myslím, že to sami stáhnou z provozu, kdyby to způsobovalo víc problémů, než užitku. (A ano, na "chudáky" techniky, kteří se musí mentálně vyrovnat s (ne)řízením toku UDP se hledět nebude - ajťáci jsou dnes něco jako popeláři - všichni je potřebují, ale medaile se za to nedávají).
@87vdf4vg82
Nepochopil jsem, jakého stavu byste rád dosáhl. Buďto se musí vše řídit centrálně - tj. někdo rozhoduje o specifikacích, dbá na jakost, testování, ... - podobně, jako je tomu třeba u léčiv. Nebo se to nechá volně, pak si rozhoduje trh a standardy se kodifikují až zpětně. Tedy ve chvíli, kdy technologie ukáže svoji účelnost a někomu stojí za to se standardizaci věnovat. Já jsem zastáncem toho druhého způsobu.
@Miroslav Šilhavý
Aha. Tak v tom případě nehledejte v mém textu jednu z verzí, kterou si myslíte Vy, ale přečtete si, co si myslím já.
Hint: nemluvím o tom kam co kdo nasazuje a jestli o tom rohod někdo centrálně. Po třetí a naposledy Vám píši, že se zamýšlím nad testem v produkci a odzkoušením i v produkci - ne, to opravdu nema nic společného s centrálním plánováním. Jedná se spíš, po třetí píši, o stav implementace.
Pokud nehodláte můj text aspoň jednou přečíst, bude lepší neodpovídat vůbec. Není to Vaše povinnost, já to unesu a ušetři to čas ...