Транспортный уровень — это ключ к пониманию многоуровневых протоколов

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

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

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

Теперь рассмотрим другой набор транспортных примитивов — примитивы сокетов (иногда называемых гнездами), используемые в операционной системе Berkeley UNIX для протокола TCP (Transmission Control Protocol — протокол управления передачей) Следом идет вызов LISTEN, который выделяет место для очереди входящих звонков на случай, если несколько клиентов попытаются соединиться одновременно. В отличие от примитива LISTEN в нашем первом примере, примитив LISTEN гнездовой модели не является блокирующим вызовом. Рассмотрим сперва ту часть программы, которая описывает сервер. Она начинается с включения некоторых стандартных заголовков, последние три из которых содержат основные структуры и определения, связанные с Интернетом. Теперь рассмотрим часть кода, описывающую клиента. Чтобы понять, как работает программа, необходимо вначале разобраться, как она запускается. Элементы транспортных протоколов Транспортная служба реализуется транспортным протоколом, используемым между двумя транспортными сущностями. В некоторых отношениях транспортные протоколы напоминают протоколы передачи данных, подробно изучавшиеся в главе 3.

Адресация Когда один прикладной процесс желает установить соединение с другим прикладным процессом, он должен указать, с кем именно он хочет связаться. Обратите внимание на то, что на хосте 2 могут располагаться и другие серверы, соединенные со своими TSAP и ожидающие входящих запросов на соединение, приходящих с того же NSAP Чтобы справиться с этой ситуацией, часто используется другая схема. В этой модели используется специальный процесс, называющийся сервером имен или иногда каталоговым сервером. Установка соединения, хотя и просто звучит, неожиданно оказывается весьма непростым делом. На первый взгляд, должно быть достаточно одной транспортной сущности, для того чтобы послать адресату TPDU-модуль с запросом соединения CONNECTION REQUEST и услышать в ответ CONNECTION ACCEPTED (соединение принято). Вместо этого можно применить другой подход. Следует разработать механизм, уничтожающий устаревшие заблудившиеся пакеты и не позволяющий им существовать в сети бесконечно долго. Если мы сможем гарантировать, что ни один пакет не сможет жить дольше определенного периода времени, проблема станет более управляемой.

Основная идея заключается в том, что два одинаково пронумерованных TPDU-модуля никогда не отправляются одновременно. При установке соединения младшие k битов часов используются в качестве начального порядкового номера (также k битов). Неприятности у протокола могут возникнуть по двум причинам. Если хост посылает слишком быстро и слишком много данных, кривая используемых в действительности порядковых номеров может оказаться круче линии зависимости начальных номеров от времени. Разорвать соединение проще, чем установить. Тем не менее, здесь также имеются подводные камни. Как уже было сказано, существует два стиля разрыва соединения: асимметричный и симметричный. Теперь улучшим протокол с помощью «тройного рукопожатия». Инициатор оригинального предложения должен подтвердить ответ. Но и в этом случае останется неясным, было ли доставлено последнее сообщение. Протокол четырехкратного рукопожатия здесь также не поможет. Чтобы удалять полуоткрытые соединения, можно применять правило, гласящее, что если по соединению в течение определенного времени не прибывает ни одного ТРБи-модуля, соединение автоматически разрывается.

Управление потоком и буферизация Изучив процессы установки и разрыва соединения, рассмотрим, как происходит управление соединением во время его использования. Одним из ключевых вопросов, уже обсуждавшихся ранее, является управление потоком. Другой метод решения указанной проблемы состоит в использовании буферов переменного размера, как показано на рис. 6.12, б. Преимущество этого метода заключается в более оптимальном использовании памяти, но платой за это является усложненное управление буферами Потенциальные проблемы при такой схеме выделения буферов в дейтаграммных сетях могут возникнуть при потере управляющего ТРБи-модуля Мультиплексирование Объединение нескольких разговоров в одном соединении, виртуальном канале и по одной физической линии играет важную роль в нескольких уровнях сетевой архитектуры. Восстановление после сбоев Поскольку хосты и маршрутизаторы подвержены сбоям, следует рассмотреть вопрос восстановления после сбоев. Если транспортная сущность целиком помещается в хостах, восстановление после отказов сети и маршрутизаторов не вызывает затруднений.

