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

Рис. 6.18. Изменение распределения пропускной способности с течением времени
6.3.2. Регулирование скорости отправки
Теперь самое время перейти к основному вопросу: как можно регулировать скорость отправки, чтобы получить необходимую пропускную способность? Скорость отправки может зависеть от двух факторов. Первый из них — управление потоком данных, которое требуется, если буфер получателя обладает недостаточной емкостью. Второй фактор — перегрузка, которую необходимо учитывать при недостаточной пропускной способности сети. На рис. 6.19 эта проблема проиллюстрирована на примере водопровода. На рис. 6.19, а мы видим толстую трубу, ведущую к получателю с небольшой емкостью. Это тот случай, когда ограничительным фактором является управление потоком данных. До тех пор пока отправитель не посылает воды больше, чем может поместиться в ведро, вода не будет проливаться. На рис. 6.29, б ограничительным фактором является не емкость ведра, а пропускная способность сети. Если из крана в воронку вода будет литься слишком быстро, то уровень воды в воронке начнет подниматься, и, в конце концов, часть воды может перелиться через край воронки.
Отправителю эти примеры могут показаться похожими, так как в обоих случаях результатом слишком быстрой передачи данных является потеря пакетов. Но поскольку эти ситуации происходят по разным причинам, они требуют разных решений. Об одном из возможных решений — управлении потоком данных с помощью окна переменного размера — мы уже говорили. Теперь мы рассмотрим другое решение, связанное с управлением перегрузкой. Поскольку на практике может произойти любая из этих проблем, транспортный протокол должен включать реализацию обоих решений.
То, как транспортный протокол должен регулировать скорость отправки, зависит от формы обратной связи, использующейся в сети. Разные сетевые уровни могут использовать обратную связь разных типов: явную и неявную, точную и неточную.
Пример явной точной обратной связи — ситуация, когда маршрутизаторы сообщают источникам свою допустимую скорость отправки. Так работает, к примеру, XCP (eXplicit Congestion Protocol) (Katabi и др., 2002). Явная и неточная схема — использование ECN (Explicit Congestion Notification, явное уведомление о насыщении) с TCP. В этом случае маршрутизаторы специальным образом маркируют пакеты, страдающие от перегрузки, и таким образом сообщают отправителю, что ему следует уменьшить скорость передачи данных, не указывая при этом, насколько сильно ее нужно уменьшить.

Рис. 6.19. Быстрая сеть и получатель малой емкости (а); медленная сеть и получатель большой емкости (б)
В других схемах явный сигнал отсутствует. FAST TCP измеряет круговую задержку и использует ее в качестве параметра для контроля перегрузки (Wei и др., 2006). Наконец, метод контроля перегрузки, наиболее распространенный в современном Интернете, использует TCP и маршрутизаторы с отбрасыванием конца очереди или маршрутизаторы со случайным ранним обнаружением перегрузки. Показателем перегрузки сети в нем является число потерянных пакетов. Существует множество вариантов этого вида TCP — в частности, CUBIC TCP, использующийся в системе Linux (Ha и др., 2008). Возможны также комбинации нескольких методов. К примеру, Windows включает Compound TCP (составной TCP), в котором показателями насыщения являются и круговая задержка, и число потерянных пакетов (Tan и др., 2006). Эти схемы показаны в табл. 6.3.
Читать дальше
Конец ознакомительного отрывка
Купить книгу