Http

http
Név Hypertext Transfer Protocol
Szint ( az OSI modell szerint ) Alkalmazott
Család TCP/IP
Létrehozva: 1992
Port/ID 80/ TCP
Leírás RFC 124 , RFC 1945 , RFC 2616 , RFC 2617 , RFC 6266 , RFC 7230 , RFC 7240 , RFC 8446 .
Főbb megvalósítások (kliensek) Webböngészők , például Internet Explorer , Mozilla Firefox , Opera , Google Chrome , Yandex Browser , Microsoft Edge stb.
Alapvető megvalósítások ( szerverek ) Apache , IIS , nginx , Google webszerver stb.
 Médiafájlok a Wikimedia Commons oldalon

A HTTP ( HyperText  Transfer Protocol  – „ hipertext átviteli protokoll ”) egy alkalmazási rétegbeli adatátviteli protokoll, eredetileg HTML formátumú hiperszöveg dokumentumok formájában , jelenleg tetszőleges adatok átvitelére használják.

Alaptulajdonságok

A HTTP alapja a "kliens-szerver" technológia , vagyis a következők létezése:

A HTTP ma már mindenütt jelen van a világhálón az információk lekérésére a webhelyekről . 2006 - ban Észak-Amerikában a HTTP - forgalom 46%-kal meghaladta a P2P-hálózatokét , ennek csaknem a fele video- és hangadatfolyam volt [1] .

A HTTP-t más alkalmazási rétegbeli protokollok „átviteleként” is használják, mint például a SOAP , XML-RPC , WebDAV .

A HTTP-ben végzett manipuláció fő célja az az erőforrás, amelyre egy URI (Uniform Resource Identifier) ​​mutat egy ügyfélkérelemben. Ezek az erőforrások általában a szerveren tárolt fájlok , de lehetnek logikai objektumok vagy valami absztrakt. A HTTP protokoll egyik jellemzője, hogy a kérésben és a válaszban megadható, hogy ugyanazt az erőforrást hogyan ábrázolják különböző paraméterek: formátum , kódolás , nyelv stb. (különösen a HTTP fejlécet használják erre ). Az üzenet kódolási módjának meghatározásának köszönhetően a kliens és a szerver bináris adatokat cserélhet , bár ez a protokoll szöveges.

A HTTP egy alkalmazási réteg protokoll ; megfelelői az FTP és az SMTP . Az üzenetek cseréje a szokásos „kérés-válasz” séma szerint történik. A HTTP globális URI -kat használ az erőforrások azonosítására . Sok más protokolltól eltérően a HTTP állapot nélküli. Ez azt jelenti, hogy a kérés-válasz párok között nincs köztes állapot. A HTTP-t használó összetevők egymástól függetlenül tárolhatják a legutóbbi kérésekhez és válaszokhoz kapcsolódó állapotinformációkat (pl. " cookie -k " a kliens oldalon, "munkamenetek" a szerver oldalon). A kéréseket küldő böngésző nyomon tudja követni a válaszadási késéseket. A szerver képes tárolni a legutóbbi kliensek IP-címeit és kérésfejléceit. Maga a protokoll azonban nem ismeri a korábbi kéréseket, válaszokat, nem nyújt belső állami támogatást, nincsenek ilyen követelményei.

A legtöbb protokoll lehetővé teszi egy TCP-munkamenet létrehozását, amelynek során az engedélyezés egyszer megtörténik, és további műveleteket hajtanak végre ezzel az engedélyezéssel összefüggésben. A HTTP minden kéréshez külön TCP-munkamenetet hoz létre; a HTTP újabb verziói lehetővé tették több kérés lebonyolítását egyetlen TCP-munkamenetben, de a böngészők jellemzően csak az oldalt és a benne található objektumokat (képek, lépcsőzetes stílusok stb.) kérik le, majd azonnal leállítják a TCP-munkamenetet. A HTTP cookie -kat használ az engedélyezett (nem névtelen) hozzáférés támogatására ; Ezenkívül ez az engedélyezési módszer lehetővé teszi a munkamenet mentését még az ügyfél és a kiszolgáló újraindítása után is.

FTP-n vagy fájlprotokollokon keresztüli adatok elérésekor a fájl típusát (pontosabban a benne található adatok típusát) a fájlnév kiterjesztése határozza meg, ami nem mindig kényelmes. A HTTP az adatok továbbítása előtt továbbítja a Content-Type: type / subtype fejlécet, amely lehetővé teszi a kliens számára, hogy egyértelműen meghatározza az elküldött adatok feldolgozásának módját. Ez különösen akkor fontos, ha CGI szkriptekkel dolgozik , amikor a fájlnév kiterjesztése nem a kliensnek küldött adatok típusát jelzi, hanem azt, hogy ezt a fájlt le kell futtatni a szerveren és el kell küldeni a fájlba írt program eredményét a kliensnek. (ebben az esetben ugyanaz a fájl a kérés argumentumaitól és saját szempontjaitól függően különböző típusú válaszokat generálhat - a legegyszerűbb esetben különböző formátumú képeket).

Ezenkívül a HTTP lehetővé teszi a kliens számára, hogy paramétereket küldjön a kiszolgálónak, amelyek átadásra kerülnek a futó CGI-szkriptnek. Ehhez űrlapokat vezettek be a HTML -be.

A HTTP ezen funkciói lehetővé tették keresőmotorok (amelyek közül az első a DEC által létrehozott AltaVista ), fórumok és internetes áruházak létrehozását. Ezzel kommercializálódott az internet, megjelentek a cégek, amelyek fő tevékenységi köre az internetelérés (szolgáltatók) biztosítása, honlapkészítés volt.

Szoftver

A HTTP protokollal dolgozó összes szoftver három nagy kategóriába sorolható:

A végkiszolgálók és a proxyszerverek megkülönböztetésére a hivatalos dokumentáció az eredetkiszolgáló kifejezést használja .  Egy és ugyanaz a szoftvertermék a feladatoktól függően egyidejűleg is elláthatja kliens, szerver vagy közvetítő funkcióit. A HTTP protokoll specifikációi részletezik az egyes szerepkörök viselkedését.

