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

6.3. Контроль перегрузки

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

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

6.3.1. Выделение требуемой пропускной способности

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

Эффективность и мощность

При эффективном распределении пропускной способности между транспортными подсистемами должны использоваться все возможности сети. Однако это не значит, что в канале со скоростью 100 Мбит/с каждая из пяти подсистем получит по 20 Мбит/с. Для хорошей производительности им необходимо выделить меньшую мощность. Причина в том, что трафик часто бывает неравномерным. В разделе 5.3 мы определили полезную пропускную способность (goodput), скорость, с которой полезные пакеты приходят к получателю, как функцию абонентской нагрузки на сеть. Эта кривая и соответствующая ей кривая задержки (как функция нагрузки) приведены на илл. 6.19.

Илл. 6.19. (а) Полезная пропускная способность. (б) Задержка как функция нагрузки

С повышением нагрузки на сеть полезная пропускная способность увеличивается с постоянной скоростью (илл. 6.19 (а)), но по мере того как их значения сближаются, рост полезной пропускной способности замедляется. Этот спад необходим, чтобы предотвратить переполнение буферов сети и потерю данных в случае всплесков трафика. Если транспортный протокол повторно передает задерживающиеся, но не потерянные пакеты, может произойти отказ сети из-за перегрузки. В таком случае отправители продолжают передавать все больше и больше пакетов, а пользы от этого все меньше и меньше.

График задержки пакетов приведен на илл. 6.19 (б). Сначала она постоянна и соответствует задержке распространения в сети. Когда значение нагрузки приближается к значению пропускной способности, задержка возрастает, сначала медленно, а затем все быстрее. Это также происходит из-за всплесков трафика, которые возрастают при высокой нагрузке. Задержка не уйдет в бесконечность (разве что в модели, где у маршрутизаторов бесконечный буфер). Вместо этого пакеты будут теряться при переполнении буферов.

Что касается полезной пропускной способности и задержки, производительность начинает снижаться в момент возникновения перегрузки. Логично, что мы получим наилучшую производительность сети, если будем выделять пропускную способность, пока задержка не начнет быстро расти. Эта точка находится ниже пропускной способности сети. Чтобы ее определить, Клейнрок (Kleinrock) в 1979 году предложил ввести метрику мощность (power), которая вычисляется по формуле:

.

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

Равнодоступность по максиминному критерию

Мы еще не говорили о том, как распределять пропускную способность между несколькими отправителями. Кажется, что ответ очень прост: можно разделить пропускную способность между ними поровну. Но на самом деле все намного сложнее.

Во-первых, какое отношение эта проблема имеет к контролю нагрузки? Ведь если сеть предоставляет отправителю некоторое количество пропускной способности, он должен просто использовать то, что у него есть. Но на практике сети часто не резервируют строго ограниченное количество пропускной способности для потока или соединения. Конечно, они могут это делать для некоторых потоков (если есть поддержка QoS), но как правило, соединения стремятся использовать максимум доступной пропускной способности; также возможен вариант, когда сеть выделяет ресурсы группе соединений для совместного использования. К примеру, дифференцированное обслуживание IETF делит трафик на два класса, и соединения конкурируют друг с другом в пределах каждого из этих классов. Часто все соединения одного IP-маршрутизатора используют общую пропускную способность. В таких случаях распределение ресурсов между конкурирующими соединениями должно осуществляться за счет механизмов контроля нагрузки.

Во-вторых, не совсем ясно, что означает равнодоступность для потоков в сети. Если N потоков используют один канал, то решение довольно простое: каждому выделяется 1/N пропускной способности (в случае импульсного трафика эта величина немного меньше по соображениям эффективности). Но что, если потоки используют разные, но пересекающиеся пути? К примеру, если один поток проходит по трем каналам, а остальные — по одному? Очевидно, что поток, идущий по трем каналам, потребляет больше сетевых ресурсов. Поэтому в некотором смысле справедливее было бы выделить ему меньше пропускной способности, чем остальным. Кроме того, неплохо было бы добавить новые одноканальные потоки за счет уменьшения пропускной способности трехканального. На этом примере видно, что между эффективностью и равнодоступностью всегда существуют противоречия.

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

