1 Vvedenie.

1.1 Cel'.

Protokol peredachi Giperteksta (HTTP) - protokol prikladnogo urovnya dlya raspredelennyh, sovmestnyh, mnogosrednyh informacionnyh sistem. HTTP ispol'zuetsya v World Wide Web (WWW) nachinaya s 1990 goda. Pervoj versiej HTTP, izvestnoj kak HTTP/0.9, byl prostoj protokol dlya peredachi neobrabotannyh dannyh cherez Internet. HTTP/1.0, kak opredeleno v RFC 1945 [6], byl uluchsheniem etogo protokola, pozvolyaya soobshcheniyam imet' MIME-podobnyj format, soderzhashchij metainformaciyu o peredavaemyh dannyh i imel modificirovannuyu semantiku zaprosov/otvetov. Odnako, HTTP/1.0 nedostatochno horosho uchityval osobennosti raboty s ierarhicheskimi proksi-serverami (hierarchical proxies), keshirovaniem, postoyannymi soedineniyami, i virtual'nymi hostami (virtual hosts). Krome togo, bystroe uvelichenie ne polnost'yu sovmestimyh prilozhenij, nazyvayushchih tot protokol, kotoryj oni ispol'zovali "HTTP/1.0", potrebovalo vvedeniya versii protokola, v kotoroj byli by zalozheny vozmozhnosti, pozvolyayushchie prilozheniyam opredelyat' istinnye vozmozhnosti drug druga.

|ta specifikaciya opredelyaet protokol "HTTP/1.1". |tot protokol soderzhit bolee strogie trebovaniya, chem HTTP/1.0, garantiruyushchie nadezhnuyu realizaciyu vozmozhnostej.

Prakticheski informacionnye sistemy trebuyut bol'shej funkcional'nosti, chem prosto zagruzku informacii, vklyuchaya poisk, modifikaciyu pri pomoshchi vneshnego interfejsa, i annotaciyu (annotation). HTTP predostavlyaet otkrytyj nabor metodov, kotorye ukazyvayut cel' zaprosa. Oni osnovany na discipline ssylki, obespechennoj Universal'nym Identifikatorom Resursa (URI) [3] [20], kak raspolozhenie (URL) [4] ili imya (URN), dlya identifikacii resursa, k kotoromu etot metod primenyaetsya. Soobshcheniya peredayutsya v formate, podobnom ispol'zuemomu elektronnoj pochtoj, kak opredeleno Mnogocelevymi Rasshireniyami |lektronnoj Pochty (MIME).

HTTP takzhe ispol'zuetsya kak obobshchennyj protokol svyazi mezhdu agentami pol'zovatelej i proksi-serverami/shlyuzami (proxies/gateways) ili drugimi servisami Interneta, vklyuchaya takie, kak SMTP [16], NNTP [13], FTP [18], Gopher [2], i WAIS [10]. Takim obrazom, HTTP zakladyvaet osnovy mnogosrednogo (hypermedia) dostupa k resursam dlya raznoobraznyh prilozhenij.

1.2 Trebovaniya.

|ta specifikaciya ispol'zuet te zhe samye slova dlya opredeleniya trebovanij k realizacii protokola, chto i RFC 1123 [8]. |ti slova sleduyushchie:

NEOBHODIMO, DOLZHEN (MUST): Primenyaetsya dlya ukazaniya, chto dannoe trebovanie specifikacii neobhodimo obespechit' v lyubom sluchae.
REKOMENDUETSYA, SLEDUET (SHOULD): Ispol'zuetsya dlya ukazaniya, chto dannoe trebovanie specifikacii dolzhno byt' obespecheno, esli etomu ne prepyatstvuyut ser'eznye prichiny.
VOZMOZHNO, MOZHET (MAY): Ispol'zuetsya dlya ukazaniya, chto dannoe trebovanie specifikacii yavlyaetsya opcional'nym i mozhet byt' libo realizovano, libo net - po neobhodimosti.

