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

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

310

Часть

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

Операция отмены, инициированная пользователем, не сразу останавливает пе-

редачу данных. Рассмотрим пример браузера, контактирующего напрямую с Web-

сервером. Когда пользователь нажимает кнопку Stop, браузер инициирует закры-

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

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

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

как сервер получит RST/FIN. Проблема обостряется, когда клиент передает запрос

через прокси-сервер. В таком случае, передача HTTP-данных использует ТСР-со-

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

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

имеет большую пропускную способность, чем соединение клиент-прокси. Это

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

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

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

Рассмотрим случай, когда клиент запрашивает ресурс объемом 20 мегабайтов и

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

время весь ресурс. Пересылка оставшихся 15 мегабайтов становится бесполезной,

если прокси-сервер не получит запрос на этот же ресурс в ближайшем будущем.

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

кси-сервер, сервер не передал бы лишние 15 мегабайтов. Управление трафиком не

дало бы Web-серверу посылать пакеты так часто. Предотвращение передачи лиш-

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

и «прокси-клиент». Прокси-сервер может ограничить объем данных, получаемых

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

фактически уменьшает приемное окно ТСР-соедипения с сервером. В свою оче-

редь,

это ограничивает объем данных, которые сервер может передать. Выбор объе-

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

чием между получением лишних данных при отмене передачи данных и уменьше-

нием задержек при нормальной передаче данных.

ЗАКРЫТИЕ ТСР-СОЕДИНЕНИЯ

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

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

системы, этот вызов приведет к передаче либо пакета FIN, либо RST. Предполо-

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

передаст приложению Web-сервера EOF. Операционная система продолжит пере-

давать данные из выходного буфера удаленному клиенту. Получив EOF, Web-сер-

вер прекращает передавать данные в выходной буфер. Данные, уже находящиеся

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

ром работает браузер). Получит ли эти дополнительные данные браузер

—

зависит

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

передачи и приема дарн1ых, то операционная система отбросит данные. Если конец

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

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

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

пользователя.

Некоторые реализации UNIX не позволяют приложениям инициировать отправ-

ку пакета RST. В них отмена запроса порождает пакет FIN, тогда как в других опе-

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

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

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

данные, включая те данные, которые Web-сервер уже записал в выходной буфер.

Это одновременно и хорошо, и плохо. Плюсом является то, что такое закрытие со-

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

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

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

соединение. Это позволит Web-серверу обойтись без чтения последовательности

НТТР-занросов, которые могут находиться во входном буфере. Минусом является

то,

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

кетов, отправленных сервером, не дошла до получателя. Получив RST, операцион-

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

8.2.2. Алгоритм Нагла

Интерактивные приложения, такие как Rlogin и Telnet, обычно передают много

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

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

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

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

зовании долговременных соединений. Потом мы расскажем, как Web-сервер может

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

УМЕНЬШЕНИЕ ЧИСЛА НЕБОЛЬШИХ ПАКЕТОВ

Рассмотрим пример приложения Telnet, позволяющего пользователю взаимодей-

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

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

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

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

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

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

ведет передаче 41-байтного пакета: 20-байтный заголовок IP, 20-байтный заголовок

TCP и один байт данных. Передача 41 байта на каждый байт данных приводит

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

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

накопление данных перед тем, как их передать. Интерактивные приложения не тер-

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

пых надолго. Алгоритм Нагла предназначен для поиска компромисса. Алгоритм га-

рагггирует, что отправитель не передает более одного короткого пакета за одно RTT.

В этом контексте небольшой пакет — это пакет, содержащий меньше байтов, чем

максимальный размер сегмента (MSS — Maximum Segment Size) для данного

TCP-соединения (например, 536 или 1460 байтов).

Предположим, что отправитель пакетов TCP передал пакет и ждет подтвержде-

ния от получателя. Отправитель не передает небольших пакетов, пока не получит

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

тель мог накопить дополнительные данные. В глобальной сети для соединений

с большим RTT алгоритм Нагла предотвращает наличие нескольких небольших

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

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

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

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

кета. В дополнение к этому алгоритм Нагла не влияет на работу приложений,

312

Часть

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

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

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

ход оказывает наибольшее влияние там, где это нужно

—

в интерактивных прило-

жениях, использующих соединения с большими RTT.

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

Алгоритм Нагла может отрицательно сказаться на работе Web, если передача

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

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

сти.

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

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

тело ответа тоже меньше максимального размера сегмента. Теоретически, операци-

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

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

дет ожидать от него дополнительных данных. Тогда операционная система произ-

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

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

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

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

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

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

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

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

