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

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

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

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

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

ассоциировать входящий IP-пакет с нужным сокетом. Для решения этой проблемы

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

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

подобно помещению одного конверта внутрь другого; информации на внешнем

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

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

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

чить информацию на внутреннем конверте.

Точно так же TCP располагается поверх IP. TCP-заголовок содержится в дан-

ных 1Р-накета. Маршрутизаторам в сети не нужно просматривать биты в ТСР-за-

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

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

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

чаются в ТСР-заголовок. Разделение функций между IP и TCP очень важно.

ТСР-заголовок должен содержать достаточно информации для передающего и

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

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

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

ТСР-отправителем и ТСР-получателем.

Рассмотрим передачу сообщения из одного приложения в другое. Операцион-

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

которых представляет собой последовательность байтов, помещенных в 1Р-накет.

ТСР-заголовок идентифицирует соединение, ассоциированное с сегментом. Чтобы

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

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

в том порядке. Если пакет 2 прибыл до пакета 1, операцио1Н1ая система получающе-

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

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

были ли данные повреждены в процессе передачи. В частности, ТСР-отнравитель

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

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

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

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

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

кеты были получены. Например, после получения сегментов 1 и 2 получатель мо-

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

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

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

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

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

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

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

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

еще одну копию. При получении по крайней мере одной (неповрежденной) копии

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

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

Глава 5. Протоколы, связанные с HTTP 151

5.2.3.

Открытие и закрытие ТСР-соединения

Флаги SYN, АСК, FIN и RST в ТСР-заголовке используются при открытии и

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

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

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

ТСР-соединения с приложением В па удаленной машине. Установка ТСР-соедине-

ния состоит в трехэтапном обмене с квитированием (handshake), как показано на

рис.

5.5.

В-

• •

Рис. 5.5. Временная диаграмма ТСР-соедипспия

SYN от А к В. А инициирует соединение, отправляя пакет с установленным

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

в 32-битном поле порядкового номера. Таким образом, SYN-iiaKCT синхрони-

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

имеет первый порядковый помер. Предположим, что SYN-пакет имеет поряд-

ковый помер, равный 4500. После этого первый пакет да1Н1ых от А должен

иметь порядковый номер 4501, что идентифицирует первый байт данных.

SYN-ACK от В к А. После передачи SYN-пакета А ожидает ответа от удален-

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

ТСР-соединения на определенном порту. Прибытие SYN-пакета от А обу-

словливает создание сокета и передачу подтверждающего пакета от В к А.

В посылает пакет А, в котором установлены флаги SYN и АСК. Флаг SYN

инициирует соединение в обратном направлении (от В к А), а флаг АСК под-

тверждает получение SYN-пакета от А. Номер подтверждения в ТСР-заголов-

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

порядковый номер в SYN-пакете от А. Как и SYN-пакет от А, пакет SYN-ACK

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

начало потока байтов, передающихся от В к А, и не имеет отношения к на-

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

АСК от А к В. После поступления пакета SYN-ACK установление соедине-

ния от А к В завершается, и онерациогнхая система информирует приложение

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

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

знает, получило ли приложение А пакет SYN-ACK. Третья часть в трехэтап-

ном взаимодействии состоит в отправке пакета АСК от А к В для подтвер-

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

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

SYN-ACK от В. После получения этого пакета приложение В может переда-

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

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

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

ТСР-соединений. Посмотрим, что произойдет, если каждое ТСР-соединение ис-

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

ТСР-соединению между А и В по сети передается ожидающий обработки пакет,

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

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

ют ТСР-соединение, как только передача данных заканчивается. После этого А и

В могут установить новое ТСР-соединение с теми же номерами портов, что и для

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

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

чения. В этой ситуации получатель может ошибочно ассоциировать старый пакет

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

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

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

ТСР-соединение может быть завершено на любой стороне. Приложение ини-

циирует закрытие ТСР-соединеиия путем закрытия соответствующего сокета. За-

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

Если приложение В закрывает сокет первым, как показано на рис. 5.5, эти четыре

этапа заключаются в следующем:

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

та с установленным флагом FIN. С этого момента В не передает каких-либо

новых данных. Тем не менее, В ответственно за гарантированную, упорядо-

ченную доставку предыдущих данных, отправленных приложению А. Так что

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

В,

продолжает повторную передачу утерянных пакетов потока. Кроме того,

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

добно пакету SYN, пакет FIN от В занимает один номер в пространстве по-

рядковых номеров.

