Http na backendech a čím jej nahradit (a zda vůbec)

[Ondřej Novák]

S nástupem Http/2.0 a snahou vytlačit HTTP z prohlížečů opět řeším problém, jaký protokol používat na komunikaci mezi webserverem a nějakým pokročilým backendem. Doposud jsem si vystačil s proxypassem přes protokol http. Nevidím důvod, proč bych na backendu měl používat http/2.0, už kvůli tomu, že nevyužiju ani multiplexing ani šifrování, ale spíš honím maximální rychlost při přenosu dat z backendu na webserver.

Uvažoval jsem také o fastcgi, ale po prostudování dokumentace jsem ty úvahy znechuceně opustil. Je to protokol ze staré školy, podle mě moc komplikovaný a necítím to jako inovaci (spíš jako krok do historie). Zatím mi zpravidla http protokol přes proxypass postačoval, byť na můj vkus ukecaný. Obávám se ale, že zejména z pohledu managerů tlačených mainstreamem bude snaha věci zbytečně komplikovat.

Co se používá v jiných firmách a projektech?

[Reklama]

[Filip Jirsák]

S nástupem Http/2.0 a snahou vytlačit HTTP z prohlížečů

Asi jste mylně informován. Nikdo se z prohlížečů nesnaží vytlačit HTTP, dokonce ani prohlížeče neimplementují žádnou náhradu, která by mohla HTTP vytlačit. HTTP je pro prohlížeče stále ten nejdůležitější protokol, některé prohlížeče vedle něj jako doplněk nabízejí třeba FTP.

jaký protokol používat na komunikaci mezi webserverem a nějakým pokročilým backendem

Nechápu, jak to souvisí s předchozí částí – i kdyby prohlížeče používaly jiný protokol, nic vás nenutí opouštět HTTP.

Nevidím důvod, proč bych na backendu měl používat http/2.0, už kvůli tomu, že nevyužiju ani multiplexing ani šifrování, ale spíš honím maximální rychlost při přenosu dat z backendu na webserver.

Zrovna multiplexing využijete ještě víc, než prohlížeče, protože jedním spojením přenesete mnohem víc požadavků, než jeden prohlížeč. Díky komprimaci hlaviček také můžete ušetřit objem přenášených dat. Nevidím žádný důvod, proč by přenos přes HTTP/2 byl pomalejší, než HTTP/1.1 – naopak má potenciál být rychlejší.

Co se používá v jiných firmách a projektech?

Například HTTP.

[Ondřej Novák]

S nástupem Http/2.0 a snahou vytlačit HTTP z prohlížečů

Asi jste mylně informován. Nikdo se z prohlížečů nesnaží vytlačit HTTP, dokonce ani prohlížeče neimplementují žádnou náhradu, která by mohla HTTP vytlačit. HTTP je pro prohlížeče stále ten nejdůležitější protokol, některé prohlížeče vedle něj jako doplněk nabízejí třeba FTP.

Poslední vývoj chrome i firefoxu hodně šlapou na http a snaží se vnutit aspoň https. Protokol http má výhodu také v tom, že během vývoje mohu použít i prohlížeč na prezentaci výsledků backendu. Stačí mi třeba mít webovou administraci na intranetu jen v http a už na mě bliká, že to je nezabezpečný a nedejbože abych tam měl okénko s heslem.

Nevidím důvod, proč bych na backendu měl používat http/2.0, už kvůli tomu, že nevyužiju ani multiplexing ani šifrování, ale spíš honím maximální rychlost při přenosu dat z backendu na webserver.

Zrovna multiplexing využijete ještě víc, než prohlížeče, protože jedním spojením přenesete mnohem víc požadavků, než jeden prohlížeč. Díky komprimaci hlaviček také můžete ušetřit objem přenášených dat. Nevidím žádný důvod, proč by přenos přes HTTP/2 byl pomalejší, než HTTP/1.1 – naopak má potenciál být rychlejší.

Multiplexing je vždy pomalejší než několik otevřených konekcí. Na backend nemá smysl už proto, že často padá jedna konekce na klienta, jelikož statické stránky obslouží sám webserver, na backend pak už padá tak jeden až dva requesty na stránku. Na rychlých sítích je přenos dat menší problém, než jejich zpracování. Například šifrování a náklady na správu multiplexu mohou být mnohem dražší a co se týče hlaviček tak opět, jejich množství lezoucí mezi webserverem a backendem může být významě redukováno.

Co se používá v jiných firmách a projektech?

Například HTTP.

Dík

[Filip Jirsák]

Poslední vývoj chrome i firefoxu hodně šlapou na http a snaží se vnutit aspoň https.

Aha. To je pak těžké uhodnout, o čem vlastně píšete, protože HTTPS není v pravém smyslu protokol – je to HTTP přenášené TLS kanálem. Výběr, zda použijete šifrovanou nebo nešifrovanou variantu, pak závisí jenom na tom, zda potřebujete přenášená data šifrovat. Pokud máte zabezpečenou infrastrukturu, můžete použít pro komunikaci s backendem nešifrovaný kanál – ale zase pak nerozumím, na co se vlastně ptáte, protože jestli použijete pro komunikaci s backendem HTTP nebo HTTPS je vlastně jedno a je to akorát věc jednoduché změny konfigurace.

