Компьютерные сети. 6-е изд.

На илл. 6.21 показан пример распределения пропускной способности, которая меняется со временем и быстро сходится. Изначально поток 1 получает всю емкость канала. Через секунду начинает работать поток 2. Ему тоже нужна пропускная способность. Поэтому распределение быстро меняется таким образом, чтобы оба потока получали по 1/2. Еще через три секунды появляется третий поток. Но он использует только 20 % пропускной способности — меньше, чем то, что ему полагается исходя из принципа равнодоступности (1/3). Потоки 1 и 2 быстро реагируют на изменение ситуации, и каждый из них получает 40 %. На 9-й секунде второй поток отключается, а третий продолжает работать без изменений. Поток 1 быстро занимает 80 % ресурса. В каждый момент времени суммарная пропускная способность приблизительно равна 100 %, то есть возможности сети используются полностью; при этом все конкурирующие потоки находятся в равных условиях (но не используют больше пропускной способности, чем им нужно).

Илл. 6.21. Изменение распределения пропускной способности с течением времени

6.3.2. Регулирование скорости отправки

Теперь самое время перейти к основному вопросу: как регулировать скорость отправки, чтобы получить необходимую пропускную способность? Скорость отправки может зависеть от двух факторов. Первый фактор — управление потоком данных, которое требуется, если буфер получателя обладает недостаточной емкостью. Второй — перегрузка, которую нужно учитывать при недостаточной пропускной способности сети. На илл. 6.22 эта проблема представлена на примере водопровода.

На илл. 6.22 (а) мы видим толстую трубу, ведущую к получателю с небольшой емкостью. Это тот случай, когда ограничительным фактором является управление потоком. Пока отправитель не передает больше воды, чем может поместиться в ведро, вода не будет проливаться. На илл. 6.22 (б) ограничительным фактором является не емкость ведра, а пропускная способность сети. Если из крана в воронку вода будет литься слишком быстро, то уровень воды в воронке начнет подниматься, и в конце концов часть воды может перелиться через край.

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

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

Илл. 6.22. (а) Быстрая сеть и получатель с малой емкостью. (б) Медленная сеть и получатель с большой емкостью

Пример явной точной обратной связи — ситуация, когда маршрутизаторы сообщают источникам свою допустимую скорость отправки. Так работает, к примеру, явный протокол перегрузки (eXplicit Congestion Protocol, XCP) (Катаби и др.; Katabi et al., 2002). Явная и неточная схема — использование явного уведомления о перегрузке (Explicit Congestion Notification, ECN) с TCP. В этом случае маршрутизаторы специальным образом маркируют пакеты, страдающие от перегрузки, сообщая отправителю, что ему следует уменьшить скорость передачи данных, но не указывая насколько.

В других схемах явный сигнал отсутствует. FAST TCP измеряет задержку в пути туда и обратно и использует ее в качестве параметра для контроля перегрузки (Вэй и др.; Wei et al., 2006). Наиболее распространенный в современном интернете метод контроля перегрузки использует TCP и маршрутизаторы с отбрасыванием конца очереди или RED-маршрутизаторы. Показателем перегрузки в этом случае является число потерянных пакетов. Существует множество вариантов такого TCP, в частности, CUBIC TCP, используемый в системе Linux (Ха и др; Ha et al., 2008). Возможны комбинации нескольких методов. Например, Windows содержит Compound TCP (составной TCP), где в качестве сигналов обратной связи используется и задержка, и число потерянных пакетов (Тань и др.; Tan et al., 2006). Все эти варианты представлены в таблице на илл. 6.23.

Протокол

Сигнал

Явный?

Точный?

XCP

Скорость, которую следует использовать

Да

Да

TCP с ECN

Предупреждение о перегрузке

Да

Нет

FAST TCP

Сквозная задержка

Нет

Да

Compound TCP

Потеря пакетов и сквозная задержка

Нет

Да

CUBIC TCP

Потеря пакетов

Нет

Нет

TCP

Потеря пакетов

Нет

Нет

Илл. 6.23. Сигналы некоторых протоколов контроля перегрузки