Реклама:

info.krc.karelia.ru

win -:|:- koi -:|:- iso -:|:- dos -:|:- mac

Start -:|:- Проекты -:|:- О нас

Протокол UDP

Радик Усманов
radik@binep.ac.ru

Январь, 1995 г.

Реферат: Документ содержит русский перевод спецификации протокола UDP (User Datagram Protocol) - одного из основных транспортных протоколов стека IP, применяемого в международной компьютерной сети Internet. Оригинальный документ известен, как RFC768.

Примечания редактора

Оригинальная версия документа RFC768 размещается на сервере ISI (Information Sciences Institute):

 URL - http://info.internet.isi.edu/in-notes/rfc/files/rfc768.txt

RFC 768                                                        J. Postel
                                                                     ISI
                                                          28 August 1980



                    Протокол датаграмм клиента                    
                      User Datagram Protocol                      
                      ----------------------                      

Введение
--------

   Этот протокол (User Datagram Protocol - UDP) проектировался для 
создания в объединенной системе компьютерных сетей с коммутацией 
пакетов режима передачи датаграмм клиента. Протокол UDP предпола- 
гает, что нижестоящим протоколом является Internet (IP) [1].

   Данный протокол предоставляет прикладной программе процедуру 
для посылки сообщений другим программам, причем механизм протокола 
минимален. Протокол UDP ориентирован на транзакции, получение да- 
таграмм и защита от дублирования не гарантированы. Приложения, 
требующие гарантированного получения потоков данных, должны ис- 
пользовать протокол управления пересылкой (Transmission Control 
Protocol - TCP) [2].

Формат
------


                  0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |      Порт       |      Порт       |
                 |   Отправителя   |   Получателя    |
                 +--------+--------+--------+--------+
                 |                 |  Контрольная    |
                 |      Длина      |       сумма     |
                 +--------+--------+--------+--------+
                 |
                 |       октеты данных  ...
                 +---------------- ...

              Формат заголовка для датаграмм клиента              

Поля
----

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

Длина - длина в октетах данной датаграммы, включая как заголовок, 
так и данные (Это означает, что минимальное значение поля длины 
равно восьми).

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

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

                  0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |        адрес отправителя          |
                 +--------+--------+--------+--------+
                 |        адрес получателя           |
                 +--------+--------+--------+--------+
                 |  нули  |протокол|    длина UDP    |
                 +--------+--------+--------+--------+

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

Интерфейс пользователя
----------------------

Интерфейс пользователя должен позволять:

- создание новых портов для получения датаграмм

- операции получения на портах, способные принимать октеты данных, 
  а также осуществлять индикацию порта и адреса отправителя

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

Интерфейс протокола IP
----------------------

Модуль протокола UDP должен иметь возможность извлекать из Inter- 
net заголовка датаграммы Internet адреса отправителя и получателя, 
а также тип протокола. Один из возможных интерфейсов UDP/IP мог бы 
возвращать в ответ на команду получения полную Internet датаграм- 
му, включая Internet заголовок целиком. Такой интерфейс мог бы 
также позволить протоколу UDP передавать протоколу IP для посылки 
некую готовую Internet датаграмму вместе с заголовком. Протокол IP 
мог бы лишь проверять определенные поля Internet заголовка на со- 
вместимость, а также вычислять контрольную сумму.

Применение протокола
--------------------

Главным применением протокола UDP являются системы Internet Name 
Server [3], и Trivial File Transfer [4].

Номер протокола
---------------

При использовании Internet протокола протокол UDP идентифицируется 
номером 17 (21 в восьмеричной системе счисления). Список других 
номеров протокола приведен в документе [5].

Ссылки
------

[1]     Postel,   J.,   "Internet  Protocol,"  RFC 760,  USC/Information
        Sciences Institute, январь 1980.

[2]     Postel,    J.,   "Transmission   Control   Protocol,"   RFC 761,
        USC/Information Sciences Institute, январь 1980.

[3]     Postel,  J.,  "Internet  Name Server,"  USC/Information Sciences
        Institute, IEN 116, август 1979.

[4]     Sollins,  K.,  "The TFTP Protocol,"  Massachusetts  Institute of
        Technology, IEN 133, январь 1980.

[5]     Postel,   J.,   "Assigned   Numbers,"  USC/Information  Sciences
        Institute, RFC 762, январь 1980.

 

Rambler's Top100 Service Яндекс цитирования