Нагла может уменьшить эффективность долговременных соединений [Hei97]. Пред-

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

фер добавится сравнительно большой объем данных (скажем, 8-12 Кбайт) за корот-

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

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

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

ной 6000 байтов передается по соединению с MSS, равным 1460 байтам. Сообщение

займет четыре 1460-байтных пакета и один 160-байтный. Операционная система по-

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

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

следующих условий:

• Запись дополнительных данных в выходной буфер. Сервер может добавить

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

ного пакета, как показано на рис. 8.6. Пакет содержит конец первого сообще-

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

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

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

Ответ 1 Ответ 2

Время

Рис 8.6. Сервер передает полноразмерный пакет, содержащий конец ответа

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

• Получение подтверждений на все переданные пакеты. Могут прийти под-

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

операционной системе передать заключительный неполный пакет. На рис. 8.7

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

длине двух полноразмерных пакетов, сервер получает пакет АСК на каждый

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

равную RTT. Для небольших ответов задержка передачи небольшого заклю-

чительного пакета может быть значительной.

1 1

2 1

[

» *]

Задержка получения

подтверждений

—>g

Время

Рис 8.7. Сервер передает небольшой пакет после получения подтверждений

Отключение алгоритма Нагла

—

простой способ избежать этих потерь произво-

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

время открытия соединения. Например, в операционной системе UNIX есть функ-

ция setsockoptQ для выполнения различных настроек. Установленный флаг

TCP_NODELAY при вызове функции setsockoptQ отключает алгоритм Нагла.

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

алгоритм Нагла. Web-клиенты также могут отключить алгоритм Нагла, так как

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

привести к снижению производительности.

НЕДОСТАТКИ ОТКЛЮЧЕНИЯ АЛГОРИТМА НАГЛА

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

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

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

ленькими порциями. Представим себе Web-сервер, который по отдельности (с по-

мощью вызовов системной функции) записывает каждую строку заголовка HTTP-

ответа. Когда алгоритм Нагла отключен, каждый вызов функции writeQ создает от-

дельный пакет. Это было бы крайне неэффективно. Например, 300-байтовый заго-

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

мимо этого, в пакет поместится начало тела ответа, если таковое имеется. Запись

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

Нагла отключен. Эта проблема была характерной для ранних версий Web-сервера

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

ков HTTP. Подобный феномен имеется и в протоколе Network News Transfer

Protocol (NNTP) [MSMV99].

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

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

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

ет сотни ответов одновременно. Передача IP-пакетов ограничена пропускной спо-

собностью подключения сервера к сети. При большой нагрузке операционная систе-

ма создает очередь данных, передаваемых сервером. Рассмотрим серверный процесс,

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

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

как будет передана первая. Операционная система соединит эти две строки в один

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

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

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

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

рых содержал бы по 40 байтов заголовков протоколов IP и TCP.

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

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

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

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

же позволит уменьшить число системных вызовов. Сервер может произвести всего

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

дет более подробно описано позже в разделе

8.4.1.

8.2.3.

Отложенные подтверждения

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

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

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

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

и эффективно для таких интерактивных приложений, как Telnet или Rlogin, за-

держка отправки подтверждений замедляет передачу Web-ресурсов. Если включен

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

чительной части Web-страиицы. В этом подразделе мы опишем причины примене-

ния отложенных подтверждений и изучим их влияние на работу Web.

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

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

ждений от получателя. Скользящее окно управляет передачей пакетов. Когда оно

заполнено, отправитель не может передать пакеты, не получив АСК от получателя.

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

передачи данных. Но посылка АСК требует 40-байтного пакета: 20-байтный заго-

ловок IP и 20-байтный заголовок TCP с уставленным битом АСК. Это очень неэф-

фективно. Рассмотрим отправителя, который посылает получателю 400-байтные

пакеты. Посылка 40-байтиого пакета с подтверждением на каждый пакет данных

увеличит трафик на 10%. Существуют два способа уменьшить трафик подтвержде-

ний. Во-первых, получатель не обязан посылать АСК в ответ на каждый получен-

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

(флаг АСК и номер подтверждения) к передаваемому им же пакету данных.

Присоединение АСК к передаваемому пакету данных позволит не посылать до-

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

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

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

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

пакета АСК в надежде, что приложение вскоре будет передавать данные. Это очень

эффективно для интерактивных приложений. Представим себе, что компьютер А

подключился посредством Rlogin к компьютеру В. Предположим, что пользователь

ввел один или более символов. Эти символы посылаются по ТСР-соединению ком-

пьютеру В. Rlogin на компьютере В читает эти символы и генерирует эхо, которое

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

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

