Cloud – ako na SSL certifikaty?

i-PRESS: no pokud máš u SANu sto domén, zmanená to skoro 1kb dat navíc (podle velikosti domén) a to už je samozřejmě znát. Souki nejspíš myslel direktivu ssl_buffer_size u nginx, která udává velikost cache před odesláním dat, běžně se totiž dává na co nejnižší hodnotu (4kb), aby se co nejdříve odeslaly data ze serveru a klient dostal rychle odpověď, cert se musí vejít celý do bufferu a pokud je moc velký, musíme navýšit buffer a tím zpozdit první paket = klient se déle počká u každého požadavku.Load balancování http/2 je oříšek sám pro sebe. Staré http má mnoho krátkých spojení, které je jednoduché rozprostřít mezi více serverů, naproti tomu http/2 je jedno dlouho spojení, které se musí balancovat trochu jinak (nevíme dopředu jak bude dlohé a jak bude vytěžovat servery), není problém, že by to load balancery neuměly, ale je nutné spolupráce i backendu a to je už horší, krom toho si nemůže na proxy jen tak odchytit dotazy na statické soubory a naservírovat je, musí se výrazně předělat architektura a proto to kromě CDN zatím nikdo moc nepoužívá. Krom toho http/2 nemá upgrade hlavičku a nepodporuje websockety, což je další drobná překážka.Při návrhu http/2 se tyhle situace už myslel a existují tam řídící frame pro přesun spojení na jinej server. Experimentujeme s několika variantami:- http/2 pouze na bráně a dále už http/1.x - snížíme tím počet spojení na bránu, snížím prodlevu při načítání na pomalejších (či vzdálenějších) sítích, ale zhoršíme dostupnost stránek na nestabilním spojení (3g, lte), platí celkově u http/2. Můžeme mít certy pouze na bráně. Nemáme ale možnost push souborů a dalších nových výhod nového http- Http/2 až na backend - musíme mít statické soubory dostupné z aplikáčů (nebo přepsat frontend), failover nebo restart backendu se špatné řeší, musíme spojení nejprve převést na jiný backend a to je prozatím pro nás oříšek. V nodu relativně snadno řešitelné, v javě nebo php už mnohem hůře.- http/2 na proxy, nové http/2 na backend - certy můžeme mít na bráně, funguje push a další optimalizace, opět je při restartu nebo failover nutné převést spojení jinám, to už ale není takový problém. Podpora v balancerech minimální a zatím nestabilníK http/2 je dále nutné upravit i monitoring a autobalancing, to ale většina projektů stejně neřeší. Rád bych se o tom rozpovídal více a ne jen zkratovitě, není tady ale dostatek prostoru, téma to je zajímavé a řada lidí se s ním bude setkávat a zápasit...

@TomášX: Díky za doplnění. Nemám to bohužel jak otestovat, protože tak velký SAN k dispozici nemám, ale docela by mě zajímal ten reálný dopad na výkon. ssl_buffer_size je u NGINXu by default na 16k, osobně jej mám také snížený na 4k. Nemyslím si ale, že tak velký SAN bude mít na TTFB nějak zásadní vliv, drtivá většina webserverů je v defaultní konfiguraci, aplikace neoptimalizované a myslím si, že zabývat se téměř neměřitelným dopadem díky více alternative names je zbytečené. Ale kdo ví, nepátral jsem po tom.Pokud jde o CDN případně statický obsah, tak zde nevidím problém. Pokud mám CDN, pak je adresa obrázků na servery té CDNky, případně je servíruji sám, ale pro omezení přenášení třeba cookies je mám stejně na zvláštní doméně static.mujweb.cz, nebo podobně. V reálu je pak již tento request směřován na server k tomu určený DNSkem, na ten balancovaný se ani dostat nemusí, ale i kdyby, díky jiné doméně stejně bude navázáno nové spojení jako na nový server. Pokud tedy nepošlu statický obsah jako push (obejdu výhody HTTP/2), tak se normálně z browseru provede nový request na CDN/static server, klidně dalším HTTP/2 spojením, ne? Stejně jako iframe, embed.... Zde je pak právě na zvážení, jestli je pro mě výhodnější využít HTTP2 a v rámci jednoho spojení zasílat se samotným dokumentem i static files, nebo to raději deleguji na CDN/static server, ať si browser vytvoří novej request.Totéž platí o WS. WS si stejně používá jiný port a navazuje se až klientem, nebude tedy součástí HTTP2 streamu. WS běží stejně na jiném portu a pokud už má mít proxy typu NGINX, pak pravděpodobně půjde o jinou instanci, než tu, co mi odbavuje HTTP. U WS lze balancovat pouze sestavení spojení, jelikož je perzistentní. Zde tedy pokud už bych potřeboval i tak nenáročný provoz balancovat použiji jiné metody než u bezstavového HTTP, kde mám obrovské množství relativně krátkých requestů.

