что  поле Length заголовка UDP принимает  участи  в  расчете  контрольной  суммы  заголовка UDP 
дважды – как часть заголовка UDP и как часть псевдозаголовка. Отметим, что контрольная сумма 
UDP, как и контрольная сумма IP, рассчитывается как дополнение до единицы всех двухбайтовых 
слов  защищаемого  содержимого  (т.е.  псевдозаголовка,  заголовка UDP и  данных UDP), если 
количество  защищаемых  байт  не  кратно  двум,  то  для  расчета  контрольной  суммы  данные UDP 
дополняются  нулевым  байтом  в  конце  с  целью  выравнивания,  при  чем  этот  нулевой  байт  не 
передается в линии связи, а дополнение происходит только на этапе расчета контрольной суммы. 
Аналогично,  как  и  в  случае  с  протоколом IP в  момент  расчета  контрольной  суммы,  САМО  поле 
контрольной  суммы  (которое,  формально  говоря,  тоже  входит  в  защищаемую  область  данных) 
полагается равным 00 00. В случае, если расчет контрольной суммы привел к значению 00 00, оно 
заменяется  при  передаче  на FF FF, допустимо,  когда  отправитель  дейтаграммы  отказывается  от 
расчета контрольной суммы, в таком случае поле контрольной суммы UDP должно быть заполнено 
00 00 в  отправляемой  в  линию  связи  дейтаграмме.  Сразу  отметим,  что  ВСЕ  вышесказанное  о 
расчете  контрольных  сумм  для  протокола UDP останется  справедливым  и  для  протокола TCP, за 
тем  лишь  исключением,  что  при  использовании    TCP  НЕ  допустимо  отказываться  от  расчета 
контрольной суммы и заполнять поле контрольной суммы нулями. Так же отличие состоит в том, 
что  поле Length (полная  длина  заголовка UDP и  данных)  присутствует  в  заголовке UDP, но 
аналогичного поля НЕТ в заголовке TCP, соответствующая длина вычисляется (как было описано 
выше, на основании полей заголовка IP) непосредственно для формирования псевдозаголовка TCP 
при расчете контрольной суммы TCP.  
 

Важно,  ОЧЕНЬ  четко  понимать,  что UDP является  дейтаграммным  протоколом,  т.е.  на 

посланную UDP дейтаграмму НЕ ожидается ответной дейтаграммы, но если серверное приложение, 
получившее  данные  с  помощью UDP желает  сформировать  ответ,  то  он  так  же  будет  передан 
поверх протокола UDP, подчеркиваем, что речь здесь идет не об ответе на UDP дейтаграмму, а об 
ответе  на  данные  прикладного  протокола,  переданные  поверх UDP. В  этом UDP полностью 
эквивалентен  протоколу IP. Однако,  вспомним  протокол IP: при  работе  этого,  в  чистом  виде 
дейтаграммного протокола, встречаются ситуации, когда в ОТВЕТ на IP пакет отправляется ответ – 
в случае, если IP пакет вызывает ошибку (самого разного рода, это уже изучалось), в ответ на нее 
может  быть  сформировано ICMP сообщение.  Действительно,  так  как  в  протоколе IP (и UDP) нет 
своих  инструментов  обратной  связи  отправителя  и  получателя,  такая  обратная  связь  создается  с 
помощью дополнительного протокола для информирования об ошибках. Отметим, что и в работе 
протокола UDP может возникать ошибка, связанная самим протоколом UDP (а не с протоколом IP, 
переносящим  дейтаграмму),  рассмотрим  ситуацию – пусть  клиент  отправил  серверу UDP 
дейтаграмму,  как  мы  знаем,  в  случае  потери  такой  дейтаграммы  клиент  не  получает  от  сервера 
никой  ответной  информации.  Однако  возможна  ситуация,  когда  на  сервере  порт,  к  которому 
обратился  клиент,  не  связан  с  каким  либо  приложением,  т.е.  ответа  не  может  поступить  из-за 
отсутствия  отвечающей  стороны.  В  таком  случае  узел-сервер  уведомляет  клиентский  процесс  об 
этом, но не с помощью протокола UDP (у которого нет специальных полей для этого), а с помощью 
протокола ICMP, так  как  это  было  изучено  нами  ранее  в  прошлом  курсе,  с  помощью  сообщения 
типа 3 с кодом 3. 

Фактически на этом теоретическое изучение протокола UDP завершено, подведем некоторые 

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

Полезно  проанализировать,  к  какому  уровню  модели OSI имеет  смысл  отнести  протокол 

UDP.  Очень  часто  в  литературе  игнорируется,  что  модель TCP/IP содержит host-to-host уровень, 
близкий по функциям совокупности транспортного и сеансового уровней модели OSI, вместо этого