iPon Hírek

Hatalmasat fejlődik a HTTP protokoll

Dátum | 2015. 02. 20.
Szerző | J.o.k.e.r
Csoport | IT VILÁG

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!
Új hozzászólás írásához előbb jelentkezz be!

Eddigi hozzászólások

6. junkie
2015.02.20. 15:21
az eljárás mind TCP-n, mind pedig TLS-en keresztül képes működni

Alma és narancs. TCP szállítási réteg, TLS alkalmazás réteg.
Egyébként van már webszerver is ami képes http/2-t kiszolgálni? Mert anélkül igen hasztalan a kliens oldali támogatás. Ja, és az is bele fog telni 5-10 évbe, IF EVER, hogy elterjedjenek ezek a szerverfrissítések. See also: IPv6.
A széleskörű adaptációt még az is hátráltatni fogja, hogy mivel alapjaiban új technológia, minden bizonnyal tele van sebezhetőséggel, amiket évek alatt fognak csak betömködni.
 
Válasz írásához előbb jelentkezz be!
5. thedevelop... junki...
2015.02.20. 16:41
Vannak már webszerverek, nyílt forrású is van, ráadásul a Microsoft-tól.
A probléma inkább az, hogy a szabvány még nem végleges, így a webszerverek sem lehetnek véglegesek.
Egyébként képes fall back-elni sima HTTP -re, ha a böngésző nem támogatja a 2-es verziót.
A weblapokat pedig nem kell majd átírni hozzá.
Szóval akár még el is terjedhet.
 
Válasz írásához előbb jelentkezz be!
4. sensorprim...
2015.02.20. 18:19
Arra valaki tud választ adni hogy 2004 óta T-online-os(előtte axeleronak hívták) vagyok és egyre romlik az internet stabilitása.
A kezdetekben amerikai szervereken is kitűnően lehetett játszani.
Most meg az van hogy országon belül jó aztán németekkel is jó, de onnantól kezdve más eu-s országgal már csak fele jó a válasz idő.
USA-val meg egyébb nem EU-s országgal meg katasztrofálisan használhatatlan.
A pingek 170 fölött és csomagvesztés, a sávszél is leesik a béka segge alá.
Sorra dobál ki a játékokból mert megszakad a kapcsolat (eu-n belül is).

Azt se tudom hova tenni bár más téma hogy Q6600 egyik napról a másikra world of tank-ban 60-ról 15 fps-re esett, és már a gagyi facebookos flash játékokat se viszi. 1 éve meg minden ment szuperül. Most vehettem új gépet, de ha ez nem valami összeesküvés akkor semmi.
 
Válasz írásához előbb jelentkezz be!
3. j.panzer senso...
2015.02.21. 11:24
Én tudok rá választ. Ugyan ebben a cipőben járok. Anno, 2005-ben, mikor 0,5 Mbps volt a letöltési sebességem teljesen jól ment minden online játék, aztán megnövelték (ingyen) a sávszélességemet 1 megabitre, akkor nagyot romlott a helyzet, majd mikor 2 megára növelték, már akkora pingek lettek, hogy lehetetlen volt játszani.
Aztán pár évre rá már 15 megabites netem volt, de sosem jött 8-nál többel, és percenként szakadozott.

Kiküldtek egy szerelőt, lecserélték az összes kábelt a lakásban, semmi nem változott. Aztán bemértek egy csomó mindent, és rájöttek, hogy mi a baj. A belváros azon pontján lakom, ami kb. a legmesszebb van az átjátszóállomástól. Több, mint 1 kilométerre.
És az a baj, hogy a telefon kábel, amin az internet jön, egyfelől egyre öregszik el, másfelől közel nem erre az adatforgalomra lett tervezve. A főkábel, ami az utca alatt fut, folyamatosan öregszik, ugyanakkor minél több embernél van internet, annál több adat fut rajta (erre még rájátszik a folyamatosan növekvő sávszélesség, stb.). Emiatt lesz egyre instabilabb és néha belassul, mint a dög, vagy meg-megszakad a net.

Egész egyszerűen a kábelek nem bírják már a terhelést. Ezért is van az, hogy nekem a minimál csomag van 10 megás (ez a legkisebb, amire elő lehet fizetni) és még ezt sem bírja a hálózat.

A megoldás nagyon egyszerű, vagy ki kéne cserélni a főkábelt, vagy (és a t-online erre gyúr) optikai kábelre kéne cserélni. A baj az, hogy ehhez fel kell bontani az utcai burkolatot, ami baromi nagy meló, és sok munka tehát pénz. Nekem a szerelők már akkor (2-3 éve) megmondták, hogy a t-online addig fogja ezt húzni, halasztani, amíg csak tudják, mert ez az optikai kábel fektetés elég drága móka. De elvileg idén már ki fogják cserélni, és azt mondta az egyik szerelő, hogy akkor majd lehet akár 50-100 megabites netem, optikai kábelen el fogja bírni a rendszer ezt a sávszélességet is, úgy, hogy közben stabil is lesz.
Már alig várom.

Másik megoldás, hogy ha idén nem cseréli ki, akkor átmegyek a UPC-hez. A koax kábelek bírják a durva sávszélességet, hisz alapból nagyobb terhelésre lettek kitalálva, mint a hajszál vékony telefon kábelek.
 
Válasz írásához előbb jelentkezz be!
2. sensorprim...
2015.02.21. 13:56
Kábelneten jön a cucc nem telefon kábelen.
Régen telefonon jött, de kb 6 éve már választhatóvá vált a kábelnet és minek fizessek vezetékes telefonért havi díjat mikor nem is használom csak netre, tv meg amúgyis kell más családtagjaimnak.
Persze gondoltam hogy esetleg amiatt van ez, hogy egyre többen neteznek, de akkor csinálják már olyanra hogy ne csak honlapokat lehessen nézni
Nem tudom ebből hogy lesz 2020-ra mindenhol 100 megás net...vagy mit ígért/vállalt a kormány. Pár hónapja volt a hírekben.
 
Válasz írásához előbb jelentkezz be!
1. junkie senso...
2015.02.21. 15:22
@sensorprime

Erre eygszerű a válasz: a sebességduplázásokat szinte semmilyen infrastruktúra fejlesztés nem követte, vagy előzte meg. A nemzetközi sávszél sem növekedett jelentősen, viszont mind a magyar előfizetők száma, mind ezek felhasznált sávja jelentősen emelkedett, logikusan ez a torlódás oka.
 
Válasz írásához előbb jelentkezz be!