Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

290 Часть III. Web-протоколы

ЗАГОЛОВКИ СОДЕРЖИМОГО

В НТТР/1.0 было описано шесть заголовков содержимого, еще один, Content-

Language, был рассмотрен в приложении к RFC 1945. Некоторые из заголовков со-

держимого НТТР/1.0 были изменены в НТТР/1.1, чтобы извлечь преимущества из

его новых возможностей. Например, в НТТР/1.1 уточнено, что к ресурсу может

быть применено несколько кодировок содержания в заголовке содержимого Con-

tent-Encoding. Web-серверы обязаны проверять, что значение Last-Modified совпа-

дает со временем, сгенерированным ими для значения поля Date в ответе. Если

уже после того как ответ был сгенерирован, содержимое было изменено, то получа-

тель узнает об этом по времени модификации содержимого.

7.12.3.

Различные изменения, относящиеся к кодам ответов

При переходе от НТТР/1.0 к НТТР/1.1 почти во всех классах ответов было по

несколько кодов, семантика которых была изменена. Мы рассмотрим эти измене-

ния кодов в соответствии с теми классами, к которым они относятся.

КОДЫ ОТВЕТОВ 2ХХ

Из четырех прежних кодов ответов класса 2хх только два были незначительно

изменены. Код ответа 200 ОК дополнен небольшим уточнением, что ответы на за-

просы HEAD не содержат тела сообщения, в отличие от тела содержимого

в НТТР/1,0. Иначе говори, заголовки содержимого могут быть включены.

В коде ответа НТТР/1.0 201 Created было сделано несколько небольших допол-

нений. Заголовок Location можно включать в ответ, указывая конкретный URI для

созданного ресурса. Ресурс может иметь несколько адресов, и заголовок Location

можно использовать, чтобы указать конкретный адрес. В заголовок ответа можно

также включать другие свойства, характерные для да^нюго ресурса, такие как тин

содержания.

Из трех новых в НТТР/1.1 кодов ответов класса 2хх, два объясняются здесь.

Третий (206 Partial Content) был рассмотрен в разделе

7.4.1.

Здесь мы добавляем

пояснение относительно кэширования ответов 206 Partial Content.

203 Non-Authoritative Information. Этот новый код ответа используется для

указания, что метаданные о ресурсе были получены не от самого Web-сервера, а из

других источников. Метаданные вероятно не идентичны тем, которые прислал бы

исходный сервер. В тех случаях, когда наличие дополнительных метаданных о ре-

сурсе возможно, протокол разрешает включить эту информацию, но с другим ко-

дом ответа.

205 Reset Content. Новый код ответа в НТТР/1.1 205 Reset Content использу-

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

ную связь с пользователем. В НТТР/1.0 не было возможности это сделать. Пред-

положим, что пользователь передал данные из формы на сервер. Сервер, возвратив

код 205, может вызвать очистку формы агентом пользователя, показывая пользова-

телю,

что данные формы были приняты сервером. Пользователь может продол-

жить ввод данных в форму для передачи дополнительных запросов. Это пример

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

сервера, для информирования пользователя об изменении состояния.

Глава 7. HTTP/1.1 291

206 Partial Content. Кэши, которые не поддерживают заголовки Range, не

должны кэшировать ответ 206 Partial Content. Такое предупреждение — пример

ограничений накладываемых на реализации, которые не поддерживают новое свой-

ство,

но легко могут получать ответы с кодами состояний, связанными с новым

свойством. Спецификация протокола включает много таких ограничений, но реа-

лизации не всегда проходят проверку на соответствие этим ограничениям, что при-

водит к потенциальным проблемам. Так изменение протокола оказывает воздейст-

вие на реализации серверов и клиентов, которые этим изменением не затронуты.

КОДЫ ОТВЕТОВ ЗХХ

Четырьмя НОВЫМИ кодами ответов в HTTP/1.1 являются 303 See Other, 305