Часто в сетях удобнее использовать равнодоступность по максиминному критерию (max-min fairness). Это значит, что увеличение пропускной способности одного потока невозможно без ее уменьшения для какого-либо другого потока с меньшей или равной пропускной способностью. Иными словами, от увеличения пропускной способности потока страдают менее «обеспеченные» потоки.

Рассмотрим пример. На илл. 6.20 показано распределение пропускной способности по максиминному критерию в сети с четырьмя потоками: A, B, C и D. Все каналы между маршрутизаторами имеют одинаковую пропускную способность, принятую за 1 (хотя на практике она обычно разная). На пропускную способность канала R4–R5, расположенного слева внизу, претендуют три потока. Поэтому каждый из них получает по 1/3. Оставшийся поток A конкурирует с B на участке R2–R3. Поскольку для B уже выделена 1/3 емкости канала, A получает оставшееся количество, 2/3. Как видно из рисунка, на остальных каналах часть ресурсов не используется. Но их нельзя отдать какому-либо потоку, не снизив пропускную способность другого, более медленного. К примеру, если на участке R2–R3 выделить больше емкости потоку B, то A достанется меньше. Это логично, поскольку на данный момент у A пропускной способности больше. А чтобы обеспечить большую емкость канала для B, ее придется снизить для C или D (или для обоих), и тогда она станет меньше пропускной способности B. Данное распределение соответствует максиминному критерию.

Илл. 6.20. Распределение пропускной способности по максиминному критерию для четырех потоков

Такое распределение пропускной способности можно вычислить на основе данных обо всей сети. Чтобы представить это наглядно, предположим, что скорость всех потоков медленно возрастает, начиная от 0. Как только один из потоков достигает узкого места, его скорость перестает расти. Скорость остальных потоков продолжает увеличиваться (при этом доступная пропускная способность делится поровну), пока каждый из них не дойдет до своего узкого места.

Третий вопрос, возникающий при обсуждении равнодоступности, — на каком уровне ее рассматривать? Сеть может быть справедливой на уровне соединений, соединений между парой хостов или всех соединений одного хоста. Этой проблемы мы касались, когда говорили о взвешенном справедливом обслуживании (см. раздел 5.4): выяснилось, что с каждым из этих вариантов связаны определенные трудности. К примеру, если считать равноправными все хосты, активно работающий сервер будет получать не больше ресурсов, чем обычный мобильный телефон; если же таковыми считать все соединения, хостам выгодно открывать дополнительные линии. На этот вопрос нет однозначного ответа, и равнодоступность часто реализуется на уровне соединений, однако она совсем не обязана быть идеальной. В первую очередь важно, чтобы ни одно соединение не осталось без пропускной способности. На самом деле протокол TCP позволяет создавать множественные соединения, что вызывает еще более жесткую конкуренцию. Эта тактика подходит для особенно ресурсоемких приложений. Например, ее использует BitTorrent для однорангового совместного использования файлов.

Конвергенция

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

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

На илл. 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. Сигналы некоторых протоколов контроля перегрузки

Получив явный и точный сигнал, транспортная подсистема может установить скорость отправки пакетов в соответствии с новым рабочим режимом. К примеру, если XCP сообщает отправителям рекомендуемую скорость, они могут просто использовать ее. Но в остальных случаях транспортные подсистемы вынуждены действовать наугад. В отсутствие сигнала о перегрузке отправители должны увеличивать скорость отправки, а при наличии — уменьшать. Рост и снижение скорости происходит согласно закону управления (control law). Он оказывает решающее влияние на производительность.

