
что поле 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, вместо этого