Use Proxy, 306 (Unused) и 307 Temporary Redirect. Коды ответов 303 и 307 были

введены для того, чтобы Web-компоненты могли определять нужное действие бо-

лее точно. Код ответа 305 был введен в промежуточной (не принятой в качестве

стандарта) спецификации RFC 2068. Код ответа 306 был предложен в промежуточ-

ной версии проекта спецификации протокола, но был удален в процессе стандарти-

зации протокола.

303 See Other. Ответ НТТР/1.0 302 Moved Temporarily включал заголовок

Location, указывая агенту пользователя, где действительно может находиться дан-

ный ресурс. Ответ 303 See Other похож на код состояния 302 Moved Temporarily,

но был добавлен специально, чтобы исправить известную проблему с агентами

пользователя, которые некорректно обрабатывали ответ 302. Это один из примеров

эволюции протокола после обнаружения ошибок в существующих реализациях.

307 Temporary Redirect Код ответа 307 Temporary Redirect информирует агента

пользователя, что данный ресурс может временно находиться по новому URI, внесен-

ному в заголовок ответа Location. При наличии ответа переадресации некоторые аген-

ты пользователя ошибочно используют метод запроса GET, чтобы извлечь ресурс по

новому URI, независимо от того, какой метод использовался в исходном запросе. И

это несмотря на тот факт, что и в RFC 1945, и в одной из промежуточных специфика-

ций НТТР/1.1 (RFC 2068) говорится ясно, что при переадресации методы запросов

не должны изменяться. Переадресация используется в условиях наличия «зеркал»

Web-серверов, из-за чего запрос клиента может быть переадресован ближайшей

к клиенту «зеркалу». Это снижает нагрузку на отдельный сервер.

305 Use Proxy. Код ответа 305 Use Proxy сообщает запрашивающему компо-

ненту, что запрос надо повторить через указанный прокси-сервер, заданный в заго-

ловке ответа Location. Этот код был первоначально введен, чтобы дать возмож-

ность Web-серверу запрещать доступ для всех запросов кроме тех, которые посту-

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

чтобы снизить нагрузку на Web-сервер и расположить его так, чтобы он мог указы-

вать каким прокси-сервером должен пользоваться конкретный клиент. Кроме того,

промежуточная спецификация RFC 2068 была недостаточно четкой в том, что ка-

сается использования кода ответа 305, и создала возможность появления дыры

в системе безопасности. Только один запрос может быть переадресован посредст-

вом ответа 305 и такая переадресация может быть сделана только самим Web-сер-

вером. Если это не так, то существует вероятность наличия атаки типа промежу-

точного компонента (man-in-the-middle). В этом случае некий промежуточный

компонент переадресует запросы на «вражеский» прокси-сервер.

292

Часть

III. Web-протоколы

306 (Unused). Ответ 306 был введен в одной из первых версий проекта специ-

фикации HTTP и позже исключен. Версия прокси-сервера компании Netscape рас-

ширяла требования для кода ответа 306 Switch Proxy таким образом, что получа-

тель мог использовать прокси-сервер, указанный в новом заголовке промежуточ-

ных передач Set-proxy, для последующих запросов. Дополнение должно было,

главным образом, добавить некоторую недостающую функциональность к семанти-

ке ответа 305 Use Proxy и ограничить область применения этого ответа про-

кси-серверами, а не Web-серверами. Однако беспокойство о последствиях этого от-

вета для безопасности (особенно в связи с атакой типа промежуточного компонен-

та) привело к исключению в НТТР/1.1 кода состояния 306. Однако так как

простое исключение может означать, что прежние реализации станут не работоспо-

собными, этот код был зарезервирован.

КОДЫ ОТВЕТОВ 4ХХ

Несколько новых кодов ответов класса 4хх были реализованы в НТТР/1.1.

Коды ответов из таблицы 7.10, не обсуждавшиеся до этого, могут быть разбиты на

