Прокси­серверы

Особенно важно то, чтобы проксисерверы корректно использовали свойства поля заголовка Connection.

Прокси­сервер должен сигнализировать о постоянном соединении отдельно своему клиенту и исходному серверу (origin server) или другому прокси, с которым связан. Каждое постоянное соединение устанавливается только для одной транспортной связи.

Прокси­сервер не должен устанавливать постоянное соединение с HTTP/1.0 клиентом.

Практические соображения

Серверы обычно имеют некоторое значение таймаута, за пределами которого они уже не поддерживают более неактивное соединение. Прокси­серверы могут сделать эту величины больше, так как весьма вероятно, что клиент создаст больше соединений через один и тот же сервер. Использование постоянных соединений не устанавливает никаких требований на величину этого таймаута для клиента или сервера.

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

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

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

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

Клиенты, которые применяют постоянные соединения, должны ограничивать число одновременных связей, которые они поддерживают с конкретным сервером. Однопользовательскому клиенту рекомендуется поддерживать не более двух соединений с любым сервером или прокси. Прокси следует использовать до 2*N соединений с другим сервером или прокси, где N равно числу активных пользователей. Эти рекомендации призваны улучшить время отклика HTTP и исключить перегрузки Интернет и других сетей.

Требования к передаче сообщений

Общие требования

• HTTP/1.1 серверам следует поддерживать постоянные соединения и использовать TCP механизмы контроля информационного потока для преодоления временных перегрузок, а не разрывать соединение в расчете на то, что клиент совершит повторную попытку. Последнее может усугубить сетевую перегрузку.

• Клиент HTTP/1.1 (или более поздней версии), посылая тело сообщения, должен мониторировать сетевое соединение на наличие сигнала ошибки. Если клиент обнаружил состояние ошибки, он должен немедленно прервать передачу. Если тело передается с использованием блочной кодировки (chunked encoding), возможно применение фрагмента нулевой длины и пустой завершающей секции для обозначения преждевременного конца сообщения. Если телу предшествовал заголовок ContentLength, клиент должен разорвать соединение.

• Клиент HTTP/1.1 (или более поздней версии) должен быть готов принять код статуса 100 (Continue — продолжить), за которым следует обычный отклик.

• Сервер HTTP/1.1 (или позднейшей версии), который получает запрос от клиента HTTP/1.0 (или более ранней), не должен передавать отклик 100 ( continue — продолжение), ему следует или ждать нормального завершения запроса (таким образом, избегая его прерывания) или преждевременно разрывать соединение.

Клиентам следует запомнить номер версии, по крайней мере, сервера, с которым проводилась работа последним. Если клиент HTTP/1.1 получил отклик от сервера HTTP/1.1 (или позднейшей) и обнаружил разрыв соединения до получения какого-либо статусного кода, клиенту следует повторно попытаться направить запрос без участия пользователя. Если клиент действительно повторяет запрос, то должен:

• сначала послать поля заголовка запроса, а затем

• ждать, того, что сервер пришлет отклик 100 ( Continue ), тогда клиент продолжит работу, или код статуса, сигнализирующего об ошибке.

Если клиент HTTP/1.1 не получил отклика от сервера HTTP/1.1 (или более поздней версии), ему следует считать, что сервер поддерживает версию HTTP/1.0 или более раннюю и не использует отклик 100 ( Continue ). Если в этом случае клиент обнаруживает закрытие соединения до получения какого-либо статусного кода от сервера, следует повторить запрос. Если клиент повторил запрос серверу HTTP/1.0, ему нужно применить следующий алгоритм получения надежного отклика:

1. инициировать новое соединение с сервером;

2. передать заголовок запроса;

3. инициализировать переменную R для оценки задержки отклика сервера (roundtrip time) (например, на основе времени установления соединения), если RTT не доступно, ему присваивается значение 5 секунд;

4. вычислить T = RTT * (2N), где N равно числу предыдущих попыток запроса;

5. ждать в течение Т секунд или до прихода статуса ошибки (что наступит раньше);

6. если не получен сигнал ошибки, после T секунд передается тело запроса;

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

Вне зависимости от версии сервера, если получен статус ошибки, то клиент:

• не должен продолжать операции и

• должен прервать соединение, если процедура не завершена посылкой сообщения.

Клиент HTTP/1.1 (или более поздней версии), который обнаруживает разрыв соединения после получения флага 100 (Continue), но до получения какого-либо статусного кода, должен повторить запрос и не должен ждать отклика 100 (Continue), но может и делать это, если такие действия упрощают реализацию программы.