Динамическое окно перегрузки

Изменим предыдущую модель, позволив окну перегрузки изменять свой размер. Как мы говорили ранее, в начале передачи сервер устанавливает размер окна перегрузки равным величине MSS и отсылает один сегмент клиенту. Получив квитанцию, сервер увеличивает размер окна перегрузки до величины 2MSS и посылает 2 сегмента с интервалом в S/R с. Получив еще 2 квитанции, сервер увеличивает размер окна перегрузки до величины 4MSS и отсылает клиенту 4 сегмента также с интервалом в S/R с. Таким образом, каждый раз по истечении времени оборота окно перегрузки увеличивается вдвое, как показывает временная диаграмма на рис. 3.53.

Обратите внимание, что О/S представляет собой число сегментов объекта; на приведенной выше диаграмме О/S = 15. Далее, рассмотрим закон изменения размеров окна перегрузки. Первое окно содержит 1 сегмент, второе окно — 2 сегмента, третье окно — 4 сегмента, и т. д. Обобщая закономерность, получаем, что k-e окно содержит 2(k-1) сегментов. Пусть К — число окон, которые «покрывают» объект; на предыдущей диаграмме К = 4. Отношение между величинами К и О/S можно выразить следующим образом:

После передачи данных окна возможны простои сервера, обусловленные ожиданием получения квитанций. На рис. 3.53 показано, что сервер простаивает после передачи первого и второго окон, а третье окно не вызывает простоя. Подсчитаем суммарное время простоя после передачи k-то окна. Время, проходящее с момента начала передачи k-то окна до получения подтверждения для его первого сегмента, составляет S/R + RTT; время передачи k-YO окна равно (S/R) 2(k-1). Таким образом, время простоя, равное разности указанных величин, составляет

[S/R + RTT — 2(k-1) (S/R)],

Простой сервера возможен после передачи любого из первых К — 1 сегментов, поскольку К-й сегмент является последним. Теперь мы можем подсчитать полную задержку передачи файла. В нее входят три составляющие: 2RTT для установления ТСР-соединения и запроса файла, О/К для передачи объекта и сумма всех простоев сервера. Таким образом, задержка составляет

Сравнив полученную формулу с формулой задержки для статического окна перегрузки, можно увидеть, что единственным отличием первой от второй является член 2(k-1)(S/R) вместо WS/R. Для упрощения выражения введем величину Q, равную числу простоев сервера в предположении, что передаваемый объект состоит из бесконечного числа сегментов. Проводя преобразования, аналогичные тем, которые были выполнены для величины К, получим

Фактическое число простоев сервера при передаче составляет Р = mm{Q,K- 1}. На рис. 3.53 Р = Q = 2. С учетом принятых обозначений формула задержки преобразуется к следующему виду (см. упражнения, приведенные в конце главы):

Таким образом, для вычисления задержки необходимо получить значения К и Q, присвоить величине Р минимальное из значений Q и К — 1 и подставить его в приведенную формулу.

Сравним задержку протокола TCP с задержкой, которая имела бы место при отсутствии механизма контроля перегрузки (то есть при отсутствии ограничений, налагаемых окном перегрузки). Как мы определили ранее, минимальное значение задержки в случае контроля перегрузки составляет 2RTT + О/R. Нетрудно показать, что

Из приведенной формулы видно, что фаза медленного старта не вносит ощутимого вклада в задержку, если RTT « О/R, то есть при длительности передачи, значительно превышающей время оборота.

Рассмотрим несколько количественных примеров. Положим, что величина 5 составляет 536 байт — значение, обычно применяемое в TCP по умолчанию. Время оборота возьмем равным 100 мс, что не является редкостью для континентальных или межконтинентальных линий связи, испытывающих перегрузку средней силы.

Для начала рассмотрим передачу объекта размером О = 100 Кбайт. Число окон К, «покрывающих» объект, равно 8. Таблица 3.4 демонстрирует влияние медленного старта на задержку для нескольких значений скорости передачи.

и TCP за короткое время достигает максимальной скорости передачи. Например, если R = 100 Кбайт/с, число простоев составляет Р= 2, в то время как количество окон К равно 8. Это означает, что сервер простаивает лишь после передачи первых двух из восьми окон. Вместе с тем если R = 10 Мбит/с, то простои наблюдаются после передачи каждого пакета и значительно увеличивают общую задержку.

Теперь рассмотрим передачу небольшого объекта размером 0 = 5 Кбайт. Число окон, покрывающих объект, составляет К = 4. Таблица 3.5 демонстрирует влияние медленного старта на задержку для нескольких скоростей передачи.

Как и в предыдущем случае, медленный старт значительно повлиял на задержку только для больших скоростей передачи. Например, когда R = 1 Мбит/с, сервер простаивает после передачи каждого окна, что обусловливает значение задержки, почти вдвое превосходящее минимальное.

С возрастанием величины RTT влияние медленного старта для небольших объектов становится заметным и при небольших скоростях передачи. Таблица 3.6 демонстрирует влияние медленного старта на задержку при RTT = 1 с и О =5 Кбайт (К = 4).

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