8 Soedineniya (Connections).

8.1 Postoyannye soedineniya (Persistent Connections).

8.1.1 Cel'.

Do postoyannyh soedinenij dlya zaprosa kazhdogo URL ustanavlivalos' otdel'noe TCP soedinenie, chto uvelichivalo nagruzku na HTTP servera i vyzyvalo zagruzku Interneta. Ispol'zovanie vstroennyh izobrazhenij i drugih svyazannyh dannyh chasto trebuet ot klienta delat' neskol'ko zaprosov k odnomu serveru za korotkij promezhutok vremeni. Issledovaniya problem effektivnosti takogo resheniya dostupny v [30][27]; analiz i rezul'taty realizacii prototipa nahodyatsya v [26].

Postoyannye HTTP soedineniya imeyut ryad preimushchestv:

Otkrytie i zakrytie men'shego kolichestva TCP soedinenij ekonomit vremya central'nogo processora i pamyat', ispol'zuemuyu dlya upravlyayushchih blokov protokola TCP.
HTTP zaprosy i otvety mozhet byt' konvejerizovany v soedinenii. Konvejernaya obrabotka pozvolyaet klientu delat' mnozhestvo zaprosov ne ozhidaya otveta na kazhdyj, sledovatel'no, odinochnoe TCP soedinenie, ispol'zovanie kotorogo namnogo bolee effektivno, teryaet men'she vremeni.
Zagruzka seti umen'shaetsya s umen'sheniem chisla paketov, vyzvannyh otkrytiem TCP soedinenij, i, sledovatel'no, daet protokolu TCP dostatochnoe vremya dlya opredeleniya sostoyaniya zagruzki seti.
HTTP mozhet razvivat'sya bolee elegantno; tak kak oshibki mogut soobshchat'sya bez zakrytiya TCP soedineniya v kachestve shtrafa. Klienty, ispol'zuyushchie budushchie versii HTTP mogli by optimistichno probovat' novye vozmozhnosti, no pri svyazi so starym serverom, povtoryat' zapros, ispol'zuya staruyu semantiku posle soobshcheniya ob oshibke.

HTTP realizaciyam SLEDUET realizovyvat' postoyannye soedineniya.

8.1.2 Obshchee opisanie.

Znachitel'noe otlichie HTTP/1.1 ot bolee rannih versij HTTP sostoit v tom, chto postoyannye soedineniya yavlyayutsya zadannym po umolchaniyu povedeniem lyubogo HTTP soedineniya. To est' esli ne oboznacheno inogo, klient mozhet schitat', chto server podderzhit postoyannoe soedinenie.

Postoyannye soedineniya obespechivayut mehanizm, soglasno kotoromu klient i server mogut soobshchit' o razryve TCP soedineniya. |to signaliziruetsya pri pomoshchi ispol'zovaniya polya zagolovka Connection. Pri poluchenii soobshcheniya o razryve soedineniya klient NE DOLZHEN posylat' bol'she zaprosov po etomu soedineniyu.

8.1.2.1 Obsuzhdenie (Negotiation).

HTTP/1.1 server MOZHET schitat', chto HTTP/1.1 klient ne predpolagaet podderzhivat' postoyannoe soedinenie, esli poslannyj v zaprose zagolovok Connection soderzhit leksemu soedineniya (connection-token) "close". Esli server reshaet zakryt' soedinenie nemedlenno posle posylki otveta, to emu SLEDUET poslat' zagolovok Connection, kotoryj soderzhit leksemu soedineniya (connection-token) "close".

HTTP/1.1 klient MOZHET ozhidat', chto soedinenie ostanetsya otkrytym, no dolzhen reshit' ostavlyat' li ego otkrytym na osnovanii togo, soderzhit li otvet servera zagolovok Connection s leksemoj soedineniya "close". V sluchae, esli klient ne hochet podderzhivat' soedinenie dlya posleduyushchih zaprosov, emu SLEDUET poslat' zagolovok Connection, soderzhashchij leksemu soedineniya "close".

Esli klient ili server posylaet leksemu zakrytiya soedineniya "close" v zagolovke Connection, to zapros stanovitsya poslednim v soedinenii.

Klientam i serveram NE SLEDUET schitat', chto postoyannoe soedinenie podderzhivaetsya HTTP versiyami, men'shimi chem 1.1, esli eto ne ukazano yavno. Smotrite razdel 19.7.1 s bolee podrobnoj informaciej o obratnoj sovmestimosti s HTTP/1.0 klientami.

CHtoby soedinenie ostavalos' postoyannym, vse soobshcheniya, peredavaemye po nemu dolzhny imet' samoopredelennuyu (self-defined) dlinu soobshcheniya (to est', ne opredelyaemuyu zakrytiem soedineniya), kak opisano v razdele 4.4.

8.1.2.2 Konvejernaya obrabotka (Pipelining).

Klient, kotoryj podderzhivaet postoyannye soedineniya MOZHET "proizvesti konvejernuyu obrabotku" zaprosov (to est', posylat' neskol'ko zaprosov ne ozhidaya otveta na kazhdyj). Server DOLZHEN poslat' otvety na eti zaprosy v tom zhe samom poryadke, v kakom byli polucheny zaprosy.

Klienty, kotorye podderzhivayut postoyannye soedineniya i proizvodyat konvejernuyu obrabotku nemedlenno posle ustanovleniya soedineniya, DOLZHNY byt' gotovy povtorit' soedinenie, esli pervaya popytka konvejernoj obrabotki dala sboj. Esli klient delaet takoj povtor, on NE DOLZHEN proizvodit' konvejernuyu obrabotku prezhde, chem uznaet, chto soedinenie postoyannoe. Klienty DOLZHNY takzhe byt' gotovy snova poslat' zaprosy, esli server zakryvaet soedinenie pered posylkoj vseh sootvetstvuyushchih otvetov.

8.1.3 Proksi-servera (Proxy Servers).

Ochen' vazhno, chtoby proksi-servera pravil'no vypolnyali svojstva polej zagolovka Connection, kak opredeleno v 14.2.1.

Proksi-server DOLZHEN soobshchat' o postoyannyh soedineniyah otdel'no svoim klientam i otdel'no pervonachal'nym serveram (ili drugim proksi-serveram), kotorye s nim soedineny. Kazhdoe postoyannoe soedinenie primenyaetsya tol'ko k odnoj transportnoj svyazi.

Proksi-server NE DOLZHEN ustanavlivat' postoyannoe soedinenie s HTTP/1.0 klientom.

8.1.4 Prakticheskie coglasheniya (Practical Considerations).

Servera obychno imeyut nekotoroe znachenie vremeni ozhidaniya, posle kotorogo oni ne podderzhivayut neaktivnoe soedinenie. Proksi-servera mogut delat' eto znachenie bolee vysokim, tak kak, veroyatno, klient sdelaet bol'shee kolichestvo soedinenij cherez etot zhe server. Ispol'zovanie postoyannyh soedinenij ne vvodit nikakih ogranichenij na prodolzhitel'nost' etogo vremeni ozhidaniya kak dlya klienta, tak i dlya servera.

Kogda u klienta ili servera isteklo vremya ozhidaniya, emu SLEDUET proizvesti izyashchnoe zakrytie transportnogo soedineniya. Kak klientam, tak i serveram SLEDUET postoyanno nablyudat' za drugoj storonoj na predmet zakrytiya soedineniya, i sootvetstvenno otvechat'. Esli klient ili server ne obnaruzhivaet zakrytiya soedineniya drugoj storonoj srazu, to eto vyzyvaet ne opravdannuyu tratu resursov seti.

Klient, server, ili proksi-server MOGUT zakryt' transportnoe soedinenie v lyuboe vremya. Naprimer, klient MOZHET nachat' posylat' novyj zapros v to vremya, kogda server reshaet zakryt' "bezdejstvuyushchee" soedinenie. S tochki zreniya servera, soedinenie zakryvaetsya, v to vremya kak ono bylo neaktivno, no s tochki zreniya klienta, zapros proizoshel.

|to oznachaet, chto klienty, servery, i proksi-servery DOLZHNY byt' v sostoyanii obrabatyvat' asinhronnye sobytiya zakrytiya. Programmnomu obespecheniyu klienta SLEDUET vnov' otkryt' transportnoe soedinenie i povtorno peredat' prervannyj zapros bez vzaimodejstviya s pol'zovatelem, poskol'ku metod zaprosa idempotent (smotrite razdel 9.1.2); drugie metody NE DOLZHNY byt' povtoreny avtomaticheski, hotya agenty pol'zovatelya MOGUT predlozhit' operatoru vybor povtoryat' zapros, ili net.

Odnako eto avtomaticheskoe povtorenie NE SLEDUET proizvodit', esli sboj proishodit uzhe vo vtorom zaprose.

Serveram vsegda SLEDUET otvechat' na po krajnej mere na odin zapros v soedinenii, esli eto vozmozhno. Serveram NE SLEDUET razryvat' soedinenie v seredine peredachi otveta, esli ne predpolagaetsya setevoj ili klientskij otkaz.

Klientam, ispol'zuyushchim postoyannye soedineniya, SLEDUET ogranichit' chislo odnovremennyh soedinenij, kotorye oni ustanavlivayut s dannym serverom. Odnopol'zovatel'skomu klientu SLEDUET ustanavlivat' maksimum 2 soedineniya s lyubym serverom ili proksi-serverom. Proksi-serveru SLEDUET ogranichit'sya 2*N soedinenimi s drugimi serverami ili proksi-serverami, gde N - chislo odnovremenno aktivnyh pol'zovatelej. |ti rukovodyashchie principy prednaznacheny dlya umen'sheniya vremeni HTTP otveta i izbezhaniya chrezmernoj zagruzki Interneta ili drugih setej.

8.2 Trebovaniya k peredache soobshchenij.

Obshchie trebovaniya:

HTTP/1.1 serveram SLEDUET podderzhivat' postoyannye soedineniya i ispol'zovat' mehanizmy upravleniya potokom dannyh TCP v celyah umen'sheniya vremennyh peregruzok, vmesto zakrytiya soedinenij, kotorye, kak ozhidaetsya, mogut byt' povtorno ispol'zovany klientami. Poslednyaya metodika mozhet usilivat' setevuyu zagruzku.
HTTP/1.1 (ili bolee pozdnim) klientam, posylayushchim telo soobshcheniya (message-body) SLEDUET kontrolirovat' setevoe soedinenie na predmet oshibok vo vremya peredachi zaprosa. Esli klient obnaruzhivaet oshibku, emu SLEDUET nemedlenno prekratit' peredachu tela soobshcheniya. Esli telo posylaetsya s ispol'zovaniem kodirovaniya "po kuskam" ("chunked", razdel 3.6), to kusok nulevoj dliny, i pustoj zavershitel' MOGUT ispol'zovat'sya dlya indikacii prezhdevremennogo konca soobshcheniya. Esli telu predshestvoval zagolovok Content-Length, klient DOLZHEN zakryt' soedinenie.
HTTP/1.1 (ili bolee pozdnij) klient DOLZHEN byt' gotov prinyat' otvet s kodom sostoyaniya 100 (Prodolzhat', Continue), predshestvuyushchij osnovnomu otvetu.
HTTP/1.1 (ili bolee pozdnij) server, kotoryj poluchaet zapros ot HTTP/1.0 (ili bolee rannego) klienta NE DOLZHEN peredat' otvet s kodom sostoyaniya 100 (Prodolzhat', Continue); emu SLEDUET libo ozhidat' poka zapros budet vypolnen obychnym obrazom (to est' bez ispol'zovaniya prervannogo zaprosa), libo prezhdevremenno zakryt' soedinenie.

Posle polucheniya metoda, podchinennogo etim trebovaniyam, ot HTTP/1.1 (ili bolee pozdnego) klienta, HTTP/1.1 (ili bolee pozdnij) server DOLZHEN libo otvetit' kodom sostoyaniya 100 (Prodolzhat', Continue) i prodolzhat' chtenie vhodnogo potoka, libo otvetit' oshibochnym kodom sostoyaniya. Esli server otvetil oshibochnym kodom sostoyaniya, to on MOZHET libo zakryt' transportnoe soedinenie (TCP), libo prodolzhat' chitat' i otbrasyvat' ostavshuyusya chast' zaprosa. On NE DOLZHEN vypolnyat' zaproshennyj metod, esli vozvratil kod sostoyaniya oshibki.

Klientam SLEDUET pomnit' nomer versii HTTP, ispol'zuemoj serverom po krajnej mere v poslednij raz; esli HTTP/1.1 klient vstrechal HTTP/1.1 ili bolee pozdnij otvet ot servera, i vidit zakrytie soedineniya pered polucheniem kakogo-libo koda sostoyaniya ot servera, klientu SLEDUET povtorit' zapros bez vzaimodejstviya s pol'zovatelem, poskol'ku metod zaprosa idempotent (smotrite razdel 9.1.2); drugie metody NE DOLZHNY byt' povtoreny avtomaticheski, hotya agenty pol'zovatelya MOGUT predlozhit' operatoru vybor povtoryat' zapros, ili net. Esli klient povtoryaet zapros, to on

DOLZHEN snachala poslat' polya zagolovka zaprosa, a zatem
DOLZHEN ozhidat' otveta servera s kodom 100 (Prodolzhat', Continue), a zatem prodolzhat', ili s kodom sostoyaniya oshibki.

Esli HTTP/1.1 klient ne vstrechal otveta servera versii HTTP/1.1 ili bolee pozdnej, to emu sleduet schitat', chto server realizuet HTTP/1.0 ili bolee staryj protokol i ne ispol'zovat' otvety s kodom sostoyaniya 100 (Prodolzhat', Continue). Esli v takoj situacii klient vidit zakrytie soedineniya pered polucheniem kakogo-libo otveta s kodom sostoyaniya ot servera, to emu SLEDUET povtorit' zapros. Esli klient povtoryaet zapros k etomu HTTP/1.0 serveru, to on dolzhen ispol'zovat' sleduyushchij "binary exponential backoff" algoritm, chtoby byt' uverennym v poluchenii nadezhnogo otveta:

Inicializirovat' novoe soedinenie s serverom.
Peredat' zagolovki zaprosa (request-headers).
Inicializirovat' peremennuyu R primernym vremenem peredachi informacii na server i obratno (naprimer na osnovanii vremeni ustanovleniya soedineniya), ili postoyannym znachenie v 5 sekund, esli vremya peredachi ne dostupno.
Vychislit' T = R * (2**N), gde N - chislo predydushchih povtorov etogo zaprosa.
Libo dozhdat'sya ot servera otveta s kodom oshibki, libo prosto vyzhdat' T sekund (smotrya chto proizojdet ran'she).
Esli otveta s kodom oshibki ne polucheno, posle T sekund peredat' telo zaprosa.
Esli klient obnaruzhivaet, chto soedinenie bylo zakryto prezhdevremenno, to emu nuzhno povtoryat' nachinaya s shaga 1, poka zapros ne budet prinyat, libo poka ne budet poluchen oshibochnyj otvet, libo poka u pol'zovatelya ne konchitsya terpenie i on ne zavershit process povtoreniya.

Nezavisimo ot togo, kakaya versiya HTTP realizovana serverom, esli klient poluchaet oshibochnyj kod sostoyaniya, to on

NE DOLZHEN prodolzhat' i
DOLZHEN zakryt' soedinenie, esli on ne zavershil posylku soobshcheniya.

HTTP/1.1 (ili bolee pozdnemu) klientu, kotoryj obnaruzhivaet zakrytie soedineniya posle polucheniya otveta s kodom sostoyaniya 100 (Prodolzhat', Continue), no do polucheniya otveta s drugim kodom sostoyaniya, SLEDUET povtorit' zapros, no uzhe ne ozhidat' otveta s kodom sostoyaniya 100 (Prodolzhat', Continue) (no on MOZHET sdelat' tak, esli eto uproshchaet realizaciyu).