Realizaciya schitaetsya nesovmestimoj, esli narusheno hotya by odno NEOBHODIMYH trebovanij specifikacii protokola. Realizaciya, udovletvoryayushchaya vsem NEOBHODIMYM i REKOMENDUEMYM tredovaniyam nazyvaetsya polnost'yu sovmestimoj, a udovletvoryayushchaya vsem NEOBHODIMYM, no ne vsem REKOMENDUEMYM trebovaniyam nazyvaetsya uslovno sovmestimoj.

1.3 Terminologiya.

|ta specifikaciya ispol'zuet ryad terminov dlya opisaniya roli uchastnikov, nekotoryh ob®ektov, i HTTP svyazi.

Soedinenie (connection): Virtual'nyj kanal transportogo urovnya, ustanovlennyj mezhdu dvumya programmami s cel'yu svyazi.
Soobshchenie (message): Osnovnoj modul' HTTP svyazi, sostoyashchej iz strukturnoj posledovatel'nosti oktetov, sootvetstvuyushchih sintaksisu, opredelennomu v razdele 4 i peredavaemyh po soedineniyu.
Zapros (request): Lyuboe HTTP soobshchenie, soderzhashchee zapros, opredelyaemyj v razdele 5.
Otvet (response): Lyuboe HTTP soobshchenie, soderzhashchee otvet, opredelyaemyj v razdele 5.
Resurs (resource): Setevoj ob®ekt dannyh ili servis, kotoryj mozhet byt' identificirovan URI, opredelelyaemym v razdele 3.2. Resursy mogut byt' dostupny v neskol'kih predstavleniyah (naprimer na neskol'kih yazykah, v raznyh formatah dannyh, imet' razlichnyj razmer, imet' razlichnuyu razreshayushchuyu sposobnost') ili razlichat'sya po drugim parametram.
Ob®ekt (entity): Informaciya, peredavaemaya v kachestve poleznoj nagruzki zaprosa ili otveta. Ob®ekt sostoit iz metainformacii v forme polej zagolovka ob®ekta i soderzhaniya v forme tela ob®ekta, kak opisano v razdele 7.
Predstavlenie (representation): Ob®ekt vklyuchennyj v otvet, i podchinyayushchijsya obsuzhdeniyu soderzhimogo (Content Negotiation), chto opisano v razdele 12. Mozhet sushchestvovat' neskol'ko predstavlenij, svyazannyh so specificheskimi sostoyaniyami otveta.
Obsuzhdenie soderzhimogo (content negotiation): Mehanizm dlya vybora sootvetstvuyushchego predstavleniya vo vremya obsluzhivaniya zaprosa, kak opisano v razdele 12. Predstavlenie ob®ektov v lyubom otvete mozhet byt' obsuzhdeno (vklyuchaya oshibochnye otvety).
Variant (variant): Resurs mozhet imet' odno, ili neskol'ko predstavlenij, svyazannyh s nim v dannyj moment. Kazhdoe iz etih predstavlenij nazyvaetsya "variant". Ispol'zovanie termina "variant" ne obyazatel'no podrazumevaet, chto resurs podchinen obsuzhdeniyu soderzhimogo.
Klient (client): Programma, kotoraya ustanavlivaet soedineniya s cel'yu posylki zaprosov.
Agent pol'zovatelya (user agent): Klient, kotoryj iniciiruet zapros. Kak pravilo brauzery, redaktory, roboty (spiders), ili drugie instrumental'nye sredstva pol'zovatelya.
Server (server): Prilozhenie, kotoroe slushaet soedineniya, prinimaet zaprosy na obsluzhivanie i posylaet otvety. Lyubaya takaya programma sposobna byt' kak klientom, tak i serverom; nashe ispol'zovanie dannogo termina otnositsya skoree k roli, kotoruyu programma vypolnyaet, sozdavaya specificheskie soedineniya, nezheli k vozmozhnostyam programmy voobshche. Analogichno, lyuboj server mozhet dejstvovat' kak pervonachal'nyj server, proksi-server, shlyuz, ili tunnel' (tunnel), izmenyaya povedenie, osnovyvayas' na haraktere kazhdogo zaprosa.
Pervonachal'nyj server (origin server): Server, na kotorom dannyj resurs postoyanno nahoditsya ili dolzhen byt' sozdan.
Proksi-server (proxy): Programma-posrednik, kotoraya dejstvuet i kak server, i kak klient s cel'yu sozdaniya zaprosov ot imeni drugih klientov. Zaprosy obsluzhivayutsya proksi-serverom, ili peredayutsya im, vozmozhno s izmeneniyami. Proksi-server dolzhen udovletvoryat' trebovaniyam klienta i servera, soglasno etoj specifikacii.
SHlyuz (gateway): Server, kotoryj dejstvuet kak posrednik dlya nekotorogo drugogo servera. V otlichie ot proksi-servera, shlyuz poluchaet zaprosy v kachestve pervonachal'nogo servera dlya zaproshennogo resursa; klient zaprosa mozhet ne znat', chto on soedinyaetsya so shlyuzom.
Tunnel' (tunnel): Programma-posrednik, kotoraya podderzhivaet soedinenie. Odin raz sozdannyj, tunnel' ne rassmatrivaetsya kak chast' HTTP svyazi, hotya tunnel', vozmozhno, byl inicializirovan zaprosom HTTP. Tunnel' prekrashchaet sushchestvovat', kogda oba konca soedineniya zakryvayutsya.
Kesh (cache): Lokal'naya pamyat', v kotoroj programma hranit soobshcheniya otvetov, i v kotoroj raspolagaetsya podsistema, upravlyayushchaya hraneniem, poiskom i stiraniem soobshchenij. Kesh sohranyaet otvety, kotorye mogut byt' sohraneny, chtoby umen'shit' vremya otveta i zagruzku seti (traffik) pri budushchih ekvivalentnyh zaprosah. Lyuboj klient ili server mozhet imet' kesh, no kesh ne mozhet ispol'zovat'sya serverom, kotoryj dejstvuet kak tunnel'.
Keshiruemyj (cachable): Otvet yavlyaetsya keshiruemym, esli keshu razresheno sohranit' kopiyu otvetnogo soobshcheniya dlya ispol'zovaniya pri otvete na posleduyushchie zaprosy. Pravila dlya opredeleniya keshiruemosti HTTP otvetov opredeleny v razdele 13. Dazhe esli resurs keshiruem, mogut sushchestvovat' dopolnitel'nye ogranicheniya na ispol'zovanie keshem sohranennoj kopii dlya shodnogo zaprosa.
Neposredstvennyj (first-hand): Otvet schitaetsya neposredstvennym, esli on prihodit neposredstvenno ot pervonachal'nogo servera bez nenuzhnoj zaderzhki, vozmozhno cherez odin ili neskol'ko proksi-serverov. Otvet takzhe yavlyaetsya neposredstvennym, esli ego pravil'nost' tol'ko chto byla proverena neposredstvenno pervonachal'nym serverom.
Tochnoe vremya ustarevaniya (explicit expiration time): Vremya, opredelennoe pervonachal'nym serverom i pokazyvayushchee keshu, kogda ob®ekt bol'she ne mozhet byt' vozvrashchen keshem klientu bez dopolnitel'noj proverki pravil'nosti.
|vristicheskoe vremya ustarevaniya (heuristic expiration time): Vremya ustarevaniya, naznachennoe keshem, esli ne ukazano tochnoe vremya ustarevaniya.
Vozrast (age): Vozrast otveta - vremya, proshedshee s momenta otsylki, ili uspeshnoj proverki otveta pervonachal'nym serverom.
Vremya zhizni (freshness lifetime): Otrezok vremeni mezhdu porozhdeniem otveta i vremenem ustarevaniya.
Svezhij (fresh): Otvet schitaetsya svezhim, esli ego vozrast eshche ne prevysil vremya zhizni.
Prosrochennnyj (stale): Otvet schitaetsya prosrochennym, esli ego vozrast prevysil vremya zhizni.
Semanticheski prozrachnyj (semantically transparent): Govoryat, chto kesh vedet sebya "semanticheski prozrachnym" obrazom v otnoshenii specificheskogo otveta, kogda ispol'zovanie kesha ne vliyaet ni na klienta zaprosa, ni na pervonachal'nyj server, no povyshaet effektivnost'. Kogda kesh semanticheski prozrachen, klient poluchaet tochno takoj zhe otvet (za isklyucheniem promezhutochnyh (hop-by-hop) zagolovkov), kotoryj poluchil by, zaprashivaya neposredstvenno pervonachal'nyj server, a ne kesh.
Ukazatel' pravil'nosti (validator): |lement protokola (naprimer, metka ob®ekta ili vremya poslednej modifikacii (Last-Modified time)), kotoryj ispol'zuetsya, chtoby vyyasnit', yavlyaetsya li nahodyashchayasya v keshe kopiya ekvivalentom ob®ekta.