три категории: уточне1Н1е, использование возможности согласования в НТТР/1.1 и

новые коды для других свойств.

Уточняющие коды состояний. В этой категории мы обсудим три новых кода

состояния.

405 Method Not Allowed. Код ответа 405 Method Not Allowed был введен

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

при отклонении запроса на конкретный ресурс. Вместо того чтобы возвра-

щать более общий код ошибки 403 Forbidden (как это имеет место

в HTTP/1.0), сервер перечисляет набор методов, которые разрешены для за-

прашиваемого URI. Это делается с помощью заголовка содержимого Allow.

Заметьте, что сервер обязан это делать, если посылается ответ 405 Method

Not Allowed. Отправитель запроса может затем изменить метод запроса.

Предположим, что клиент послал запрос TRACE серверу, у которого этот ме-

тод не реализован. Этот сервер вернет

НТТР/1.1 405 Method Not Allowed

Allow: GET, HEAD, POST, PUT

Таким образом клиент узнает набор адекватных методов, которые данный

сервер может обрабатывать.

408 Request Timeout. Другой пример уточнения отразился в коде состояния

408 Request Timeout. Сервер может оказаться не готов все время ждать, когда

клиент пришлет запрос, и может отключиться. Вместо того, чтобы закрывать

соединение с неоднозначным кодом ошибки, сервер посылает более детализи-

рованный код, указывающий, что он находится в состоянии таймаута.

410 Gone. Если ресурс отсутствует, НТТР/1.1 сервер вернет ответ 404 Not

Found также как и серверы, поддерживающие НТТР/1.0. Однако если серве-

ру известно, что этот ресурс был удален или если его новый адрес нельзя оп-

ределить, чтобы указать его, можно использовать новый код ответа 410 Gone.

Информация о том, что ресурс вряд ли появится позже, известна благодаря

внутренней конфигурационной информации доступной серверу. В этом слу-

чае клиент, в отличие от получения 404 Not Found, знает, что не следует по-

Глава 7. HTTP/1.1 293

вторять запрос, который вызвал ответ 410 Gone. При использовании метода

DELETE, некоторые ресурсы могут быть удалены навсегда. Различие между

404 Not Found и 410 Gone похоже на различие между 301 Moved Perma-

nently и 302 Found.

Коды состояния согласования. Мы обсудим здесь два новых кода состояния

относящихся к категории согласования.

413 Request Entity Too Large. Код ответа 413 Request Entity Too Large по-

сылается, если сервер не может обработать сообщение-запрос слишком боль-

шого размера. Сервер может разрешить отправителю возобновить тот же за-

прос позже, если существует вероятность, что у него появится возможность

обработать содержимое большого размера. Заголовок Retry-After использу-

ется для указания времени, после которого клиент может повторить запрос.

Этот код ответа особенно полезен в сочетании с механизмом Expect

—

клиент

может послать заголовок Expect с размером содержимого запроса и если он

получит ответ 100 Continue, то может посылать остальную часть запроса.

415 Unsupported Media Type. Код ответа 415 Unsupported Media Type ис-

пользуется тогда, когда содержимое запроса отправителя представлено в фор-

мате, который не поддерживается сервером для указанного запроса. Измене-

ние метода запроса может изменить реакцию сервера. Предположим, запрос

с методом PUT включает содержимое в формате, который не поддерживается

сервером. Тот же формат может использоваться в запросе POST, возможно

сервер сможет принять содержимое и передать его программе, которая это со-

держимое сможет обработать.

Новые коды для других возможностей в HTTP/1.1. Мы обсудим два новых

кода ответа в этой категории.

402 Payment Required. Код состояния 402 Payment Required был добавлен

для электронной коммерции в Web. Тем не менее, за этим кодом не зарезер-

вировано никакой семантики. Это просто «заполнитель» для будущего при-

менения.

