Ugrás a tartalomhoz

HTTP

Ellenőrzött
A Wikipédiából, a szabad enciklopédiából
HTTP-logó

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]
  1. 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.)
  2. Tim Berners-Lee: HyperText Transfer Protocol. World Wide Web Consortium. (Hozzáférés: 2010. augusztus 31.)
  3. Tim Berners-Lee: The Original HTTP as defined in 1991. World Wide Web Consortium. (Hozzáférés: 2010. július 24.)
  4. Tim Berners-Lee: HTTP V0.9. World Wide Web Consortium. (Hozzáférés: 2010. július 24.)
  5. Dave Raggett: Hypertext Transfer Protocol Working Group. World Wide Web Consortium. (Hozzáférés: 2010. szeptember 29.)
  6. Dave Raggett: HTTP WG Plans. World Wide Web Consortium. (Hozzáférés: 2010. szeptember 29.)
  7. https://en.wikipedia.org/wiki/HTTP/2#Genesis_in_and_later_differences_from_SPDY
  8. 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.)
  9. https://en.wikipedia.org/wiki/HTTP/2#Goals
  10. 6.1 Status-Line

Kapcsolódó szócikkek

[szerkesztés]
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy