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

Изменим предыдущую модель, позволив окну перегрузки изменять свой размер. Как мы говорили ранее, в начале передачи сервер устанавливает размер окна перегрузки равным величине 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 можно выразить следующим образом:

form.png

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

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

353.png

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

form1.png

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

form2.png

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

form3.png

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

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

form4.png

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

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

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

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

34t.png

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

35t.png

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

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

36t.png

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

Данная статья "Динамическое окно перегрузки" размещена на сайте Компьютерные сети и многоуровневая архитектура интернета (conlex.kz) в ознакомительных целях.

Уточнения, корректировки и обсуждения статьи "Динамическое окно перегрузки" - под данным текстом, в комментариях.

Ответственность, за все изменения, внесённые в систему по советам данной статьи, Вы берёте на себя.

Копирование статьи "Динамическое окно перегрузки", без указания ссылки на сайт первоисточника Компьютерные сети и многоуровневая архитектура интернета (conlex.kz), строго запрещено.

Добавить комментарий

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