Protokol http má výhodu také v tom, že během vývoje mohu použít i prohlížeč na prezentaci výsledků backendu.

Jak kdy, musíte tím protokolem přenášet data, která je prohlížeč schopen zobrazit. A tady správně píšete o protokolu HTTP, nezáleží tedy na tom, zda použijete šifrovanou nebo nešifrovanou alternativu.

Stačí mi třeba mít webovou administraci na intranetu jen v http a už na mě bliká, že to je nezabezpečný a nedejbože abych tam měl okénko s heslem.

To ale nepíšete o komunikaci webserveru s backendem, ale o komunikace prohlížeče s webserverem. A tam jsou upozornění prohlížeče správná, protože prohlížeč nemůže vědět, že je to na intranetu, navíc to, že je něco na intranetu, vůbec neznamená, že je síťová komunikace bezpečná.

Multiplexing je vždy pomalejší než několik otevřených konekcí.

Proč? Navíc HTTP/2 vám nijak nebrání mít otevřených víc spojení.

Na backend nemá smysl už proto, že často padá jedna konekce na klienta, jelikož statické stránky obslouží sám webserver, na backend pak už padá tak jeden až dva requesty na stránku.

To s tím přece vůbec nesouvisí. Webserver může mít otevřené jedno nebo několik spojení s backendem, a přes tahle spojení posílat různé požadavky od různých klientů.

Na rychlých sítích je přenos dat menší problém, než jejich zpracování.

HTTP/2 je binární protokol, takže oproti HTTP/1.x je rychlejší i to zpracování.

Například šifrování

Šifrování vůbec nesouvisí s protokolem. I kdybyste měl protokol jenom s nešifrovanou variantou, vždycky ho můžete poslat šifrovaným kanálem, třeba VPN nebo SSH.

náklady na správu multiplexu mohou být mnohem dražší

Než náklady na správu více spojení? Mohou, a nebo také mohou být mnohem levnější...

co se týče hlaviček tak opět, jejich množství lezoucí mezi webserverem a backendem může být významě redukováno.

Což pořád nevylučuje možnost ten zbytek hlaviček komprimovat.

[Ondřej Novák]

Na http se mi líbí hlavně to, že nemusím psát speciálního klienta na přístup ke službám backendu.

Benefit binárního http/2 nechápu jako výhodu. Klasické http má jen pár řádek hlaviček a pak payload. Otázkou je, zda náklady na provoz multiplexu, tedy kouskování dat, přidávání binárních rámců, rozdělování dat jednotlivým listenerům na straně backendu není ve výsledku mnohem náročnější a nepřinese větší datové náklady, než pár textových nezkomprimovaných hlaviček.

Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.

Ale jinak dík, zůstanu u http.

[Reklama]

[.]

Na http se mi líbí hlavně to, že nemusím psát speciálního klienta na přístup ke službám backendu.

Benefit binárního http/2 nechápu jako výhodu. Klasické http má jen pár řádek hlaviček a pak payload. Otázkou je, zda náklady na provoz multiplexu, tedy kouskování dat, přidávání binárních rámců, rozdělování dat jednotlivým listenerům na straně backendu není ve výsledku mnohem náročnější a nepřinese větší datové náklady, než pár textových nezkomprimovaných hlaviček.

Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.

Ale jinak dík, zůstanu u http.

Když jste si sám odpověděl, tak nechápu, proč jste se vůbec ptal?

HTTP/2 klient nebo i server je zpravidla stejně dlouhý jako HTTP klient nebo server, protože použijete knihovnu. Pokud si to píšete celé sám, pak je jasné, kde se berou ty špatné implementace.

A pokud ještě stále hledáte pokročilý protokol, tak gRPC. Knihovny a generátory jsou pro všechny relevantní jazyky.

[Sten]

Benefit binárního http/2 nechápu jako výhodu. Klasické http má jen pár řádek hlaviček a pak payload. Otázkou je, zda náklady na provoz multiplexu, tedy kouskování dat, přidávání binárních rámců, rozdělování dat jednotlivým listenerům na straně backendu není ve výsledku mnohem náročnější a nepřinese větší datové náklady, než pár textových nezkomprimovaných hlaviček.

Mnohem náročnější než kouskování dat, přidávání binárních rámců a rozdělování dat jednotlivých socketům, jako to dělá OS pro těch víc TCP spojení? No to záleží, jak to napíšeš

Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.

Proč? Pokud budeš využívat jen multiplexing, tak ten protokol není o moc složitější. A třeba parsování hlaviček je naopak o dost jednodušší, nemusíš řešit šílenosti jako několik možností, jak hlavičky kódovat, nebo víceřádkové hlavičky. Což je mimochodem důvod, proč třeba SCGI používá binární hlavičky. Ono správně zpracovat hlavičky HTTP není žádná sranda, a docela pochybuju, že klient na 160 řádků bude splňovat RFC.