Рассматривая бинарный сигнал о перегрузке, Чиу и Джейн (Chiu and Jain, 1989) пришли к выводу, что закон аддитивного увеличения и мультипликативного уменьшения (Additive Increase Multiplicative Decrease, AIMD) позволяет эффективно вычислять рабочий режим с учетом идеи равнодоступности. Чтобы это показать, они привели простой наглядный пример, в котором два соединения соперничают друг с другом за ресурс общего канала. На илл. 6.24 пропускная способность для пользователя 1 располагается на оси X, а для пользователя 2 — на оси Y. При справедливом распределении оба пользователя получают одинаковое количество ресурса. Оно обозначено с помощью прямой равнодоступности (пунктирная линия). Когда суммарная пропускная способность, выделяемая всем пользователям, составляет 100 % (то есть равна емкости канала), распределение эффективно. Оно располагается на прямой эффективности. Когда суммарная

Илл. 6.24. Аддитивное и мультипликативное регулирование пропускной способности

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

Пусть изначально пользователям 1 и 2 выделено некоторое количество пропускной способности. Посмотрим, что произойдет, если они оба начнут аддитивно ее увеличивать. К примеру, они могут повышать скорость отправки пакетов на 1 Мбит/с каждую секунду. В результате рабочий режим пересечет прямую эффективности и оба пользователя получат от сети сигнал о перегрузке. В этот момент им придется снизить свою пропускную способность. Однако аддитивное уменьшение просто приведет к колебаниям значений вдоль аддитивной прямой (см. илл. 6.24). Рабочий режим останется близким к эффективному, однако не обязательно будет справедливым.

Теперь рассмотрим ситуацию, в которой оба пользователя увеличивают свою пропускную способность мультипликативно до тех пор, пока не поступит сигнал о перегрузке. Например, они могут каждую секунду повышать скорость отправки пакетов на 10 %. Если после получения сигнала о перегрузке пользователи начнут мультипликативно уменьшать пропускную способность, рабочий режим будет колебаться вдоль мультипликативной прямой (см. илл. 6.24). Наклон мультипликативной прямой отличается от наклона аддитивной прямой. (Мультипликативная прямая проходит через начало координат, а аддитивная имеет наклон в 45°.) Однако это ничего нам не дает. Ни в том ни в другом случае оптимальная скорость отправки достигнута не будет.

Разберем другой сценарий. Предположим, пользователи аддитивно увеличивают пропускную способность, а после получения сигнала о перегрузке начинают мультипликативно ее уменьшать. Такой метод называется законом управления (AIMD control law) (илл. 6.25). Оказывается, что в результате таких преобразований рабочий режим сходится к оптимальной точке, в которой распределение пропускной способности является одновременно справедливым и эффективным, причем это происходит независимо от начальной точки. Поэтому AIMD широко применяется на практике. При обратном варианте —

Илл. 6.25. Закон управления AIMD

мультипликативном увеличении и аддитивном уменьшении — рабочий режим будет отклоняться от оптимальной точки.

TCP использует AIMD не только по этой причине, но и по соображениям стабильности (поскольку перейти в состояние перегрузки гораздо проще, чем из него выйти, политика увеличения должна быть мягкой, а уменьшения — агрессивной). Но в результате распределение пропускной способности является не совсем справедливым. Дело в том, что размер окна задается исходя из времени в пути туда и обратно (round-trip time, RTT), индивидуального для каждого соединения. Поэтому соединения с ближними хостами получают большую пропускную способность, чем соединения с удаленными хостами (при прочих равных условиях).

В разделе 6.5 мы подробно поговорим о том, как с помощью AIMD в TCP осуществляется регулировка скорости отправки пакетов и контроль перегрузки. Это гораздо сложнее, чем может показаться. Проблемы возникают из-за того, что значения скорости измеряются через определенный интервал времени, а трафик, как правило, неравномерный. Часто вместо прямого регулирования скорости задается размер раздвижного окна. Такая стратегия используется и в TCP. Если размер окна равен W, а время в пути туда и обратно — RTT, то эквивалентная скорость равна W/RTT. Это удобно, поскольку управление потоком данных также основано на регулировке размера окна. Кроме того, такой метод обладает важным преимуществом: если подтверждения о доставке пакетов перестанут приходить, через время RTT скорость отправки уменьшится.

