Формат сообщения об ошибке и утилита traceroute

На рис. 19.21 показан формат ICMP-сообщения об ошибке, в данном случае это сообщение о недостижимости узла назначения. Остальные ICMP-сообщения об ошибках имеют такой же формат и отличаются друг от друга только значениями полей типа и кода.

	4 байта W
Тип = 3	Код = (0 -15)	Контрольная сумма
Не используется (0)
Заголовок IP + первые 8 байт ошибочных данных IP-дейтаграммы

Рис. 19.21. Формат ICMP-сообщения об ошибке — недостижимости узла назначения

 

Когда маршрутизатор не может передать или доставить IP-пакет, он отсылает узлу, отправившему этот пакет, сообщение о недостижимости узла назначения. В поле типа помещается значение 3, а в поле кода — значение из диапазона 0-15, уточняющее причину, по которой пакет не был доставлен. Следующие за полем контрольной суммы 4 байт заголовка не используются и заполняются нулями.

Помимо причины ошибки, указанной в заголовке, в поле данных ICMP-сообще- ния всегда помещается заголовок IP и первые 8 байт данных того IP-пакета, ко­торый вызвал ошибку. Эта информация позволяет узлу-отправителю точнее ус­тановить причину ошибки, так как все протоколы стека TCP/IP, использующие- для передачи своих сообщений IP-пакеты, содержат наиболее важную для ана­лиза информацию в первых 8 байт своих сообщений. В частности, ими вполне могут оказаться первые 8 байт заголовка TCP или UDP, в которых содержится информация, идентифицирующая приложение, пославшее потерянный пакет. Следовательно, при разработке приложения можно предусмотреть встроенные средства реакции на сообщения о недоставленных пакетах.

Узел (или сеть) назначения может быть недостижим по причине временной не­работоспособности аппаратуры из-за того, что отправитель указал неверный ад­рес назначения или маршрутизатор не имеет данных о пути к сети назначения. Недостижимость протокола и порта означает отсутствие реализации какого-ли- бо протокола прикладного уровня в узле назначения или же отсутствие открыто­го порта протокола UDP или TCP в узле назначения.

Как было показано на примере утилиты ping, ICMP-сообщения эффективно ис­пользуются для мониторинга сети. В частности, сообщения об ошибке истечения тайм-аута лежат в основе работы другой популярной утилиты traceroute для Unix, имеющей в Windows 2000 название tracert. Эта утилита позволяет проследить маршрут до удаленного хоста, определить RTT, IP-адрес и доменное имя для ка­ждого промежуточного маршрутизатора (если это имя зарегистрировано в об­ратной зоне службы DNS). Такая информация полезна для локализации маршру­тизатора, на котором обрывается путь пакета к удаленному хосту.

Утилита traceroute осуществляет трассировку маршрута путем посылки обычных IP-пакетов с адресом назначения, являющимся конечной точкой изучаемого мар­шрута. Суть метода трассировки состоит в том, что значение TTL первого от­правляемого пакета установлено равным 1. Когда протокол IP первого маршру­тизатора принимает этот пакет, то он в соответствии со своим алгоритмом уменьшает значение TTL на 1 и получает 0. Маршрутизатор отбрасывает пакет с нулевым временем жизни и возвращает узлу-источнику ICMP-сообщение об ошибке истечения тайм-аута вместе с заголовком IP и первыми 8 байтами поте­рянного пакета.

Получив ICMP-сообщение о причине недоставки пакета, утилита traceroute за­поминает адрес первого маршрутизатора (который извлекает из заголовка IP-па­кета, несущего ICMP-сообщение) и вычисляет для него RTT. Затем traceroute посылает следующий IP-пакет, но теперь со значением TTL, равным 2. Этот пакет благополучно проходит первый маршрутизатор, но «умирает» на втором, о чем немедленно отправляется аналогичное ICMP-сообщение об ошибке исте­чения тайм-аута. Утилита traceroute запоминает адрес и время для второго мар­шрутизатора и т. д. Такие действия выполняются с каждым маршрутизатором вдоль маршрута вплоть до узла назначения.

