TCP-IP крупным планом

       

ICMP сообщение об истечении времени



Рисунок 8.2 ICMP сообщение об истечении времени ("time exceeded").


В сообщении, которое генерируется, когда TTL достигает нуля, поле code равно нулю.

Существует возможность, что хост пошлет ICMP сообщение "время истекло в течении повторной сборки" (time exceeded during reassembly) в том случае, если время истекло в течении повторной сборки фрагментированной датаграммы. (Мы подробно рассмотрим фрагментацию и повторную сборку в разделе "Фрагментация IP" главы 11.) В этом случае поле code устанавливается в единицу.

Строки с 9-ой по 14-ую на рисунке 8.1 соответствуют трем датаграммам, которые посылаются с TTL равным 2. Они достигают конечного пункта назначения, при этом генерируется ICMP сообщение о недоступности порта.

Попробуем рассчитать время возврата, которое соответствует SLIP каналу, как это было сделано в разделе "Программа Ping" главы 7, когда при работе программы Ping была установлена скорость канала - 1200 бит/сек. Исходящая UDP датаграмма содержит 12 байт данных, 8 байт UDP заголовка, 20 байт IP заголовка и 2 байта (минимум) для создания SLIP фреймов (см. раздел "SLIP: IP по последовательной линии" главы 2), что в целом составляет 42 байта. В отличие от Ping, размер возвращающихся датаграмм изменяется. На рисунке 6.9, мы видели, что возвращаемое ICMP сообщение содержит IP заголовок датаграммы, которая вызвала ошибку и первые 8 байт данных, которые следуют за IP заголовком (содержащие UDP заголовок, в данном случае traceroute). При этом мы получаем 20+8+20+8+2 или 58 байт. При скорости передачи в 960 байт/сек, ожидаемое RTT составляет (42+58/960) или 104 миллисекунды. Это сопоставимо со значением, рассчитанным для svr4 и равным 110 миллисекундам.

Номер порта источника на рисунке 8.1 достаточно большой (42804). traceroute устанавливает номер порта источника IP датаграмм, которые она посылает в логическое ИЛИ (logical OR), со своим идентификатором процесса (32768). В этом случае, если traceroute запущена несколько раз на одном и том же хосте, каждый процесс просматривает номер порта источника в UDP заголовке, который возвращается в ICMP сообщении, и обрабатывает только те сообщения, которые были отправлены в качестве отклика на его запрос.

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

Во-вторых, не существует гарантии того, что путь, по которому вернется ICMP сообщение, совпадет с путем, по которому traceroute отправила UDP датаграмму. Это означает, что время возврата, которое печатает программа, может не совпадать со временем, потребовавшимся на передачу исходящей датаграммы и возвращенного сообщения. (Возможен вариант, что UDP датаграмма дойдет от источника до маршрутизатора за 1 секунду, однако ICMP сообщение проделает обратный путь за 3 секунды, при этом время возврата будет напечатано как 4 секунды.)

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

slip % traceroute svr4
traceroute to svr4 (140.252.13.34), 30 hops max, 40 byte packets
1 bsdi (140.252.13.66) 110 ms 110 ms 110 ms
2 slip (140.252.13.34) 110 ms 120 ms 110 ms

В этом случае IP адрес, напечатанный для хоста bsdi, это адрес SLIP интерфейса (140.252.13.66), тогда как до этого адрес был 140.252.13.35, что соответствовало интерфейсу Ethernet. Так как traceroute пытается определить имя, связанное с IP адресом, имена будут различны. (В нашем примере оба интерфейса bsdi имеют одно и то же имя.)

Обратимся к рисунку 8.3. На нем показаны две локальные сети, соединенные через маршрутизаторы. Два маршрутизатора соединены по каналу точка-точка. Если мы запустим traceroute с хоста в левой локальной сети на хост в правой локальной сети, IP адреса для маршрутизатора будут if1 и if3. При использовании другого пути, будут получены адреса if4 и if2. Два интерфейса if2 и if3 имеют один и тот же идентификатор сети, тогда как два других интерфейса имеют разные идентификаторы сетей.



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