409 Conflict. Код состояния 409 Conflict был введен в одном из первых про-

ектов НТТР/1.0 для поддержки управления версиями, но формально до

HTTP/1.1 в спецификацию не входил. Если два пользователя пытаются из-

менить ресурс с помощью метода PUT, Web-сервер может обнаружить эту

ситуацию и послать ответ 409 Conflict. Тело ответа включает указание на то,

что может быть не так, если этот запрос будет выполнен. Ответ 409 Conflict

посылается, если сервер имеет основания рассчитывать на то, что клиент мо-

жет предпринять корректирующие действия и повторить запрос. Ответ мо-

жет включать информацию, которая может быть использована агентом поль-

зователя, чтобы принять соответствующие меры.

КОДЫ ОТВЕТОВ 5ХХ

Из двух новых кодов ответов класса 5хх ответ 504 Gateway Timeout уже рас-

сматривался в контексте директив управления кэшами. Еще один новый код ответа

этого класса

—

это 505 HTTP Version Not Supported. Это специфический код ошиб-

294 Часть III. Web-протоколы

ки,

указывающий, что номер версии протокола в сообщении-запросе не поддержива-

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

простым, например, сервер может не воспринимать сообщения в формате того номе-

ра версии протокола, который использовал отправитель. Или наоборот, возможно

сервер не воспринимает семантику и не отвечает требованиям, которые подразуме-

вались отправителем. Данный ответ может указывать на другой протокол, поддержи-

ваемый сервером, чтобы отправитель мог отправить соответствующий запрос.

7.13.

Резюме

Спустя почти десять лет с момента своего появления протокол HTTP сформиро-

вался в наиболее популярный современный протокол прикладного уровня. Потоки

данных, передаваемых в доступной измерениям части Internet, показывают, что три

из четырех пакетов передаются но протоколу HTTP версий НТТР/1.0 или

НТТР/1.1.

По любой мерке это ошеломляющая статистика. Хотя с протоколом

НТТР/1.0 были связаны некоторые проблемы, значительная часть трафика Internet

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

живают НТТР/1.1, но большинство промежуточных компонентов продолжают под-

держивать протокол НТТР/1.0. Это озцачает, что лишь небольшая часть сквозного

трафика полностью осуществляется по протоколу НТТР/1.1. Один из доводов

в пользу усовершенствования механизма промежуточных передач в НТТР/1.1 за-

ключается в возможности, что усовершенствования протокола смогут использовать-

ся между любыми двумя компонентами, реализующими НТТР/1.1.

В этой главе приведены логические обоснования перехода к НТТР/1.1 и, где

это уместно, прослежена эволюция идей, лежащих в основе этих изменений. Мы

надеялись познакомить читателей с процессом разработки протоколов, который

часто осуществлялся в непростых условиях. Сравнительное изложение элементов

НТТР/1.0 и НТТР/1.1. должно помочь читателю оценить объем работы, проделан-

ной в процессе эволюции протокола. Систематизация основных изменений должна

помочь сосредоточиться на важных аспектах протокола с практической точки зре-

ния. Читатели должны помнить, что хотя мы честно пытались охватить большое

число проблем, в области корректности изложения последнее слово остается за

стандартами IETF. В следующей главе рассматривается взаимодействие протокола

транспортного уровня с HTTP.

Взаимодействие

HTTP и TCP

Хотя протокол HTTP (Hypertext Transfer Protocol) не зависит от протоколов

транспортного уровня, почти все его реализации используют TCP (Transmission

Control Protocol). TCP был стандартизован в 1980 году, за десять лет до возникнове-

ния Web. Ранние протоколы прикладного уровня, использовавшие TCP, заметно от-

личались от HTTP. Например, Telnet представляет собой интерактивное приложе-

ние,

использующее одиночное соединение TCP для обмена данными между клиен-

том и сервером в течение определенного периода времени. В отличие от этого,

