Шрифт:
Ответ должен быть получен от сервера, авторизованного для управления маской адреса сервера. Обычно в качестве такого сервера применяется маршрутизатор, но может использоваться и хост. В ответе в полях сети и подсети установлены единицы, определяя 32-разрядное поле маски адреса.
Сервер маски адреса может быть сконфигурирован так, что, даже при отключении от сети на какое-то время, он будет далее передавать широковещательные сообщения Address Mask Reply, как только станет активным. Это предоставляет шанс на получение нужной информации системам, которые были запущены в то время, когда сервер был неактивен.
На рис. 7.13 показан формат запроса маски адреса и ответа на него. Тип 17 применяется для запроса, а тип 18 — для ответа. В общем случае можно игнорировать идентификатор и последовательный номер.
Рис. 7.13. Формат ICMP-сообщений Address Mask
На практике более предпочтительный метод определения маски адреса предоставляют протоколы загрузки, например Dynamic Host Configuration Protocol или BOOTP. Эти протоколы более эффективны, поскольку обеспечивают полный набор конфигурационных параметров. Кроме того, операции выполняются более точно, в том числе и некорректные.
7.6.3 Временная метка и ответ на Timestamp
Сообщение с ответом на Timestamp предоставляет сведения о времени в системе. Оно предназначено для оценки буферизации и обработки датаграммы на удаленной системе. Отметим следующие поля:
Originate timestamp (исходная временная метка) | Время последнего обращения к сообщению в системе-отправителе |
Receive timestamp (временная метка получения) | Время первого обращения к сообщению отвечающей системы |
Transmit timestamp (временная метка пересылки) | Время последнего обращения к сообщению отвечающей системы |
По возможности, возвращаемое время должно измеряться в миллисекундах относительно полуночи по универсальному времени (Universal Time), которое ранее называлось временем по Гринвичу (Greenwich Mean Time). Большинство реализаций реально возвращает одно и то же время в полях Receive timestamp и Transmit timestamp.
Протокол ICMP обеспечивает очень простой способ синхронизации систем по времени. Однако это несколько грубая синхронизация, поскольку на нее влияют задержки в сети. Существует более совершенный протокол сетевого времени (Network Time Protocol), который был разработан для синхронизации по времени в Интернете.
Тип 13 используется для запросов, а 14 — для ответов. Формат сообщения представлен на рис. 7.14.
Рис. 7.14. Формат сообщений запросов и ответов о временной метке
7.7 Просмотр действий в ICMP
Ниже показана часть отчета о статистике протоколов команды netstat. Приведенный фрагмент посвящен протоколу ICMP. В отчете отражены операции ICMP, выполненные после последней инициализации.
Система отправила 1075 сообщений Destination Unreachable. Был получен 231 запрос Echo Requests, на каждый из которых был отправлен ответ. Было получено 26 ответов Echo Replies.
Локальная система зафиксировала 21 сообщение ICMP, полученное с неверной контрольной суммой ICMP.
Системой было получено 1269 сообщений Destination Unreachable и 2 сообщения Source Quenches.
Следующий далее отчет команды netstat содержит сведения о маршрутизации. Видно, что через сообщения Redirect были динамически обнаружены новые маршрутизаторы. Было 12 отчетов о недостижимости точки назначения (Destination Unreachable). Для выбора маршрута по умолчанию было использовано около 349 подстановочных символов (wildcard).