Управление соединениями

Фактически все известные реализации HTTP используют TCP в качестве транспортного протокола. Однако TCP не был оптимизирован для краткосрочных соединений, типичных для обмена сообщениями в HTTP. Использование TCP в качестве транспортного протокола требует последовательности из грех квитирующих пакетов для установления соединения и еще четырех для закрытия открытого соединения (глава 5, раздел 5.2.3). Типичное НТТР-сообщение состоит из 10 пакетов. Таким образом 7 из 17 пакетов представляют собой пакладпые расходы. Это также означает, что пи одна Web-транзакция не обходится без медленной начальной фазы установления ТСР-соединения Qac88J (обсуждалось в главе 5, раздел 5.2). Прежде чем размер скользящего окпа TCP сможет существенно увеличиться, соединение закроется. Это означает, что доступная полоса пропускания никогда не будет использована полностью.

По мере роста популярности Web, в Web-страницы стали включать встроенные изображения. Загрузка составного документа, то есть совокупности текста и изображений требовала нескольких НТТР-транзакций и, следовательно, нескольких ТСР-соединепий. Прежде чем в браузере отображался весь документ, пользователь ощущал задержку, являющуюся результатом последовательности соединений. Подобным образом был реализован Mosaic — один из первых популярных браузеров. Одним из способов снизить задержку было введение параллельных НТТР-соеди- непий. Впервые это было реализовано в Netscape, до четырех соединений Можно было открыть параллельно для загрузки изображений, ускоряя таким образом загрузку всего документа. Однако это увеличивало общую загрузку сети, на сервер ложилась донолпительпая нагрузка по поддержанию множества ТСР-соединепий.

Другим решением данной проблемы было использование одиого ТСР-соедипе- иие для нескольких HTTP-транзакций. Это привело к введению в НТТР/1.1 долговременных соединений Qjersistent connections). Основной идеей, лежащей в основе долговременных соединений, было сокращение числа открываемых и закрываемых ТСР-соединепий. Вместе со снижением числа открытий и закрытий ТСР-соедине- ний, уменьшалось число пакетов, передаваемых по сети, что в свою очередь снижало ее загрузку. Увеличение времени существования ТСР-соедипепий позволяет серверу получить информацию о загруженности сети. Если загрузка меньше, можно послать больше пакетов, и отправитель может гараптировать, что оп чрезмерно не увеличивает загруженность сети, посылая слишком много пакетов. Выигрыш при последовательной передаче ответов по одному соединению получается за счет снижения загруженности сети. К тому же значительно снижается воспринимаемая пользователем задержка, так как передаваемые последовательно по одному соединению запросы не должны ожидать закрытия предыдущего соединения, установления нового и фазы медленного старта ТСР-соединения. Сообщения об ошибках запросов могут быть переданы по тому же соединению.

Заголовок Connection. Механизм Keep-Alive в НТТР/1.0

Возможность продлевать http-соедииение за пределы одной транзакции запрос-ответ в НТТР/1.0 первоначально отсутствовала. Однако по мере роста популярности Web некоторые реализации НТТР/1.0 ввели разновидность долговременных соединений. Некоторые браузеры включали заголовок запроса Keep-Alive для запроса установления соединения, которое остается открытым и после выполнения текущего запроса. Серверы, готовые оставить соединение открытым, принимали данный заголовок и не закрывали соединение после передачи ответа.

Идея, лежащая в основе Keep-Alive, та же, что и у долговременных соединений в НТТР/1.1. Клиент, заинтересованный в сохранении соединения открытым, просил, чтобы Web-cepвep не закрывал данное соединение. Это делалось следующим образом:

GET /home.html НТТР/1.0

Connection: Keep-Alive

Если сервер также был заинтересован в сохранении открытого соединения, он отправлял следующий ответ: НТТР/1.0 200 0K

Connection: Keep-Alive

<тело ответа>

Однако если сервер, использующий НТТР/1.0, передает динамическое содержание, у клиента, принимающего его, нет способа определить окончание ответа без закрытия этого соединения сервером. Динамически генерируемое содержание Обычно не включает заголовок Content-Length, поскольку ожидаиие вычисления длины после завершения формирования содержания увеличивало задержку для клиента.

Простые расширения позволяли серверу указывать (с помощью нолей заголовков), как долго соединение может оставаться открытым после последнего запроса или максимальное количество запросов, которые будут переданы с помощью даипо- го соединения. Клиент мог проверить поля заголовков и принять решение не посылать но этому долговременному соединению более определенного числа запросов.

