Bevezetés
A HTTP / 2 a. Legújabb verziója Hypertext Transfer Protocol vagy HTTP [01], amelyet a böngészők használnak a webszerverekkel való kommunikációhoz. Az idősebb SPDY-ből származik [02] protokoll, a HTTP / 2 az első új verzió a HTTP / 1.1 szabványnak az RFC 2068 szabványban 1997-es szabványosítása óta.
Ezt az Internet Engineering Task Force (IETF) HTTP munkacsoport fejlesztette ki httpbis (ahol a „bis” jelentése „kétszer”), és RFC 7540 néven jelent meg [03] május 2015.
HTTP / 2 átvétel
A HTTP / 2-t egyre inkább a működő weboldalak fogadják el hivatalos közzététele óta. A W3Techs online felmérési szolgáltatása [04] megjegyzi, hogy 2017. szeptember és 2018. szeptember között a HTTP / 2 támogatás az összes megfigyelt webhely 16% -áról 30% -ra emelkedett.
Ezenkívül a nagyobb böngészők (pl. Chrome, Firefox, Edge stb.) Már teljes mértékben támogatják a HTTP / 2-t [05]. (Néhányan még a kísérleti megvalósításokat kifejlesztették, még mielőtt a HTTP / 2 szabványt elfogadták volna.)
Ez a széles körű elfogadás azt jelenti, hogy a HTTP / 2 a Web tényleges kommunikációs protokolljává válhat.
Motiváció a HTTP / 2 mögött
Httpbischarter [06] a HTTP / 1.1 több olyan összetevőjét említi, amelyek javíthatók a HTTP / 2 motivációjaként. A csoport elsődleges célja azonban a végfelhasználó által észlelt késés csökkentése volt.
Ezt csináld meg, httpbis fontolóra vette a sávszélesség növelését fejléc-tömörítés és agresszív előhívási technikák (pl. szerver push) révén, miközben megpróbálta szisztematikusan megoldani az ismert teljesítményproblémákat, például a kapcsolat torlódását és a Head-of-Line (HoL) blokkoló problémát [07].
Ezenkívül a HTTP / 2-nek visszamenõleg kompatibilisnek kellett lenniük, vagyis ugyanazokat a módszereket, állapotkódokat, URI-ket és (a legtöbb) fejlécmezőt kellett használniuk, amelyek a HTTP / 1.1-ben találhatók. A HTTP / 2-t úgy is meg kellett fejleszteni, hogy támogassa a szokásos HTTP-használati eseteket, például asztali és mobil webböngészőket, programozási felületeket, proxyk és tűzfalakat.
A kompatibilitás fenntartása érdekében a munkacsoport kifejlesztett egy protokoll-tárgyalási mechanizmust, amely lehetővé teszi az ügyfelek és a kiszolgálók számára, hogy a HTTP / 1.1, HTTP / 2 vagy akár nem HTTP protokollok közül válasszanak.
Tehát mi új a HTTP / 2-ben?
A HTTP / 2 továbbra is ugyanazokat az URI sémákat és portszámokat használja, amelyeket a HTTP / 1.1-ben használt (azaz a 80-as port a http
URI, és a 443-as port a https
URI), de sok minden másként történik a motorháztető alatt.
A legalapvetőbb változás a keretek mint a HTTP / 2 alapegysége.
A HTTP / 1.1 hagyományosan használja csomagok a hálózati adatok ábrázolására. Az ügyfél létrehoz egy kérési csomagot egy módszer ige (pl GET
or POST
), mellékelve a kapcsolatot leíró fejlécek és egy test, amely tartalmazza az alkalmazás adatait.
A kérelemcsomag fogadása után a HTTP / 1.1-kiszolgáló hasonló válaszcsomaggal válaszol, amely tartalmazza a kért információkat. Ennek eredményeként minden kérés és válaszciklus új kapcsolatot igényel.
Ezzel szemben a HTTP / 2 ügyfelek egyetlen hálózati kapcsolatot létesítenek a kiszolgálóval, amelyet minden további hálózati kommunikációhoz használnak. A fejlécek, a felhasználói adatok, a hibaüzenetek és minden ilyen információ különálló bináris adatstruktúrákba csomagolódik, amelyeket kereteknek hívnak, mielőtt azokat a hálózaton továbbítják.
Ez kismértékű változásnak tűnik, de jelentős következményekkel jár.
A fejléc tömörítése
A keretek használatának nagy előnye, hogy a HTTP / 2 fejléceket csomagolják a HEADER
keret, amelyet normál tömörítési módszerekkel lehet tömöríteni. A fejléceket minden adat elküldése előtt át kell vinni, így a fejléc-tömörítés csökkentheti a HTTP / 2 által előírt sávszélességet.
A fejléc-tömörítés és a következő teljesítménynövelő HTTP / 2 funkciók mellett különösen hasznos lehet mobil vagy tárgyak internetes (IOT) alkalmazásokban, ahol minimális hálózati használat szükséges.
Patakok és multiplexelés
A szemantikailag releváns keretek független sorozatát a-nak hívjuk folyam. A streameket egyedi azonosítóhoz rendeli az őket létrehozó végpont (azaz kliens vagy szerver), hogy más végpontok megkülönböztessék őket.
A végpontok több adatfolyamból származó keretekbe vonhatják ugyanazt a HTTP / 2 kapcsolatot, lehetővé téve, hogy egyetlen hálózati kapcsolat támogatja több egyidejűleg nyitott adatfolyamot. Ezt a folyamatot nevezik multiplexer [08].
Ugyanazon kapcsolat újbóli felhasználása enyhíti az olyan problémákat, mint a kapcsolatok torlódása és a korábban említett HoL-probléma, és jobb teljesítményt nyújt és simább felhasználói élményt nyújt, mint a korábbi HTTP-verziók.
Patakfüggőség és prioritások meghatározása
Több párhuzamos adatfolyam kezelése azt jelenti, hogy néhány adatfolyamot mások előtt dolgoznak fel. A HTTP / 2 lehetővé teszi a fejlesztőnek (vagy adminisztrátornak), hogy finomítsa ezt a viselkedést az úgynevezett funkcióval patakfüggőség.
Egy adatfolyam függhet egy másik adatfolyam teljes átvitelétől, mielőtt kezelni kezdené. Például egy olyan webhelyen, ahol a weboldal fő tartalmát be kell tölteni, mielőtt a hasonló tartalomra vonatkozó javaslatokat megteszik, a HTTP / 2 lehetővé teszi az ajánlásfolyam létrehozását a fő tartalomfolyamtól függően.
A HTTP / 2 is támogatja stream prioritások meghatározása. Ez azt jelenti, hogy minden egyes adatfolyamhoz hozzárendelhető egy prioritás, hogy javasoljuk, hogy a végpontoknak milyen sürgősen kell kiosztaniuk az erőforrásokat a folyam kereteinek kezelésére.
A rangsorolás és az adatfolyam-függőség segít a fejlesztőknek és a webhelytulajdonosoknak optimalizálni a webhelyük használatát, ami jelentősen javíthatja a webhely felhasználói élményét.
Szerver push
Végül a HTTP / 2 javíthatja a weboldal teljesítményét azáltal, hogy „push” funkciót biztosít. A HTTP / 2 webkiszolgáló több lekérdezéssel tud adattal válaszolni, mint amennyit az ügyfél eredetileg kért. Ez lehetővé teszi a kiszolgáló számára, hogy olyan adatokat szolgáltasson, amelyekről tudja, hogy a webböngészőnek egy oldalt kell megjelenítenie, anélkül, hogy megvárná, amíg a böngésző megvizsgálja az első választ, és így egy további kérési ciklus nélkül.
A kiszolgáló lekérdezése révén a fejlesztők teljes mértékben ellenőrizhetik a böngésző által a webhelyük megjelenítéséhez szükséges kérelmek számát. Helyes használat esetén ez a szolgáltatás minimalizálja a hálózati terhelést.
Természetesen a push funkcióval való visszaélés a ténylegesen szükséges sávszélességet is elveszti. Ezért a HTTP / 2 lehetővé teszi az ügyfelek számára, hogy a kapcsolat első tárgyalásakor kérjék a kiszolgáló letiltásának letiltását.
HTTP / 2 biztonság
Ha eddig elolvastál, akkor egyértelműnek kell lennie, hogy a HTTP / 2 fejlesztői valóban erőfeszítéseket tesznek a teljesítmény javítására. Meg kell azonban jegyezni, hogy a HTTP / 2 szintén hozzájárulhat a böngésző felhasználói biztonságának javításához.
Pontosabban: a HTTP / 2 meghatározása mind a HTTP URI (azaz titkosítás nélkül), mind a HTTPS URI (felett) TLS titkosított csatornák). Bár maga a szabvány nem követeli meg titkosítás használatát, az összes főbb böngésző implementáció (azaz a Firefox [09], Chrome, Safari, Opera, IE, Edge) úgy döntöttek, hogy meg fogják tenni csak támogatja a HTTP / 2-t TLS.
Valójában a böngészők megkülönböztetik a tiszta szöveges HTTP / 2 és a HTTP / 2 kódolást titkosítva TLS mint két különféle protokoll. A titkosított HTTP / 2 hívásra kerül h2
és tiszta szöveg h2c
. A cikk írása óta a fő böngészők egyikét sem támogatják h2c
, Ami azt jelenti, hogy TLS a HTTP / 2 egyéb előnyeinek kihasználásához a weboldalak számára kötelező a titkosítás. Ezért, amikor a HTTP / 2 lesz az alapértelmezett webhálózati protokoll, a régi webhelytulajdonosok, akik még nem frissítettek SSL /TLSerősen motiválva lesz arra, hogy végre megtegyük.
Következtetés
A HTTP / 2 széles körű elfogadása új és továbbfejlesztett internetet fog létrehozni. Ez gyorsabb, kevesebb sávszélességet igényel, és elősegíti a webhelyek biztonságát. A mainstream elfogadása minden bizonnyal zökkenőmentesebbé és biztonságosabbá teszi az általános felhasználói élményt.
Szerezz be egy igazolást ma, és csatlakozz hozzánk a jövőben is.