TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
Рис. 6.14. Интерпретация
Заголовок MAC начинается 6-байтовыми физическими адресами систем источника и назначения. Отметим, что анализатор Sniffer заменяет первые 3 байта каждого физического адреса на соответствующее имя компании — производителя сетевого адаптера (в нашем случае это Sun). Поле типа содержит код X'0800, что означает: "данную информацию доставлять в IP".
На рисунке датаграмма IP следует сразу за коротким MAC-заголовком сети DIX Ethernet. Это кадр стандарта 802.3, а за MAC-заголовком располагаются 8-байтовый заголовок LLC с подзаголовком SNAP.
Размер кадра — 61 байт. В эту величину включается 14-байтовый MAC-заголовок кадра, но не учитывается 4-байтовая завершающая часть MAC, поэтому полный кадр имеет длину 65 байт. Кадры Ethernet или 802.3 для носителя на коаксиальном кабеле должны иметь длину не менее 64 байт, следовательно, кадр едва не стал меньше допустимого минимального размера. Датаграмма кадра имеет общую длину только 47 байт.
Как и многие заголовки IP, рассматриваемый в примере заголовок не содержит
Можно заметить, что датаграмма не является фрагментом более длинной датаграммы, поскольку поле Fragment Offset хранит 0, показывая начало датаграммы, и второй флаг установлен в 0, указывая на ее конец.
Датаграмма зафиксировала информацию о 30 попаданиях в поле TTL. Поле Protocol имеет значение 6, что указывает на доставку датаграммы TCP на хост назначения.
Анализатор Sniffer транслировал IP-адреса источника и назначения в общепринятый формат с точками.
Шестнадцатеричные октеты, создающие исходный заголовок MAC и заголовок IP, показаны в нижней части рисунка. Заданный в Sniffer вывод в шестнадцатеричном формате был заменен на соответствующие, но более простые значения в формате с точками.
6.18 Сценарий обработки датаграммы
Для лучшего понимания работы IP рассмотрим операции по обработке датаграммы в маршрутизаторе и хосте назначения. Выполняемые при этом шаги показаны на рис. 6.15.
Рис. 6.15. Обработке датаграммы
Возникающие проблемы и ошибки приводят обычно к отбрасыванию датаграммы и посылке источнику сообщения об ошибке. Эти процессы будут рассмотрены в главе 7, посвященной протоколу Internet Control Message Protocol (ICMP).
6.18.1 Обработка в маршрутизаторе
После получения датаграммы маршрутизатор проводит серию проверок, чтобы узнать, не нужно ли отбросить данную датаграмму. Вычисляется контрольная сумма заголовка и сравнивается со значением из поля контрольной суммы.
Просматриваются поля версии, длины заголовка, общей длины и протокола для выявления имеющих смысл значений. Уменьшается значение из поля времени жизни. При ошибке в контрольной сумме, параметрах или нулевом значении времени жизни, а также в том случае, когда маршрутизатор не имеет достаточного объема памяти для продолжения ее обработки, датаграмма отбрасывается.
На следующем шаге выполняется анализ безопасности посредством серии предварительно сконфигурированных тестов. Например, маршрутизатор может ограничить входной трафик, чтобы было доступно только несколько серверов назначения.
Далее маршрутизатор выполняет процедуру маршрутизации датаграммы. По указанию в заголовке датаграммы выбирается вариант точного или произвольного маршрута от источника. Затем, если это необходимо и разрешено, осуществляется фрагментирование. Если датаграмма не может быть передана дальше без фрагментации, но поле "Не фрагментировать" имеет значение 1, она отбрасывается.
Имеющиеся варианты обрабатываются. Измененные заголовки должны быть построены для каждой датаграммы или ее фрагмента. Наконец повторно вычисляется контрольная сумма заголовка и датаграмма пересылается системе следующего попадания. Это наиболее общий сценарий обработки датаграммы маршрутизатором. Однако иногда он является конечной точкой назначения датаграммы. Например, запрос сетевой управляющей информации может посылаться на сам маршрутизатор.