Решение загадки заключается в том, что эти механизмы работают в разных временных масштабах. В беспроводных сетях, таких как 802.11, повторные передачи канального уровня происходят через промежутки времени порядка нескольких микросекунд или миллисекунд. Таймеры транспортных протоколов, следящие за потерей пакетов, срабатывают раз в несколько миллисекунд или секунд. Благодаря разнице в три порядка беспроводные каналы успевают обнаружить потерю фреймов и решить проблему путем их повторной передачи задолго до того, как об этом узнает транспортная подсистема.
Этот подход позволяет транспортным протоколам корректно работать с беспроводными каналами в большинстве случаев. Но существуют сценарии, при которых это решение не подходит. Некоторые беспроводные каналы (например, спутниковые) обладают большой задержкой в пути туда и обратно. В таких ситуациях требуются другие методы, позволяющие скрыть потерю пакетов, например упреждающая коррекция ошибок (Forward Error Correction, FEC), или же транспортный протокол должен использовать для контроля перегрузки сигналы об отсутствии потерь.
Еще одна проблема, связанная с контролем перегрузки в беспроводных каналах, — переменная пропускная способность. Пропускная способность беспроводного канала меняется со временем, причем иногда скачкообразно, при перемещении узлов и изменении соотношения сигнал/шум; в проводных каналах она постоянна. Транспортный протокол вынужден адаптироваться к изменениям пропускной способности беспроводного канала. В противном случае либо произойдет перегрузка сети, либо мощность канала будет использоваться не полностью.
Одно из возможных решений — просто не задумываться об этом. Алгоритмы контроля перегрузки и так должны хорошо работать при добавлении новых пользователей или изменении скорости отправки пакетов. Несмотря на то что пропускная способность проводного канала является фиксированной, для каждого отдельного пользователя меняющееся поведение других пользователей выглядит как колебание доступной полосы. Поэтому для пути, содержащего беспроводной канал 802.11, можно просто использовать протокол TCP и добиться хорошей производительности.
Однако при высокой нестабильности беспроводного канала транспортные протоколы, разработанные для проводных соединений, могут не успевать отслеживать изменения, в результате чего производительность существенно снижается. В таком случае требуется специальный транспортный протокол, созданный для беспроводных каналов. Особый интерес представляет разработка такого протокола для беспроводной ячеистой сети, где пересекается множество беспроводных каналов, маршруты постоянно меняются из-за мобильности и теряется много пакетов. Исследования в этой области продолжаются. Пример транспортного протокола для беспроводных каналов можно найти в работе Ли и др. (Li et al., 2009).
6.4. Транспортные протоколы интернета: UDP
В интернете применяются два основных протокола транспортного уровня, дополняющих друг друга; один из них требует установления соединения, другой — нет. Протокол без установления соединения, UDP, просто передает пакеты между приложениями, позволяя им надстраивать свои собственные протоколы. TCP — протокол, ориентированный на установление соединения. В его задачи входит практически все. Он устанавливает соединения и обеспечивает надежность сети, выполняя повторную передачу данных, а также осуществляет управление потоком данных и контроль перегрузки — и все это в интересах приложений, которые его используют.
В следующих разделах мы изучим UDP и TCP. Мы начнем с UDP, так как он проще, и рассмотрим два варианта применения этого протокола. Поскольку сам UDP обычно работает в операционной системе, а использующие его протоколы — в пользовательской области, эти варианты вполне можно считать приложениями. Однако методы, которые в них используются, полезны для многих приложений и их лучше рассматривать как часть транспортной службы. Поэтому их мы тоже обсудим.
6.4.1. Основы UDP
В наборе интернет-протоколов есть протокол передачи пользовательских дейтаграмм (User Datagram Protocol, UDP). Это транспортный протокол без установления соединения, описанный в RFC 768. UDP позволяет приложениям отправлять инкапсулированные IP-дейтаграммы без установления соединений.