Napsal TomášX;1280222

Load balancování http/2 je oříšek sám pro sebe. Staré http má mnoho krátkých spojení, které je jednoduché rozprostřít mezi více serverů, naproti tomu http/2 je jedno dlouho spojení, které se musí balancovat trochu jinak (nevíme dopředu jak bude dlohé a jak bude vytěžovat servery).

Tohle přece nemůže být problém. U HTTP 1.1 přece taky požadavek na vygenerování stránky způsobí 1000x větší zátěž než ikonka. V případě HTTP/2 je to alespoň rozloženo rovnoměrně.

Souki: ano, proto ikonku si odchytnu, dobře zacachuji na proxy a požadavek na vygenerování stránky pošlu na zrovna volný aplikáč (podle počtu spojení z proxy). U http/2 ale pošlu ideálně na aplikáč celé spojení, ve kterém se přenáší mnoho souborů a klidně mnoho načtení stránek (či api requestů z frontendu) a já dopředu a ani v průběhu nevím, jakou zátěž dané spojení generuje a jak je aplikáč vytížený, může se pak stát, že se náročné požadavky sejdou na jednom serveru a ten přetíží zatímco ostatní se budou flákat. Tohle jsem myslel. U http/1.x stačí často jen balancovat podle počtu konkurenčních požadavků, ikonka bude vyřízena rychle, noapak načtení stránky blokuje slot dlouho, u http/2 ale nevím, co se v pozadí děje, jestli je spojení idle nebo mi generuje nějaký export. Rozumíme si?i-PRESS: udělej si svůj selfsign a ten otestuj. Pokud se bavíme o 100+ doménách, určitě návštěvnost bude tak velká, že se vyplatí i tyhle drobnosti měřit. Neprovozujeme SANy tak ve velkém, takže nevím také přesně.U http/2 může klidně více domén využívat jedno http spojení :), takže pořád můžeš používat domain shardering kvůli cookies, ale negenerovat další ssl handshaky, obrazně řečeno. Defacto stačí, když subdoména bude viset na stejné ip adrese a prohlížeč se už s webserverem dohodne. Jediná režie je jedna dns query navíc.Pozor na to, obecně se na různých sítích považuje za stabilně průchodný pouze port 80 a 443 (viz naši oblíbení operátoři a jejich FUPy mimo http). Je tedy nutné i WS routovat spolu s http. To je i náš případ. Ano, může se to dát na subdoménu a jiný server či jinak řešit, pořád to ale znamená určitý zásah do infrastruktury, alespoň pro nás. WS se v tomhle chová podobně jako http/2, ale má jiné požadavky na výkon, klient nečeká na odpověď a tu můžeš poslat kdy chceš. V našem případě balancujeme WS podle počtu volných slotů na backend a backend nedělá nic jiného než posílá dál příchozí požadavky a odebírá frontu z Kafky, tj. kromě datového toku a režije pro spojení nám to negeneruje jinou zátěž (netuším ale jak používají WS jiné firmy, naprosto netuším, my s tím zásobujeme mobilní a webové aplikace o live data pro grafy). Http/2 je naopak klasický req>res a je nutné ten požadavek vyřídit ideálně okamžitě a ne frontovat dle libosti.

@TomášX: Ohledně toho WS jsem to tak myslel.. Tedy buďto si spustím WS na vlastním portu (což může být blokováno jak píšeš), nebo jej přesunu na server, kde mám dostupný port 443/80 a není obsazen.Ale i v případě, kdy mám se serverem otevřeno HTTP/2 spojení mohu přeci navázat další. HTTP/2 dovoluje, aby server ukončil neaktivní stream který již není potřeba a stejně tak může být push zablokován nějakou proxy atd. Viz třeba IETF draft. Pokud browser chce zahájit komunikaci protokolem WS v rámci HTTP/2 streamu, posílá po něm frame SETTINGS_WEBSOCKET_CAPABLE. Jestliže server chce neaktivní spojení terminovat, nebo prostě WS po HTTP2 nechce, není nic jednoduššího, než odeslat 501 - Not implemented a browser si dle specifikace pro WS vytvoří vlastní nové spojení.Co vím, tak dříve byl defaultně v Chrome WS over HTTP2 defaultně vypnutý, browser se tedy frame "SETTINGS_WEBSOCKET_CAPABLE" ani odeslat nepokoušel. Pro testování se to zapínalo parametrem --enable-websocket-over-spdy . Jaké je defaultní chování nyní nevím, nicméně pokud vím, stále se může rozhodnout webserver, jestli mu vyhovuje držet spíše HTTP2 spojení, nebo je ukončovat a držet si zvláš WS connections, což preferuji.Jde totiž o to, že WS se naváže v drtivé většině až v okamžiku zpracování domu browserem, v tu chvíli ale server již "nemá co říci, protože už vše poslal". Když se podívám na aktivní spojení browseru, vidím že drtivá většina jede na :443, ale na zvláštní doméně a není to obsahem HTTP/2.Zajímavý je ještě přístup FB, který po načtení aktivuje WSS spojení, po chvíli jej terminuje a pak pomocí JS zase spouští. Asi se snaží vyhnout držení miliónů WS spojení současně a nějak kombinují HTTP/2 a WS tím, že je aktivní vždy pouze jedno z toho a jedním otevírají druhé?

