Решение, предложенное Джекобсоном, объединяет линейное и мультипликативное увеличение. При установлении соединения отправитель задает маленькое окно размером не более четырех сегментов. (Изначально начальный размер окна не превышал один сегмент, но впоследствии это значение на основании экспериментов было увеличено до четырех.) Подробнее об этом рассказывается в RFC 3390. Затем отправитель передает в сеть начальное окно. Получение пакетов подтвердится через время, равное круговой задержке. В каждом случае, когда подтверждение о получении сегмента приходит до срабатывания таймера повторной передачи, отправитель увеличивает окно перегрузки на длину одного сегмента (в байтах). Кроме того, если сегмент был получен, то в сети стало на один сегмент меньше. Поэтому в результате каждый подтвержденный сегмент позволяет отправить еще два сегмента. Таким образом, размер окна насыщения увеличивается вдвое через интервал времени, равный круговой задержке.
Этот алгоритм называется медленным стартом (slow start), однако на самом деле он не медленный — он растет экспоненциально, — особенно в сравнении с предыдущим алгоритмом, который позволяет отправлять целое окно управления потоком за один раз. Медленный старт показан на рис. 6.38. Во время первой круговой задержки (RTT) отправитель передает в сеть один пакет (и приемник получает один пакет). Во время второй круговой задержки передается два пакета, во время третьей — четыре.
Рис. 6.38. Медленный старт с начальным окном перегрузки в один сегмент
Медленный старт хорошо работает для широкого диапазона значений скорости и круговой задержки. Чтобы регулировать скорость отправки в зависимости от сетевого пути, он использует скорость прихода подтверждений. Посмотрим на то, как подтверждения возвращаются от отправителя к получателю (рис. 6.38). Когда отправитель получает подтверждение, он увеличивает окно насыщения на единицу и сразу же передает в сеть два пакета. (Один пакет соответствует увеличению окна на единицу, а второй передается взамен пакета, прибывшего на место назначения и таким образом покинувшего сеть. В каждый момент времени число неподтвержденных пакетов определяется окном перегрузки.) Однако эти два пакета не обязательно придут на хостполучатель с таким же интервалом, с каким они были отправлены. Пусть, например, отправитель подключен к сети Ethernet мощностью 100 Мбит/с. На отправку каждого 1250-байтного пакета уходит 100 мкс. Поэтому интервал между пакетами может быть маленьким, от 100 мкс. Ситуация меняется, если путь следования пакетов проходит через ADSL-линию мощностью 1 Мбит/с. Теперь для отправки такого же пакета требуется 10 мс. Таким образом, минимальный интервал между пакетами возрастает, по меньшей мере, в 100 раз. Этот интервал так и останется большим, если только в какой-то момент пакеты не будут все вместе ожидать отправки в одном буфере.
На рис. 6.38 описанный эффект можно увидеть, если посмотреть на интервал прибытия пакетов на приемник. Этот интервал сохраняется при отправке подтверждений и, следовательно, при их получении отправителем. Если сетевой путь медленный, подтверждения приходят медленно (через время, равное круговой задержке). Если сетевой путь быстрый, подтверждения приходят быстро (опять же через время, равное круговой задержке). Отправитель должен просто учитывать скорость прихода подтверждений при отправке новых пакетов, — а это и делает алгоритм медленного старта.
Поскольку алгоритм медленного старта приводит к экспоненциальному росту, в какой-то момент (скорее рано, чем поздно) в сеть будет слишком быстро отправлено слишком много пакетов. В результате на маршрутизаторах выстроятся очереди. Когда очереди переполняются, происходит потеря пакетов. В таком случае, когда подтверждение о доставке этого пакета не придет на хост-отправитель, сработает соответствующий таймер. На рис. 6.38 можно увидеть, в какой момент окно насыщения оказалось слишком большим. Через три круговых задержки в сети находится четыре пакета. Чтобы добраться до получателя, этим пакетам требуется время, равное целой круговой задержке. Это значит, что для данного соединения подходит окно перегрузки размером в четыре пакета. Но так как получение этих пакетов подтверждается, алгоритм медленного старта продолжает увеличивать окно перегрузки, и в результате через одну круговую задержку отправитель посылает в сеть восемь пакетов. Независимо от того, сколько пакетов отправлено, только четыре из них успевают дойти до места назначения за одну круговую задержку. Это значит, что сетевая шина заполнена. Дополнительные пакеты, попадая в сеть, будут застревать в очередях на маршрутизаторах, так как сеть не может достаточно быстро доставлять их получателю. Вскоре возникнут заторы и потери пакетов.
Чтобы контролировать медленный старт, отправитель должен хранить в памяти пороговое значение для каждого соединения. Оно называется порогом медленного старта (slow start threshold). Изначально устанавливается произвольное высокое значение, не превышающее размер окна управления потоком, чтобы оно никак не ограничивало возможности соединения. Используя алгоритм медленного старта, TCP продолжает увеличивать окно перегрузки, пока не произойдет тайм-аут или размер окна перегрузки не превысит пороговое значение (или не заполнится окно получателя).
При обнаружении потери пакета (например, в ситуации тайм-аута) порог медленного старта устанавливается равным половине окна перегрузки, и весь процесс начинается заново. Идея в том, что если текущее окно перегрузки слишком велико, оно вызывает перегрузку, которую удается зафиксировать с опозданием. Вдвое меньший размер окна, при котором перегрузок не было, лучше подходит для окна перегрузки: пропускная способность пути используется довольно эффективно, а потерь данных не происходит. В нашем примере на рис. 6.38 увеличение окна до восьми пакетов может вызвать потерю данных, тогда как окно размером четыре пакета хорошо подходит. После этого размер окна перегрузки устанавливается равным начальному значению, и алгоритм медленного старта выполняется сначала.
При превышении порога медленного старта TCP переключается с медленного старта на аддитивное увеличение. В этом режиме окно перегрузки увеличивается на один сегмент через промежутки времени, равные круговой задержке. Как и в случае медленного старта, увеличение происходит по мере получения подтверждений о доставке, а не ровно на один сегмент на каждом круге. Пусть cwnd — окно перегрузки, а MSS — максимальный размер сегмента. Обычно увеличение окна производится с коэффициентом (MSS х MSS)/cwnd для каждого из cwnd/MSS пакетов, доставка которых может быть подтверждена. Это увеличение не обязано быть быстрым. Общая идея состоит в том, чтобы TCP-соединение максимально долго работало с размером окна, близким к оптимальному, — не слишком маленьким, чтобы пропускная способность не была низкой, и не слишком большим, чтобы не возникало заторов.
Аддитивное увеличение показано на рис. 6.39. Ситуация та же, что и для медленного старта. В конце каждого круга окно перегрузки отправителя увеличивается так, что в сеть может быть передан один дополнительный пакет. По сравнению с медленным стартом линейная скорость роста оказывается очень низкой. Для маленьких окон разница будет не очень существенной, но она станет ощутимой, если, к примеру, вам нужно увеличить окно на 100 сегментов.
Рис. 6.39. Аддитивное увеличение при начальном окне размером один сегмент
Здесь кое-что можно улучшить, тем самым повысив производительность. Дело в том, что недостатком этой схемы является ожидание тайм-аута. Время ожидания подтверждения обычно бывает большим, так как его оценка должна быть заниженной. Если пакет будет потерян, приемник не отправит соответствующее подтверждение, так что номер подтверждения не изменится. Отправитель не сможет отправить в сеть новые пакеты, так как его окно все еще будет полным. В таком состоянии хост может пробыть довольно долго, пока не сработает таймер и не произойдет повторная передача пакета. В этот момент медленный старт начинается заново.