Эволюция механизма долговременных соединений в НТТР/1.1

Еще до введения современного механизма долговременных соединений в НТТР/1.1 предпринимались разнообразные попытки сохранять НТТР-соедине- пия за пределами одной транзакции запрос-ответ. Их можно подразделить на два больших класса: (1) новые методы HTTP, которые Можно было использовать для получения более чем одного ресурса и (2) использование нескольких параллельных соединений для выборки ресурсов. Первый подход включал вариации механизма многократного метода GET, позволяющего выполнить многократные запросы поверх одного транспортного соединения. Второй подход использовал параллельно нескольких транспортпых соединений для выборки Группы ресурсов. Разработка механизма, который был стандартизован в качестве механизма долговременных соединений в НТТР/1.1, начиналась с попыток избежать необходимости создавать несколько параллельных соединений.

Подход, связанный с новыми методами HTTP: MGET, GETLIST, GETALL.

Первый подход предлагал новые методы HTTP для передачи нескольких запросов по одному и тому же транспортному соединению. Было предложено три метода: MGET, GETLIST и GETALL. Ни одно из этих предложений не сохранилось в процессе эволюции протокола и не вошло в НТТР/1.1. Однако рассмотреть предлагавшиеся альтернативные решепия представляется полезным.

Предложение по введению нового метода MGET, было сделапо в [Fra94a, Fra94b]. Метод MGET похож на команду FTP mget, посредством которой можно было получить с помощью одной команды несколько файлов, соответствующих определенному шаблону. В FTP, команда mget требовала нескольких соединений для передачи данных, то есть отдельных ТСР-соедипепий. Предложенный метод HTTP MGET не требовал установления нескольких ТСР-соедииеиий, путем перечисления набора ресурсов в самом запросе. Весь запрос должен был обрабатываться Web-сервером последовательно. В следующем примере запроса MGET, заимствованном из [Fra94a], приводится список нескольких URI вместе с модификаторами запроса:

