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), или же транспортный протокол должен использовать для контроля перегрузки сигналы об отсутствии потерь.

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