Nebo jestli chceš primitivní HTTP-like protokol, použij jmenované SCGI. Je tak primitivní, jak to jen jde, a bez záludností textového formátu HTTP.

[Karel]

Vlastni http client ok jako cviceni ve skole jinak zbytecnost na n-tou.
Mluvis o backendu a prokladas to prikladem psani clienta?

K backendu je to sumak klidne to mej jako http pred to postav ptoxy a ta at klidne zajisti vsechny zname protokoly a sifrovani.

[Kamil Podlešák]

Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.

To asi bylo bez keepalive, co?

Pokud takové http stačí, tak je skutečně nesmysl byť jen uvažovat o http2.

[Filip Jirsák]

Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.

To asi bylo bez keepalive, co?

Pokud takové http stačí, tak je skutečně nesmysl byť jen uvažovat o http2.

No a taky asi bez komprese, bez chunked přenosu, bez podpory stovkových stavových kódů... Asi by bylo přesnější nazvat to ,,telnet klientem, který používá protokol připomínající HTTP/0.9".

[Jan Forman]

Na druhé straně člověk s úžasem sleduje například implementace v JAVĚ, kde to fakt naprosto nic nedělá.
X Core CPU je vytížený na doraz a vy stále přemýšlíte jaký to vlastně má smysl. Takže on i ten argument "jen připojíš jinou knihovnu" je celkem na zamyšlení.

Prostě na přesazení kytky na záhoně není nutné ihned vyjíždět s bagrem :-)
Stejně tak na pár řádkový program kvůli ušetření třeba deseti řádek není nutné připojit knihovnu a desetitisíci jiných řádek.
Btw. mnoho těch "zrychlujících" funkcí může při vysokém zatížení mít přesně opačný efekt.

Dle mého tedy starý triviální http smysl má, u TLS spojení už by klidně http/2 mohlo zůstat.
Problém bude v tom, že cokoliv nezabezpečeného se postupem času asi stane opravdu nebezpečným.
Na spojení backendu nešifrovaně mezi sebou a s edge TLS výstupem asi ideální stav.

Ničím jiným bych to nenahrazoval, protože tohle je poměrně jednoduché a interoperabilní.

Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.

To asi bylo bez keepalive, co?

Pokud takové http stačí, tak je skutečně nesmysl byť jen uvažovat o http2.

No a taky asi bez komprese, bez chunked přenosu, bez podpory stovkových stavových kódů... Asi by bylo přesnější nazvat to ,,telnet klientem, který používá protokol připomínající HTTP/0.9".

[Filip Jirsák]

Dle mého tedy starý triviální http smysl má, u TLS spojení už by klidně http/2 mohlo zůstat.

Ničím jiným bych to nenahrazoval, protože tohle je poměrně jednoduché a interoperabilní.

Jak už jsem upozorňoval ve svém předchozím komentáři, ono  ani to ,,staré HTTP" (1.1) není zas tak triviální. Jistě, pokud si řeknu, že budu používat jednoduchou podmnožinu HTTP, protože mám na obou stranách komunikace svůj software a můžu tak zaručit, že se používá jenom ta podmnožina, může to být velmi výhodné řešení. A může pak být dokonce výhodné napsat si pro to vlastního klienta a server, protože tím, že nebudu muset řešit některé záludnosti HTTP, můžu mít efektivnější kód. Ovšem je zase potřeba počítat s tím, že ta moje implementace bude mít mnohem méně testerů, takže je mnohem pravděpodobnější že tam budou nějaké chyby. A také musím důsledně zajistit to bezpečné prostředí – ne že budu tvrdit, že se tam používá HTTP, a pak se někdo, kdo nezná detaily aplikace, rozhodne, že vlastně kvůli zjednodušení může pár lidí jenom kvůli administraci pustit prohlížečem přímo na backend – vždyť je to přece HTTP.

A vždycky je otázka, zda se opravdu vyplatí psát vlastní řešení se všemi riziky z toho plynoucími, abych tím získal jedno procento výkonu – jestli nakonec není levnější v cloudu prostě nakoupit navíc to jedno procento výpočetního výkonu.

Problém bude v tom, že cokoliv nezabezpečeného se postupem času asi stane opravdu nebezpečným.
Na spojení backendu nešifrovaně mezi sebou a s edge TLS výstupem asi ideální stav.

Dneska je ještě běžné používat ,,uvnitř" nešifrované spojení, ale myslím, že i tam se postupně bude přecházet na šifrování. Je to další stupeň zabezpečení, a není pak nutné složitě analyzovat, zda všechno, co je ,,uvnitř", je opravdu dostatečně bezpečné. Ono je fajn, když můžete třeba při řešení výpadku komunikaci s backendem, která jde normálně přes bezpečnou síť, pustit přes internet, a nemusíte před tím řešit, že je vlastně nezabezpečená a je potřeba ji nejprve nějak zabezpečit.