Борьба с перегрузкой в TCP

Прежде всего перегрузку сети надо уметь обнаружить. Все TCP-алгоритмы Интернета предполагают, что потери пакетов вызываются в основном перегрузкой сети и, следовательно, являются её индикатором.

Основная идея борьбы с перегрузкой сети состоит в признании существования двух потенциальных проблем: низкой пропускной способности сети и низкой емкости получателя — и в раздельном решении этих проблем. Для этого у каждого отправителя есть два окна: окно, предоставленное получателем, и окно перегрузки. Размер каждого из них соответствует количеству байтов, которое отправитель имеет право передать. Отправитель руководствуется минимальным из этих двух значений.

При установке соединения отправитель устанавливает размер окна перегрузки равным размеру максимального используемого в данном соединении сегмента. Затем он передает один максимальный сегмент. Если подтверждение получения этого сегмента прибывает прежде, чем истекает период ожидания (о самом периоде ожидания мы поговорим чуть позже), к размеру окна добавляется размер сегмента, то есть размер окна перегрузки удваивается, и посылаются уже два сегмента. В результате, подтверждение каждой последовательности сегментов приводит к удвоению окна перегрузки. Этот процесс экспоненциального роста продолжается до тех пор, пока не будет достигнут размер окна получателя или не будет выработан признак тайм-аута, сигнализирующий о перегрузке в сети. Например, если пакеты размером 1024, 2048 и 4096 байт дошли до получателя успешно, а в ответ на передачу пакета размером 8192 байта подтверждение не пришло в установленный срок, окно перегрузки устанавливается равным 4096 байтам. Пока размер окна перегрузки остается равным 4096 байтам, более длинные пакеты не посылаются, независимо от размера окна, предоставляемого получателем. Этот алгоритм называется алгоритмом медленного пуска Джекобсона (Jacobson, 1988). Он поддерживается всеми реализациями протокола.

Помимо окон получателя и перегрузки, в реально используемом механизме есть и третий параметр: пороговое значение, которое изначально устанавливается равным 64 Кбайт. Когда возникает ситуация тайм-аута (подтверждение не возвращается в срок), новое значение порога устанавливается равным половине текущего размера окна перегрузки, а окно перегрузки уменьшается до размера одного максимального сегмента. Затем, так же как и в предыдущем случае, используется алгоритм медленного пуска, позволяющий быстро обнаружить предел пропускной способности сети. Однако на этот раз экспоненциальный рост размера окна останавливается по достижении им порогового значения, после чего окно увеличивается линейно, на один сегмент для каждой следующей передачи. Предполагается, что при возникновении перегрузки можно урезать вдвое размер окна перегрузки, после чего постепенно наращивать его.

Таймеры TCP

Протокол TCP использует четыре таймера.

Таймер повторной передачи (retransmission) используется при ожидании подтверждения. Когда посылается сегмент, запускается таймер повторной передачи. Если подтверждение получения сегмента прибывает раньше, чем истекает период таймера, таймер останавливается. Если же, наоборот, период ожидания истечет раньше, чем прибудет подтверждение, сегмент передается еще раз (а таймер запускается снова).

Однако предсказать, сколько потребуется времени для прохождения данных от отправителя до получателя и обратно, весьма непросто. Если выбрать значение интервала ожидания слишком малым, возникнут излишние повторные передачи, забивающие сеть бесполезными пакетами. Если же установить значение этого интервала слишком большим, то из-за увеличения времени ожидания в случае потери пакета пострадает производительность. Более того, среднее значение и величина дисперсии времени прибытия подтверждений может существенно изменяться всего за несколько секунд.

Решение заключается в использовании динамичного алгоритма, постоянно изменяющего величину периода ожидания, основываясь на измерениях производительности сети. Алгоритм, применяемый в TCP, разработан Джекобсоном (Jacobson) в 1988 году. Для каждого соединения в протоколе TCP предусмотрена переменная RTT (Round-Trip Time — время перемещения в оба конца), в которой хранится наименьшее время получения подтверждения для данного соединения. При передаче сегмента запускается таймер, который измеряет время, требуемое для получения подтверждения, а также запускает повторную передачу, если подтверждение не приходит в срок. Если подтверждение успевает вернуться прежде чем истечет период ожидания, ТСР измеряет время, потребовавшееся для его получения и обновляет значение переменной RTT по определенному алгоритму. Само же время ожидания подтверждения вычисляется по RTT с учетом его дисперсии.

При динамической оценке величины RTT возникает вопрос, что делать со значением RTT при повторной передаче сегмента. В этом случае непонятно, относится это подтверждение к первой попытке передаче пакета или же к последней. Было решено при каждой повторной передаче время ожидания удваивать до тех пор, пока сегменты не пройдут с первой попытки. Это решение получило название алгоритма Карна. Он применяется в большинстве реализаций протокола TCP.

Таймер настойчивости (persist) определяет время, в течении которого протокол ждет информацию о ненулевом размере окна получателя. Предположим, что получатель послал подтверждение, в котором указал окно нулевого размера, давая тем самым отправителю команду подождать. Через некоторое время получатель посылает пакет с новым размером окна, но этот пакет теряется. Теперь обе стороны ожидают действий противоположной стороны. Когда срабатывает таймер настойчивости, отправитель посылает получателю пакет с вопросом, не изменилось ли текущее состояние. В ответ получатель сообщает текущий размер окна. Если он все еще равен нулю, таймер настойчивости запускается снова, и весь цикл повторяется.

Таймер времени жизни (keepalive) определяет, когда можно считать, что удаленный конец вышел из строя или перезагрузился. Когда соединение не используется в течение долгого времени, этот таймер заставляет проверить в рабочем ли состоянии другой конец соединения. Если проверяющая сторона не получает ответа, соединение разрывается.

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

Как и все в нашем мире протокол TCP не идеален. Одним из его существенных недостатков является использование факта потери пакетов в качестве единственного индикатора перегрузки канала. Этот алгоритм удобен для хороших линий связи, но при использовании технологий, которые в принципе не могут обеспечить очень малой вероятности потери данных при передаче, это становиться не самым лучшим вариантом. У TCP возникают проблемы и на высокоскоростных каналах связи с большим временем доставки (например, спутниковые). В этом случае описанные процедуры оптимизации скорости передачи данных требуют неприемлемо длительного времени. Не приспособлен TCP и к работе в условиях переменной загрузки используемого канала.

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