Ügyfelek

A HTTP protokollt eredetileg a világháló hiperszöveges dokumentumainak elérésére tervezték. Ezért a fő kliens megvalósítások a böngészők (felhasználói ügynökök). A webhelyek mentett tartalmának internetkapcsolat nélküli számítógépen való megtekintéséhez offline böngészőket találtak ki . Ha a kapcsolat instabil, a letöltéskezelők nagy fájlok letöltésére szolgálnak ; lehetővé teszik a megadott fájlok letöltését a webszerverrel való kapcsolat megszakadása után bármikor. Egyes virtuális atlaszok (például a Google Earth és a NASA World Wind ) szintén használnak HTTP-t.

A programok gyakran a HTTP protokollt használják frissítések letöltésére.

Az internetes keresőkben robotprogramok egész sorát használják . Köztük vannak webpókok ( bejárók ), amelyek bejárják a hiperhivatkozásokat, adatbázist állítanak össze a szerver erőforrásairól, és tárolják azok tartalmát további elemzés céljából.

Forrásszerverek

Főbb megvalósítások: Apache , Internet Information Services (IIS), nginx , LiteSpeed ​​​​Web Server (LSWS), Google Web Server , lighttpd .

Proxy szerverek

Főbb megvalósítások: Squid , UserGate , Multiproxy , Naviscope , nginx .

HTTP üzenetstruktúra

Minden HTTP üzenet három részből áll, amelyek a felsorolt ​​sorrendben kerülnek elküldésre:

  1. Starting line ( eng.  Starting line ) - meghatározza az üzenet típusát;
  2. Fejlécek ( angol  fejlécek ) - az üzenet törzsét, az átviteli paramétereket és egyéb információkat jellemzik;
  3. Az üzenet törzse ( angolul  Message Body ) - közvetlenül az üzenet adatai. Üres sorral kell elválasztani a fejlécektől.

Az üzenet törzse elhagyható, de a kezdősor és a fejléc kötelező elemek. A kivétel a protokoll 0.9-es verziója, ahol a kérés üzenet csak a kezdősort, a válaszüzenet pedig csak az üzenet törzsét tartalmazza.

Az 1.1-es protokollverzió esetén a kérésüzenetnek tartalmaznia kell a Host fejlécet .

Kezdő sor

A kezdő karakterláncok eltérőek a kérés és a válasz esetében. A lekérdezési karakterlánc így néz ki:

GET URI — 0.9-es protokollverzióhoz; Метод URI HTTP/Версия - más verziókhoz.

Itt:

Ahhoz, hogy oldalt kérjen ehhez a cikkhez, az ügyfélnek át kell adnia a karakterláncot (csak egy fejléc van megadva):

Szerezze be a /wiki/HTTP HTTP/1.0-t Házigazda: en.wikipedia.org

A szerver válaszának kezdősora a következő formátumú: HTTP/Версия КодСостояния Пояснение, ahol:

Például a kiszolgáló egy korábbi kérésre adott válaszának kezdősora így nézhet ki:

HTTP/1.0 200 OK

Módszerek

HTTP metódus ( angol  HTTP Method ) - a vezérlők és a határolók kivételével tetszőleges karaktersorozat, amely az erőforrás fő műveletét jelzi. Általában a módszer egy rövid, nagybetűvel írt angol szó. Vegye figyelembe, hogy a metódus neve megkülönbözteti a kis- és nagybetűket.

A szerver bármilyen metódust használhat, a szerverre vagy a kliensre nincsenek kötelező metódusok. Ha a szerver nem ismeri fel a kliens által megadott metódust, akkor a 501(Nincs implementálva) állapotot kell visszaadnia. Ha a módszert ismeri a kiszolgáló, de nem alkalmazható egy adott erőforrásra, akkor a rendszer egy kódot tartalmazó üzenetet küld 405vissza (A módszer nem engedélyezett). Mindkét esetben a szervernek tartalmaznia KELL egy fejlécet Allowa támogatott metódusok listájával a válaszüzenetben.

GETA és módszerek HEADmellett gyakran alkalmazzák a módszert POST.

OPCIÓK

Egy adott erőforrás webszerver-képességeinek vagy csatlakozási lehetőségeinek meghatározására szolgál. Válaszul a szervernek tartalmaznia KELL egy fejlécet Allowa támogatott metódusok listájával. A válaszfejléc tartalmazhat információkat a támogatott bővítményekről is.

Feltételezhető, hogy az ügyfélkérelem tartalmazhat egy üzenettörzset, amely jelzi az őt érdeklő információkat. A törzs formátuma és a vele való munkavégzés sorrendje jelenleg nincs meghatározva; a szervernek egyelőre figyelmen kívül kell hagynia. Hasonló a helyzet a szerver válaszában szereplő testtel.

A teljes szerver képességeinek megismeréséhez a kliensnek meg kell adnia egy csillagot - " *" - az URI-ban. A " " kérések OPTIONS * HTTP/1.1a kiszolgáló állapotának ellenőrzésére is használhatók (hasonlóan a " ping "-hez), valamint annak tesztelésére, hogy a szerver támogatja-e a HTTP 1.1-es verziójú protokollt.

A módszer végrehajtásának eredménye nem kerül gyorsítótárba .

GET

A megadott erőforrás tartalmának lekérdezésére szolgál. A folyamatot metódussal GETis elindíthatja . Ebben az esetben a folyamat előrehaladásáról szóló információkat fel kell tüntetni a válaszüzenet törzsében.

?Az ügyfél a „ ” karakter után adhat át kérésvégrehajtási paramétereket a cél erőforrás URI-jában :
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

A HTTP szabvány szerint a típuskérések idempotensnekGET minősülnek [2]

A szokásos módszeren GETkívül vannak még

Az ilyen kérések végrehajtásának sorrendjét a szabványok külön határozzák meg.