1.4 Obshchee opisanie.

Protokol HTTP - eto protokol zaprosov/otvetov. Klient posylaet serveru zapros, soderzhashchij metod zaprosa, URI, versiyu protokola, MIME-podobnoe soobshchenie, soderzhashchee modifikatory zaprosa, klientskuyu informaciyu, i, vozmozhno, telo zaprosa, po soedineniyu. Server otvechaet strokoj sostoyaniya, vklyuchayushchej versiyu protokola soobshcheniya, kod uspeshnogo vypolneniya ili kod oshibki, MIME-podobnoe soobshchenie, soderzhashchee informaciyu o servere, metainformaciyu ob®ekta, i, vozmozhno, telo ob®ekta. Svyaz' mezhdu HTTP i MIME opisana v prilozhenii 19.4.

Bol'shinstvo HTTP soedinenij inicializiruetsya agentom pol'zovatelya i sostoit iz zaprosa, kotoryj nuzhno primenit' k resursu na nekotorom pervonachal'nom servere. V samom prostom sluchae, on mozhet byt' vypolnen posredstvom odinochnogo soedineniya (v) mezhdu agentom pol'zovatelya (UA) i pervonachal'nym serverom (O).

             cepochka zaprosov --------------------->
          UA -------------------v------------------- O
             <----------------------- cepochka otvetov

