TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Формат сообщения о перенаправлении показан на рис. 7.9. Коды этого сообщения перечислены в таблице 7.5. Некоторые протоколы маршрутизации способны выбирать путь доставки на основе содержимого поля типа обслуживания (TOS) датаграммы. Коды 2 и 3 предоставляют некоторые сведения да такого выбора.

Таблица 7.5 Коды перенаправления

Код	Смысл
0	Перенаправление датаграммы в сеть
1	Перенаправление датаграммы в хост
2	Перенаправление датаграммы в сеть на основе значения из поля типа обслуживания
3	Перенаправление датаграммы в хост на основе значения из поля типа обслуживания

7.4.7 Управление поступающими сообщениями ICMP

Что должен делать хост, получивший сообщение ICMP? Реализации различных разработчиков по-разному отвечают на этот вопрос. В некоторых из них хосты игнорируют все или многие такие сообщения. Стандарты TCP/IP оставляют большую свободу выбора в решении этого вопроса. Для различных типов сообщений ICMP предлагаются следующие рекомендации:

Destination Unreachable	Доставить ICMP-сообщение на транспортный уровень. Выполняемые действия должны зависеть от того, является ли причина вывода сообщения временной или постоянной (например, административный запрет на пересылку).
Redirect	Хост обязан обновить таблицу маршрутизации.
Source Quench	Доставить ICMP-сообщение на транспортный уровень или в модуль обработки ICMP.
Time Exceeded	Доставить на транспортный уровень.
Parameter Problem	Доставить ICMP-сообщение на транспортный уровень с необязательным уведомлением пользователя.

Иногда ошибки должны обрабатываться совместно операционной системой, коммуникационным программным обеспечением и сетевым приложением.

7.5 Исследование MTU по пути

При пересылке большого объема данных (например, при копировании файлов по сети) с одного хоста на другой размер датаграмм существенно влияет на производительность. Заголовки IP и TCP требуют не менее 40 дополнительных байт.

■ Если данные пересылаются в 80-байтовых датаграммах, дополнительная нагрузка составит 50%.

■ Если данные пересылаются в 400-байтовых датаграммах, дополнительная нагрузка составит 10%.

■ Если данные пересылаются в 4000-байтовых датаграммах, дополнительная нагрузка составит 1%.

Для минимизации дополнительной нагрузки лучше отсылать датаграммы наибольшего размера. Однако этот размер ограничивается значением максимального элемента пересылки (Maximum Transmission Unit — MTU) для каждого из носителей. Если датаграмма будет слишком большой, то она будет фрагментирована, а этот процесс снижает производительность. (С точки зрения пользователя, качество сети определяется двумя параметрами: интервалом пересылки (от начала пересылки до ее завершения) и временем ожидания (задержкой доступа к сети, занятой другими пользователями). Увеличение размера датаграммы приводит к снижению интервала пересылки, но увеличению ожидания для других пользователей. Грубо говоря, нагрузка на сеть будет выглядеть как пиковые импульсы с очень небольшой нагрузкой между ними, что считается самым неудачным вариантом загрузки сети. Гораздо лучше, когда сеть нагружается равномерно. — Прим. пер.)

Многие годы хосты избегали фрагментации, устанавливая эффективное значение MTU для пересылки в 576 октетов для всех нелокальных хостов. Это часто приводило к ненужному снижению производительности.

Гораздо полезнее заранее знать наибольший допустимый размер датаграммы, которую можно переслать по заданному пути. Существует очень простой механизм исследования MTU по пути (Path MTU discovery), позволяющий узнать это значение. Для такого исследования:

■ Флаг "Не фрагментировать" заголовка IP устанавливают в 1.

■ Размер MTU по пути первоначально устанавливают в значение MTU для локального интерфейса.

■ Если датаграмма будет слишком велика для одного из маршрутизаторов, то он пошлет обратно ICMP-сообщение Destination Unreachable с кодом 4.

■ Хост источника уменьшит размер датаграммы и повторит попытку.