FEJ

Hasonló a módszerhez GET, kivéve, hogy a szerver válaszában nincs törzs. A lekérdezést HEADáltalában metaadatok lekérésére , egy erőforrás meglétének ellenőrzésére ( URL- ellenőrzés ) használják, és megnézik, hogy változott-e az utolsó hozzáférés óta.

A válaszfejlécek gyorsítótárazhatók. Ha az erőforrás metaadatai nem egyeznek a gyorsítótárban lévő megfelelő információkkal, az erőforrás másolata elavultként lesz megjelölve.

POST

A felhasználói adatok adott erőforrásnak való továbbítására szolgál. Például a blogokban a látogatók általában egy HTML űrlapba írhatják be a bejegyzésekhez fűzött megjegyzéseiket, majd a POST módszerrel elküldik a szerverre, és az felteszi az oldalra. Ebben az esetben a továbbított adatok (a blog példájában a megjegyzés szövege) szerepelnek a kérés törzsében. Hasonlóképpen, a módszer használatával a POSTfájlok általában feltöltésre kerülnek a szerverre.

A metódussal ellentétben a metódus GETnem POSTtekinthető idempotensnek [2] , azaz ugyanazon lekérdezések ismételt ismétlése POSTeltérő eredményeket adhat (például minden megjegyzés elküldése után ennek a megjegyzésnek egy másik példánya jelenik meg).

Ha a végrehajtás eredménye 200(Ok), akkor a válasz törzsének tartalmaznia kell egy üzenetet a kérés eredményéről. Ha létrejött egy erőforrás, a kiszolgálónak választ KELL adnia 201(Létrehozva) az új erőforrás URILocation -jával a .

A metódus-végrehajtási kiszolgáló válaszüzenete POSTnincs gyorsítótárban.

PUTS

A kérelem tartalmának letöltésére szolgál a kérelemben megadott URI-ra. Ha az adott URI-hoz nem létezik erőforrás, akkor a szerver létrehozza azt, és visszaadja a 201(Létrehozva) állapotot. Ha az erőforrás megváltozott, akkor a szerver 200(Ok) vagy 204(Nincs tartalom) visszatér. A szerver NEM hagyhatja figyelmen kívül Content-*az ügyfél által az üzenettel együtt küldött érvénytelen fejléceket. Ha a fejlécek bármelyike ​​nem ismerhető fel vagy érvénytelen a jelenlegi körülmények között, akkor hibakódot 501(Nincs implementálva) kell visszaadni.

A módszerek közötti alapvető különbség az erőforrás-URI-k céljának megértésében POSTrejlik . PUTA módszer POSTfeltételezi, hogy az ügyfél által továbbított tartalom a megadott URI-n kerül feldolgozásra. A használatával PUTaz ügyfél feltételezi, hogy a betöltendő tartalom megegyezik az adott URI-n lévő erőforrással.

A metódusra küldött kiszolgálói válaszüzenetek PUTnem kerülnek gyorsítótárba.

PATCH

Hasonló a PUT-hoz, de csak egy erőforrás-részletre vonatkozik.

TÖRLÉS

Törli a megadott erőforrást.

TRACE

Visszaadja a kapott kérést, így az ügyfél láthatja, hogy a köztes szerverek milyen információkat adnak hozzá vagy módosítanak a kérésben.

CONNECT

Átlátszó TCP/IP - alagúttá alakítja át a kéréskapcsolatot, általában azért, hogy megkönnyítse a biztonságos SSL -kapcsolat létrehozását egy titkosítatlan proxyn keresztül .

Állapotkódok

Az állapotkód a kiszolgáló válaszának első sorának része. Ez egy háromjegyű egész szám [3] . Az első számjegy az állapotosztályt jelöli. A válaszkódot általában egy szóközzel elválasztott magyarázó mondat követi angolul, amely elmagyarázza a személynek, hogy mi a válasz oka. Példák:

201 Weblap létrehozva 403 A hozzáférés csak regisztrált felhasználók számára engedélyezett 507 Elégtelen tárhely

Az ügyfél a válaszkódból értesül a kérésének eredményéről, és meghatározza, hogy milyen lépéseket tegyen ezután. Az állapotkódok készlete szabványos, és leírásuk a vonatkozó RFC dokumentumokban található . Az új kódok bevezetése csak az IETF -fel folytatott konzultációt követően történhet . Előfordulhat, hogy a kliens nem ismeri az összes állapotkódot, de a kódosztálynak megfelelően válaszolnia kell.

Jelenleg az állapotkódok öt osztálya létezik

A kód Osztály Célja
1xx Tájékoztató

(angol tájékoztató )

Információ az átviteli folyamatról.

HTTP/1.0 esetén az ilyen kódokat tartalmazó üzeneteket figyelmen kívül kell hagyni.

HTTP/1.1 esetén a kliensnek fel kell készülnie arra, hogy normál válaszként elfogadja ezt az üzenetosztályt, de semmit sem kell küldenie a szervernek.

Maguk a szervertől érkező üzenetek csak a válasz kezdősorát és szükség esetén néhány válaszspecifikus fejlécmezőt tartalmaznak. A proxyszervereknek az ilyen üzeneteket tovább kell küldeniük a szerverről a kliensnek.

2xx Siker

(angol siker )

Tájékoztatás az ügyfél kérelmének sikeres elfogadásának, feldolgozásának eseteiről. Az állapottól függően a szerver továbbra is elküldheti az üzenet fejléceit és törzsét.
3xx átirányítás

(magyar átirányítás )

Tájékoztatja az ügyfelet, hogy a művelet sikeres befejezéséhez újabb kérést kell benyújtani (általában egy másik URI-n keresztül). Ebből az osztályból öt kód 301, 302, 303, 305és 307közvetlenül utal az átirányításokra (átirányítás). Azt a címet, amelyre a kliensnek kérést kell benyújtania, a szerver jelzi a Location. Ez lehetővé teszi a töredékek használatát a cél URI-ban.
4xx Ügyfél hiba