Bolee slozhnaya situaciya voznikaet, kogda v cepochke zaprosov/otvetov prisutstvuet odin ili neskol'ko posrednikov. Sushchestvuyut tri osnovnyh raznovidnosti posrednikov: proksi-servera, shlyuzy, i tunneli. Proksi-server yavlyaetsya agentom-posrednikom, kotoryj poluchaet zaprosy na nekotoryj URI v absolyutnoj forme, izmenyaet vse soobshchenie ili ego chast', i otsylaet izmenennyj zapros serveru, identificirovannomu URI. SHlyuz - eto prinimayushchij agent, dejstvuyushchij kak by uroven' vyshe nekotorogo drugogo servera(ov) i, v sluchae neobhodimosti, transliruyushchij zaprosy v protokol osnovnogo servera. Tunnel' dejstvuet kak rele mezhdu dvumya soedineniyami ne izmenyaya soobshcheniya; tunneli ispol'zuyutsya, kogda svyaz' nuzhno proizvodit' cherez posrednika (naprimer Firewall), kotoryj ne ponimaet soderzhanie soobshchenij.

             cepochka zaprosov ----------------------------------->
          UA -----v----- A -----v----- B -----v----- C -----v----- O
             <------------------------------------ cepochka otvetov

Na poslednem risunke pokazany tri posrednika (A, B, i C) mezhdu agentom pol'zovatelya i pervonachal'nym serverom. Zaprosy i otvety peredayutsya cherez chetyre otdel'nyh soedineniya. |to razlichie vazhno, tak kak nekotorye opcii HTTP soedineniya primenimy tol'ko k soedineniyu s blizhajshim ne tunnel'nym sosedom, nekotorye tol'ko k konechnym tochkam cepochki, a nekotorye ko vsem soedineniyam v cepochke. Hotya diagramma linejna, kazhdyj uchastnik mozhet byt' zadejstvovan v neskol'kih soedineniyah odnovremenno. Naprimer, B mozhet poluchat' zaprosy ot drugih klientov, a ne tol'ko ot A, i/ili peresylat' zaprosy k serveram, otlichnym ot C, v to zhe vremya, kogda on obrabatyvaet zapros ot A.