Мы рассмотрели работу утилиты traceroute весьма схематично, но и этого доста­точно, чтобы оценить изящество идеи, лежащей в основе ее работы.

Ниже приведена копия экранной формы, выведенной утилитой tracert (Windows) при трассировке хоста ds.internic.net [198.49.45.29]:

1 311 ms 290 ms 261 ms 144.206.192.100

2 281 ms 300 ms 271 ms 194.85.73.5

3 2023 ms 290 ms 311 ms moscow-m9-2-S5.relcom eu.net [193.124.254.37]

4 290 ms 261 ms 280 ms MSK-M9-13 Relcom.EU.net [193.125.15.13]

5 270 ms 281 ms 290 ms MSK.RAIL-l-ATM0-155Mb.Relcom.EU.net [193 124.254.82]

6 300 ms 311 ms 290 ms SPB-RASC0M-l-E3-l-34Mb.Relcom.EU.net [193.124.254.78]

7 311 ms 300 ms 300 ms Hssill-0.GW1.STK2.ALTER.NET [146.188.33.125]

8 311 ms 330 ms 291 ms 421.ATM6-0-0.CR2.STK2.Alter.Net [146.188.5.73]

9 360 ms 331 ms 330 ms 219 Hssi4-0.CR2.LND1.Alter.Net [146.188.2.213]

10 351 ms 330 ms 331 ms 412.Atm5-0.BRl.LNDl.Alter.net [146.188.3.205]

11 420 ms 461 ms 420 ms 167.ATM8-0-0.CR1.ATL1.Alter.Net [137.39.69.182]12 461 _ms 441 ms 440 ms 311.ATM12-0-0.BR1.ATL1.Alter.Net [137.39.21 73]13 451 ms 410 ms 431 ms atlantal-brl.bbnplanet.net [4.0.2.141]14 420 ms 411 ms 410 ms viennal-br2.bbnplanet.net [4.0.3.154]15 411 ms 430 ms 2514 ms viennal- nbr3.bbnplanet.net [4.0.3.150]16 430 ms 421 ms 441 ms viennal- nbr2.bbnplanet.net [4.0.5.45]17 431 ms 451 ms 420 ms cambridgel- brl.bbnplanet.net [4.0.5.42]18 450 ms 461 ms 441 мс cambridgel- crl4.bbnplanet.net [4.0.3.94Ц9 451 мс 461 мс 460 мс attbcstoll.bbnplanet.net [206.34.99.38]20 501 мс 460 мс 481 мс shutdown.ds.internic.net [198.49.45.29]

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

Далее идут IP-адрес и доменное имя (если оно имеется) маршрутизатора. Видно, что почти все интерфейсы маршрутизаторов поставщиков услуг Интернета заре­гистрированы в службе DNS, а первые два, относящиеся к локальным маршру­тизаторам, — нет.

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

Выводы

В то время как задачей протокола IP является передача данных между сетевыми интерфейса­ми в составной сети, основная задача протоколов TCP и UDP заключается в передаче данных между прикладными процессами, выполняющимися на разных конечных узлах сети.

Основным отличием TCP от UDP является то, что на протокол TCP возложена дополнительная задача — обеспечение надежной доставки сообщений через составную сеть, все узлы которой используют для передачи сообщений ненадежный дейтаграммный протокол IP.

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

Системные очереди к точкам входа прикладных процессов называют портами. Порты иденти­фицируются номерами и однозначно определяют приложение в пределах компьютера. Прило­жения, которые используют протокол UDP, получают номера портов UDP, а приложения, обра­щающиеся к протоколу TCP, номера портов TCP.

Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP, TFTP, DNS ит. п., то за ними централизовано закрепляются стандартные (назначенные) номера, называемые также общеизвестными номерами портов. Для тех служб, которые еще не стали столь распространенными, чтобы закреплять за ними стандартные номера, номера портов выделяются локальной операционной системой. Такие номера называют динамиче­скими.