Web-клиент обычгю устанавливает многочисленные соединения для получения раз-

личных ресурсов с Web-сервера. Протокол FTP (File Transfer Protocol) поддержива-

ет отдельное соединение между клиентом и сервером для передачи команд, а данные

передает с помощью других соединений. В отличие от FTP, HTTP передает и дан-

ные,

и команды по одгюму и тому же соединению. По сравнению с файлами, переда-

ваемыми по FTP, размеры большинства HTTP-запросов и ответов небольшие. Эти

особенности Web-трафика существенно влияют на эффективность работы TCP.

В этой главе рассматривается взаимодействие между HTTP и TCP, а также его

влияние па работу Web. Во-первых, мы обсудим, как TCP использует таймеры для

выполнения некоторых ключевых операций, таких как повторная передача утерян-

ных пакетов. Хотя эти таймеры влияют на любой протокол прикладного уровня,

функционирующий поверх TCP, особенности трафика HTTP приводят к их более

заметному влиянию на производительность Web, чем в более ранних Internet-при-

ложениях. Затем мы изучим, как распределение функций между протоколами

транспортного и прикладного уровней сказываются на производительности Web

в целом. Некоторые механизмы работы TCP были обусловлены более ранними

протоколами прикладного уровня, такими как Telnet и Rlogin. Эти механизмы не

всегда хорошо взаимодействуют с HTTP. Затем мы обсудим влияние Web-клиен-

тов,

создающих одновременно несколько соединений с одним и тем же Web-серве-

ром, на эффективность и качество работы. Например, браузер может установить

несколько соединений для загрузки изображений, встроенных в Web-страницу.

Web-серверы должны при этом работать с большим числом одновременных

ТСР-соединений с различными клиентами. Мы опишем способы снизить нагрузку

Web-серверов при обработке большого числа ТСР-соединений.

8.1.

Таймеры TCP

Реализации TCP используют таймеры для запуска перечисленных ниже ключе-

вых операций:

• Повторная передача утерянных пакетов. Конец работы таймера повторной

передачи запускает операцию повторной передачи нредноложР1тельно утерян-

ного пакета.

296

Часть

III. Web-протоколы

• Повтор фазы медленного старта. Некоторые реализации TCP требуют от

ТСР-отправителя повторного выполнения фазы медленного старта для управ-

ления параметрами скользящего окна после некоторого периода бездействия.

• Удержание состояния разорванного соединения. Отправитель ТСР-пакета,

инициирующий разрыв соединения, окончательно «забывает» его состояние

только через некоторый промежуток времени.

В этом разделе мы объясним, почему таймеры, управляющие перечисленными

операциями, сильно влияют на производительность Web. Позже, в разделе 8.2.3,

мы рассмотрим еще один таймер, который управляет передачей отложенных под-

тверждений.

8.1.1.

Таймер повторной передачи

Иногда процесс загрузки Web-страниц замирает в самом начале. Эти задержки

происходят преимущественно из-за того, что у отправителя много времени уходит

на то, чтобы обнаружить утерю IP-пакетов. В этом разделе мы расскажем о том,

как процесс установления ТСР-соединепия может растянуться на несколько се-

кунд в результате большого начального значения таймаута повторной передачи

(RTO

—

Retransmission Timeout). Затем мы объясним, почему такие задержки воз-

никают сравнительно часто именно при передаче данных с помощью HTTP, а не

при работе других протоколов прикладного уровня.

ЗАДЕРЖКИ В ПРОЦЕССЕ УСТАНОВЛЕНИЯ ТСР-СОЕДИНЕНИЙ

С точки зрения пользователя, щелчок мышью на гиперссылке приводит непо-

средственно к отображению требуемой страницы в окне браузера. Невидимо для

пользователя браузер выполняет последовательность действий, необходимых для

получения и отображения Web страницы: установление ТСР-соединепия, передача

HTTP-запроса, получение ответа, анализ содержимого и его отображение в окне.