лов и пошлет эхо одним пакетом. С другой стороны, В не следует ждать слишком

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

долго. Подтверждение получения пакета от А очень важно. Ведь компьютер А не

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

не было подтверждено. Следовательно, задержка пакета АСК может замедлить пе-

редачу данных от А к В. Чтобы найти компромисс, TCP запускает таймер, который

активизирует передачу АСК, даже если нет никаких данных для отправки. Боль-

шинство реализаций TCP передают АСК через 200 мс, но некоторые увеличивают

задержку до 500 мс. Чтобы избежать задержки пакетов АСК в загруженных соеди-

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

полноразмерного пакета до завершения таймера задержки подтверждения. Напри-

мер,

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

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

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

ВЗАИМОДЕЙСТВИЕ ОТЛОЖЕННЫХ АСК С ТРАФИКОМ HTTP

Отложенные АСК уменьшают трафик подтверждений двумя путями: присоеди-

няя АСК к передаваемому пакету данных, а также посылая АСК для каждого вто-

рого пакета данных. Присоединение АСК к пакетам данных несвойственно для

Web-трафика. Обычная передача Web-данных включает в себя короткий НТТР-за-

ирос клиента, после которого следует HTTP-ответ сервера.

Маловероятно, что оба компьютера будут передавать данные одновременно,

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

сы из той же последовательности. Задержка передачи пакета АСК редко позволяет

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

в 200, а то и 500 мс, вызванная таймером задержки АСК, может снизить скорость

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

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

ждений приостанавливает передачу сервером оставшейся части ответа.

Механизм отложенных АСК может привести к ненужной задержке Web-трафи-

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

редает заголовок и тело HTTP-ответа раздельно. Заголовок ответа обычно меньше

MSS.

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

пишет хоть какие-нибудь дополнительные данные в выходной буфер. Позже сер-

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

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

щие тело ответа. Первый полноразмерный пакет окажется вторым для клиента. Но

клиент не передаст АСК, так как первый пакет (заголовок HTTP) будет меньше

MSS.

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

тверждения, прежде чем передаст АСК. В зависимости от размера скользящего

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

данных до получения АСК, как показано на рис. 8.8. Чтобы избежать такой ситуа-

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

чале соединения. Однако это не предотвращает возникновения данной ситуации

при передаче последующих ответных сообщений по тому же соединению.

Алгоритм Нагла достаточно сложно взаимодействует с механизмом отложен-

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

