
взаимодействия. Так же эти сообщения могут использоваться для решения
задачи связанной с выяснением возможности обмена пакетами между
узлами, если по каким либо причинам использовать сообщения типа 0 и 8
нельзя. Но, в этом случае длина пакета фиксирована и невелика всего 12
байт данных.
• Выяснить IP адреса портов промежуточных маршрутизаторов при передаче
пакетов некоторому узлу с помощью сообщений типа 11 (Time Exceeded),
хотя, и сам протокол IP имеет для этого некоторые встроенные средства.
• Исследовать MTU транзитных сетей с помощью сообщения типа 3 с кодом 4
(Destination Unreachable - Fragmentation needed and DF set).
• Выяснить причины недостижимости узлов в сети благодаря сообщениям
типа 3 с кодами 1 и 2 (Destination Unreachable - Host Unreachable и Protocol
Unreachable).
• Выяснить, что на узлах не используются те или иные протоколы (тип 3 код
2)
• Выяснить, что на узлах не используются те или иные приложения UDP (тип
3 код 2)
Помимо администратора, преимущества от использования ICMP так же
получают и приложения. Например, в адрес приложения приходят сообщения об
ошибках типа 3 со всеми кодами (Destination Unreachable), типа 11 или типа 12
(Time Exceeded и Parameter Problem), при этом приложение оперативно
информирует об этом пользователя, сокращая тем самым лишний трафик,
который мог бы быть отправлен и время ожидания пользователя.
Кроме того, ICMP сообщения позволяют получить преимущества для самой
сети:
• Сообщения типа 5 (ICMP Redirect) могут уменьшить трафик путем более
разумной маршрутизации некоторых пакетов
• Сообщения типа 4 (ICMP Source Quench) позволяют избежать перегрузок в
сети и предотвратить перегрузки в сети и как следствие, потери пакетов
(уже устарело, напомнить – почему и какой протокол этим сейчас
занимается)
Так же сообщения типов 9 и 10 (Router Advertisement и Router Solicitation)
позволяют администратору организовать для пользователей динамическое
взаимодействие с маршрутизаторами, увеличивая тем самым надежность
функционирования сети.
Тем не менее, по усмотрению разработчиков, протокол типа ICMP, вообще
говоря, может быть, и не реализован в стеке протоколов операционной системы.
В истории развития компьютерных сетей существуют относительно полноценные
стеки протоколов, например, IPX/SPX, в которых реализованы функции от
сетевого уровня модели OSI и выше. Но при этом никакого аналога ICMP такие
стеки не содержат, что значительно затрудняет диагностику неисправностей в
составных сетях, базирующихся на указанных стеках протоколов. В конечном
счете, такое положение вещей делает подобные стеки протоколов менее
пригодными для построения больших составных сетей.
Таким образом, к этому моменту нами рассмотрены следующие базовые
темы курса:
• Причины, приводящие к необходимости использования сетевого
уровня модели OSI