HTTP
TCP/IP protokollhierarchia |
---|
Alkalmazási protokollok |
DHCP · DNS · FTP · HTTP · IMAP · IRC · POP3 · SIP · SMTP · SNMP · SSH · Telnet · BitTorrent |
Szállítási protokollok |
Hálózati protokollok |
Adatkapcsolati protokollok |
Ethernet · Wi-Fi · Token-Ring · FDDI · PPP |
Fizikai protokollok |
RS-232 · 100Base-TX · 1000Base-TX · 10Base2 · 10Base-T |
A HTTP (HyperText Transfer Protocol) egy információátviteli protokoll elosztott, kollaboratív, hipermédiás, információs rendszerekhez.
A HTTP fejlesztését a World Wide Web Consortium és az Internet Engineering Task Force koordinálta RFC-k formájában. Az 1999-ben kiadott RFC 2616 definiálja a HTTP/1.1-et, amit 2015 végére leváltott a HTTP/2.0-ás verzió, amit az RFC 7540 definiál. Hivatalosan ez a legújabb protokoll.[1]
A HTTP egy kérés-válasz alapú protokoll kliens és szerver között. A HTTP-klienseket a „user agent” gyűjtőnévvel is szokták illetni. A user agent jellemzően, de nem feltétlenül webböngésző.
A HTTP a TCP/IP réteg felett helyezkedik el. A HTTP implementálható más megbízható szállítási réteg felett is, akár az interneten, akár más hálózaton. Kizárólagosan TCP protokollt használ, mivel az adatveszteség nem megengedhető.
Történet
[szerkesztés]Tim Berners-Lee és csapata alkották meg a HTTP és a HTML legelső változatát, és az ahhoz tartozó technológiát, azaz egy szervert és egy klienst.[2]
- 0.9 verzió (1991)
Az első dokumentált verzió.[3] A kliens csak a GET metódust használhatta a kérésben. A GET egyparaméteres volt, csak az erőforrás nevét kellett megadni, a verziószámra itt még nem gondoltak. Mivel ebben a verzióban nem volt POST, a kliens nem tudott túl sok információt eljuttatni a szerverre. Ez a verzió még nem támogatta a headereket sem. A szerver válasza ekkor még minden esetben HTML formátumú volt.[4]
- 1.0 verzió (1996. május)
A HTTP munkacsoport kiterjesztette a protokollt, és 1996 májusában kiadta az 1.0 verziót.[5] Itt vezették be a verziószámozást, így a kérések kétparaméteresek lettek. A kliens a kérésben megadja az általa támogatott legfrissebb verziót, a szerver pedig vagy azzal megegyező, vagy annál korábbi verzióval válaszol. RFC 1945
- 1.1 verzió (1999. június)
A HTTP munkacsoport 1995 decemberében tervezte bevezetni az 1.1 verziót.[6] Ezt hivatalosan 1997 januárjában sikerült kiadni, az RFC 2068 formájában. Ehhez javításokat és frissítéseket tartalmaz az 1999 júniusában kiadott RFC 2616. A szabvány e verziójával vezették be a perzisztens kapcsolatokat és a request pipeliningot.
2.0 verzió (2015. február 17.)
HTTP/2 (hivatalosan HTTP/2.0) második verziója a HTTP hálózati protokollnak, aminek az SPDY képzi az alapját.[7] A protokollt Hypertext Transfer Protocol munkacsoport fejlesztette (httpbis[8]). Alapelvei közé tartoznak olyan fontos tényezők, mint például a szerverek túlterheltségének csökkentése, a felhasználói élmény javítása, több egyidejű hálózati kapcsolat, a meglévő push/pull technológiák leváltása (ajax,json), és valamint az Információs technológiai biztonság.[9] A HTTP/2 specifikációját (RFC 7540) 2015 májusában hozták nyilvánosságra.
A verziószámok használatát az RFC 2145 írja le.
Kérés (request)
[szerkesztés]Egy HTTP kérés első sora mindig ,,METÓDUS ERŐFORRÁS VERZIÓ" alakú, például így:
GET /images/logo.gif HTTP/1.1
Ezt a sort követheti tetszőleges számú header sor ,,HEADER: ÉRTÉK" alakban, például így:
Host: example.com Connection: close User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0 Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7 Cache-Control: no-cache Accept-Language: de,en;q=0.7,en-us;q=0.3
- A fenti példában a User-Agent sor a kliens által használt webböngésző típusát jelöli.
- Az Accept-Charset sor jelzi, hogy milyen karakter kódolásban várja a szervertől a választ.
- Az Accept-Language hasonlóan a válaszban elfogadott nyelvet jelöli.
- A Cache-Control határozza meg, hogy a kliens és szerver közti útvonalon kötelezően használjanak-e cache-elést, vagy sem.
A header sorok végét egy üres sor jelzi, melyet az opcionális üzenettest követ. A sorokat a CRLF (azaz kocsi vissza + soremelés) karakterpárral kell elválasztani. A headerek végét jelző üres sor csak ezt a két karaktert tartalmazhatja, nem lehet benne szóköz és tabulátor sem.
Metódusok
[szerkesztés]HTTP protokoll nyolcféle metódust definiál. A metódusok (más szóval verbek) a megadott erőforráson végzendő műveletet határozzák meg.
verb | jelentés |
---|---|
HEAD | Ugyanazt adja vissza, mint a GET, csak magát az üzenettestet hagyja ki a válaszból. |
GET | A megadott erőforrás letöltését kezdeményezi. Ez messze a leggyakrabban használt metódus. |
POST | Feldolgozandó adatot küld fel a szerverre. Például HTML űrlap tartalmát. Az adatot az üzenettest tartalmazza. |
PUT | Feltölti a megadott erőforrást. |
DELETE | Törli a megadott erőforrást. |
TRACE | Visszaküldi a kapott kérést. Ez akkor hasznos, ha a kliens oldal arra kíváncsi, hogy a köztes gépek változtatnak-e, illetve mit változtatnak a kérésen. |
OPTIONS | Visszaadja a szerver által támogatott HTTP metódusok listáját. |
CONNECT | Átalakítja a kérést transzparens TCP/IP tunnellé. Ezt a metódust jellemzően SSL kommunikáció megvalósításához használják. |
Biztonságos metódusok
[szerkesztés]Biztonságosnak azokat a metódusokat nevezzük, amelyek csak információ lehívására szolgálnak és elvben nem változtatják meg a szerver állapotát. Más szóval mellékhatás nélküliek. Ilyenek például a HEAD, a GET, az OPTIONS és a TRACE. Fontos megjegyezni, hogy a gyakorlatban lehetnek a biztonságos metódusoknak is szerveroldali mellékhatásai. Előfordulhat például, hogy egy GET kérés hatására a szerver cache-elésbe kezd. Ennél veszélyesebb az, amikor a szerver egy egyszerű hiperlinkből mutató GET kérés hatására végez módosítást vagy törlést az adatbázisban. Ez a gyakorlat nem ajánlott, mert problémákat okozhat cache-elő, kereső vagy egyéb automatizált klienseknél, mert ezek nem kívánt változásokat okozhatnak a szerveren az ilyen jellegű GET-eknél.
Idempotens metódusok
[szerkesztés]Idempotensnek azokat a metódusokat nevezzük, melyeknek többszöri végrehajtása ugyanazt a hatást váltja ki, mint az egyszeri. Ilyenek például a PUT és a DELETE. Minden biztonságos metódus (például HEAD, GET, OPTIONS és TRACE) értelemszerűen idempotens is. Az RFC szerint az idempotens metódusoknál a kliens (leggyakrabban webböngésző) következmény nélkül újrapróbálkozhat, ha a kérés sikertelen volt. Ez arra jó, hogy ha a szerver túl lassan vagy hibásan válaszol, akkor a böngésző felhasználói beavatkozás nélkül újrapróbálhatja az oldal letöltését.
Fontos azonban tudni, hogy a szabványban definiált idempotencia nem nyújt automatikus védelmet a szerveroldali változásoktól. Minden további nélkül írható olyan webalkalmazás, amely GET kérés hatására adatbázis-módosítást (sql update) vagy -beszúrást (sql insert) hajt végre, amelyek nyilvánvalóan szerveroldali változást okoznak.
Az ilyen GET használat és a kliens automatikus újrapróbálkozásának összetalálkozása nemkívánatos eredményeket okozhat, ezért a GET használata tranzakciók esetében kerülendő. Tanácsos követni az RFC-ben definiált szabványt, és a GET metódust csak adatok lehívására használni.
Feltételes kérés
[szerkesztés]A feltételes kérésre azért van szükség, hogy meggyorsítsuk a HTTP kommunikációt a cache-elés segítségével. Mivel a web-szerverek és böngészők képesek az oldalak, fájlok, képek ideiglenes tárolására, így nincs szükség ismételt letöltésre. Ezt a lekérést a feltételes (conditional) GET metódus végzi, melyet a kliens akkor küld a szerver irányában, ha azt már legalább egyszer meglátogatta (az első lekérés során csak általános GET lekérés történik).
A feltételes GET kérést két 'header' sor jelöli:
GET /pelda.html HTTP/1.1 (...) If-Modified-Since: Sat, 22 Oct 2001 19:43:31 GMT (...) If-None-Match: „kód”
- Az If-Modified-Since-szel a kliens lekérdezi a szervertől, hogy a kért dokumentum módosult-e a megadott dátum óta.
- Az If-None-Match a szerver által küldött dokumentum hash kódjára hivatkozik.
Válasz (response)
[szerkesztés]A HTTP válasz első sora a státuszsor, amely ,,VERZIÓ STÁTUSZKÓD INDOKLÁS" alakú. A státuszkód (angolul status code) egy három számjegyű szám, az indoklás (angolul reason phrase) egy üzenet valamilyen emberi nyelven. Az előbbit inkább gépi, az utóbbit inkább emberi feldolgozásra szánták. Például:
HTTP/1.1 200 OK
vagy
HTTP/1.1 404 Not Found
A szöveges üzenetekre a szabvány csak javaslatokat tartalmaz. A szerver küldhet lokalizált üzeneteket is:
HTTP/1.1 404 Nincs meg.
Állapotkódok
[szerkesztés]Az állapotkódok (státuszkódok) jelentését az RFC 2616 tartalmazza részletesen, az alábbi lista egy áttekintő osztályozást ad a kezdő számjegy alapján:
- 1xx: Informatív – Kérés megkapva.
- Pl.: 100 – Folytatás, 101 – Protokoll váltás
- 2xx: Siker – A kérés megérkezett; értelmezve, elfogadva.
- Pl.: 200 – OK, 202 – Elfogadva, 203 – Nem autoritatív információ
- 3xx: Átirányítás – A kérés megválaszolásához további műveletre van szükség.
- Pl.: 301 – Ideiglenesen elköltözött, 305 – Használjon proxyt
- 4xx: Kliens hiba – A kérés szintaktikailag hibás vagy nem teljesíthető.
- Pl.: 403 – Nem engedélyezett, 404 – Nem található
- 5xx: Szerver hiba – A szerver nem tudta teljesíteni az egyébként helyes kérést.
- Pl.: 503 – Szolgáltatás nem elérhető, 505 – Nem támogatott HTTP verzió
Ha a státuszkód hibára utal, akkor a kliens megjelenítheti a hibaüzenetet, hogy tájékoztassa a felhasználót a hiba természetéről. A szabvány megengedi azt is, hogy a kliens maga interpretálja a státuszkódot és az alapján saját üzenetet generáljon a felhasználónak, de ez zavaró lehet. A szabvány szerint a státuszkódot szánják gépi feldolgozásra, és a „reason phrase” való emberi fogyasztásra. Használhatóak egyedi státuszkódok is, mert a kliens ismeretlen kód esetén az első számjegy alapján már tudja osztályozni a választ.[10]
Header sorok
[szerkesztés]A státuszsor után header sorok következhetnek a HTTP kérésnél látott módon ,,HEADERNÉV: ÉRTÉK" alakban. Például így:
Server: Apache Date: Sat, 24 Mar 2012 16:49:31 GMT Content-type: text/html Pragma: no-cache Connection: close
- A Server magán a szerveren futó kiszolgáló szoftvert azonosítja.
- A Date az elküldött válasz dátumát tartalmazza.
- A Content-type: a válaszban (body-ban) elküldött szöveg típusát tartalmazza.
- Pragma: a kliens oldalon futó böngésző nem fogja cache-elni a lekért adatokat.
A header sorokat itt is üres sor zárja, melyet az opcionális üzenettest követ.
A kliens elsősorban a státuszkód, másodsorban a header sorok tartalma alapján kezeli a választ.
Feltételes válasz
[szerkesztés]A feltételes válasz kétféle lehet, attól függően, hogy a kért adat szerepel-e már a kliens gyorsítótárjában.
Ha a kliens először látogatja az oldalt, akkor a következő válasz érkezik:
HTTP/1.1 200 OK (...) Cache-Control: max-age=21600 Last-Modified: Wed, 01 Sep 2009 13:24:52 GMT Etag: "4586bdc8"
- A Cache-Control megadja a kliensnek, hogy mennyi ideig cache-elje (tárolja) a dokumentumot.
- A Last-Modified megadja, hogy mikor lett utoljára módosítva a dokumentum.
- Az Etag egy egyedi azonosító (hash) a dokumentumhoz.
Ezt a választ követően a kliens elmenti a dokumentumot a max-age paraméterben megadott ideig. Legközelebb, amikor a kliens ismét meglátogatja az oldalt, már a fentebb leírt feltételes kéréssel hivatkozik a dokumentumra. Ha a dokumentum nem módosult, akkor a következő válasz érkezik a szervertől:
HTTP/1.1 304 Not Modified (...) Keep-Alive: timeout=2, max=99 Etag: "4586bdc8" Cache-Control: max-age=21600
- A szerver látja, hogy még nem módosult a dokumentum az utolsó lekérés óta, ezért egy 304-es kódot küld a kliensnek.
- Beállítja ismételten a dokumentumhoz tartozó értékeket.
A szerver csak akkor fogja elküldeni a kliensnek a kért dokumentumot, ha az módosult a cache-elés óta.
Hatékonyságnövelés
[szerkesztés]A HTTP/0.9 és 1.0 verziókban a kapcsolat egy kérés-válasz után lezáródik. A HTTP/1.1 verzióban bevezettek egy mechanizmust a kapcsolat életben tartására, így a kapcsolat újrafelhasználható további kérésekhez. A kapcsolat életben tartását hívják idegen szóval perzisztenciának, az ilyen kapcsolatot pedig a perzisztens jelzővel illetik. Ez az újítás gyorsíthatja a kommunikációt, mert a kliensnek nem kell újratárgyalnia a TCP kapcsolatot minden egyes kérésnél.
Egy másik teljesítménynövelő újítás a HTTP/1.1 verzióban az ún. chunked transfer encoding, mellyel a perzisztens kapcsolat felett adatfolyam (stream) továbbítható, a kevésbé gazdaságos pufferelés helyett. A HTTP pipelining segítségével pedig a kliens elküldhet több kérést is egymás után anélkül, hogy megvárná a választ. További hatékonyságoptimalizáló újítás a byte serving, ami azt jelenti, hogy a kért erőforrásnak csak a kliens által kijelölt darabját (byte range) küldi el a szerver.
Munkamenet (session)
[szerkesztés]A HTTP egy állapot nélküli protokoll. Az állapot nélküli protokollok előnye, hogy a szervernek nem kell nyilvántartania felhasználói információkat az egyes kérések kiszolgálása között. A HTTP eredetileg nem arra készült, hogy felhasználók jelentkezzenek be rajta keresztül szerverekre és ott munkamenetet (idegen szóval session-t) indítsanak. Történetileg azonban úgy alakult, hogy a HTTP terjedt el széles körben más, felhasználói bejelentkezést támogató protokollok helyett, ami arra kényszerítette a webfejlesztőket, hogy a HTTP-t mintegy megerőszakolva, kerülőutakon járva tárolják a felhasználók munkamenetállapotait. Egy tipikus megoldás cookie-kban tárolni a felhasználói állapotot. Egyéb módszerek még a rejtett változók (például <input type="hidden" name="session_id" value="1956">
) vagy az URL-ben kódolt paraméterek (például /index.php?userid=3
) használata illetve a szerveroldali állapotmegőrzés. A legbiztonságosabb megoldás vélhetően a szerveroldali állapotmegőrzés, mert az az egyetlen, amelyet nem tudnak ,,megpiszkálni" rosszindulatú kliensek.
Biztonságos HTTP
[szerkesztés]Jelenleg két módszer áll rendelkezésre biztonságos http-kapcsolat felépítésére: Az egyik a https URI-séma, a másik pedig a HTTP/1.1 verzióban bevezetett Upgrade header (lásd RFC 2817). Az Upgrade header kliensoldali támogatása jelenleg gyakorlatilag még nem létezik, ezért egyértelműen a https dominál.
A HTTPS URI-rendszer
[szerkesztés]A https séma szintaktikailag megegyezik a http-sémával, de jelzi a böngészőnek, hogy használni kell az SSL/TSL titkosító réteget az adatforgalom védelme érdekében. Az SSL különösen célszerű a HTTP esetében, mert akkor is nyújt némi védelmet, ha csak a kommunikáció egyik oldala hitelesített (más szóval autentikált). Az internetes HTTP-tranzakciók esetében jellemzően csak a szerveroldal hitelesített.
A HTTP 1.1 Upgrade header
[szerkesztés]A HTTP 1.1 verzióban bevezették az Upgrade headert. A kommunikáció során a kliens először egy sima titkosítatlan kérést küld, majd később vagy a kliens vagy a szerver kéri (vagy megköveteli) a kapcsolat titkosítását. Jellemzően a szerver követeli meg a titkosítást:
- Kliens
GET /secret-activity HTTP/1.1 Host: www.msi.com
- Szerver
HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade
A 426-os státuszkód jelzi, hogy kötelező a titkosítás, az Upgrade header pedig megadja a támogatott protokollverziókat. Ha a kliens nem támogatja az Upgrade headert és nem ismeri ezt a hibakódot, akkor is tudja az első számjegyből, hogy kliensoldali hibáról van szó.
Jegyzetek
[szerkesztés]- ↑ Hypertext Transfer Protocol Version 2 (HTTP/2). http2.github.io. [2013. július 15-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. május 10.)
- ↑ Tim Berners-Lee: HyperText Transfer Protocol. World Wide Web Consortium. (Hozzáférés: 2010. augusztus 31.)
- ↑ Tim Berners-Lee: The Original HTTP as defined in 1991. World Wide Web Consortium. (Hozzáférés: 2010. július 24.)
- ↑ Tim Berners-Lee: HTTP V0.9. World Wide Web Consortium. (Hozzáférés: 2010. július 24.)
- ↑ Dave Raggett: Hypertext Transfer Protocol Working Group. World Wide Web Consortium. (Hozzáférés: 2010. szeptember 29.)
- ↑ Dave Raggett: HTTP WG Plans. World Wide Web Consortium. (Hozzáférés: 2010. szeptember 29.)
- ↑ https://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_differences_from_SPDY
- ↑ Hypertext Transfer Protocol Version 2 (HTTP/2). httpwg.org. [2016. május 7-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. május 10.)
- ↑ https://en.wikipedia.org/wiki/HTTP/2#Goals
- ↑ 6.1 Status-Line