(angol kliens hiba )

Hibajelzés kliens oldalról. Ha az összes módszert használja, kivéve HEADa kiszolgálót, a kiszolgálónak hiperszöveges magyarázatot kell adnia a felhasználó számára az üzenet törzsében.
5xx szerver hiba

(angol szerverhiba )

Tájékoztatás a szerver hibájából eredő sikertelen működés eseteiről. A módszer használatán kívül minden esetben HEADa szervernek magyarázatot KELL megadnia az üzenet szövegében, amelyet a kliens megjelenít a felhasználónak.

Címek

A HTTP-fejlécek egy HTTP-üzenetben lévő karakterláncok, amelyek kettősponttal elválasztott paraméter-érték párost tartalmaznak .  A fejlécek formátuma követi az ARPA szöveges hálózati üzenetfejlécek általános formátumát (lásd RFC 822 ). A fejléceket legalább egy üres sorral el kell választani az üzenet törzsétől.

Példák fejlécekre:

Szerver: Apache/2.2.11 (Win32) PHP/5.3.0 Utolsó módosítás: 2010. január 16. szombat, 21:16:42 GMT Tartalom típusa: szöveges/sima; charset=windows-1251 Tartalom-Nyelv: en

A fenti példában minden sor egy fejlécet jelent. Ebben az esetben azt, ami a kettőspont előtt van, névnek ( angol  név ), az utána lévőt pedig értéknek ( angol  érték ) nevezzük.

Minden címsor négy fő csoportra oszlik:

  1. Általános fejlécek ("Fő fejlécek") - a kliens és a szerver bármely üzenetében szerepelhetnek;
  2. Kérelemfejlécek ("Kérésfejlécek") – csak ügyfélkérések esetén használatos;
  3. Válaszfejlécek ("Válaszfejlécek") – csak a szervertől érkező válaszokhoz;
  4. Entitásfejlécek ("Az entitás fejlécei") – az üzenet minden entitását kísérik.

Ebben a sorrendben ajánlott a fejléceket elküldeni a címzettnek.

A HTTP működéséhez szükséges összes fejléc az alapvető RFC -kben van leírva . Ha nincs elég meglévő, megadhatja a sajátját. Hagyományosan az ilyen további fejlécek neve elé " X-" kerül, hogy elkerüljük a névütközéseket az esetlegesen meglévő fejlécekkel. Például, mint a fejlécekben X-Powered-Byvagy X-Cache. Egyes fejlesztők saját egyéni előtagjaikat használják. Ilyen fejlécek például a Microsoft által a WebDAVMs-Echo-Request kiterjesztéshez bevezetett fejlécek . Ms-Echo-Reply

Üzenet törzse

A HTTP-üzenet törzse ( message-body), ha van, a kéréshez vagy válaszhoz társított objektumtörzs továbbítására szolgál. Az üzenet törzse csak akkor tér el az objektumtörzstől ( entity-body), ha átviteli kódolást alkalmaznak, amint azt a fejléc mező jelzi Transfer-Encoding.

üzenet-test = entitás-test | <szerint kódolt entitástest átvitel-kódolás>

A mezőt Transfer-Encodingaz alkalmazás által alkalmazott átviteli kódolás jelzésére kell használni, hogy biztosítsák az üzenet biztonságos és helyes továbbítását. A mező Transfer-Encoding egy üzenet tulajdonsága, nem egy objektum, és így a kérés/válasz láncban lévő bármely alkalmazás hozzáadhatja vagy eltávolíthatja.

Az üzenetben lévő üzenettörzs érvényességét szabályozó szabályok eltérőek a kérések és a válaszok esetében.

Az üzenettörzs jelenlétét a kérésben fejlécmező hozzáadásával Content-Lengthvagy a kérés fejléceivel jelzi Transfer-Encoding. Üzenettörzs csak akkor adható hozzá a kéréshez, ha a kérési metódus lehetővé teszi az objektumtörzs használatát.

Az, hogy az üzenettörzs szerepel-e a válaszüzenetben, mind a kérés módszerétől, mind a válasz állapotkódjától függ. A metódussal érkezett kérésekre adott válaszok HEADnem tartalmazhatnak üzenettörzset, még akkor sem, ha az objektum fejlécmezői ( entity-header) jelen vannak, így az objektum jelenléte látható. 1xxA (Informational), 204(Nincs tartalom) és (Not Modified) állapotkóddal rendelkező válaszok 304nem tartalmazhatnak üzenettörzset. Az összes többi válasz üzenettörzset tartalmaz, még akkor is, ha az nulla hosszúságú.

Példák HTTP párbeszédablakra

Rendszeres GET kérés

Ügyfél kérése:

Szerezze be a /wiki/ HTTP/1.1 oldalt Házigazda: en.wikipedia.org Felhasználói ügynök: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Elfogadás: text/html Csatlakozás: zárható (üres sor)

Szerver válasz:

HTTP/1.1 200 OK Dátum: 2009. február 11., szerda, 11:20:59 GMT Szerver: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Utolsó módosítás: 2009. február 11., szerda, 11:20:59 GMT Tartalom-Nyelv: en Tartalom típusa: szöveg/html; charset=utf-8 Tartalom hossza: 1234 Csatlakozás: zárható (üres karakterlánc) (kért oldal HTML -ben )

A válasz ugyanúgy néz ki 203. Ami fontos: a közvetlenül kért adatokat a HTTP fejlécektől a CR , LF , CR, LF használatával választják el.

Átirányítások

Tegyük fel, hogy a fiktív "Example Corp." van egy fő webhely a "http://example.com" címen és egy alias domain "example.org" . Az ügyfél kérelmet küld a „Névjegy” oldalra a másodlagos domainnek (néhány fejléc kimaradt):

Szerezze be a /about.html HTTP/1.1-et Házigazda: example.org Felhasználói ügynök: MyLonelyBrowser/5.0

