L10-Сети (tcp v2)

Управление потоком

Контроль перегрузки (Вопрос 1)

Вопрос: Почему при потере сегмента CWND делается равным 1, а не CWND-1 или CWND/2 ? Ведь эффективность канала максимальна при наибольшем, возможном значении CWND

Ответ: Если произошла потеря сегмента из-за переполнения буфера, оптимальное значение CWND может быть выбрано лишь при исчерпывающем знании прогноза состояния виртуального канала

Постольку такая информация обычно недоступна, система переходит в режим освобождения буфера (CWND=1). Ведь если потеря была

связана с началом сессии обмена с конкурирующим клиентом,

операция CWND= CWND-1 проблему не решит. А потеря пакета вызовет таймаут и канал будет блокирован минимум на 1 секунду, что вызовет резкое падение скорости передачи

Управление потоком

узкие места

Покажем, что скорость поступления подтверждений лимитируется наличием «узких мест» в сети между отправителем и получателем.

«Узким местом» может быть: либо сетевое устройство, либо часть канала, пропускная способность которого значительно уступает скоростным показателям сети в целом, либо станция-получатель.

«Узкие места» можно разделить на логические и физические

Если отправитель имеет пропускную способность 10 Мбит/с, то канал со скоростью 1,5 Мбит/с между маршрутизаторами становится физическим «узким местом» для работы протокола ТСР.

В таком случае после достижения устойчивого режима передачи протокол TCP будет эффективно использовать доступную пропускную способность.

Управление потоком

узкие места

Примеры логических и физических «узких мест»

Управление потоком

узкие места

Логические «узкие места» образуются из-за наличия очередей в маршрутизаторах, коммутаторах или на станциях-получателях

Задержки в очередях, как правило, подвержены флуктуациям и усложняют процесс формирования устойчивого потока данных

Флуктуации задержек, которые образуются в распределенных IP-сетях, затрудняют выбор политики отсылки данных протоколом TCP на стороне отправителя

Управление потоком

узкие места

Если поток имеет слишком маленькую скорость, то распределенная сеть будет задействоваться неэффективно

Если один или несколько отправителей передают данные на повышенной скорости, то другие потоки TCP будут «зажаты» потоками, исходящими от этих отправителей

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

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

Стратегии отправителя

Казалось бы, чем больше окно, тем больше сегментов отсылается до момента получения очередного подтверждения

На практике, в установившемся режиме передачи данных скорость отправки сегментов регулируется за счет автосинхронизации протокола

И гораздо сложнее выбрать такие начальную скорость передачи данных (сразу же после создания соединения) и алгоритм ее повышения, которые не позволят заполнить сегментами весь канал связи

Решить задачу можно двумя способами

Первый способ стратегии поведения отправителя:

отправитель начинает посылать данные с относительно большим размером окна

постепенно увеличивая размер окна до значения, которое оптимально для стационарного режима передачи

Однако существует риск заполнения распределенной сети множеством сегментов до того момента, когда отправитель поймет, что он посылает данные со слишком большим темпом (скоростью)

Очевидно, что основной недостаток этого способа — возможность изначального выбора слишком большого окна отсылки

Стратегии отправителя

«Медленный старт»

Второй способ стратегии поведения отправителя

использовании сразу после формирования соединения минимального размера окна отсылки, который ни при каких обстоятельствах не вызовет перегрузку сети

«Изюминка» этого подхода — наращивание размера окна отсылки с помощью алгоритма «Медленный старт»

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

AWND = min [CREDIT, CWND]

AWND — разрешенный размер окна передачи в сегментах (разрешенный для использования для реализации стратегии отправителя )

CWND — размер окна перегрузки в сегментах, используемого в начальный период работы и позволяющего снизить скорость при возникновении

перегрузки

CREDIT —размер окна, выданый получателем в самых последних подтверждениях

«Медленный старт»

При создании нового соединения TCP устанавливает окно перегрузки CWND равным единице

Это означает, что отправитель может послать только один сегмент и должен дождаться подтверждения о его успешном приеме, прежде чем отправить следующий сегмент

Каждый раз, когда поступает подтверждение, значение окна CWND увеличивается на единицу

Так происходит до тех пор, пока размер данного окна не достигнет максимального значения

Поскольку отправитель увеличивает свое окно отсылки только по мере

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

Описанный алгоритм правильнее было бы назвать «Экспоненциальным стартом»,

«Медленный старт»

Сказанное иллюстрирует рис. 10. В этом примере станция А посылает сегмент размером 100 байт и по истечении приблизительно четырехкратного времени обращения RTT получает возможность заполнить канал связи непрерывным потоком своих сегментов.

Алгоритм «Медленный старт» достаточно эффективен при установлении соединения. Он позволяет протоколу TCP на стороне отправителя быстро определить оптимальный размер окна для данного соединения. Но что делать, если, несмотря на принятые меры, перегрузка все-таки возникла?

Предположим, что устанавливается соединение с «Медленным стартом» и прежде чем увеличивающийся размер окна перегрузки CWND достигает

лимита, выделенного отправителю другой стороной, происходит потеря

сегмента. Этот факт может свидетельствовать о перегруженности сети, однако данных, позволяющих оценить серьезность возникшей ситуации, практически не существует. А раз так, то самым очевидным решением будет сброс размера окна перегрузки CWND до первоначального единичного значения и повторный запуск процедуры «Медленный старт».

«Медленный

старт»

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