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

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

300

Часть

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

Потеря пакета, определяемая

по повторяющимся подтверждениям

Потеря пакета,

определенная по RTO

Гк^

/ Порог медленного старта

^^^"^-^.Фаза медленного

старта

"""^и /

Интервал

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

1 /

1 / • • •

/^^s Фаза медленного

старта

Время

Рис.

8.3. Повтор фазы медленного старта после таймаута повторной передачи

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

ные на этом же сервере. При наличии долговременного соединения ответы на все

эти запросы могут передаваться по одному и тому же ТСР-соединению. Пропуск-

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

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

четырех содержащихся в нем изображений. Передача данных начинается при раз-

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

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

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

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

передачи сервером многочисленных ответов.

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

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

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

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

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

хранить соединение. Сетевой график может существенно измениться за пятисе-

кундный период простоя. Пока соединение было неактивно, другие ТСР-соедине-

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

мере использовать пропускную способность канала. Возьмем простой пример: по

участку сети проходит трафик пяти соединений с одинаковыми RTT. В среднем,

каждое из них имеет пропускную способность в 20% от общей пропускной способ-

ности участка сети. Если одно из этих соединений будет неактивно несколько се-

кунд, то остальные четыре соединения «съедят» его долю и будут занимать по 25%

от общей пропускной способности.

Если соединение, которое было некоторое время неактивным, будет работать

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

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

вать для передачи 20% пропускной способности сети, хотя остальные соединения

продолжат использовать по 25%. В таком случае пропускная способность будет

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

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

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

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

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

пользовать пропускную способность сети. В итоге, помимо снижения общей

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

пропускную способность и самого соединения, так как общая перегрузка сети мо-

жет привести к существенным потерям пакетов данным соединением. Все это при-

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

ПОВТОР ФАЗЫ МЕДЛЕННОГО СТАРТА

Чтобы предотвратить «вспышку» активности, отправитель должен после перио-

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

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

шек» трафика. В течение фазы медленного старта ТСР-отправитель увеличивает

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

способности соединения с сервером. Позволить соединению, бывшему неактив-

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

—

это все равно, что позволить но-

вому соединению начать работу с большим скользящим окном. Такая «вспышка»

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

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

фазы медлегнюго старта после периода бездействия. Этот механизм называется по-

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

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

нения двух ключевых понятий: начала периода бездействия и установки начально-

го размера скользящего окна. Период бездействия начинается сразу же, как только

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

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

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

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

дагнхых. Отправитель ТСР-пакетов использует текущее значение RTO для измере-

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

в течение периода времени, равного RTO, то отправитель устанавливает началь-

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

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

дольше, чем несколько RTT, что составляет обычно не более нескольких секунд.

Большинство автоматически генерируемых запросов на загрузку встроенных ре-

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

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

они просматривают различные страницы на том же сайте. При этом часто бывают

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

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

в главе 10 (раздел 10.5.3). Большие промежутки между запросами, обусловленные

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

старта. Повтор фазы медлегнюго старта снижает преимущества повышения произ-

водительности с помощью долговременных соединений. Сервер не сможет в пол-

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

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

окном. С другой стороны, повтор фазы медленного старта также влияет на общую

пропускную способность сети.

302

Часть

III.

Web-протоколы

УМЕНЬШЕНИЕ ВЛИЯНИЯ ПОВТОРОВ ФАЗЫ МЕДЛЕННОГО СТАРТА

НА ОБЩУЮ ПРОПУСКНУЮ СПОСОБНОСТЬ СЕТИ

Механизм повтора фазы медленного старта предотвращает генерацию слишком

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

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

фазы медленного старта на снижение производительности соединения [Hei97J:

• Отключение повтора фазы медленного старта. Web-сервер может заблокиро-

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

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

мя.

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

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

неактивно в течение 15 секунд, чтобы уменьшить общее число соединений,

как это описано ниже в разделе 8.4.2.

• Использование большего таймаута повтора фазы медленного старта. В опе-

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

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

Однако не следует забывать, что чем больше таймаут, тем больше вероятность

того,

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

тивности, не будет соответствовать текущему состоянию сети.

• Постепенное уменьшение размера скользящего окна. Вместо того чтобы ис-

пользовать решение «все или ничего», отправитель ТСР-пакетов может по-

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

Отправитель может уменьшать ее нропорционально времени периода простоя.

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

нии неопределегнюсти в предсказании состояния сети.

• Постепенная отправка пакетов. Чтобы избежать резкого возрастания числа

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

правляемых получателю пакетов. Предположим, что размер скользящего окна

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

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

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

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

скользящее окна, размер которого равен размеру четырех пакетов.

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

нять комбинацию этих методов. Например, отправитель может использовать боль-

ший таймаут, постепенно уменьшать размер скользящего окна и постепенно пере-

давать пакеты.

8.1.3.

Сохранение состояния TIME_WAIT

Сильно загруженные Web-cepsepbi обрабатывают большое количество запросов

на создание новых ТСР-соединений. Поддержка большого числа ТСР-соединений

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

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

ла бы освобождать эти ресурсы сразу же, как только соединение закрывается. Но

протокол TCP требует, чтобы один или оба компьютера сохраняли информацию о

закрытом соединении. В этом подразделе мы объясним, почему хотя бы один из

компьютеров должен сохранять состояние TIME_WAIT и почему ответственность

за это обычно ложится не на клиента, а на сервер. Потом мы рассмотрим несколько

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

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

ния TIME_WAIT па Web-сервере.

СОХРАНЕНИЕ ИНФОРМАЦИИ О ЗАКРЫВШИХСЯ СОЕДИНЕНИЯХ

Сохранение информации о закрывшихся ТСР-соедипениях приводит к значи-

тельным накладным расходам па сильно загруженном Web-сервере. Рассмотрим

пример сервера, который закрывает соединение после отправки HTTP-ответа кли-

енту. Закрытие соединения производится с помощью процедуры, состоящей из че-

тырех шагов и начинающейся передачей пакета FIN, как это описывалось в главе 5

(раздел 5.2.3). При получении пакета FIN, клиент посылает пакет с подтверждени-

ем.

Потом клиент читает HTTP-ответ. За последним байтом сообщения клиент на-

ходит символ конца файла (EOF), который означает, что сервер закрыл свою сто-

рону соединения. Клиент затем закрывает свою сторону соединения, посылая при

этом пакет FIN серверу. Получив пакет FIN от клиента, сервер посылает АСК, за-

вершающий четырехшаговую процедуру. Получение подтверждающего пакета

АСК сообщает клиенту, что соединение закрыто. Но в то же время сервер не может

знать, дошло ли его подтверждение до клиента или нет.

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

казано на рис. 8.4. Если пакет АСК был потерян, то клиент, в конце концов, запус-

тит таймер повторной передачи, но истечению которого он снова пошлет пакет

FIN. При потере этого пакета клиент снова запустит таймер повторной передачи,

после чего снова пошлет пакет FIN. Так как сервер не знает, дошел ли его пакет

АСК по назначению или нет, то сервер не может решить, надо ли передавать ли его

снова. Поэтому сервер не может удалить информацию о соединении в течение не-

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

нении, некорректно полагая, что клиент получил его пакет АСК. Позже, когда от

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

относится к только что закрытому соединению. Думая, что пакет FIN был послан

по ошибке, сервер пошлет клиенту пакет RST вместо того, чтобы снова послать

подтверждающий пакет АСК.

Сервер-

Kлиeнт-

Утеря

пакета

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

Рис 8.4. Потеря и повторная передача заключительного АС К-пакета сервером

Более серьезная ситуация складывается, если один или более пакетов, относя-

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

что сервер получил запрос целиком, а клиент получил ответ полностью. Какой-ни-

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

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

пия дошла до адресата, а другая продолжала блуждать по сети. Такой пакет может,

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

стояния соединения между компьютерами:

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

• Соединение все еще открыто. Предположим, что повторный пакет приходит,

пока соединение еыде открыто. Получатель смотрит помер пакета и находит,

что эти данные уже были получены. Получатель отбрасывает такой пакет.

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

рое соединение было закрыто, а новое соединение не было установлено. Когда

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

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

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

• Соединение было закрыто, а новое соединение создано. Предположим, что

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

парой номеров портов. Когда повторный пакет прибывает, номера портов ана-

лизируются операционной системой получателя. Номера портов пакета совпа-

дают с номерами портов нового соединения, и данные передаются приложе-

нию,

связанному с новым соединением. Это ошибочно, так как этот пакет не

принадлежит новому соединению.

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

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

номерами портов, по крайней мере, в течение некоторого промежутка времени по-

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

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

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

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

первым послал пакет FIN. На этом компьютере ТСР-соедипепие переходит в со-

стояние TIME_WAIT. Операционная система сохраняет информацию, связанную

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

пакет АСК и предотвратить создание нового соединения с теми же номерами пор-

тов.

Соединение должно оставаться в состоянии TIME_WAIT столько времени,

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

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

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

ловке IP-пакета, содержащее время его жизни (TTL), должно ограничивать время

пребывания пакета в сети, как это описано в главе 5 (раздел 5.1.4). Это 8-битпое

поле позволяет задавать максимальное значение TTL в 255 секунд.

TCP требует, чтобы компьютер оставался в состоянии TIME_WAIT в течение

двух периодов максимального времени жизни сегмента (MSL — maximum segment

lifetime) — оценки времени наибольшей задержки при доставке пакетов. В специ-

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

ние MSL, равное двум минутам [J.81J, хотя на практике различные реализации ис-

пользуют 30 секунд, одну минуту или две минуты. С одной стороны, малое значе-

ние MSL уменьшает длительность состояния TIME_WAIT, что в свою очередь

уменьшает объем системных ресурсов, необходимых для хранения информации о

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

того,

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

уменьшает вероятность того, что отправитель сумеет повторно выслать утерянный

заключительный пакет АСК. С другой стороны большое значение MSL приводит

к тому, что состояние TIME_WAIT длится дольше. В результате, достаточно много

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

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

вере.

Необходимо также отметить, что большие значения MSL ограничивают ско-

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

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

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

ционирующим на удаленном компьютере на порту 80. После передачи пакета FIN

для закрытия ТСР-соединения сервер переходит в состояние TIME_WAIT на че-

тыре минуты. Получив подтверждение АСК от сервера, клиент завершает соедине-

ние.

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

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

ентский порт (например, 1026), потому что сервер все еще находится в состоянии

TIME_WAIT из-за завершенного соединения. Заголовок TCP пакета имеет 16-бит-

ное ноле номера порта, что ограничивает число различных портов, которое клиент

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

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

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

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

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

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

запросы следующему прокси-серверу в цепочке.

ВЛИЯНИЕ TIME_WAIT НА WEB-СЕРВЕРЫ

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

нительные накладные расходы, связанные с гюддержанием состояния TIME_WAIT.

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

ного соединения. В такой ситуации сервер обычно закрывает соединение (посылая

пакет FIN) сразу после отсылки HTTP-ответа клиенту. Теперь рассмотрим другую

ситуацию, когда клиент и сервер поддерживают соединение открытым. В этом слу-

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

ние.

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

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

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

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

рассмотрегю позже, в разделе 8.4.2. Браузер, напротив, имеет достаточно мало пово-

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

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

В любом из перечисленных сценариев первым закрывает соединение сервер и,

соответственно, он и должен поддерживать состояние TIME_WAIT. Ситуация ос-

ложняется, если клиентом является прокси-сервер. Интенсивно функционирую-

щий прокси-сервер связан ТСР-соедипениями с большим числом клиентов и сер-

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

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

должен поддерживать состояние TIME_WAIT, а не Web-сервер. Поддержка со-

тояний TIME_WAIT сильно влияет на производительность прокси-серверов.

В общем случае TIME_WAIT представляет собой неудачный компромисс, так как

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

живать состояние TIME_WAIT.

Дополнительная нагрузка, обусловленная TIME_WAIT, увеличивается еще и за

счет того, что ТСР-соединения — достаточно коротки, так как большинство

Web-ответов относительно невелики. Предположим, что клиент запрашивает оди-

ночный ресурс с Web-сервера. Сервер тратит несколько секунд, отвечая на этот за-

прос.

После закрытия соединения сервер находится в состоянии TIME_WAIT

в течение четырех минут. Это гораздо больше времени соединения. Более ранние

Internet-нриложения, такие как Telnet или FTP, обычно использовали ТСР-соеди-

306

Часть

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

пения в течение более долгого времени. По сравнению с FTP-сервером, HTTP-сер-

вер большую часть времени находится в состоянии TIME_WAIT. Использование

долговременных соединений частично решает эту проблему. Использование одного

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

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

во соединений, находящихся в состоянии TIME_WAIT. И, тем не менее, интенсив-

но работающему Web серверу все равно приходится поддерживать доста!очно мно-

го соединений в состоянии TIME_WAIT.

УМЕНЬШЕНИЕ НАГРУЗКИ, СВЯЗАННОЙ С СОСТОЯНИЕМ TIME_WAIT

Уменьшение нагрузки, обусловленной состоянием TIME_WAIT, чрезвычайно

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

шения нагрузки делятся на две основные категории: уменьшение объема ресурсов,

идущих на поддержание состояния TIME_WAIT, и передача ответственности за

поддержание состояния TIME_WAIT клиенту. Операционная система должна со-

хранять информацию о состоянии TIME_WAIT для каждого соединения. Сохране-

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

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

К счастью, операционной системе необходимо хранить меньше информации о

соединениях в состоянии TIME_WAIT, чем об активных соединениях. В совре-

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

передачи последнего пакета АСК и для предотвращения создания соединения

с теми же IP-адресами и номерами портов, снижены до минимума. Большое число

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

для проверки таймеров, например, таймера повторной передачи. Многие операци-

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

ТСР-соедипепий. Перенося соединения в состоянии TI]VIE_WA1T в конец списка,

операционная система уменьшает время, требуемое для сканирования списка.

Уменьшение затрат процессорного времени и памяти на соединения в состоянии

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

ров [AD99].

Несмотря на достигнутое уменьшение затрат процессорного времени и памяти,

соединения в состоянии TIME__WAIT все равно могут привести к перегрузке

Web-серверов. Предлагаются несколько методов переложить ответственность за

обработку состояния TIME_WAIT на клиента [FTY99], который, как предполага-

ется, работает с небольшим числом соединений.

• Внесение изменений в TCP. Спецификация TCP может быть изменена таким

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

первого пакета FIN. Например, Web-сервер закрывает соединение и посылает

клиенту пакет FIN. Получив пакет FIN, клиент переходит в состояние

TIME__WAIT. Чтобы убедиться в том, что сервер не находится в состоянии

TIME__WAIT, клиент может послать серверу пакет RST (рис. 8.5). Получение

RST заставляет сервер покинуть состояние TIME_WA1T и освободить ресур-

сы,

отведенные для соединения. Альтернативный подход представляет собой

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

вер договаривались, кто будет обрабатывать TIME_WAIT при закрытии со-

единения.

Глава

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

и TCP 307

Сервер

Клиент

Рис 8.5. Клиент посылает RST, чтобы освободить сервер от необходимости

поддержки состояния TIME_WAIT

• Внесение изменений в HTTP. Спецификация HTTP может быть изменена та-

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

вер.

Например, новый заголовок ответа может содержать инструкцию клиенту

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

позволить клиенту принять на себя ответственность за закрытие соединения.

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

ные в HTML-страницу изображения. Правда, отдавать управление соединени-

ем клиенту

—

не всегда подходящее решение. Клиент может иметь веские при-

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

обслуживание состояния TIME_WAIT.

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

TCP,

либо HTTP. Ни один из предложенных подходов не предоставляет привлека-

тельного решения проблемы. Вместо этого администраторы загруженных Web-сер-

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

длительность состояния TIME_WAIT (например, до 5 секунд). Это уменьшает на-

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

мым вероятность создания соединение с теми же номерами портов.

8.2. Разделение функций между HTTP и TCP

Передача Web-ресурсов базируется на функциях прикладного уровня, предос-

тавляемых HTTP, и на функциях транспортного уровня, предоставляемых TCP.

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

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

реализованные на уровне транспортного уровня, влияют на работу Web.

• Отмененные HTTP-передачи. Так как в HTTP отсутствует механизм для

прекрапдения передачи данных, то лля отмены текущего НТТР-занроса на

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

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

8.2.1.

• Алгоритм Нагла. Алгоритм Нагла (Nagle) ограничивает число небольпшх па-

кетов, передаваемых ТСР-отправителем, что может задержать отправку по-

следнего пакета HTTP-сообщения, как описано в разделе 8.2.2.

• Отложенные подтверждения. Получатель ТСР-накетов может отложить пе-

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

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

робно описано в разделе 8.2.3.

308

Часть

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

Обработка прерванных передач HTTP на транспортном уровне позволяет

HTTP избежать привязки к какому-либо конкретному транспортному протоколу.

Алгоритм Нагла и отложенные подтверждения были добавлены в реализации TCP,

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

тивных приложений, как Telnet и Rlogin.

8.2.1.

Отмененные HTTP-передачи

Пользователь может отменить текущую HTTP-передачу, нажав кнопку Stop

или щелкнув мышью на гиперссылке, чтобы перейти на другую страницу. Опера-

ции отмены — это обычная составляющая процесса работы в Web. В некоторых

случаях браузер может отображать содержимое страницы но мере ее загрузки

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

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

стью.

Пользователь может щелкнуть мышью на гиперссылке до завершения загруз-

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

ную загрузку и нажать кнопку Reload, чтобы попытаться снова загрузить страницу.

Пользователи с медленными подключениями к Internet чаще отменяют запросы.

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

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

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

ОТСУТСТВИЕ МЕХАНИЗМА ОТМЕНЫ ПЕРЕДАЧИ ДАННЫХ В HTTP

В протоколе HTTP отсутствует механизм прерывания клиентом текущей переда-

чи данных. Возможность отмены текущей передачи данных лежит на границе между

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

данных в HTTP затруднительно без привязки к какому-либо конкретному протоко-

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

связана с особенностями какого-либо протокола транспортного уровня. Другие про-

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

В Telnet выбрано другое решение. Во время сеанса Telnet пользователь может на-

жать Ctrl+C или Delete, чтобы отменить текущее действие. Отправитель может ис-

пользовать ноле указателя срочности в заголовке ТСР-пакета, чтобы привлечь вни-

мание получателя, как описано в главе 5 (раздел 5.2.7). Это позволяет получателю

избежать необходимости обрабатывать предыдущие байты сообщения. Правда, это

решение привязано к протоколу TCP.

В спецификации HTTP/1.1 можно было бы пойти по тому же пути, введя метод

запроса для отмены передачи текущего сообщения. Но это осложнит обработку по-

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

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

нению запрос об отмене передачи данных. Серверу необходимо было бы просмот-

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

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

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

ту пришлось бы указывать, какие именно запросы нужно отменить. Решение этих

проблем сильно усложнило бы протокол. Поэтому спецификация НТТР/1.1 не

включает механизма отмены передачи данных.

В результате у Web-клиента нет эффективного способа отмены HTTP-запроса,

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

ватель отменил загрузку 20-ти мегабайтного файла, когда 5 мегабайтов уже полу-

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

чены. Клиент (то есть браузер) имеет выбор: разорвать соединение или получить

15 Мбайт ненужных данных. Получение данных увеличивает трафик и уменьшает

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

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

зователем. Соответственно, большинство реализаций Web клиентов предпочитают

закрывать соединения.

ВЛИЯНИЕ ОПЕРАЦИЙ ОТМЕНЫ ПЕРЕДАЧИ ДАННЫХ НА ПРОИЗВОДИТЕЛЬНОСТЬ

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

Например, браузер по протоколу HTTP/1.1 установил долговреме1П1ое соединение

с сервером. Получив HTML-файл, браузер посылает последовательность запросов

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

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

другую страницу того же сайта. Браузер разрывает соединение, чтобы отменить по-

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

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

вит новое соединение, чтобы получить другую страницу. Для того чтобы открыть

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

ного старта.

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

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

сурс,

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

на сайте электронгюй торговли. Если соединение разрывается до того, как браузер

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

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

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

полнительные данные, которые позволят клиенту узнать, был ли обработан запрос.

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

прос,

который добавляет товар в «магазинную тележку». Отменив запрос, пользова-

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

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

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

единение было разорвано. Другой вариант состоит в том, что HTML-форма может

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

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

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

ной последовательности в одном ТСР-соединепии. Отмена одного запроса в после-

довательности приводит к отмене всех еще необработанных запросов в этой после-

довательности. Например, отмена зафузки страницы прекращает загрузку всех

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

менить загрузку всей страницы, а не отдельных ее ресурсов. А теперь рассмотрим

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

тов но одному ТСР-соединению с Web-сервером. Прокси-сервер сначала посылает

запрос от лица клиента А, а затем

—

от лица клиента В. Если клиент А отменит свой

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

крытым и получить весь ответ Web-сервера клиенту А. Это неэкономно, так как от-

вет уже не нужен клиенту. Прокси-сервер может закрыть соединение. В таком слу-

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

Оба варианты плохи. Прокси-сервер не может уйти от этой проблемы, не открывая

отдельного соединения для каждого из клиентов.