Так как браузер представляет собой интерактивное приложение, то задержка при

выполнении хотя бы одной из перечисленных операций становится заметной поль-

зователю. Это сильно контрастирует с неинтерактивными приложениями, напри-

мер,

электронной почтой, в которых пользователь не ожидает немедленного ответа.

Хотя Telnet и FTP в некоторой мере интерактивны, но в них четко отделяется ус-

тановление соединения и передача данных. При этом среднестатистический поль-

зователь взаимодействует с удаленным компьютером достаточно долгое время; так

что несколько секунд дополнительной задержки при установлении ТСР-соедине-

пия и передаче имени пользователя и пароля не сильно влияют на степень удовле-

творения пользователя работой с приложением.

Установка ТСР-соединепия представляет собой трехшаговую процедуру: кли-

ент отправляет пакет SYN, в ответ сервер отправляет клиенту пакет SYN-ACK и,

наконец, процедура завершается отправкой пакета АС К клиентом. Если пакеты не

теряются, то на установление соединения уходит лишь время на отправку и полу-

чение перечисленных пакетов. В случае потери пакета SYN или SYN-ACK времени

тратится существенно больше. У отправителя ТСР-пакета имеется всего два спосо-

ба обнаружения потери пакета: получение повторного подтверждения или завер-

шение таймаута повторной передачи, как об этом говорилось в главе 5 (раз-

дел 5.2.5). Но получатель не посылает повторных подтверждений, если отправи-

тель не передал ни одного пакета данных. В начале соединения, когда отправитель

еще не передал ни одного пакета, скорость передачи пакетов ограничивается не-

Глава

Взаимодействие HTTP

TCP

297

большим размером скользящего окна.

При

отсутствии повторных подтверждений

ТСР-отправитель должен

для

обнаружения потери пакета полагаться

на

таймер

повторной передачи.

При

этом выбор значения

RTO

достаточно критичен. Слиш-

ком большое значение приведет

чрезмерной задержке

случае потери пакета,

слишком маленькое —

излишним повторным передачам. Чтобы найти компро-

мисс,

отправитель выбирает величину

RTO па

основе приблизительной оценки

времени прохода пакета

до

получателя

обратно

(RTT

—

Round-Trip Time).

Но

начале связи отправитель

еще не

имеет данных

об RTT. Это

осложняет

выбор

RTO для

начальных пакетов соединения. Чтобы разрешить

эту

проблему,

спецификация

TCP

предписывает устанавливать начальный

RTO

равным трем

се-

кундам [РАОО]. Если SYN-ACK

не

приходит

течение трех секунд после отправки

пакета SYN,

то

отправитель увеличивает RTO

до

шести секунд

удваивает

его по-

сле каждой последующей повторной передачи,

как

показано

на рис

8.1. Сочетание

большого начального

RTO и

увеличение этого времени

геометрической прогрес-

сии позволяют избежать излишних передач пакетов

SYN или

SYN-ACK

случае

взаимодействия компьютеров

большим RTT. Если пакет SYN

или

SYN-ACK уте-

рян,

то

задержка дополнительной отправки пакета помогает

не

перегружать сеть.

Эти консервативные методы повторной передачи утерянных пакетов

SYN и

SYN-ACK

не

оказывают заметного влияния

на

неинтерактивные приложения.

В то

же время потеря одного

или

нескольких пакетов

SYN или

SYN-ACK заметно ска-

зывается

на

работе Web. Потеря двух следующих друг

за

другом пакетов SYN при-

ведет

суммарной задержке

девять секунд перед тем,

как

будет отправлен третий

пакет

SYN. При

разработке протокола считалось,

что

вероятность потери одного

или более пакетов

SYN или

SYN-ACK будет достаточно малой.

Но

широкое

ис-

пользование

Web

привело

высокой загрузке сетей

и к

сравнительно большо11

ве-