Mivel az "example.org" domain nem elsődleges domain, és a vállalat a jövőben nem kívánja más célra használni, a szerverük egy kódot küld vissza az állandó átirányításhoz, Locationa fejlécben feltüntetve a cél URL-t:

HTTP/1.x 301 véglegesen áthelyezve Hely: http://example.com/about.html#contacts Dátum: 2009. február 19., csütörtök, 11:08:01 GMT Szerver: Apache/2.2.4 Tartalom típusa: szöveg/html; charset=windows-1251 Tartalom hossza: 110 (üres sor) <html><body><a href="http://example.com/about.html#contacts">Kattintson ide</a></body></html>

A címben Locationmegadhat töredékeket, mint ebben a példában. A böngésző nem adott meg egy töredéket a kérésben, mert a teljes dokumentum érdekli. De automatikusan görgeti az oldalt a "kapcsolatok" töredékig, amint betölti. A válasz törzsébe egy rövid HTML dokumentumot is elhelyeztek egy linkkel, amely a céloldalra viszi a látogatót, ha a böngésző nem navigál oda automatikusan. A cím Content-Typeaz adott HTML-magyarázat jellemzőit tartalmazza, nem a cél URI-n található dokumentumé.

Tegyük fel, hogy ugyanaz a cég "Example Corp." számos regionális irodával rendelkezik szerte a világon. És minden ügynökségnek van egy webhelye a megfelelő ccTLD -vel . Az "example.com" fő webhely kezdőlapkérelme így nézhet ki:

LEGYEN /HTTP/1.1 host: example.com Felhasználói ügynök: MyLonelyBrowser/5.0 Elfogadás: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Charset: windows-1251,utf-8;q=0,7,*;q=0,7

A szerver figyelembe vette a fejlécet, Accept-Languageés ideiglenes átirányítással válaszolt az "example.ru" orosz szerverre , feltüntetve a címét a fejlécben Location:

HTTP/1.x 302 található Helyszín: http://example.ru/ Cache-Control: privát Dátum: 2009. február 19., csütörtök, 11:08:01 GMT Szerver: Apache/2.2.6 Tartalom típusa: szöveg/html; charset=windows-1251 Tartalom hossza: 82 (üres sor) <html><body><a href="http://example.ru">Példa Corp.</a></body></html>

Ügyeljen a fejlécre Cache-Control: a "private" érték azt jelzi a többi szervernek (elsősorban a proxyknak), hogy a válasz csak a kliens oldalon tárolható gyorsítótárban. Ellenkező esetben előfordulhat, hogy a következő látogatók más országokból mindig más képviseletre mennek.

303A válaszkódok (Lásd más) és 307(Ideiglenes átirányítás) is használhatók az átirányításhoz .

Folytatás és töredék letöltés

Tegyük fel, hogy egy fiktív szervezet felajánlja a múltbeli konferencia videójának letöltését a következő webhelyről: „http://example.org/conf-2009.avi” – körülbelül 160 MB méretű . Nézzük meg, hogyan folytatódik ez a fájl hiba esetén, és hogyan szervezné meg a letöltéskezelő több szál több szálú letöltését.

Mindkét esetben az ügyfelek a következőképpen nyújtják be első kérésüket:

GET /conf-2009.avi HTTP/1.0 Házigazda: example.org Elfogad: */* Felhasználói ügynök: Mozilla/4.0 (kompatibilis; MSIE 5.0; Windows 98) Hivatkozó: http://example.org/

A cím Refererazt jelzi, hogy a fájlt az oldal főoldaláról kérték. A letöltéskezelők általában azt is megadják, hogy emulálják az átmenetet a webhely oldaláról. Enélkül a szerver válaszolhat 403(Hozzáférés tiltva), ha más webhelyekről érkező kérések nem engedélyezettek. Esetünkben a szerver sikeres választ adott:

HTTP/1.1 200 OK Dátum: 2009. február 19., csütörtök, 12:27:04 GMT Szerver: Apache/2.2.3 Utolsó módosítás: 2003. június 18., szerda, 16:05:58 GMT Ecímke: "56d-9989200-1132c580" Tartalom típusa: video/x-msvideo Tartalom-hossz: 160993792 Elfogadási tartományok: bájtok Csatlakozás: zárható (üres karakterlánc) (a teljes fájl bináris tartalma)

A fejléc Accept-Rangestájékoztatja a klienst, hogy kérhet töredékeket a szervertől, ha a fájl elejétől bájtban adja meg azok eltolásait. Ha ez a fejléc hiányzik, akkor az ügyfél figyelmeztetheti a felhasználót, hogy a fájl letöltése nagy valószínűséggel meghiúsul.

A fejléc értéke Content-Lengthalapján a letöltéskezelő a teljes kötetet egyenlő részekre osztja, és külön kéri le, több adatfolyamot szervezve. Ha a szerver nem ad meg méretet, akkor a kliens nem tud párhuzamos letöltéseket megvalósítani, de a szerver válaszáig 416(A kért tartomány nem teljesíthető) továbbra is le tudja tölteni a fájlt.

Tegyük fel, hogy a 84. megabájton megszakadt az internetkapcsolat és leállt a letöltés. Amikor az internetkapcsolat helyreállt, a letöltéskezelő automatikusan új kérést küldött a szervernek, de azzal az utasítással, hogy a 84. megabájtból küldje vissza a tartalmat:

GET /conf-2009.avi HTTP/1.0 Házigazda: example.org Elfogad: */* Felhasználói ügynök: Mozilla/4.0 (kompatibilis; MSIE 5.0; Windows 98) Tartomány: bytes=88080384- Hivatkozó: http://example.org/

A szervernek nem kell emlékeznie arra, hogy korábban mire és kitől érkezett kérés, ezért a kliens újra beszúrta a fejlécet Referer, mintha az lenne a legelső kérése. A megadott fejlécérték Rangeazt mondja a szervernek: "Adja meg a tartalmat a 88080384. bájttól a legvégéig." Ezzel kapcsolatban a szerver a következő választ ad vissza:

