Транспортный уровень. Пользовательский протокол дейтаграмм

UDP-операции

UDP использует общую концепцию для транспортного уровня. Изложим коротко эту концепцию, затем она будет более подробно рассмотрена в следующей лекции для TCP-протокола.

Услуги, не ориентированные на соединение

Как уже упоминалось раньше, UDP обеспечивает услуги, не ориентированные на соединение. Это означает, что каждая дейтаграмма посылает независимую UDP-дейтаграмму. Между различными пользовательскими дейтаграммами нет никакой зависимости, даже если они поступили от одного и того же исходного процесса и пришли в программу от одного и того же пункта назначения. Пользовательская дейтаграмма не нумерована. Это означает, что каждая пользовательская дейтаграмма может проходить различным путем.

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

Управление потоком и контроль ошибок

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

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

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

Инкапсуляция и деинкапсуляция

Чтобы послать сообщение от одного процесса к другому, UDP-протокол инкапсулирует и деинкапсулирет сообщения ( рис. 9.4.).

Инкапсуляция

Когда процесс хочет послать сообщение с помощью UDP, он передает сообщение к UDP в соответствии с парой гнездовых адресов и длины данных. UDP получает данные, дополненные заголовком UDP. Затем UDP передает пользовательскую дейтаграмму к IP с гнездовым адресом. IP дополняет свой заголовок, который использует значение 17 в поле протокола, указывающее, что данные поступили от UDP-протокола.

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

Рис. 9.4. Инкапсуляция и деинкапсуляция

Деинкапсуляция

Когда сообщение пребывает на хост пункта назначения, физический уровень декодирует биты и передает их к уровню звена данных. Уровень звена данных использует заголовок (и окончание) для проверки данных. Если нет ошибки, заголовок и окончание отбрасываются, а дейтаграмма передается IP. Программное обеспечение IP делает свою собственную проверку. Если нет ошибки, заголовок отбрасывается и пользовательская дейтаграмма передается UDP с адресами передатчика и приемника. UDP вычисляет контрольную сумму для проверки всей пользовательской дейтаграммы. Если нет ошибки, заголовок отбрасывается, и прикладные данные с гнездовым адресом передатчика передаются процессу. Гнездовой адрес передатчика передается процессу в случае необходимости отклика на полученное сообщение.

Организация очередей

В UDP организация очереди связана с портом ( рис. 9.5.).

На стороне клиента, процесс начинает с того, что запрашивает номер порта при помощи операционной системы. Некоторые реализации создают и входящую, и исходящую очередь, связанную с каждым процессом. Другие реализации создают только входящие очереди, связанные с процессом.

Заметим, что даже если процесс хочет связаться со многими процессами, он получает только один номер порта и, в конечном счете, одну исходящую и одну входящую очереди.

Очередь, открытая клиентом, в большинстве случаев определяется кратковременным номером порта. Функции очереди выполняются в течение процесса. Когда процесс заканчивается, очередь разрушается.

Рис. 9.5. Очередь UDP

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

Когда сообщение прибывает к клиенту, UDP проверяет, создана ли входящая очередь для номера порта, заданного в поле пункта назначения для исходящей очереди пользовательской дейтаграммы. Если такой очереди нет, то UDP удаляет пользовательскую дейтаграмму и просит ICMP-протокол послать серверу сообщение порт недостижим.

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

На стороне сервера механизм создания очереди отличается, поскольку имеются различные типы серверов. Однако в своей простейшей форме сервер, когда начинает работу, запрашивает закрепленный порт (well-know port) для использования входящей и исходящей очереди. Эта очередь остается открытой, пока сервер работает.

Когда сообщение прибывает к серверу, UDP проверяет, создана ли входящая очередь для номера порта, заданного в поле конечного пункта пользовательской дейтаграммы. Если такая очередь есть, UDP посылает полученную пользовательскую дейтаграмму в конец очереди. Если такой очереди нет, UDP удаляет пользовательскую дейтаграмму и просит протокол послать клиенту сообщение "порт недостижим". Все входящие сообщения для одного конкретного сервера, пришли ли они от того же самого или другого клиента, посылаются к одной и той же очереди. Если входящая очередь переполнится, UDP отбрасывает пользовательскую дейтаграмму и посылает клиенту сообщение "порт недостижим".

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

Мультиплексирование и демультиплексирование

В хосте, выполняющем набор протоколов TCP/IP, имеется только один UDP, но возможны несколько процессов, которые могут вызвать услуги UDP. Для того чтобы обработать эту ситуацию, UDP использует процессы мультиплексирования и демультиплексирования ( рис. 9.6.).

Мультиплексирование

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

Демультиплексирование

На стороне приемника есть только один UDP. Однако мы можем иметь много процессов, которые могут получать пользовательские дейтаграммы от IP. После проверки ошибок отбрасывания заголовка UDP доставляет каждое сообщение к соответствующему процессу, основываясь на номере порта.

Рис. 9.6. Мультиплексирование и демультиплексирование