Lyubaya storona soedineniya, kotoraya ne dejstvuet kak tunnel', mozhet ispol'zovat' vnutrennij kesh dlya obrabotki zaprosov. |ffekt kesha zaklyuchaetsya v tom, chto cepochka zaprosov/otvetov sokrashchaetsya, esli odin iz uchastnikov v cepochke imeet keshirovannyj otvet, primenimyj k dannomu zaprosu. Dalee illyustriruetsya cepochka, voznikayushchaya v rezul'tate togo, chto B imeet keshirovanuyu kopiyu rannego otveta O (polechennogo cherez C) dlya zaprosa, i kotoryj ne keshirovalsya ni UA, ni A.

             cepochka zaprosov ------->
          UA -----v----- A -----v----- B - - - - - - C - - - - - - O
             <-------- cepochka otvetov

Ne vse otvety polezno keshirovat', a nekotorye zaprosy mogut soderzhat' modifikatory, kotorye vklyuchayut special'nye trebovaniya, upravlyayushchie povedeniem kesha. Trebovaniya HTTP dlya povedeniya kesha v otnoshenii keshiruemyh otvetov opredeleny v razdele 13.

Fakticheski, imeetsya shirokoe raznoobrazie arhitektur i konfiguracij keshej i proksi-serverov, v nastoyashchee vremya razrabatyvaemyh ili razvernutyh v World Wide Web; eti sistemy vklyuchayut nacional'nye ierarhii proksi-keshej, kotorye sohranyayut propusknuyu sposobnost' mezhokeanskih kanalov, sistemy, kotorye rasprostranyayut vo mnogo mest soderzhimoe kesha, organizacii, kotorye rasprostranyayut podmnozhestva keshiruemyh dannyh na CD-ROM, i tak dalee. HTTP sistemy ispol'zuyutsya v korporativnyh intranet-setyah s vysokoskorostnymi liniyami svyazi, i dlya dostupa cherez PDA s malomoshchnymi liniyami i neustojchivoj svyazi. Cel' HTTP/1.1 sostoit v podderzhanii shirokogo mnogoobraziya konfiguracij, uzhe postroennyh pri vvedenii rannih versij protokola, a takzhe v udovletvorenii potrebnostej razrabotchikov web prilozhenij, trebuyushchih vysokoj nadezhnosti, po krajnej mere nadezhnyh otnositel'no indikacii otkaza.

HTTP soedinenie obychno proishodit posredstvom TCP/IP soedinenij. Zadannyj po umolchaniyu port TCP - 80, no mogut ispol'zovat'sya i drugie porty. HTTP takzhe mozhet byt' realizovan posredstvom lyubogo drugogo protokola Interneta, ili drugih setej. HTTP neobhodima tol'ko nadezhnaya peredacha dannyh, sledovatel'no mozhet ispol'zovat'sya lyuboj protokol, kotoryj garantiruet nadezhnuyu peredachu dannyh; otobrazhenie struktury zaprosa i otveta HTTP/1.1 na transportnye moduli dannyh rassmatrivaemogo protokola - vopros, ne reshaemyj etoj specifikaciej.

Bol'shinstvo realizacij HTTP/1.0 ispol'zovalo novoe soedinenie dlya kazhdogo obmena zaprosom/otvetom. V HTTP/1.1, ustanovlennoe soedinenie mozhet ispol'zovat'sya dlya odnogo ili neskol'kih obmenov zaprosom/otvetom, hotya soedinenie mozhet byt' zakryto po ryadu prichin (smotrite razdel 8.1).