роятности потери пакета (0.05

или

более) [Pax99J. Несмотря

на

применение высо-

коскоростных линий связи

во

многих сегментах Internet

па

критических участках

возникают заторы. Участки, подсоединяющие

Internet отдельные организации,

университеты или даже целые страны, часто бывают перегружены, особенно

часы

пик. Соединение между Internet

провайдерами обычно всегда перегружены. Даже

при небольшом трафике сильно перегруженый Web-сервер может терять пакеты

SYN. Операционная система,

под

управлением которой работает Web-сервер, под-

держивает очередь ТСР-соединепий,

если

эта

очередь переполняется, новые

па-

кеты

SYN

отбрасываются.

Сервер-

Утерянный Утерянный

пакет пакет

Клиент-

Утерянный

пакет

Зс 6с

12с

Рис 8.1. Клиент повторно отправляет серверу утерянный пакет SYN

Большие задержки влияют

на

поведение пользователей. Если пользователю

на-

доело ждать,

то

он/она может отменить запрос нажатием кнопки Stop

браузере.

Затем

он

нажимает кнопку Reload

для

повторения запроса.

итоге, когда пользо-

ватель нажимает Stop, браузер отдает распоряжение операционной системе

о за-

298 Часть III. Web-протоколы

крытии данного соединения (это будет детально описано в разделе 8.2.1). Когда же

пользователь нажимает кнопку Reload, браузер немедленно начинает устанавли-

вать новое ТСР-соединение. Операционная система при этом посылает серверу па-

кет SYN и устанавливает начальное значение КТО по умолчанию (скажем, три се-

кунды). Если посланный пакет SYN достигает сервера, соединение устанавливает-

ся быстрее, чем при ожидании окончания трех- или шестисекундиого таймаута.

Действия пользователя по отмене/повторению попытки соединения фактически

вызывают немедленную переотправку пакета SYN. Пользователь может также на-

жать только кнопку Reload, не нажимая Stop. Нажатие Reload одновременно вызы-

вает и закрытие текущего соединения, и открытие нового.

Завершение и повторное установление «зависшего» соединения обычно умень-

шает задержку, воспринимаемую пользователем, но происходит это за счет увели-

чения нагрузки на сервер и на сеть. Например, операционная система компьютера

с Web-сервером могут отбросить пакеты SYN от разных пользователей, если все

запросы пришли со слишком малым промежутком времени. Если же пользователи

при этом повторят свои запросы, то каждый из них пошлет па сервер по одному

пакету SYN. Это только увеличит и без того высокую нагрузку на сервер. Такое по-

ведение только увеличивает трафик на загруженном участке сети. Перегрузка при-

водит к потере пакетов. Так как большинство Web-запросов и ответов коротки, то

SYN и SYN-ACK составляют относительно большую долю всех утерянных пакетов.

Если в результате потери пакета пользователь останавливает и тут же снова запус-

кает запрос, то клиент вскоре посылает второй пакет SYN. Это увеличивает трафик

на перегруженном участке сети.

ЗАДЕРЖКИ В ПРОЦЕССЕ ПЕРЕДАЧИ ДАННЫХ В WEB

По сравнению с началом соединения, длинные таймауты повторной передачи

в процесса передачи ответа возникают реже по двум причинам:

• Меньшее значение КТО. Отправитель пакетов TCP постепенно уточняет зна-

чение RTO, измеряя временя между отправкой запросов и получением отве-

тов.

Постепенно RTO приобретает значение, близкое к реальному RTT между

отправителем и получателем. Например, RTT между отправителем и получа-

телем равно 200 мс. В начале связи отправитель устанавливает трехсекундное

RTO.

Затем отправитель выбирает RTO в зависимости от среднего значения

RTT. В результате RTO снижается до 250-300 мс.

• Повторяющиеся подтверждения. Появление таймаутов повторной передачи

менее вероятно, когда отправитель пакетов TCP начинает посылать свои дан-

ные.

По мере получения данных получатель пакетов TCP подтверждает их по-

лучение АСК-пакетами, отражающими число полученных байтов в смежных

пакетах данных. В случае утери пакета это число не увеличивается в после-

дующих АСК-пакетах. При получении таких повторяющихся пакетов отпра-

витель понимает, что ранее переданный пакет был утерян. Это служит ему

сигналом передать утерянный пакет, не дожидаясь таймаута повторной пере-

дачи, как это описывалось ранее в главе 5 (раздел 5.2.5).

Указагнхые положительные эффекты становятся значимыми, когда по TCP пе-

редаются большие объемы данных. Оценка RTT становится более точной при дли-

тельном обмене данными между компьютерами, и вероятность повторяющихся

подтверждений увеличивается по мере того, как отправитель устанавливает боль-

шие размеры скользящего окна.

Глава 8. Взаимодействие HTTP и TCP

299

Большинство Web-ответов, однако, имеют не очень большие размеры, примерно

от 8 до 12 килобайтов. Эти короткие пересылки проходят по большей части (если

не целиком) па фазе медленного старта. Эта фаза начинается с небольшого началь-

ного размера скользящего окна в один или два пакета, как описано в главе 5 (раз-

дел 5.2.6). С небольшим скользящим окном вероятность успешно доставить боль-

шое число пакетов после утери пакета очень мала.

Маловероятно, что получатель ТСР-пакетов отправит три повторяющихся

АСК, необходимых для быстрой повторной передачи утерянного пакета [BPS^98J.

Например, утеря первого пакета ответа сервера вызовет передачу единственного

повторяющегося АСК в ответ на приход второго пакета, как показано на рис. 8.2.

Небольшой размер скользящего окна мешает серверу отправить дополнительные

пакеты до тех пор, пока не получено подтверждение о прибытии первого пакета.

Ожидание окончания интервала повторной передачи приостанавливает передачу

сервером данных. Кроме того, после таймаута повторной передачи отправитель

ТСР-пакетов вынужден вернуться к своему первоначальному небольшому размеру

скользящего окна, как показано на рис. 8.3. Таймауты повторной передачи могут

вызвать значительные задержки при передаче данных. Останов и перезапуск сеан-

са передачи да1П1ЫХ может привести к более быстрому отклику, чем при ожидании

таймаута повторной передачи.

Таймаут повторной передачи

Сервер

Клиент

1 \

/ /

\ \

\ Потеря

^\ пакета

Щ.

cs\

со\

/г

/о

/с

—w^

*"\

• • •

Рис 8.2. Клиент посылает повторный пакет АСК серверу

8.1.2. Повтор фазы медленного старта

Долговреме1Н1ые соединения создают привлекательную альтернативу установле-

нию отдельных ТСР-соединений для каждого сеанса передачи данных. Возможность

предотвратить фазу медлеьнюго старта является одним из преимуществ использова-

ния уже имеющегося соединения, как уже говорилось в главе 7 (раздел 7.5). Однако

отправка ответного сообщения по пассивному в течение некоторого времени долго-

временному соединению приводит к появлению большого числа передаваемых па-

кетов. Чтобы не перегрузить сеть, спецификация TCP требует от отправителя по-

вторить фазу медленного старта для управления скользящим окном после некото-

рого периода бездействия соединения. Однако имеется несколько рекомендаций,

как все-таки избежать этой фазы без перегрузки сети.

НЕАКТИВНЫЕ ДОЛГОВРЕМЕННЫЕ СОЕДИНЕНИЯ

Клиент HTTP часто загружает многочисленные ресурсы с одгюго Web-сайта за

очень короткое время. Например, пользователь может загрузить Web страницу, со-

держащую несколько изображений. Браузер запрашивает эти изображения, про-

анализировав содержимое HTML-файла. В дополнение к этому пользователь мо-