Реакция на истечение интервала ожидания
Согласно предыдущему описанию, размер окна перегрузок протокола TCP, будучи изначально равным величине MSS, экспоненциально растет до первой потери пакета, после чего в силу вступает алгоритм аддитивного увеличения и мультипликативного уменьшения. Эта картина уже весьма близка к реальной, однако и она останется неполной, если мы не раскроем еще одну деталь механизма контроля перегрузок TCP: оказывается, по истечении интервала ожидания протоколом предпринимаются иные действия, нежели при получении трех дублирующих квитанций. В последнем случае поведение TCP соответствует описанному выше: размер окна перегрузки уменьшается вдвое, а затем начинает линейно расти. Однако по истечении интервала ожидания передающая сторона TCP входит в состояние медленного старта, уменьшая размер окна перегрузки до величины MSS и далее позволяя ему увеличиваться по экспоненциальному закону до тех пор, пока он не достигнет половины своего значения до истечения интервала ожидания. После этого рост значения CongWin вновь становится линейным.
Для реализации этого усложненного механизма TCP поддерживает специальную переменную Threshold (пороговое значение), определяющую размер окна перегрузки, при котором происходит окончание фазы медленного старта и начинается фаза ухода от перегрузки. Обычно по умолчанию для переменной Threshold используется большое значение (чаще всего 65 Кбайт), чтобы минимизировать влияние этой переменной в начале передачи. При потере пакета значение Threshold становится равным половине текущего значения CongWin. Например, если перед потерей пакета размер окна перегрузки составлял 20 Кбайт, то переменная Threshold окажется равной 10 Кбайт и сохранит это значение до следующей потери пакета.
Зная о существовании переменной Threshold, мы можем уточнить описание механизма управления значением переменной CongWin после истечения интервала ожидания. Как показано выше, передающая сторона TCP входит в состояние медленного старта. Величина CongWin экспоненциально увеличивается до тех пор, пока не достигнет значения Threshold. После этого TCP вступает в фазу ухода от перегрузки, где CongWin увеличивается линейно.
Резюмируя изложенные выше идеи, алгоритм контроля перегрузки протокола TCP можно представить следующим образом.
□ Когда размер окна перегрузки не превышает пороговую величину (Threshold), передающая сторона находится в фазе медленного старта, и размер окна перегрузки растет экспоненциально.
□ Когда размер окна перегрузки превышает пороговую величину, Передающая сторона находится в фазе ухода от перегрузки, и размер окна перегрузки растет линейно.
□ При получении трех дублирующих квитанций пороговая величина устанавливается равной половине текущего значения размера окна перегрузки, а размер окна перегрузки становится равным пороговому значению.
□ По истечении интервала ожидания пороговая величина устанавливается равной половине текущего значения размера окна перегрузки, а размер окна перегрузки становится равным величине MSS.
Вызывает интерес вопрос о причине разных моделей поведения протокола TCP при истечении интервала ожидания и при получении трех дублирующих квитанций. Другими словами, чем обусловлена «осторожность» TCP, заставляющая его снижать размер окна перегрузки до минимального значения по истечении интервала ожидания, и почему получение трех дублирующих квитанций вызывает «урезание» окна перегрузки лишь вдвое? Ранняя версия TCP, TCP Tahoe, в обоих случаях устанавливала размер окна перегрузки равным величине MSS и входила в фазу медленного старта. Более поздняя версия, TCP Reno, предусматривает выход из фазы медленного старта при получении трех дублирующих квитанций. Логика этой модификации заключается в том, что наличие трех квитанций указывает не только на потерю одного сегмента, но и на успешную доставку трех следующих за ним сегментов. Следовательно, в отличие от ситуации с истечением интервала ожидания, сеть способна успешно доставлять, по крайней мере, часть передаваемых сегментов. «Досрочный» выход из фазы медленного старта при получении трех дублирующих квитанций называется ускоренным восстановлением.
На рис. 3.47 показаны графики изменения размера окна перегрузки для версий Reno и Tahoe протокола TCP. В рассматриваемом случае начальное пороговое значение составляет 8 х MSS. Размер окна перегрузки экспоненциально растет и достигает порогового значения в четвертой фазе передачи. Затем размер окна увеличивается линейно до тех пор, пока передающая сторона не получит трех дублирующих квитанций в конце восьмой фазы; при этом размер окна составляет 12 х MSS.
Пороговое значение устанавливается равным 0,5 х 12 х MSS = 6 х MSS. В протоколе TCP Reno новый размер окна также становится равным 6 х MSS и далее увеличивается по линейному закону. TCP Tahoe, напротив, устанавливает размер окна равным 1 х MSS и экспоненциально наращивает его до тех пор, пока он не превысит порогового значения.
Как было показано ранее, в большинстве современных реализаций TCP используется алгоритм Reno. Существует множество модификаций этого алгоритма (RFC 2018, RFC 2582). Так, например, в алгоритме Вегаса предпринимается попытка избежать перегрузок и одновременно обеспечить высокую скорость передачи. Основными идеями алгоритма Вегаса являются обнаружение перегрузок в маршрутизаторах на пути соединения до появления потерь пакетов и линейное снижение скорости передачи при перегрузках. Прогнозирование перегрузок осуществляется путем анализа времени оборота: чем больше это время, тем более значительной является перегрузка в маршрутизаторах.
Необходимо отметить, что контроль перегрузок протокола TCP эволюционировал много лет и процесс его развития не завершен. Механизмы, использовавшиеся в период, когда большинство TCP-соединений поддерживало протоколы SMTP, FTP и Telnet, являются не столь эффективными в современном Интернете, где доминирующее положение занимает HTTP. Службы, которые будут созданы в будущем, также потребуют новых механизмов контроля перегрузки.