Краткие выводы

UDP это простой протокол. Официальная спецификация RFC 768 [Postel 1980] состоит всего лишь из трех страниц. Сервисы, которые он предоставляет пользовательским процессам, находящиеся над и позади IP, это номера портов и необязательные контрольные суммы. Мы использовали UDP, чтобы просмотреть расчет контрольных сумм и посмотреть, как осуществляется фрагментация.

Затем мы рассмотрели ICMP ошибку о недоступности, которая является частью новой характеристики определения транспортного MTU (см. главу 2, раздел "Транспортный MTU"). Мы рассмотрели определение транспортного MTU с использованием Traceroute и UDP. Также рассмотрен процесс взаимодействия UDP и ARP.

Мы убедились, что ICMP ошибка подавления источника может быть послана системой, которая принимает IP датаграммы быстрее, чем может обработать. Существует возможность легко генерировать эти ICMP ошибки с использованием UDP.

Упражнения

В разделе "Фрагментация IP" этой главы мы вызвали фрагментацию в Ethernet, записав UDP датаграмму с размером пользовательских данных в 1473 байта. Какой наименьший размер пользовательских данных может вызвать фрагментацию в Ethernet, если используется инкапсуляция IEEE 802 (глава 2, раздел "Ethernet и IEEE 802 инкапсуляция")?
Прочитайте RFC 791 [Postel 1981a] и скажите, почему все фрагменты кроме последнего должны иметь длину кратную 8 байтам.
Представьте себе Ethernet и UDP датаграмму с 8192 байтами пользовательских данных. Сколько фрагментов будет передано и какова будет длина смещения для каждого фрагмента?
Продолжая предыдущий пример, представьте себе, что эти датаграммы затем передаются в SLIP канал с MTU равным 552. Вам необходимо помнить, что количество данных в каждом фрагменте (все кроме IP заголовка) должно быть кратно 8 байтам. Сколько фрагментов передано и каковы смещение и длина каждого фрагмента?
Приложение, использующее UDP, посылает датаграмму, которая фрагментирована на 4 части. Представьте себе, что фрагменты 1 и 2 достигли своего пункта назначения, тогда как фрагменты 3 и 4 были потеряны. Приложение отрабатывает тайм-аут, а затем, через 10 секунд, повторяет передачу UDP датаграммы. Эта датаграмма фрагментируется точно так же, как и при первой передаче (то же смещение и та же длина). Теперь представьте, что фрагменты 1 и 2 потеряны, однако фрагменты 3 и 4 достигли своего пункта назначения. Таймер повторной сборки на принимающем хосте установлен в 60 секунд, поэтому когда фрагменты 3 и 4 прибыли на конечный пункт назначения, фрагменты 1 и 2 из первой передачи еще не были отброшены. Может ли получатель собрать IP датаграмму из этих четырех фрагментов?
Как Вы можете узнать, что фрагменты на рисунке 11.15 действительно соответствуют строкам 5 и 6 на рисунке 11.14?
После того как хост gemini работал 33 дня, программа netstat показала, что 129 IP датаграмм из 48 миллионов были отброшены из-за несовпадения контрольной суммы заголовка, а 20 сегментов из 30 миллионов сегментов TCP были отброшены из-за несовпадения контрольной суммы TCP. Однако, примерно из 18 миллионов UDP датаграмм ни одна не была отброшена по причине ошибки в контрольной сумме UDP. Приведите минимум две причины, почему это могло произойти. (Подсказка: см. рисунок 11.4.)
В нашем описании фрагментации мы ни разу не упомянули, что происходит с IP опциями в IP заголовке - либо они копируются как часть IP заголовка в каждый фрагмент, либо остаются только в первом фрагменте? Мы описали следующие опции: запись маршрута (глава 7, раздел "Опция записи IP маршрута"), временная марка (глава 7, раздел "IP опция временной марки"), жесткая и свободная маршрутизация от источника (глава 8, раздел "Опция IP маршрутизации от источника"). Как Вы считаете, как при фрагментации обрабатываются эти опции? Сопоставьте Ваш ответ с RFC 791.
На рисунке 1.8 мы сказали, что входящие IP датаграммы демультиплексируются на основе номера порта назначения UDP. Правильно ли это?

На главную

Содержание раздела