Új protokoll
Az idei CRAFT fejlesztői konferencián lehetőségem nyílt interjút készíteni Daniel Stenberggel, a cURL projekt alapítójával, a Mozilla hálózatmérnökével, a HTTP2 protokoll egyik megalkotójával. A konferencián a protokoll működését mutatta be, beszélt a terjedésről és arról, miért jelent nagyobb problémát a csomagvesztés ebben az esetben, mint a HTTP protokollnál.
IT café: Mi a véleménye a HTTP2-vel kapcsolatos kritikákról? Elsősorban azokra gondolok, melyek a biztonságosságot kérdőjelezték meg, illetve azokra, melyek szerint a nagy sietségben bizonyos lehetőségek nem kerültek kihasználásra. Poul-Henning Kamp a FreeBSD-től egyenesen azt mondta, szürreálisan kevés időt adtak maguknak, emiatt maradtak ki fejlesztési lehetőségek, illetve erre vezette vissza a titkosítási problémákat is.
Daniel Stenberg: Azt gondolom, egy protokoll kidolgozása általánosságban is elég nehéz, és mindig lesznek dolgok, amik kimaradnak - később, visszanézve persze ezek már látszanak, hogy mit lehetett volna másképp, akár jobban csinálni, de más utak más problémákat hozhatnak. Sokkal fontosabbnak tartom viszont az hogy megvolt az a pillanat, amikor sok tehetséges szakértő akart és tudott együtt dolgozni. Gyorsan és hatékonyan akartuk elvégezni a feladatot. Menet közben nagyon nehéz megállapítani, hogy egy döntés jó, vagy rossz. Az eredményeket látva nem vagyok meggyőződve róla, hogy komoly hibákat vétettünk volna, vagy szükségszerűen lennének a döntéseink között rosszak.
Daniel Stenberg (forrás: CRAFT) [+]
Azt látom viszont, hogy talán lettek volna olyan területek, amiket máshogy, vagy mondjuk úgy: ügyesebben is megvalósíthattunk volna. Ilyen a fejléc tömörítés, ami lehetne jobb, de ez egy nagyon messzire vezető vita. Általánosságban azt gondolom, jó munkát végeztünk. Egy jó protokollt hoztunk létre, sokkal gyorsabban mint az megszokott. Olyan nagyon sok negatív kritika nem ért minket emiatt.
A biztonság kérdésköre: a HTTPS és a TLS jó dolgok, jól is működnek. Poul-Henning Kamp véleménye erről az, hogy a HTTPS nem használható minden esetben, erről tanulmányt is írt - a több titkosítás nem megoldás címmel. Szerintem meg igen, de ez nem kapcsolódik szorosan a HTTP2 protokollhoz.
IT café: Azt mondja, vannak olyan területek, amiket más irányból is meg lehetett volna közelíteni. Ha most lehetőséget kapna arra, hogy visszamenjen az időben és tanácsot adjon saját magának, mit mondana?
Daniel Stenberg: A HTTP2-vel kapcsolatban? Nem is tudom... talán fontosabb tanulni a hibákból és a jövőben odafigyelni ezekre, mint azon merengeni, mit lehetett volna másképp csinálni. Azt hiszem, nem bántam meg semmit a protokoll fejlesztése során. Persze ehhez hozzá kell tennem, hogy a szerepem szerint egy csapat részeként dolgoztam, nyilván nem egyedül alkottam meg a HTTP2-t. Egy jó protokollt csináltunk, ami elég jól működik, ez az, ami számít. Konkrétan nagyon büszkék vagyunk rá, hogy egy átlátható, könnyen adoptálható megoldást sikerült összehozni. Általában nem vagyunk jók abban, hogy dolgokat frissítsünk az interneten. Ehhez képest gyakorlatilag észrevétlenül lehet HTTP2-re váltani.
IT café: Előadásában azt mondta, ez a jövőben még egyszerűbb lesz. A HTTP3 helyett a QUIC (Quick UDP Internet Connections) a következő lépés. Mit érdemes erről tudni?
Daniel Stenberg: Izgalmas lesz. a QUIC ugye az UDP portokat használja, ami sok ember szemében visszatetsző. Történelmileg úgy alakult, hogy az UDP-t eddig nem túl sok forgalomhoz használtuk. A nagyvállalati ügyfelek között sokan aggódnak emiatt. Persze, ha azt tudjuk mondani, hogy a QUIC x százalékkal jobb/gyorsabb mint a HTTP2, akkor majd változnak a vélemények, egy ilyen eredmény sokat segíthet az adoptálásban. Ha viszont a különbség elhanyagolható, akkor jóval kisebb lesz a hajlandóság a váltásra. Nem tudom hova fogunk eljutni vele, lehetségesnek tartom, hogy az üzemeltetők egy része megelégszik majd a HTTP2-vel, de ez még a jövő zenéje.
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.
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.