нение [Hei97J; такой же феномен наблюдался на сервере NNTP [MSMV99J. Рас-

смотрим сервер, который записал HTTP-ответ в выходной буфер. Операционная

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

IP.

Операционная система пытается передавать данные нолноразмерными пакета-

ми,

хотя последний пакет обычно меньше остальных. Например, сообщение дли-

316

Часть

III.

Web-протоколы

Сервер-

Kлиeнт-

Задержка отложенного АСК

Рис 8.8. Клиент задерживает АСК для первых двух пакетов, переданных еервером

ной 5000 байтов передается

виде трех пакетов длиной 1460 байтов

одного дли-

ной

620

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

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

на

первые

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

операционная система

на

клиентском компьютере

не

передает подтверждения

в со-

ответствии

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

на

сервере,

в то же

время,

не

станет посылать последний короткий пакет, пока

не по-

лучит подтверждения

на все

предыдущие. Передача данных сервером останавлива-

ется, ожидая подтверждения клиента (из-за алгоритма Нагла),

клиент задержива-

ет передачу

АСК

(из-за механизма отложенных подтверждений),

как

показано

на

рис.

8.9. К

счастью, отключение алгоритма Нагла

на

сервере может предотвратить

появление такой ситуации

на

практике.

Сервер-

Передача задержана до прибытия АСК

Клиент-

Задержка отложенного АСК

Рис

8.9.

Взаимодействие алгоритма Нагла

мехапизмОхМ отложенных АСК

8.3.

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

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

Но

клиент часто устанавливает несколько ТСР-соединенР1Й

сервером. Одновременное

наличие нескольких ТСР-соединений порождает проблемы

производительностью

и равномерным распределением трафика

но

соединениям.

этом разделе

мы

изу-

чим причины,

по

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

рассмотрим проблемы

производительностью

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

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

с производительностью.

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

8.3.1.

Причины использования параллельных соединений

у Web-клиента есть несколько причин создавать несколько соединений одно-

временно с одним и тем же сервером:

• Параллельная загрузка встроенных изображений. Браузер обычно устанавли-

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

сколько встроенных изображений. Первые несколько байтов файла с изображе-

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

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

загрузится. Формат GIF поддерживает прогрессивную или чересстрочную раз-

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

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

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

ством, чем 0Д1Ю изображение с высоким качеством, что делает параллельную

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

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

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

• Прокси-сервер, действующий от лица нескольких клиентов. Прокси-сервер

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

вающих ресурсы с одного и того же Web-сервера. Прокси-сервер мог бы по-

слать все запросы по одному ТСР-соединению. Это позволило бы сэкономить

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

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

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

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

HTML-страницу сразу после того, как пользователь А запросил 100-мегабайт-

ный файл с того же сервера. Если прокси-сервер пошлет оба запроса по одно-

му и тому же (долговременному) соединению, пользователю В придется

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

маленький HTML-файл. Установка двух параллельных соединений с серве-

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

к намного меньшему времени ответа клиенту В.

• Увеличение общей пропускной способности. Клиент может добиться боль-

шей пропускной способности, устанавливая несколько ТСР-соединений с сер-

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

большим RTT. Даже если сервер и сеть загружены слабо, высокое значение

RTT ограничивает пропускную способность ТСР-соедипения. Пропускная

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

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

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

начальный размер скользящего окна небольшой из-за фазы медленгюго стар-

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

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

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

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

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

которые посылают запросы от лица разных клиентов. На практике многие реализа-

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

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

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

но в главе 7 (раздел 7.4.1).

318

Часть

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

8.3.2. Проблемы с параллельными соединениями

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

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

единений обусловливает несколько проблем:

• Несправедливое перераспределение трафика по отношению к другим кли-

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

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

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

рые посылают запросы по одному и тому же пути через сеть одному и тому же

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

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

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

рости работы для клиента А. В то же время клиенту В достанется меньшая

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

В противодействовать неравномерному распределению ресурсов

—

также ус-

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

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

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

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

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

но,

чтобы загрузить набор встроенных в Web-страницу изображений. Это

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

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

суммарный трафик соединений может быть довольно большим. Как крайний

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

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

ют 20 НТТР-занросов. Web-сервер займет большую часть своих ресурсов, пы-

таясь получить и обработать эти пакеты SYN и HTTP-запросы. В сети сум-

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

превысить допустимую пропускную способность, что, в конечном счете, при-

ведет к утере пакетов.

• Большие задержки для пользователей. Помимо конкуренции за долю трафика

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

Предположим, что у клиента подключение к Internet имеет пропускную спо-

собность в 28,8 Кбит/с (например, телефонный модем). Если клиент установит

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

ростью, не превышающей 1,44 Кбит/с. При загрузке встроенных в Web-страни-

цу изображений, большое число медленных соединений может быть предпочти-

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

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

различные Web-страницы в разных окнах браузера. Наличие большого числа

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

дольше, чтобы получить хотя бы одну полностью загруженную страницу.

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

тов,

можно разрешить следующ,ими способами:

• Сознательное уменьшение преимуществ параллельных соединений для по-

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

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

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

собности сети и системных ресурсов сервера. Например, вместо того, чтобы

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

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

Или же маршрутизатор может подсчитывать, объем трафика получателей и

отправителей и «наказывать» слишком агрессивные хосты. Наказание может

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

логии усложняют устройство маршрутизаторов. Аналогично реализация TCP

на Web-сервере может обеспечивать равномерное распределение трафика ме-

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

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

личными клиентами.

• Предоставление альтернативы параллельным соединениям. Долговремен-

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

зано в главе 7 (раздел 7.5). Передача нескольких ответов по одному соедине-

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

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

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

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

бражений одновременно. Клиент мог бы запрашивать различные изображения

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

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

внести изменения во взаимодействие между TCP и HTTP, чтобы осуществить

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

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

лись по мере эволюции Internet от экспериментальной разработки до сети, предос-

тавляющей широкий набор сервисов [Kes97J. Недавние предложения по измене-

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

ны в главе 15 (раздел 15.1).

8.4. Загрузка сервера

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

требуют существенных ресурсов Web-сервера. Эти операции требуют от сервера

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

некоторые из этих шагов можно объединить или избежать. Потом мы рассмотрим

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

Это относится как к прокси-серверам, так и к Web-серверам.

8.4.1.

Совмещение вызовов системных функций

Web-сервер взаимодействует с TCP посредством последовательностей вызовов

системных функций. Выполнение нескольких действий с помощью одного систем-

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

которая может увеличить эффективность передачи данных. Рассмотрим Web-сер-

вер под управлением операционной системы UNIX, обрабатывающий запрос GET

для статического файла:

Прослушивание запросов на новые соединения. Сервер прослушивает за-

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

соединений.