АСК от А к В. После получения этого пакета А передает пакет АСК с номе-

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

в пакете FIN от В. Выделение порядкового номера флагу FIN позволяет А

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

данных.

FIN от А к В. После того, как приложение А прочитает все байты из сокета,

следующая операция чтения покажет, что был достигнут конец дагн1ых.

В этот момент приложение А будет знать, что В не предполагает передавать

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

сокет, что приводит к передаче пакета FIN приложению В.

АСК от В к А. После получения пакета FIN В передает пакет АСК для под-

тверждения закрытия соединения от А к В. После получения пакета АСК А

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

закрыто. Передача каких-либо новых данных между А и В потребует откры-

тия нового ТСР-соединения.

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

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

свои FIN-пакеты параллельно. Для полного закрытия соединения оба этих FIN-na-

кета должны быть подтверждены.

Четырехэтапный обмен пакетами FIN и АСК является обычным способом закры-

тия ТСР-соединения. Однако ТСР-заголовок также содержит флаг RST для сброса

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

Глава 5. Протоколы, связанные с HTTP 153

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

IP и TCP не соответствуют какому-либо активному сокету этого хоста. В этом слу-

чае хост отвечает пакетом RST. Рассмотрим другую ситуацию. Допустим, что прило-

жение посылает пакет SYN на определенный порт другого хоста. Если ни одно из

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

вечает пакетом RST. В качестве примера предположим, что на компьютере

www.foo.com отсутствует Web-сервер. Если пет программы, прослушивающей за-

просы на порту 80, то хост отправит RST-пакет отправителю, который пытается от-

крыть ТСР-соедииеиие. Операционная система на отправляющей машине должна

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

5.2.4. Управление потоком с помощью скользящего окна

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

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

время, когда приложение записывает данные в сокет. Однако TCP ограничивает

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

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

рах,

—

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

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

быстрее, чем сеть может их обработать,

—

слишком «агрессивная» передача может

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

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

ничивает число ожидающих обработки (неподтвержденных) байтов в сети, исполь-

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

перейолиения буфера у получателя, пакеты от В к А содержат в ТСР-заголовке

окно приема.

2500 байт подтверждены 2000 байт не подтверждены

< •^ •

•>^

2000 байт прочитаны 4000-байтное окно приема

Рис. 5.6. Пример 4000-6айт1юго окна приема

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

после последнего байта, подтвержденного приложением В. Предположим, что опе-

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

ла 4000-байтовый входной буфер для хранения входящих данных для этого

ТСР-соединения, как показано на рис. 5.6. Предположим также, что приложение

В получило и подтвердило прием 2500 байтов от А, и 2000 байтов из этих

2500 байт были прочитаны приложением В. Тогда во входном буфере остается еще

500 байтов данных. Приложение В не может обработать более 3500 дополнитель-

ных байтов данных. АСК-пакет приложению А подтверждает получение первых

2500 байт и сообщает о размере окна приема в 3500 байтов. После получения паке-

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

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

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

что А отправляет дополнительные 2000 байтов, что составит всего 4500 байт. Пер-

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

вые 2000 байт были отправлены, получены, подтверждены и прочитаны. Следую-

щие 500 байт были отправлены, получены и подтверждены, но не были прочитаны

приложением В. Поскольку следующие 2000 байтов были отправлены, 1Ю не под-

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

Следующие 1500 байт могут быть переданы немедленно. Приложение А не мо-

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

фера на стороне В. В любой заданный момент времени А не может передать дан-

ные,

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

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

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

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

буфер размером 8 Кб, 16 Кб или 32 Кб. Приложения могут с помощью системного

вызова увеличить размер буфера приема. Для пары хостов с большим временем

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

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

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

входного буфера на стороне В равен 8 Кбайтам. Отправитель А не может передать

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

передачи 128 Кб/с вне зависимости от пропускной способности соединения от А

к В. В общем случае производительность TCP обратно пропорциональна времени

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

5.2.5. Повторная передача утерянных пакетов

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

токолом TCP надежной доставки потока байтов. IP не информирует ТСР-отправи-

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

пакет был потерян, на основе ответа (или отсутствия ответа) получателя. Получа-

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

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

вающим следующий байт, ожидаемый в потоке байтов от отправителя. Если полу-

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

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

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

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

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

полагает, что пакет был утерян па пути к получателю. Выбор соответствующего

значения таймаута повторной передачи (RTO — Retransmission TimeOut)

—

доста-