HTTP/1.1 206 Részleges tartalom Dátum: 2009. február 19., csütörtök, 12:27:08 GMT Szerver: Apache/2.2.3 Utolsó módosítás: 2003. június 18., szerda, 16:05:58 GMT Ecímke: "56d-9989200-1132c580" Elfogadási tartományok: bájtok Tartalomtartomány: bájtok 88080384-160993791/160993792 Tartalom-hossz: 72913408 Csatlakozás: zárható Tartalom típusa: video/x-msvideo (üres karakterlánc) (bináris tartalom 84. megabájttól)

A fejléc Accept-Rangesitt már nem szükséges, mivel a kliens már ismeri ezt a szerver képességet. A töredék átvitelének tényét a kód 206(Résztartalom) tudja az ügyfél számára. A fejléc Content-Rangeinformációkat tartalmaz erről a töredékről: a kezdő és záró bájt számát, a perjel után pedig a teljes fájl teljes méretét bájtokban. Ügyeljen a fejlécre Content-Length - ez jelzi az üzenettörzs méretét, vagyis a továbbított töredéket. Ha a szerver több töredéket ad vissza, akkor Content-Lengthazok teljes mennyiségét tartalmazza.

Most térjen vissza a letöltéskezelőhöz. A "conf-2009.avi" fájl teljes méretének ismeretében a program 10 egyenlő részre osztotta azt.

A kezdeti kezelő a legelső kérésre betöltődik, és megszakítja a kapcsolatot, amint eléri a második kérés kezdetét. A többit külön kérik. Például a 4. szakaszt a következő fejlécekkel kell kérni (néhány fejléc kimaradt – lásd fent a teljes példát):

GET /conf-2009.avi HTTP/1.0 Tartomány: bytes=64397516-80496894

A szerver válasza ebben az esetben a következő lesz (a fejlécek egy része kimarad – lásd a fenti teljes példát):

HTTP/1.1 206 Részleges tartalom Elfogadási tartományok: bájtok Tartalomtartomány: bájtok 64397516-80496894/160993792 Tartalom hossza: 16099379 (üres karakterlánc) (4. rész bináris tartalom)

Ha egy ilyen kérést olyan kiszolgálónak küldenek, amely nem támogatja a töredékeket, akkor az szabványos választ 200(OK) ad vissza, ahogy az elején látható, de fejléc nélkül Accept-Ranges.

Lásd még: részleges GET , bájttartományok , 206. válasz , 416. válasz .

A protokoll alapvető mechanizmusai

Részleges GET-ek

A HTTP lehetővé teszi, hogy ne egyszerre kérje le az erőforrás összes tartalmát, hanem csak a megadott töredéket. Az ilyen kéréseket részlegesnek nevezzük GET; ezek végrehajtásának lehetősége nem kötelező (de kívánatos) a szerverek számára. A részlegesek GETfőként a fájlok folytatásához és a több szálban történő gyors párhuzamos letöltéshez használatosak. Egyes programok letöltik az archívum fejlécét, megjelenítik a felhasználó számára a belső struktúrát, majd töredékeket kérnek a megadott archív elemekkel.

A töredék fogadásához a kliens kérést küld a szervernek egy fejléccel, Rangeamely megadja a szükséges bájttartományokat . Ha a szerver nem érti a részleges kéréseket (figyelmen kívül hagyja a fejlécet Range), akkor az összes tartalmat állapottal adja vissza 200, akárcsak egy normál esetén GET. Sikeres befejezés esetén a kiszolgáló kód helyett 200státuszú 206(Részleges tartalom) választ ad vissza, beleértve a fejlécet is Content-Range. Magukat a töredékeket kétféleképpen lehet továbbítani:

Feltételes GET-ek

A metódus GET"feltételes GET"-re változik, ha a kérésüzenet fejlécmezőt tartalmaz If-Modified-Since. A "feltételes" válaszként GETa kért erőforrás törzse csak akkor kerül elküldésre, ha a fejlécben megadott dátum óta megváltozott If-Modified-Since. Az ennek meghatározására szolgáló algoritmus a következő eseteket tartalmazza:

A "feltételes GET" módszer alkalmazása a hálózat tehermentesítésére irányul, mivel lehetővé teszi a redundáns információk hálózaton keresztüli továbbítását.

Tartalmi egyeztetés

A tartalomegyeztetés egy olyan  mechanizmus, amely automatikusan meghatározza a szükséges erőforrást egy dokumentum több különböző verziója esetén. A tárgyalás tárgyai nem csak a szerver erőforrásai lehetnek, hanem hibaüzeneteket tartalmazó oldalak is ( 403 , 404 stb.).

A megállapodásoknak két fő típusa van:

Mindkét típus használható egyszerre, vagy mindegyik külön-külön.

A fő protokoll specifikáció ( RFC 2616 ) szintén kiemeli az úgynevezett transzparens tárgyalást , mint a két típus preferált kombinációját .  Ez utóbbi mechanizmust nem szabad összetéveszteni a független Transparent Content Negotiation (TCN) technológiával , amely nem része a HTTP protokollnak, de használható vele. Mindkettőnek jelentős különbsége van a működési elvben és az "átlátszó" (átlátszó) szó jelentésében. A HTTP specifikációban az átláthatóság azt jelenti, hogy a folyamat láthatatlan a kliens és a szerver számára, a TCN technológiában pedig az átláthatóság az erőforrás-opciók teljes listájának elérhetőségét jelenti az adatszolgáltatási folyamat minden résztvevője számára.

Szerver által kezelt

Ha egy erőforrásnak több verziója is van, a kiszolgáló elemezni tudja az ügyfél kérésfejléceit, hogy visszaadja a szerinte legjobb verziót. AcceptA , Accept-Charset, Accept-Encodingés címsorok főként elemzésre Accept-Languageskerülnek User-Agent. Kívánatos, hogy a szerver fejlécet adjon a válaszhoz Vary, amely jelzi azokat a paramétereket, amelyek alapján a tartalmat a kért URI megkülönbözteti.

