A HTTP protokoll fejlesztését végző Internet Engineering Task Force HTTP munkacsoportja a napokban bejelentette, végre elkészült a Hypertext Transfer Protocol 2-es változata, amely idővel a kliensek és a szerverek kommunikációjában használatos HTTP/1.0 és HTTP/1.1 protokollok helyére lép.
A munkacsoport egyébként nem csak egy, hanem két, egymáshoz szorosan kapcsolódó szabványt is véglegesített. Az első maga a HTTP/2 protokollé, a másik pedig a HPACK, amely a HTTP/2 fejlécek (header) tömörítését végző eljárás.
A HTTP/2 protokoll fejlesztésével kapcsolatos munkálatok még 2012-ben indultak el, válaszul a Google SPDY protokolljának fejlesztésére. A Google SPDY protokollja a HTTP protokollt sújtó teljesítményhátrányok leküzdésére készült – gyakorlatilag ez a protokoll lett a HTTP/2 alapja.
Hogy milyen problémák övezik a ma is használatos HTTP/1.x protokollt? A legnagyobb közülük talán az, hogy a különböző tartalmak párhuzamos elérésére több kapcsolatot kell kiépítenie a webböngészőnek a szerverrel. Ugyan a szerver és a kliens között húzódó egyetlen HTTP/1.x kapcsolaton keresztül több különböző objektum lekérése is megoldható (például képeké, CSS tartalmaké és JavaScript tartalmaké), azonban fontos kitétel, hogy a kéréseket sorba állítva szolgálja ki a szerver: egyiket a másik után. Amennyiben egy adott objektum letöltése hosszú ideig tart, mert túl nagy vagy éppen sok szerveroldali feladatba kerül a kiszolgálás, úgy a többi kérés teljesítésére addig várni kell.
Ennek eredményeként a HTTP/1.x kapcsolatok többségét általában csak egy kérés teljesítésére szokás igénybe venni. A webböngészők persze képesek párhuzamos tartalombetöltésre, méghozzá úgy, hogy ennek érdekében egy-egy szerverrel több kapcsolatot is kiépítenek, ám ennek ára van: a folyamat extra hálózati sávszélességet, extra időt és extra erőforrást igényel, mivel minden egyes kapcsolaton keresztül adatátvitel folyik a klienstől a szerver felé, majd vissza.
A HTTP/2 érkezésével ez a probléma már a múlté, ugyanis a HTTP/2 protokoll több kétirányú streamet is tud multiplexelni egyetlen TCP kapcsolaton keresztül. Minden egyes stream hordozhat egy kérés és válasz párt, a szerver felé irányuló több kérést pedig több stream segítségével lehet továbbítani. Jó hír, hogy ezek a streamek függetlenek egymástól: amennyiben az egyik stream lassú, attól a HTTP/2 kapcsolat ugyanúgy használható egyéb streamekhez tartozó adatok továbbítására. Ehhez hasonlóan egy kliens kérést adhat le egy nagy, majd egy kis objektum egyidejű letöltésére, a kis objektum letöltése pedig még a nagy objektumé előtt megtörténhet – vagy akár a nagy objektuméval párhuzamosan is. A HTTP/1.x esetében megszokott várakozásra és szekvenciális kérésfeldolgozásra a HTTP/2 esetében tehát nincs szükség – a specifikáció ajánlása szerint a klienseknek és a szervereknek egyetlen kapcsolaton keresztül legkevesebb 100 különböző streamet is ki kell tudniuk szolgálni.
A HTTP/2 ezzel együtt teljesítmény és szolgáltatások terén is fejlődést képvisel. Míg a HTTP/1.x protokoll sima szövegalapú megoldás volt, amelynél a kérések és a válaszok ember által olvasható szöveg formájában mozogtak a szerver és a kliens között, addig a HTTP/2 esetében már hatékonyabb, könnyebben használható, kompaktabb megoldást használnak: a HTTP/2 már bináris alapon nyugszik. Ugyan bináris protokollról van szó, a HTTP kapcsolat szemantikája mégsem változott. A kérések és a válaszok még mindig Headerre és (optimális esetben) Body-ra osztódnak, amelyeknél a Header-ek fontos metaadatokat nyújtanak a Body résszel kapcsolatban. Az alapvető technológia nem változott, viszont a kliens és a szerver közötti "üzenetváltás" sokkal hatékonyabbá vált.
A HTTP/2 nagyrészt a Google által kifejlesztett SPDY protokollra támaszkodik, mégis különbözik tőle néhány fronton. Az SPDY esetében a TLS (Transport Layer Security) használata kötelező annak érdekében, hogy az adatbiztonság garantálható legyen. A HTTP/2 esetében a TLS alkalmazása opcionális: az eljárás mind TCP-n, mind pedig TLS-en keresztül képes működni. Egyes vállalatok persze már most leszögezték, saját megoldásaiknál a HTTP/2 mellé TLS kapcsolatokat alkalmaznak, hogy garantálható legyen az adatbiztonság és az adatvédelem.
Az SPDY esetében további különbség, hogy a fejlécek esetében eleinte gzip tömörítést használtak, ám 2012-ben kiderült, hogy a gzip tömörítés veszélyeket rejthet, ugyanis támadási felületet biztosíthat a felhasználókkal szemben. Emiatt az SPDY esetében a gzip ilyen irányú használatát be is fejezték. A HTTP/2-ben pedig az említettek miatt egy új megoldás, a HPACK segítségével tömörítik a fejléceket.
Tulajdonképpen ez, vagyis a HPACK befejezése a másik fontos bejelentés. A HPACK a gzip-pel ellentétben nem egy általános tömörítési eljárás, hanem egy speciális megoldás, amely kifejezetten a fejlécek tömörítéséhez, illetve a HTTP/2 igényeihez lett kifejlesztve.
Az új szabványokhoz természetesen webböngésző-fronton is érkezik támogatás. A Google részéről már biztos, hogy a Chrome 40-től felfelé garantált a HTTP/2 támogatás, ezzel együtt az SPDY támogatás viszont kivezetésre kerül, méghozzá 2016 elejétől. A Mozilla háza táján a következő héten megjelenő FireFox 36 már képes lesz a HTTP/2 protokollban rejlő lehetőségek kiaknázására, de csak a draft 14-es és draft 15-ös specifikációkkal. A Firefox 37 és 38 esetében már draft 16 támogatás érkezik, a véglegesített draft 17 támogatása pedig majd csak később válik elérhetővé. A Windows 10 Technical Preview esetében úgyszintén rendelkezésre áll a draft 14 specifikációra alapozó HTTP/2 támogatás, az Internet Explorert leváltó Spartan webböngésző pedig természetesen HTTp/2 protokollra támaszkodik majd.
A HTTP/2 érkezésével felhasználói szinten semmilyen extra teendőre nincs szükség a gyorsuláshoz, de szerverek, alkalmazások és API-k frontján is csak minimális változtatásokra lesz szükség.
Aki további információkra is kíváncsi a HTTP/2 protokoll újításaival kapcsolatban, látogasson el ide; aki pedig a HPACK iránt érdeklődik, itt találja meg a részletes dokumentációt. Aki a gyorsulás mértékére kíváncsi, kattintson ide!