точно тонкий процесс. Установка слишком малого значения RTO приводит

к «ложной тревоге», и отправитель напрасно повторно отправляет пакет, который

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

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

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

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

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

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

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

нужного значения RTO определяется конкретной ситуацией. ТСР-отправитель мо-

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

да1Н1Ых получателю. ТСР-отправитель оценивает время «прохождения данных

Глава 5. Протоколы, связанные с HTTP 1^

туда и обратно» (RTT

—

Round Trip Time)

—

время между передачей пакета и по-

лучением подтверждения. На основе этих измерений отправитель может оценить

среднее значение RTT, а также его дисперсию. Значение RTO устанавливается, ис-

ходя из значения RTT плюс некая дополнительная величина, которая зависит от

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

вторных передач [РАОО]. Оценка RTT становится тем точнее, чем интенсивнее об-

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

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

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

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

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

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

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

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

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

рого пакета, поскольку это поле устанавливается па основе получения непрерывного

потока байтов. После поступления четвертого пакета получатель отправляет еще

один АСК-пакет с тем же самым числом подтверждения. На этот момент отправи-

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

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

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

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

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

Получение трех повторных АСК-пакетов (четырех идентичных подтверждений)

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

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

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

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

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

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

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

правителя к получателю.

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

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

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

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

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

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

IP-пакеты проходят через сеть к получателю по различным маршрутам. Например,

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

тате чего пакет 7 прибывает после пакета 10. ТСР-получатель передает повторные

подтверждения при получении пакетов 8, 9 и 10. Третье повторное подтверждегте

приводит к повторной передаче ТСР-отправителем пакета 7. Беспорядочное посту-

пление пакетов снижает производительность TCP. Хотя протокол IP не гарантиру-

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

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

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

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

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

5.2.6. Адаптация к запзуженности сети в TCP

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

скорости передачи данных. Такая адаптация имеет важное значение в свете быстрого

роста Internet. В противном случае группа агрессивных ТСР-соединений может пе-

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

этих пакетов только увеличивает загрузку. Однако сама сущность протокола IP,

в котором отсутствует понятие соединения, затрудняет управление зафуже1Н10Стыо

маршрутизаторами в сети. Вместо этого ответственность за управление загруженно-

стью берут на себя оконечные хосты. Поскольку IP не предоставляет явной инфор-

мации о загруженности сети, ТСР-отправитель должен сделать вывод, что сеть нере-