A távoli IP - címből meghatározható a kliens földrajzi elhelyezkedése . Ez annak a ténynek köszönhető, hogy az IP-címek, például a domain nevek , egy adott személyhez vagy szervezethez vannak regisztrálva. Regisztrációkor megadja, hogy a kívánt címteret melyik régióban használja. Ezek az adatok nyilvánosan elérhetők, és az interneten megtalálhatók a megfelelő szabadon terjesztett adatbázisok és kész szoftvermodulok a velük való munkához (a "Geo IP" kulcsszavakra kell összpontosítania).

Emlékeztetni kell arra, hogy ez a módszer a város maximális pontosságával képes meghatározni a helyet (innen határozza meg az országot). Ebben az esetben az információ csak a címtér regisztrálásakor releváns. Például, ha egy moszkvai szolgáltató Moszkvát jelző címtartományt regisztrál, és hozzáférést biztosít az ügyfeleknek a legközelebbi külvárosból, akkor előfizetői bizonyos webhelyeken megfigyelhetik, hogy Moszkvából származnak, nem pedig Krasznogorszkból vagy Dzerzsinszkijből .

A szerver által kezelt egyeztetésnek számos hátránya van:

  • A szerver csak azt feltételezi, hogy melyik opció a legkedvezőbb a végfelhasználó számára, de nem tudja pontosan, hogy jelenleg mire van szükség (például orosz vagy angol nyelvű verzió).
  • Sok az Elfogadás csoportfejléc, de kevés erőforrás több opcióval. Emiatt a berendezés túlterhelt.
  • A megosztott gyorsítótár korlátozott abban, hogy ugyanazt a választ adja ki a különböző felhasználók azonos kéréseire.
  • Az Accept fejlécek átadása bizonyos információkat is felfedhet a preferenciáiról, például a használt nyelvekről, a böngészőről, a kódolásról.
Ügyfél által kezelt

Ebben az esetben a tartalom típusa csak a kliens oldalon kerül meghatározásra. Ehhez a szerver válaszként állapotkóddal 300(Több választási lehetőség) vagy 406(Nem elfogadható) egy opciólistát ad vissza, amelyek közül a felhasználó kiválasztja a megfelelőt. Az ügyfél által kezelt egyeztetés jól működik, ha a tartalom a leggyakoribb módokon (például nyelv és kódolás) különbözik, és nyilvános gyorsítótárat használnak.

A fő hátrány a rezsi, mivel a kívánt tartalom eléréséhez további kérést kell benyújtani.

Átlátható tárgyalás

Ez az egyeztetés teljesen átlátható az ügyfél és a szerver számára. Ebben az esetben egy megosztott gyorsítótárat használnak, amely a lehetőségek listáját tartalmazza, mint az ügyfél által kezelt egyeztetésnél. Ha a gyorsítótár megérti ezeket a lehetőségeket, akkor maga választja meg, mint egy szerver által felügyelt egyeztetés során. Ez csökkenti a kiindulási kiszolgáló terhelését, és kiküszöböli a klienstől érkező további kéréseket.

A HTTP magspecifikáció nem írja le részletesen az átlátható egyeztetési mechanizmust.

Több tartalom