Ten draft, který odkazuješ expiroval před rokem a nevidím žádného následovníka, bral bych to jako mrtvé (viz jeho hlavička). SETTINGS_WEBSOCKET_CAPABLE si nemyslím, že má velkou podporu, chvilku to tlačil google, ale jak je to teď, nemám ponětí, beru to za slepou cestu.Jediná zatím funkční věc s WS s http/2 na stejném portu je ručně si procházet tcp frames a detekovat co to je za obsah, což zabije lehce výkon. Teoreticky je možné si to naskriptovat na nginx přes lua, ale neviděl jsem žádné řešení.My směrujeme k samostatné doméně pro WS a do budoucna nejspíš WS úplně zrušíme a necháme to na pravidelné dotazování u klienta přes http/2. Udržet WS bezpečné je obrovský problém, protokol je příliš vysokoúrovňový, pouze textový, se špatným zabezpečením, http/2 jako přenosová zabezpečená vrstva v tomhle vyhrává na plné čáře.

jo, pardon, nevšiml jsem si expirace, no každopádně je to škoda, protože bylo plánováno držet i více WS spojení v rámci 1 HTTP/2 stramu a to i napříč kartami browseru :pNicméně si nemyslím že je vhodné nahradit WS dvojkou http. Z principu si jde každý vlastním směrem a proč něco ohýbat, když existuje i přímá cesta. "Problémů HTTP/2 je ten, že nejde o skutečně obousměrnou komunikaci. Request musí pocházet z browseru a server může pomocí push maximálně přibalit to, co chce. nemůže ale takovou komunikaci zahájit. Tíms se dostáváme k tomu, že se vrátíme o řadu let zpět do doby opakovaných AJAX dotazů, kdy se server bombardoval každou vteřinu dotazem na stav a on 499x vrátil nějaký null a 1x užitečný payload.V HTTP/2 sice odpadne na takový dotaz balast okolo (http header), ale stále to bude závislé na tom, jak často se bude klient ptát, aby server v případě že má co říci, mohl zprávu předat. To mi přijde překonané. Narozdíl od tohoto je WS opravdu plně bi-directional komunikace a když má server něco na srdci, prostě to pošle a režie je malá.Kde je problém s bezpečností? Při použití wss:// je komunikace zabezpečena stejně jako https://, pokud jde o nějaké auth, lze použít token zaslaný přes HTTP/2. Pro socket.io existuje třeba socketio-auth.HTTP/2 je určitě dobrá cesta zejména kvůli push, ale že bych se tím snažil řešit live komunikaci to spíše ne. WS/WSS má celkem dobrou podporu v mnoha jazycích, tak je jeho implementace celkem triviální, byť je samotný WS server zpravidla robustnější než HTTP server :)

ano, klient by se musel v pravidelných intervalech dotazovat, ale zase by nebyla režije s otevřením nového spojení a pouze by se poslala data, nemyslím si, že by to měl být takový problém, zatím na to na modelových případech vychází dobře, ale ještě řadu měsíců potrvá než to začneme zkoušet produkčně.Websocket je špatně navržený:- nemůžeš modifikovat hlavičky, takže jsi buď závislý cookies/basic z http spojení nebo si to musíš kompletně řešit sám- wss je fajn, ale certifikáty a šifrovanou komunikaci spravuješ přímo v aplikaci, což na větší nasazení je značný problém- nesnáší se s Same-origin policy, což lze částečně hackovat přes CSP a self- primárně je to textový protokol a parsování je dost obtížné aby nedošlo k nějaké nepleše a lze očekávat, že různé implementace budou různě náchylné k chybám- jedná se o aplikační protokol, který si spravuje přímo aplikace a to není ideální stav