фужена, на основе косвенных наблюдений за производительностью [Jac88J. ТСР-от-

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

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

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

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

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

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

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

При отсутствии потерь пакетов ТСР-отправитель постепенно увеличивает размеры

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

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

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

кумента RFC 2581 [APS99J. При отсутствии потерь пакетов отправитель ностененгю

(линейно) увеличивает размер скользящего окна. В частности, отправитель увеличи-

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

TCP-соединения. Например, при максимальной длине пакета (MTU) в 1500 байтов

величина MSS должна составить 1460 байт, чтобы оставить место для двух 20-байт-

ных заголовков IP и TCP. В ответ на утерю одного или нескольких пакетов отправи-

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

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

1ЮГ0 АСК-пакета размер скользящего окна устанавливается равным половине вели-

чины текущего значения. Д/щитивное (в арифметической прогрессии) увеличение и

мультипликативное (в геометрической прогрессии) уменьшение размеров скользя-

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

рис,

5.7. График имеет пилообразную форму с nocreneiHibiM увеличением скользя-

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

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

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

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

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

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

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

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

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

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

пятую пропускной способности.

TCP предоставляет эффективный способ настройки скорости передачи для ка-

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

7Ювое

соединение не

обладает какой-либо информацией о состоящие сети. Если начать с большого

Глава 5. Протоколы, связанные с HTTP

157

Утеря пакетов

Фаза медленного старта

Время

Рис.

5.7. Изменение размера скользящего окна TCP от времени

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

вести к перегрузке сети. Вместо этого TCP начинает новые соединения с фазы мед-

ленного старта, как показано на рис. 5.7. В начале фазы медленного старта

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

одному или двум MSS. Таким образом, отправитель может передать получателю

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

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

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

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

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

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

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

вых порах передает лдитые отиоси'телыю медленно. В это время ТСР-соединение

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

от отправителя к получателю. Фаза медле]Н10го старта завершается, как только

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

ет значение порога медленного старта в ответ на утерю пакетов [APS99J. При дос-

тижении скользящим окном границы фазы медленного старта ТСР-отнравитель

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

нейно увеличиваются. Аддитивное увеличение и мультипликативное уменьшение

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

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

женность сети значительно изменилась. В результате ТСР-отнравитель сбрасывает

размер скользящего окна в его начальное значение, равное одному или двум MSS,

и повторяет фазу медленного старта.

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

различаются для разных версий протокола TCP [FF96]. Совершенствование управле-

ния скользящим окном TCP является областью активных исследований [APS99,

MMFR96, FF96, AFP98, RF99, Flo94, FloOO]. Большинство предлагаемых расширений

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

повышения производительности приложений. Тем не менее, основные операции

158

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

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

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

через фазу медлепгюго старта. Фаза медлен1юго старта предполагает небольшой на-

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

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

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

личиваются (при гюступлении АСК-пакета) и мультипликативно уменьшаются (при

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

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

сети или переполнения входгюго буфера, соответственно.

5.2.7. Описание ТСР-заголовка

ТСР-отправитель передает каждый сегмент в одном IP-пакете вместе с ТСР-за-

головком. Как показано на рис. 5.8, ТСР-заголовок состоит из следующих нолей.

Порт источника

Порт назначения

Порядковый номер

Номер подтверждения

Длина

загол.

Резерв

Контрольная сумма TCP

Размер окна

Указатель

экстренного обращения

Рис. 5.8. Формат ТСР-сегмента

Номер порта источника (source port) (16 бит). 16-битный номер порта, ассо-

циированный с ТСР-отправителем. IP-адрес отправителя содержится в IP-за-

головке.

Номер порта получателя (destination port) (16 бит). 16-бит11ый помер порта,

ассоциированный с ТСР-получателем. IP-адрес получателя содержится в IP-за-

головке.

Порядковый номер (sequence number) (32 бита). 32-битный порядковый но-

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

те.

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

жения сегмента в потоке байтов и реорганизации сегментов, поступающих не

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

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

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

тельно этого начального порядкового номера.

Глава 5. Протоколы, связанные с HTTP 159

• Номер подтверждения (acknowledgement number) (32 бита). Для подтвер-

ждения получения данных ТСР-заголовок содержит 32-битный номер под-

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

получателем, и корректно только в том случае, если флаг АСК установлен в 1.

Когда приложение А передает данные приложению В, ТСР-заголовок содер-

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

лучение этих сегмехггов.

• Длина заголовка (header length) (4 бита). 4-битпая длина заголовка указыва-

ет на количество 32-бигпых слов в ТСР-заголовке. Заголовок обычно имеет

длину 20 байтов, что соответствует пяти 32-битпым словам. Более длинным

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

рые содержат дополнительную управляющую информацию.

• Зарезервировано (6 бит). 6-битпое поле зарезервировано для будущего ис-

пользования.

• Флаги TCP (TCP flags) (8 битов). ТСР-заголовок также содержит 8-битное

поле с шестью

1-битными

флагами. Эти флаги соответствуют различным

управляющим действиям:

- URG. Флаг URG (флаг срочности) инструктирует ТСР-получателя обра-

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

срочности в ТСР-заголовке.

- АСК. Флаг АСК (подтверждения) устанавливается при отправке подтвер-

ждения. Если флаг АСК установлен, 32-битное ноле подтверждения ука-

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

данных ТСР-отправитель почти всегда устанавливает бит АСК.

- PSH. Флаг PSH (форсированной отправки) указывает, что ТСР-получа-

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

- RST. Флаг RST (сброс) устанавливается при разрыве ТСР-соединения.

- SYN. Флаг SYN (синхронизации) устанавливается при установлении

ТСР-соединения. Если флаг SYN установлен, значение в поле порядкового

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

- FIN. Флаг FIN (окончания передачи) устанавливается, когда отправитель

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

сокета FIN преобразуется в символ конца файла.

Флаги SYN, АСК, FIN и RST будут подробнее обсуждаться далее в этом разде-

ле.

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

правляющего приложения возможность установки флага PSH, а для ТСР-полу-

чателя

—

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

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

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

дущих байтов в потоке.

• Окно приема (receiver windows) (16 битов). 16-битное поле окна приема со-

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

помимо подтвержденных на данный момент данных. Чтобы избежать пере-

полнения входного буфера, ТСР-отправитель не должен передавать данные,

объем которых превышает размер окна приема.

• Контрольная сумма TCP (TCP checksum) (16 битов). 16-битная ко1ггроль-

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