Таким образом, независимо от того, как запрограммированы клиент и сервер, всегда могут быть ситуации, в которых протокол не сможет правильно восстановиться. Простой транспортный протокол Чтобы конкретизировать обсуждавшиеся ранее идеи, в данном разделе мы подробно изучим пример реализации транспортного уровня. Таким образом, наша услуга определяется пятью примитивами: CONNECT, LISTEN, DISCONNECT, SEND и RECEIVE. Каждому примитиву соответствует библиотечная служба, выполняющая примитив. Транспортная сущность примера транспортного протокола Управление окном также осуществляется сетевым уровнем. Помимо этого прозрачного механизма приостановки есть также процедуры sleep и wakeup (не показаны), вызываемые транспортной сущностью

Наличие бита Q (Qualifier — спецификатор) в заголовке пакета позволяет избежать накладных расходов в заголовке транспортного уровня. Обычные информационные сообщения посылаются в виде пакетов данных с Q = 0. Пример протокола как конечного автомата Написание транспортной сущности является сложной и кропотливой работой, особенно для протоколов, применяющихся в действительности. Чтобы снизить вероятность ошибки, полезно представлять состояния протокола в виде конечного автомата Представление протокола в виде матрицы состояний обладает тремя преимуществами Транспортные протоколы Интернета: UDP В Интернете нашли применение два основных протокола транспортного уровня, один из которых ориентирован на соединение, другой — нет. В следующих разделах мы изучим их. Протоколом без установления соединения является UDP. Протокол TCP, напротив, ориентирован на соединение. Вызов удаленной процедуры В определенном смысле процессы отправки сообщения на удаленный хост и получения ответа очень похожи на вызов функции в языке программирования

Иногда с помощью некоторых уловок все же удается передавать указатели. Допустим, первым параметром является указатель на целое число к. Клиентская заглушка может выполнить маршализацию к и передать его серверу. Серверная заглушка создаст указатель на полученную переменную k и передаст его серверной процедуре Транспортный протокол реального масштаба времени Клиент-серверный удаленный вызов процедур — это та область, в которой UDP применяется очень широко. Еще одна функция, необходимая приложениям реального времени, — это отметки времени. Идея состоит в том, чтобы позволить источнику связать отметку времени с первым символом каждого пакета. Отметка времени генерируется источником потока и служит для записи момента создания первого слова пакета. Отметки времени помогают снизить эффект джиттера на приемнике за счет того, что момент воспроизведения делается независимым от времени прибытия пакета. Протокол TCP (Transmission Control Protocol — протокол управления передачей) был специально разработан для обеспечения надежного сквозного байтового потока по ненадежной интерсети.

TCP-соединение представляет собой байтовый поток, а не поток сообщений Ключевым свойством TCP, определяющим всю структуру протокола, является то, что в TCP-соединении у каждого байта есть свой 32-разрядный порядковый номер Заголовок ТСР-сегмента Бит RST используется для сброса состояния соединения, которое из-за сбоя хоста или по другой причине попало в тупиковую ситуацию. Кроме того, он используется для отказа от неверного сегмента или от попытки создать соединение. В протоколе ТСР-соединения устанавливаются с помощью «тройного рукопожатия», описанного в разделе «Установка соединения». Чтобы установить соединение, одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя примитивы LISTEN и ACCEPT, либо указывая конкретный источник, либо не указывая его