Наконец, иногда в одной сети используются разные транспортные протоколы. Что произойдет, если они будут одновременно пытаться контролировать перегрузку с помощью разных законов управления? Ответ очевиден: распределение пропускной способности не будет справедливым. TCP — это наиболее распространенная форма контроля перегрузки в интернете. Поэтому новые транспортные протоколы настоятельно рекомендуется разрабатывать так, чтобы при совместной работе с TCP выполнялось условие справедливого распределения ресурсов. Ранние протоколы потокового вещания не соответствовали этому требованию, существенно снижая пропускную способность TCP. В итоге возникла идея дружественного к TCP контроля перегрузки, при котором транспортные протоколы TCP и не-TCP могут работать вместе, не мешая друг другу (Флойд и др.; Floyd et al., 2000).

6.3.3. Проблемы беспроводного соединения

Транспортные протоколы, включающие контроль перегрузки (такие, как TCP), не должны зависеть от используемой сети и устройства канального уровня. В теории это звучит хорошо, но на практике в случае беспроводных сетей возникают определенные проблемы. Главная заключается в том, что во многих протоколах (включая TCP) сигналом перегрузки является потеря пакетов. Но в беспроводных сетях из-за ошибок передачи потеря пакетов происходит постоянно. Просто они не столь надежны, как проводные сети.

Если протокол использует закон управления AIMD, высокая производительность требует минимальной потери пакетов. Исследования Падхая и др. (Padhye et al., 1998) показали, что пропускная способность растет обратно пропорционально квадратному корню из скорости потери пакетов. Фактически это означает, что скорость потери пакетов для быстрых TCP-соединений очень мала; в среднем этот показатель составляет 1 %, а при значении 10 % соединение перестает работать. Однако для беспроводных сетей, таких как LAN 802.11, вполне обычными являются значения скорости потери фреймов порядка 10 % и выше. Если этого не учитывать, схемы контроля перегрузки, использующие в качестве сигнала потерю пакетов, попросту «задушат» беспроводные соединения, крайне ограничив их скорость.

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

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

Илл. 6.26. Контроль перегрузок для пути, содержащего беспроводной канал

Второй важный момент — своего рода загадка. Рисунок иллюстрирует два механизма, основанных на данных о потере пакетов: повторную передачу фрейма на канальном уровне и контроль перегрузки на транспортном уровне. Загадка в том, как эти два механизма могут сосуществовать. Ведь потеря пакетов должна приводить в действие только один из механизмов: это либо ошибка передачи данных, либо сигнал о перегрузке — но не и то и другое одновременно. Если же начинают работать оба механизма (то есть происходит и повторная передача фрейма, и уменьшение скорости передачи), мы возвращаемся к нашей первоначальной проблеме: схема работает слишком медленно для беспроводных каналов. Попробуйте немного поразмышлять и разгадать эту загадку.

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

Этот подход позволяет транспортным протоколам корректно работать с беспроводными каналами в большинстве случаев. Но существуют сценарии, при которых это решение не подходит. Некоторые беспроводные каналы (например, спутниковые) обладают большой задержкой в пути туда и обратно. В таких ситуациях требуются другие методы, позволяющие скрыть потерю пакетов, например упреждающая коррекция ошибок (Forward Error Correction, FEC), или же транспортный протокол должен использовать для контроля перегрузки сигналы об отсутствии потерь.

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

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

Однако при высокой нестабильности беспроводного канала транспортные протоколы, разработанные для проводных соединений, могут не успевать отслеживать изменения, в результате чего производительность существенно снижается. В таком случае требуется специальный транспортный протокол, созданный для беспроводных каналов. Особый интерес представляет разработка такого протокола для беспроводной ячеистой сети, где пересекается множество беспроводных каналов, маршруты постоянно меняются из-за мобильности и теряется много пакетов. Исследования в этой области продолжаются. Пример транспортного протокола для беспроводных каналов можно найти в работе Ли и др. (Li et al., 2009).