A HTTP protokoll több entitás átvitelét támogatja egyetlen üzeneten belül. Sőt, az entitások nem csak egyszintű sorozatként, hanem egymásba ágyazott elemekből álló hierarchiaként is átvihetők. A médiatípusok több tartalom jelölésére szolgálnak multipart/*. Az ilyen típusokkal való munkavégzés az RFC 2046 -ban leírt általános szabályok szerint történik (hacsak egy adott médiatípus másként nem határozza meg). Ha a vevő nem tudja, hogyan kell dolgozni a típussal, akkor ugyanúgy kezeli, mint a multipart/mixed.

A határparaméter a különböző típusú üzenetek elválasztóját jelenti. Például az űrlapról átadott DestAddress paraméter átadja az e-mail cím értékét, az azt követő AttachedFile1 elem pedig a .jpg kép bináris tartalmát

A szerver oldalon több tartalmú üzenetek is elküldhetők részüzenetekre válaszul, haGET több erőforrás-részletet kérnek. Ebben az esetben a médiatípus kerül felhasználásra multipart/byteranges.

Az ügyféloldalon HTML űrlap beküldésekor a POST. Tipikus példa erre az e- mail beküldési oldalak fájlmellékletekkel. Egy ilyen levél küldésekor a böngésző a következő típusú üzenetet generálja multipart/form-data, amelybe a felhasználó által megadott különálló részekként integrálja a levél tárgyát, a címzett címét, magát a szöveget és a csatolt fájlokat:

POST /send-message.html HTTP/1.1 Gazda: mail.example.com Hivatkozó: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Tartalom-típus: többrészes/forma-adatok; boundary="Asrf456BGe4h" Tartalom-hossz: (teljes hossz, beleértve a gyermekfejléceket) Csatlakozás: életben tartás Maradj életben: 300 (üres karakterlánc) (hiányzó preambulum) --Asrf456BGe4h Tartalom-Dispozíció: forma-adat; name="Célcím" (üres sor) [email protected] --Asrf456BGe4h Tartalom-Dispozíció: forma-adat; name="MessageTitle" (üres sor) neheztelek --Asrf456BGe4h Tartalom-Dispozíció: forma-adat; name="MessageText" (üres sor) Szia Vaszilij! A kedvenc oroszlánod, amit magad mögött hagytál én múlt héten széttéptem az egész kanapémat. Kérjük, mielőbb vedd fel! A mellékelt két kép az utóhatásról. --Asrf456BGe4h Tartalom-Dispozíció: forma-adat; name="AttachedFile1"; filename="horror-photo-1.jpg" Tartalom típusa: kép/jpeg (üres karakterlánc) (az első fotó bináris tartalma) --Asrf456BGe4h Tartalom-Dispozíció: forma-adat; name="AttachedFile2"; filename="horror-photo-2.jpg" Tartalom típusa: kép/jpeg (üres karakterlánc) (a második fénykép bináris tartalma) --Asrf456BGe4h-- (hiányzik az epilógus)

A fejlécekben található példában a Content-Dispositionparaméter namemegegyezik namea HTML címkék attribútumával <INPUT>és a <TEXTAREA>. A paraméter filenamemegegyezik a felhasználó számítógépén lévő eredeti fájlnévvel. Lásd az RFC 1867 dokumentumot a HTML űrlap létrehozásával és a fájlcsatolással kapcsolatos további információkért .

Fejlesztési előzmények

HTTP/0.9 A HTTP-t 1991 márciusában javasolta Tim Berners-Lee , akkoriban a CERN -ben, mint olyan mechanizmust, amellyel az interneten lehet dokumentumokat elérni, és a hipertext használatával megkönnyíteni a navigációt . A HTTP/0.9 protokoll legkorábbi verziója először 1992 januárjában jelent meg (bár a megvalósítás 1990 - ig nyúlik vissza ). A protokoll specifikációja a HTTP-kliensek és -kiszolgálók közötti interakció szabályainak egyszerűsítéséhez, valamint a két összetevő funkcióinak egyértelmű elkülönítéséhez vezetett. A fő szintaktikai és szemantikai rendelkezéseket dokumentálták. HTTP/1.0 1996 májusában a HTTP gyakorlati megvalósítására kiadták az RFC 1945 -öt , amely a HTTP/1.0 legtöbb összetevőjének megvalósításához adta az alapot. HTTP/1.1 A protokoll modern változata; 1999 júniusában fogadták el [4] . Ebben a kiadásban újdonság volt a „perzisztens kapcsolat” mód: a TCP - kapcsolat nyitva maradhat a kérésre adott válasz elküldése után is, így több kérés is elküldhető ugyanazon a kapcsolaton. Az ügyfélnek mostantól információt kell küldenie az általa elért gazdagép nevéről , ami lehetővé tette a megosztott tárhely egyszerűbb megszervezését . HTTP/2 2015. február 11- én megjelentek a jegyzőkönyv következő változatának tervezetének végleges változatai. A korábbi verziókkal ellentétben a HTTP/2 protokoll bináris . A legfontosabb jellemzők közé tartozik a kérések multiplexelése , a kérések prioritása, a fejléctömörítés, több elem párhuzamos betöltése egyetlen TCP -kapcsolaton keresztül, a proaktív szerveroldali push értesítések támogatása [5] . HTTP/3 A HTTP/3 a HTTP/2 [6] [7]  javasolt utódja, amely már használatban van a weben , TCP helyett UDP -n, mint átviteli protokollon. A HTTP/2-höz hasonlóan nem szünteti meg a protokoll korábbi főbb verzióit. A HTTP/3 támogatást 2019 szeptemberében adták hozzá a Cloudflare -hez és a Google Chrome -hoz [8] [9] , és a Chrome és a Firefox stabil verzióiban [10] engedélyezhető .

Lásd még

Jegyzetek

  1. ↑ A HTTP forgalom először meghaladta a P2P-t , 2007. december 22-én archiválva a Wayback Machine -nél // Compulenta, 2007. június 22. ( Fehér dokumentum az Ellacoya Networkstől , 2007. június 22-én archivált a Wayback Machine -nél ).
  2. ↑ 1 2 HTTP/1.1: Method Definitions  (angol)  (lefelé irányuló kapcsolat) . Archiválva az eredetiből 2012. június 23-án.
  3. ↑ Lásd az RFC 2068 " 6.1.1 Állapotkód és okkifejezés " szakasz első mondatát. A 40. oldalon található egy kiterjesztett BNF nyilatkozat is .) " extension-code = 3DIGIT" a kiterjesztési kódokhoz.
  4. ↑ A HTTP/1.1 specifikációt először 1997 januárjában tették közzé RFC 2068 -ban ; az RFC 2616 modern verziójában javították az elírásokat, helyenként javítottak a terminológián és a formázáson. Tisztázta továbbá a kliens (böngésző), a szerver és a proxyszerverek elfogadható viselkedését bizonyos kérdéses helyzetekben. Vagyis az 1.1-es verzió végül is 1997-ben jelent meg.
  5. ↑ HTTP/2 piszkozat . Letöltve: 2015. február 25. Az eredetiből archiválva : 2015. február 20..
  6. ↑ Bishop, Mike Hypertext Transfer Protocol 3. verzió (HTTP/3  ) . tools.ietf.org (2019. július 9.). Letöltve: 2019. augusztus 16. Az eredetiből archiválva : 2019. augusztus 31.
  7. ↑ Cimpanu, Catalin . HTTP-over-QUIC átnevezése HTTP/3 | ZDNet  (angol) , ZDNet . Az eredetiből archiválva : 2018. november 13. Letöltve: 2020. augusztus 10.
  8. ↑ A Cimpanu, a Catalin Cloudflare, a Google Chrome és a Firefox HTTP/3 támogatást ad hozzá . ZDNet (2019. szeptember 26.). Letöltve: 2019. szeptember 27. Az eredetiből archiválva : 2019. szeptember 26..
  9. ↑ HTTP/3: a múlt, a jelen és a  jövő . A Cloudflare blog (2019. szeptember 26.). Letöltve: 2019. október 30. Az eredetiből archiválva : 2019. szeptember 26..
  10. ↑ A Firefox Nightly támogatja a HTTP 3 - Általános - Cloudflare közösséget (2019. november 19.). Letöltve: 2020. január 23. Az eredetiből archiválva : 2020. június 6.

Linkek

 URI- sémák
Hivatalos
nem hivatalos
 szemantikus web
Alapok
alszakaszok
Alkalmazások
Kapcsolódó témák
Szabványok
  • Előzmények : Egyszerű régi szemantikus HTML
  • DAML+OLAJ
 http
Általános fogalmak
Mód
Címek
Állapotkódok