Эндрю Уэзеролл - Компьютерные сети. 5-е издание

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

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

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

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

6.4. Транспортные протоколы Интернета: UDP

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

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

6.4.1. Основы UDP

Среди набора протоколов Интернета есть транспортный протокол без установления соединения, UDP (User Datagram Protocol — протокол передачи дейтаграмм пользователя). UDP позволяет приложениям отправлять инкапсулированные IP-дейтаграммы без установления соединений. UDP описан в RFC 768.

С помощью протокола UDP передаются сегменты, состоящие из 8-байтного заголовка, за которым следует поле полезной нагрузки. Заголовок показан на рис. 6.23. Два номера портов служат для идентификации сокетов внутри отправляющей и принимающей машин. Когда прибывает пакет UDP, содержимое его поля полезной нагрузки передается процессу, связанному с портом назначения. Это связывание происходит при выполнении базовой операции типа BIND. Это было продемонстрировано в листинге 6.1 применительно к TCP (в UDP процесс связывания происходит точно так же). Представьте себе, что порты — это почтовые ящики, арендуемые приложениями. Мы поговорим о них подробнее при обсуждении TCP, который тоже использует порты. В сущности, весь смысл использования UDP вместо обычного IP заключается как раз в указании портов источника и приемника. Без этих двух полей на транспортном уровне невозможно было бы определить действие, которое следует производить с каждым входящим пакетом. В соответствии с полями портов производится доставка вложенных сегментов соответствующим приложениям.

Рис. 6.23. Заголовок UDP

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

Поле Длина UDP состоит из заголовка и данных. Минимальная длина равна длине заголовка, то есть 8 байтам. Максимальная длина равна 65 515 байтам — это меньше, чем максимальное число, записывающееся с помощью 16 бит, из-за ограничений на размер IP-пакета.

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