Разрыв соединения TCP Хотя ТСР-соединения являются полнодуплексными, чтобы понять, как происходит их разъединение, лучше считать их парами симплексных соединений. Каждое симплексное соединение разрывается независимо от своего напарника. Модель управления TCP-соединением Когда у приложения заканчиваются данные для передачи, оно выполняет примитив CLOSE, заставляющий локальную TCP-сущность послать FIN-сегмент и ждать ответного ЛСЖ-сегмента (пунктирный прямоугольник с пометкой «активное разъединение»). Управление передачей в TCP Как уже было сказано ранее, управление окном в TCP не привязано напрямую к подтверждениям, как это сделано в большинстве протоколов передачи данных. Хотя такой метод задержки и снижает нагрузку на сеть, тем не менее, эффективность использования сети отправителем продолжает оставаться невысокой, так как каждый байт пересылается в отдельном 41-байтовом пакете

Дэвид Кларк (David Clark) предложил запретить принимающей стороне отправлять информацию об однобайтовом размере окна Борьба с перегрузкой в TCP Когда в какую-либо сеть поступает больше данных, чем она способна обработать, в сети образуются заторы. Интернет в этом смысле не является исключением При установке соединения отправитель устанавливает размер окна перегрузки равным размеру максимального используемого в данном соединении сегмента. Затем он передает один максимальный сегмент. Если подтверждение получения этого сегмента прибывает прежде, чем истекает период ожидания, к размеру окна добавляется размер сегмента, то есть размер окна перегрузки удваивается, и посылаются уже два сегмента Управление таймерами в TCP В протоколе TCP используется много различных таймеров (по крайней мере, такова концепция). Наиболее важным из них является таймер повторной передачи. В 1988 г. Джекобсон предложил использовать значение р, грубо пропорциональное среднеквадратичному отклонению (дисперсии) функции плотности вероятности времени прибытия подтверждения.

Беспроводные протоколы TCP и UDP Теоретически, транспортные протоколы не должны зависеть от технологии, применяемой на расположенном ниже сетевом уровне. В частности, протоколу TCP должно быть все равно, передаются его сегменты по радио или по оптоволоконному кабелю Другое решение, разработанное Балакришнаном (Balakrishnan и др., 1995), не нарушает семантики протокола TCP. В его основе лежат небольшие изменения в программе сетевого уровня, работающей на базовой станции. Транзакционный TCP Мы уже рассматривали в этой главе, как осуществляется удаленный вызов процедуры в клиент-серверных системах. Если запрос и ответ достаточно малы, чтобы поместиться в один пакет, а операция идемпотентна, то можно смело использовать UDP. Вопросы производительности играют важную роль в компьютерных сетях. Когда сотни или тысячи компьютеров соединены вместе, их взаимодействие становится очень сложным и может привести к непредсказуемым последствиям. Причины снижения производительности компьютерных сетей

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

Минимизируйте количество переключений контекста Можно купить более высокую пропускную способность, но не низкую задержку Быстрая обработка TPDU-модулей Мораль приведенной истории состоит в том, что основным препятствием на пути ускорения сетей является программное обеспечение протоколов. В данном разделе мы рассмотрим некоторые способы ускорения этих программ. Чтобы увидеть, как работает этот принцип на практике, рассмотрим случай TCP/IP. В программе таймеры обычно реализуются в виде связанного списка таймеров, отсортированного по времени срабатывания.

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

Предположим, что используется управляемая часами схема генерирования начальных порядковых номеров с 15-разрядным счетчиком часов. Часы тикают раз в 100 мс, а максимальное время жизни пакета равно 60 с. Для каждого события, которое потенциально может произойти в транспортной сущности, представленной в листинге 6.2, определите, является ли оно разрешенным или нет, когда пользователь находится в состоянии sending. Обсудите преимущества и недостатки схемы кредитов по сравнению с протоколами скользящего окна. Рассмотрите эффект использования алгоритма затяжного пуска в линии со значением времени прохождения сигнала в оба конца, равным 10 мс, без перегрузок. Размер окна получателя 24 Кбайт, а максимальный размер сегмента равен 2 Кбайт. Через какое время может быть послано полное окно? В разделе «Протоколы для гигабитных сетей» мы подсчитали, что гигабитная линия отправляет хосту 80 000 пакетов в секунду, оставляя ему только 6250 инструкций на их обработку — половина производительности процессора отдается приложениям