Server Push - álom vagy valóság?
IT café: A HTTP2 egyik elméleti funkciója a server push, ami nagyon érdekesnek tűnik. Nagy vonalakban itt arról van szó, hogy a szerver úgy küld adatot a böngészőnek, hogy arra nem érkezett kérés. Ez sokat javíthat a weboldalak betöltődési sebességén, de a szükségtelen adat elvesztegetett sávszélt jelent. Ez a terület különösen sok lehetőséget rejt a bűnözőknek is, nem?
(forrás: Andy Davies, Revolution Conf) a[+]
Daniel Stenberg: A server push mind a mai napig egy fehér folt a térképen, vagy más szavakkal egy nem kipróbált terület, rengeteg ötlet, koncepció és gondolat van mögötte, hogyan is lehetne használni, de valójában nagyon nehéz jól használni. Nem lehet megijeszteni vele a felhasználókat, pontosan kell tudni mire lesz szükség a jövőben, hogy ne vesztegessünk erőforrásokat feleslegesen. Nem egyszerű. Elképzelhetőnek tartom, hogy a server push egyike lesz azoknak a funkcióknak, amik elméletben nagyon jól hangzanak, de ha belegondolunk, hogyan is kellene ezt elvégezni a gyakorlatban, már komoly kihívást és sok fejtörést jelent. Jelenleg is dolgozunk azon, hogy meghatározzuk mit érdemes, és mit nem ezzel a módszerrel küldeni. Egyáltalán nem tudom azt mondani, hogy készen volnánk. Sőt, lehet hogy soha nem is leszünk. Meglehet, hogy ez is egy lesz azok közül a funkciók közül, melyek elvi síkon jól hangzanak, de a gyakorlatban nem terjednek el.
IT café: Vannak törekvések arra, hogy esetleg egy továbbfejlesztett változat akár a QUIC révén használatba kerüljön?
Daniel Stenberg: Nem találkoztam ezzel a témával a QUIC esetében. Ez a protokoll még gyerekcipőben jár, rengeteg minden változik, formálódik. Nincs kizárva, de a server push nincs fókuszban. Mivel jelentős forgalom kerülne át TCP-ről UDP-re, van az emberekben egyfajta félelem. Viszonylag kevés esetben használtuk eddig, sok támadás történik erre, ezért sok rendszergazda egyszerűen letiltotta az UDP portokat. Ezt a mentalitást le kell győzni, nem csak blokkolással lehet védekezni. Tény és való, hogy ez egy nagyon egyszerű megoldás. Az egyik leggyakoribb támadási forma a DNS amplification, de erre is vannak megoldások. Végeredményben a TCP portokon is tudunk védekezni, de nem protokollszinten.
Hirdetés
IT café: A HTTP2 viszont mostanra egy kétéves protokoll, a W3Tech adatai szerint a leglátogatottabb tízmillió weboldal közül mindössze 13,4 százalék használja. Miért?
Daniel Stenberg: Miért nem többen? Nem tudom. Én is szeretném, ha többen alkalmaznák, de úgy tűnik, sokaknak elég az, amit a HTTP tud.
IT café: A gyorsabb oldalletöltés, az új lehetőségek, de még a keresőalgoritmusok is mellette szólnának. Nem titok, hogy előrébb sorolják azokat az oldalakat, amelyek a HTTP2 használata mellett döntöttek. Nekem úgy tűnik, mindenkinek érdemes volna váltani.
Daniel Stenberg: Ez így van. Nincs hátulütője. Gyakorlatilag szinte csak abban az esetben beszélhetünk hátrányról, ha csomagvesztések vannak. Ilyenkor jobban teljesít a HTTP1, de ezen kívül az új protokoll kenterbe veri. Mindenki nyerne a váltással, szinte minden oldal betöltési sebességén látszana. A felhasználók gyors oldalakat akarnak, tehát tényleg nem értem. Főleg, hogy könnyű is váltani!
A vesztett csomagok ölik meg (forrás: CRAFT) [+]
IT café: Akkor tényleg nem értem. Mit mondanak az érintettek? Végzett a Mozilla ezzel kapcsolatos kutatást?
Daniel Stenberg: Én sem értem. Sok népszerű oldal tulajdonosa sem váltott, a legnagyobb forgalmú ezer domain mögött mindössze 29 százalék azoknak a száma, akik használják az új protokollt. Magyarázatot még eddig senkitől sem kaptam. Jó lenne megkérdezni, érdekelne mit mond például a top50. Eddig csak olyasmit hallottam, hogy "valaki más tehet róla, például a CDN-ek", vagy csak egyszerűen "nem a mi hibánk". Persze a Mozillának fontosak ezek a kérdések, azonban nem elsődleges feladat a HTTP2-ről meggyőzni az embereket. Rengeteg más feladatunk van.
IT café: A HTTP2 ötlete a SPDY alapjaira épül, de más megoldásokkal. Mik a főbb különbségek?
Daniel Stenberg: Valóban, nagyon sokban hasonlítanak, de ha megnézzük a részleteket, rájövünk, hogy teljesen más úton járunk. Még a server push is szerepel a SPDY-ben, viszont a megoldások mások. Funkciókban hasonló, implementációban különbözőek. Fontos különbség van például a frame méretek között. A multiplexing előnyeit nem lehet kihasználni, ha hatalmas kereteket biztosítunk. Akkor mi értelme? A HTTP2 esetében például jóval kisebbek ezek a határok, ezzel tényleg el tudjuk érni, hogy legyen értelme az aszinkron multiplexálásnak.
(forrás: CRAFT) [+]
IT café: Azért is kritizálták a HTTP2 protkollt, mert nem támogatja a passzív megfigyelési technikák ellen bevethető opportunista titkosítást. A kritikusok szerint ez szembemegy az IETF RFC7258 számú állásfoglalásával, miszerint a pervazív megfigyelés is támadás, és mint ilyen, az IETF protokollok tervezésekor meg kell próbálni tenni ellene.
Daniel Stenberg: Valójában ez nem nagy ügy, két ok miatt: egyrészt a HTTP2 nem kötelező, másrészt manapság senki sem implementálja TLS nélkül, tehát egy másik rétegben ott van a védelem. A QUIC ebből a szempontból is előrelépés lesz, de a konkrét ügy inkább arra volt jó, hogy a gondolkodásmódon változtasson. A protokollalkotók közösségében eddig is az volt a fontos, hogy biztonságos megoldásokat készítsünk. az IETF ajánlásai segítik ezt, a kritika és a visszajelzések pedig kívülről világítanak rá, jó úton járunk-e.
