TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
Обычно ICMP-сообщение указывает хосту источника на причину отбрасывания посланной им датаграммы. Однако при перегрузке такое сообщение может не дойти до этого хоста, генерирующего очень напряженный сетевой трафик. Кроме того, очень расплывчаты требования к обработке поступающих сообщений Source Quench.
Текущий документ по требованиям к хостам (RFC 1812) оговаривает в качестве особого пункта, что сообщения Source Quench вовсе не нужно посылать. Работа должна выполняться более совершенным механизмом управления
7.4.6 Сообщения Redirect
К локальной сети может быть подключено более одного маршрутизатора. Когда локальный хост посылает датаграмму не на тот маршрутизатор, последний пересылает ее и отправляет хосту источника ICMP-сообщение Redirect (перенаправление), как показано на рис. 7.8. Хост должен переключить последующий трафик на более короткий путь.
Рис. 7.8. Коррекция маршрутизации на хосте посредством сообщения Redirect
Сообщение Redirect используется и для выключения маршрутизатора системным администратором. Хост может быть сконфигурирован с единственным маршрутизатором по умолчанию; при этом он будет динамически определять возможности пересылки через другие маршрутизаторы.
Рис. 7.9. Формат ICMP-сообщения Redirect
Формат сообщения о перенаправлении показан на рис. 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.
■ Хост источника уменьшит размер датаграммы и повторит попытку.
Какое же значение нужно выбрать для следующей попытки? Спецификация IP предполагает сохранение значения MTU и его доступность для протоколов транспортного уровня. Если маршрутизатор имеет современное программное обеспечение, то он будет включать в пересылаемое дальше по сети сообщение Destination Unreachable размер MTU (см. рис. 7.10). Иногда средства защиты конфигурируются на полное исключение всех входящих сообщений ICMP, что не позволяет использовать механизм определения MTU по пути следования датаграммы.
Рис. 7.10. Сообщение Destination Unreachable приносит результат исследования размера
Поскольку пути пересылки могут меняться динамически, флажок "Не фрагментировать" нужно устанавливать во всех коммуникационных датаграммах. При необходимости маршрутизатор будут посылать сведения об обновлениях.
Если маршрутизатор использует устаревшее программное обеспечение, он не сможет предоставить значение MTU для следующего попадания. В этом случае значение для следующей попытки будет выбираться из списка стандартных размеров MTU (см. главу 4) с постепенным уменьшением для каждой новой попытки до достижения значения, нужного для коммуникации с удаленным хостом.