MGET НТТР/1.0 ( URI: /image1.gif URI: /image2.gif

If-Modified-Since: Saturday 29-0ct-94 20:04:01 GMT

URI: /image3.gif

CRLF

Сервер откликается на запрос MGET, посылая ответы для каждого из запрошеп- пых ресурсов с предварительным указанием размера ресурса и кодировки содержания, что позволяет клиенту правильно обработать ответ:

НТТР/1.0 200 0K URI: /imagel.gif Content-Type: image/gif CRLF 2200

… 2200 байтов данных изображения CRLF

НТТР/1.0 304 Not Modified URI: /image2.gif

CRLF

НТТР/1.0 200 0K

URI: /image3.gif

Content-Type: image/gif

CRLF

7180

… 7180 байтов данных изображения CRLF

Клиент просматривает каждый ответ до CRLF и извлекает отдельные ответы. Очевидно, что устранение необходимости установления нескольких последовательных соединений для отправки ответов приводит к уменьшению времени ожидания и загрузки сети.

Предложение MGET возникло в коптексте дискуссий о получении страницы вместе с встроенными в нее изображениями. Имея информацию о размерах изображений, встроенных в HTML-страницу, браузер мог осуществлять ее отображение, хотя изображения еще находились в процессе загрузки. Браузер может получить даипую информацию либо средствами HTML, либо от сервера. Например, информация о встроенных изображениях могла быть включена в исходный HTML-текст докумеп- та-контейпера. Однако это потребовало бы от протокола сведений о содержимом конкретного типа (HTML) документов, что пежелательпо. В качестве альтернативы, сервер мог бы включать эту информацию в заголовок ответа. Однако зависимость от Web-cepвepa не слишком желагельпа, так как сервер не всегда в состоянии предоставить иужпую информацию. Например, не все изображения могут находиться на том же Web-сервере, что и документ-коптейпер.

GETLIST и GETALL [PM95J по сути похожи на MGET. Используя GETLIST, клиент может запросить конкретный список ресурсов. Чтобы запросить все ресурсы (документ-коптейпер и все его встроенные ресурсы), следует использовать метод GETALL. Едипственный запрос с методом GETALL автоматически передаст все составляющие документа, не требуя отдельных запросов GET. Преимущество GETLIST по сравнению с GETALL заключалось в том, что клиент.имеет возможность выбирать, какие из встроенных ресурсов запрашивать. Один и тот же ресурс может быть встроен в документ-коптейпер несколько раз, и не имеет смысла запрашивать такой ресурс более одного раза.

Подход, связанный с параллельными соединениями. Альтернативным подходом к использованию одного и того же соединения для выборки нескольких ресурсов являлось использование нескольких параллельных соединений. Браузер мог открыть несколько параллельных соедипепий и загружать встроенные изображения параллельно. Параллельные соединения были реализованы в 1994 г. в одной из ранпих версий браузера Netscape. Такой подход может быть оправдан, если при- пять ограниченную точку зрения на опыт эксплуатации Web исключительно с позиции сокращения времени ожидания пользователя. Хотя пользователь, возможно, почувствует, что данные загружаются доволыю быстро, у этого подхода есть существенный недостаток: открытие нескольких параллельных соединений зпачителыю нагружает сеть. Множество пакетов, передаваемых для устаповлепия и закрытия ТСР-соединепий, увеличивают загрузку сети. Если слишком мпого клиентов начнут использовать параллельные соединения, результатом будет перегрузка сети. Кроме того, серверы будут испытывать пиковые нагрузки. Сервер может испытывать педонустимую пагрузку, если множество клиентов запрашивают ресурсы’со встроенными изображениями, иснользуя параллельные соединения. Основная проблема заключается в том, что в условиях ограниченной пропускной способности сети, мпожество параллельпых соединений одного клиента сокращает полосу пропускания, выделяемую другому клиенту. Пытаясь запять как Можно большую часть полосы пропускания, множественные соединения на самом деле снижают реальную нропускную способность.

Однако у метода параллельпых соединений есть и более серьезный недостаток, связанный с отменой запросов. Рассмотрим следующий сценарий: на Web-cepвepe имеется ресурс с множеством встроенных изображений, браузер устанавливает несколько параллельных соединений, чтобы начать его загрузку. Если пользователь решает прекратить загрузку ресурса, все параллельные соединения должпы быть закрыты. Значительные накладные расходы на установление соединений при этом были затрачепы напрасно.

Даже если не учитывать отмепы запросов, параллельные соединения не всегда сокращают время ожидания пользователя при загрузке исходного документа. Каждое из параллельпых соединений является независимым от другого, и каждое соединение должно отдельно «платить свою плату» за установление ТСР-соединения и за прохождение фазы медленного старта (согласно изложенному в главе 5, раздел 5.2.6).

Долговременные соединения в НТТР/1.1. Наряду с множеством предлагавшихся решений, был разработан и реализован подход, который обеспечивал долговременные соединений за счет того, что давал возможность и клиенту, и серверу указывать те соединения, которые могут быть сохранены [PM95J. Это предложение может быть разделепо на две части: повторное использование существующего транснортного соединения и внесение некоторых небольших изменений на прикладном уровне (в протоколе HTTP). Идея повторного использования транспортного соединения была похожа на предложения, рассмотренные рапее, и преследовала три цели:

•   Спижеиие «стоимости» ТСР-соединения (меньше открытий и закрытий).

•          Уменьшение задержки путем сокращения фаз медленного старта ТСР-соеди- непий.

•    Сокращение потерь полосы пропускания и снижение общей загрузки.

Предложенные изменения на уровне HTTP были незначительными. Можно было добиться дополнительного уменьшения задержки, если посылать по долговременному соединению несколько запросов, не дожидаясь ответов от сервера. Этот способ известен как конвейеризация pipelining) и излагается в разделе 7.5.4. Это может повлиять на снижение общего числа соединений, если прокси-серверы используюг долговременные соединения. Потребности нескольких конкретных клиентов могут быть удовлетворены меньшим количеством соединений между прокси-сервером и Web-сервером, если прокси-сервер поддерживает долговременное соединение с данным Web-сервером.

Значительным шагом, обеспечивающим широкое использование долговременных соединений, было введение в НТТР/1.1 данного типа соединения в качестве умалчиваемого. Соединение Keep-Alive было необязательным в реализациях НТТР/1.0. В спецификации НТТР/1.1 реализация долговременных соединений относится крекомендуемым требованиям (требования уровня SHOULD). Хотя ничто не мешает администратору Web-сайта отключить установку долговременных соединений в качестве соединений но умолчапию, требование протокола уровня SHOULD повышает вероятность того, что администраторы совместимых реализаций серверов будут оставлять долговременные соединения в качестве соединений по умолчапию. Адми- цистратор Wcb-сервера, использующего НТТР/1.1, для отключения долговременных соединений в качестве установки по умолчанию в настройках сервера должпы сделать эго в явном виде. Поскольку в большинстве случаев установки по умолчанию оставляются «как есть», преимущества долговременных соединений вероятно должны стать доступны большинству пользователей.

Предложения GETALL и GETLIST преобразовались в механизм долговременных соединений, который стал частью стандарта НТТР/1.1. Ни один из предложенных методов (MGET, GETALL и т.д.) не сохранился в окончательном варианте протокола. Хотя множественные параллельные соединения доволыю распространены, общенризнапно, что долговременное соединение с копвейеризацией обеспечивают наиболее эффективное использование сетевых ресурсов и мипималыюе время ожидания для пользователей.

Еще одпа тема, касающаяся долговременных соединений, — это наличие прокси-серверов и кэшей. Должно ли долговременное соединение осуществляться по сквозному принципу (между клиентом, ценочкой прокси-серверов и Web-cepBe- ром)? Необходимо иозабогиться о прокси-серверах, которые работают по протоколу НТТР/1.0 и не воспринимают долговременных соединений. Эта гема обсуждается более подробно в разделе 7.11.

Заголовок Connection

Некоторые реализации НТТР/1.0 используют заголовок Connection чтобы оставить соединение открытым и после завершения одиночной транзакции запрос-ответ. Однако в НТТР/1.1 в соответствии с тенденцией к обеспечению унрав- лепия соединениями и отправителем, и получателем, заголовок Connection может быть использован для указания, что одпа из сторон памерепа закрыть соединение. Возможно, сервер не хочег поддерживать слишком много открытых долговременных соединений, или отправитель (например, ирокси-сервер) решит, что у него больше пет оснований сохранять открытое соединение с данным конкретным сервером. Обе стороны могут включить заголовок Connection:close, чтобы сообщить о намерении закрыть существующее долговременное соединение независимо от намерений другой стороны.

Общий заголовок Connection был описан выше, как имеющий более широкое назначение: перечислять набор заголовков, которые имеют смысл только для текущего соединения транспортного уровня с соседним сервером. Иначе говоря, сервер, получающий заголовок Connection, анализирует эгот заголовок и удаляет все заголовки перечисленные в пем. Вариаиг Connection: close был введен в качестве способа обеспечения совместимости с прежней (НТТР/1.0) формой долговременных соединений. Некоторые реализации НТТР/1.0 поддерживают заголовок Connection: Keep-Alive. Вместо того чтобы изобретать новый заголовок, семаптика которого будет пересекаться с семантикой заголовка Connection, механизм Connection в НТТР/1.1 использовал Keep-Alive в качестве одной из многих возможных лексем заголовка Connection. Защита заголовка (т.е. обеспечение того, чтобы данный заголовок не будет пересылался прокси-серверами далее) также была согласована с существующей лексемой Keep-Alive. Так как но умолчанию в НТТР/1.1 реализуется долговременное соединение, то это выглядит, как если бы заголовок Connection: Keep-Alive включался в каждое сообщение. Проблема, связанная с поддержанием долговременного соединения с прокси-серверами, которые не воспринимают заголовки Connection, обсуждается в разделе 7.11.3.

Конвейеризация в долговременных соединениях

Установление долговременных соедипеиий снижает количество иакегов, необходимых для создания и закрытия ТСР-соединеиий. Клиент, посылающий запрос и ждущий на иего ответ до того, как посылать следующий запрос по тому же долговременному соединению, впосит дополнительную задержку. Вместо этого клиент может послать совокупность запросов, не ожидая соответствующих ответов (исходя из предположения, что запросы будут обрабатываться последовательно), при этом задержка, связанная с ожиданием приема каждого ответа, исключается. На самом деле основной выигрыш от механизма долговременных соединений получается благодаря конвейеризации [Pad95].

Рассмотрим, например, четыре запроса на изображения по одному и тому же долговременному соединению:

GET /foo1.jpg НТТР/1.1 CRLF

GET /foo2.jpg НТТР/1.1 CRLF

GET /foo3.jpg НТТР/1.1 CRLF

GET /foo4.jpg НТТР/1.1 CRLF

В примере присутствуют запросы четырех ресурсов: fool.jpg, foo2.jpg, foo3.jpg и foo4.jpg, объединенных в конвейер в одном НТТР-соедииепии. Клиент извлекает выгоду из последовательных запросов четырех ресурсов, не ожидая возвращения каждого ответа до отправки следующего запроса.

Запросы, передаваемые но долговременному соединению с конвейером или без иего, должпы обрабатываться сервером в том порядке, в котором они были получены. Если запросы были обработаны не в том порядке, отправитель может не получить актуальное содержание ресурса. Спецификация протокола предполагает, что только идемпотептпые методы (глава 6, раздел 6.2.2) должпы использовагься последовательно. Например, если запрос GET следует за предшествующим ему запросом PUT, ожидаемым результатом должпо быть получение последнего содержимого ресурса (возможно измененного запросом PUT). Однако эго предполагает, что оба копвейеризировапных запроса были обработаны без перерыва. Если соответствующее транспортное соединение было преждевременно закрыто (например, по причипе аварийного завершения), ожидаемый результат может быть и не получен.

БЛОКИРОВКА ТИПА «ПЕРВЫЙ В ОЧЕРЕДИ»

Если один из предшествующих запросов ресурса в конвейере занимает значительное время, другие запросы того же соединения должпы быть задержаны. Эта проблема обостряется, когда соединение осуществляется с прокси-сервером, который передает запросы копвейера разньш Web-серверам. Возможно, что первый в очереди конвейеризированный запрос получает ресурс очень большого объема, и хотя следующий запрос может адресоваться другому Web-серверу и запрашивать небольшой ресурс, он не может быть обработан пока обрабатывается первый (большой) запрос. Эта ситуация известна как блокировка «первый в очереди (head of line)» [Get97J. Таким образом, если отправителю известно, что предыдущие запросы могут запять много времени, ему вероятно не следует включать в конвейер запросы, следующие за продолжительными запросами. Отправителю, тем не менее, не всегда известпо, сколько времени потребует обработка конкретного запроса.

Хотя сервер и может попытаться предложить более эффективную последовательность передачи ответов, избегая в некоторых случаях блокировки «первый в очереди», протокол требует, чтобы ответы посылались в том порядке, в котором были получены запросы. Это самое простое, что может сделать сервер. Спецификации протоколов предпочитают ошибаться «по простоте своей».

СЛУЧАИ НЕПРЕДВИДЕННОГО ЗАКРЫТИЯ ПОТОКА

КОНВЕЙЕРИЗИРОВАННЫХ ЗАПРОСОВ

Существует множество причип, по которым НТТР-соедипеиие может завершиться аварийно. Пользователь может намеренно прервать соединение, пажав кнопку браузера Stop или щелкнув мышью на гинерссылке, когда текущая страница продолжает загружаться. Сервер может прервать соединение, если решит, что его ресурсы пытаются использовать неправильно. В сети может произойти сбой, ведущий к разрыву текущего соединения.

Долговременные соединения страдают от всех помех, связанных с аварийными завершениями соединений, как и простые запросы, но добавляются и дополнительные проблемы. В случае, когда аварийно завершается одиночный запрос, пользователь может просто повторить его (если оп сам не инициировал этого завершения) или проигнорировать неудачный запрос (особенно если сам вызвал его завершение). В этом случае аварийное завершение не порождает проблем сохранения состояния для таких методов как GET и HEAD. Однако в случае методов PUT и POST может осуществляться попытка обновления содержания на сервере. Пусть последовательность запросов представляет собой конвейер, и пользователь завершает эти запросы до того, как будут получены все ответы. Агент пользователя должен установить, на какие запросы получепы ответы, и повторно передать все остальные запросы.

Протокол предписывает, что клиенты должпы иметь возможность восстанавливать закрытое соединение, независимо от причины закрытия. Например, возможно, что клиент должен вновь открыть соединение и отправить все запросы, которые не были обработаны. Обычно это не является проблемой. Однако если сама последовательность запросов имеет существенное значение (то есть существует зависимость от того порядка, в котором обрабатывались запросы), агенту пользователя возможно потребуется согласовать свои действия с пользователем и повторно передать прерванные запросы. Например, обработанная часть потока запросов возможно требует обязательной повторной передачи всей совокупности запросов.

Отсутствие взаимодействия между транспортным и прикладным уровнями является причиной неудовлетворительного аварийного завершения соединения в процессе обработки копвейера запросов. Если бы в HTTP имелось бы средство зафиксировать разрыв, не закрывая соединения транспортного уровня, то тогда эту проблему удалось бы преодолеть. Однако зависимость протокола прикладного уровня от протоколов нижних уровней является некорректным проектным решением. Эта тема обсуждается более подробно в главе 8 (раздел 8.2.1).

Закрытие долговременных соединений

При установлении долговременного соединения рождается естественный вопрос, когда это соединение закрывать. Протокол в принятии такого решения не играет никакой роли, оставляя его на усмотрение компонентов, участвующих в соединении. Единственная рекомендация протокола гласит, что соединения по умол- чапию должпо быть долговременным. Это вынуждает клиента или сервер явно формулировать отказ от сохранения соединения открытым. Однако не существует рекомендаций относящихся к тому, сколько времени должно существовать соединение или сколько запросов должен обработать сервер с помощью открытого долговременного соединения, прежде чем закрыть его.

Должны быть согласованы следующие противоречивые интересы:

•          Серверу иужпо обслуживать множество различных клиентов. Сохранение открытого долговременного соединения с каким-го одним клиентом может затруднить обслуживание других клиентов и обеспечение всем клиентам равных прав.

•          Сервер может принять решение обработать больше запросов от какого-то клиента по существующему соединению, поскольку если соединение закрыть, то этот клиент, возможно, просто попробует установить повое соединение.

•          Серверу может потребоваться закрыть соединение при достижении некоторого лимита времени, чтобы обеспечить равноправие клиентов. Лимит может относиться к общему времени существования соединения в открытом состоянии или ко времени простоя соединения. Это также преиятствуег попыткам какого-либо клиента получить большую, чем другие, часть ресурсов Web-сервера и полосы пропускания сети.

•          Сервер может быть подключен к особому клиенту (или прокси-серверу), может быть нужным, чтобы соединение с таким клиентом продолжало существовать дольше, чем другие; например, в случае различных дисциплин обслуживания клиентов.

Эти и другие темы обсуждались в разумных пределах до стандартизации протокола НТТР/1.1. Был сделан ряд предложений, которые подразумевали использование параметров долговременных соединений (и в запросе, и в ответе). Среди предложений были:

•          timeout. Данный параметр задает время существования долговременного соединения.

•          max. Параметр задает максимальное число запросов, которое будут обработано по данному долговременному соединению.

•          state. Данный параметр используется для указания заголовков, для которых требуется сохранения их состояний.

Однако перечисленные дополнительные параметры создавали проблемы. Параметр timeout не имел смысла там, где невозможно было сделать оценки среднего времени прохождения запроса-ответа по сети туда и обратно, или где промежуточные прокси-серверы могли использовать собственные значения параметров. Использование таймаута, даже если оп необязателен, лишает сервер возможности управления закрытием соединения. Например, клиент может использовать большое значение таймаута, рассчитывая сохранить соединение открытым в течение длителыюго периода времени. Однако если затем клиент переходит в режим ожи- дания и не использует соединение, сервер должен сам принять решение, когда его закрыть. Параметры timeout и max были реализованы в одной из ранних версий сервера NCSA [Sin95]. Поскольку запросы должны появляться последовательно, знание максимального числа запросов было бесполезным (это было до того, как была реализована конвейеризация). Параметр state был предложен, чтобы не нужно было повторно отправлять заголовки, которые не менялись в каждом сообщении. Характерным примером, использованпым в предложении по параметру state, были большие заголовки Accept. Однако параметр state существенно увеличивает издержки, в то же время нельзя определить выгоды, вытекающие из сохранения состояния. Поэтому все указанные выше параметры были удалены из механизма долговременного соединения.

Спецификация умалчивает о том, как долго соединение должно быть открыто. Каждый сервер может использовать свою собственную эвристику, чтобы решить, когда закрывать долговременное соединение. Фактически при реализации долговременных соединений для Web-серверов часто принимают во впимапие совокупность факторов, прежде чем решить, закрывать долговременное соединение или пет.

НТТР/1.1 накладывает ограничения на некоторые методы при работе с преждевременно закрытыми соединениями. Например, НТТР/1.1 требует, чтобы запросы POST могли восстанавливать свое состояние после преждевременного закрытия. Клиент должен немедленно прекратить передачу сообщения, как только ему стаиет известно, что соединение было закрыто. Клиент должен повторить запрос, если оп не получил ответа от сервера. Попытка может повторяться после того, как пройдет некоторое время несколько раз, пока не будет получен код состояния (4xx или 5xx).

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100