 |
     |
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Мы уже видели, что Межсетевой протокол обеспечивает ненадежное средство доставки без установления соединения, и что дейтаграммы путешествуют от шлюза к шлюзу до тех пор, пока они не достигнут шлюза, который может напрямую доставить их к конечному месту назначения. Если шлюз не может маршрутизировать или доставить дейтаграмму, или если шлюз обнаружил необычные условия при работе, такие как переполнение сети, влияющие на его способность отправлять дейтаграммы, ему нужно сообщить первоначальному источнику, что требуется предпринять действия для решения возникшей проблемы. Эта глава рассматривает механизм, используемый шлюзами и ГВМ для передачи управляющей информации и информации об ошибках. Мы увидим, как шлюзы используют этот механизм, чтобы сообщать о проблемах при доставке, и как ГВМ используют его для проверки достижимости назначения.
В системе без установления соединения, которую мы описали, каждый шлюз работает автономно при маршрутизации или доставке прибывающих дейтаграмм, не координируя свои действия с исходным отправителем. Эта система хорошо работает, если все функционируют корректно и согласовали маршрутизацию, но ведь не существует систем, корректно работающих все время. Помимо сбоев линий передачи и процессоров, IP аварийно завершает доставку дейтаграмм, когда машина назначения временно или постоянно отключена от сети, когда обнуляется счетчик времени жизни, или когда промежуточные шлюзы так переполняются, что не могут обработать приходящий траффик. Важное различие между реальной, аппаратной сетью и интернетом, основанным на программном обеспечении, заключается в том, что в первом разработчик часто может положиться на сетевое оборудование при доведении до машин о возникновении проблем. В интернете, не имеющем такого аппаратного механизма, отправитель не может сказать, явился ли причиной ошибки при доставке сбой на локальной машине или удаленной. Отладка становится крайне трудной. В самом протоколе IP нет ничего, что могло бы помочь отправителю проверить связность или узнать о таких ошибках.
Чтобы дать возможность шлюзам в интернете сообщать об ошибках или предоставлять информацию о нестандартных условиях работы, разработчики добавили механизм сообщений специального назначения в протоколы TCP/IP. Этот механизм, известный как Межсетевой Протокол Управляющих Сообщений(ICMP), считается необходимой частью IP и должен включаться в каждую реализацию IP.
Как и весь другой траффик, сообщения ICMP передаются по интернету в поле данных IP-дейтаграмм. Конечным назначением сообщений ICMP, тем не менее, является не прикладная программа или пользователь на машине назначения, а программное обеспечение IP на этой машине. То есть, когда прибывает сообщение ICMP об ошибке, его обрабатывает модуль программного обеспечения ICMP. Конечно, если ICMP определит, что ошибка была вызвана конкретным протоколом более высокого уровня или прикладной программой, он сообщит об этом соответствующему модулю. Подведем итоги:
Межсетевой Протокол Управляющих Сообщений позволяет шлюзам посылать управляющие сообщения или сообщения об ошибках на другие шлюзы или ГВМ; ICMP обеспечивает взаимодействие между программным обеспечением Межсетевого Протокола разных машин.
Первоначально разработанный для предоставления шлюзам возможности сообщать о причинах ошибок доставки ГВМ, ICMP не предназначен только для шлюзов. Хотя руководства ограничивают использование некоторых сообщений ICMP, любая машина может послать сообщение ICMP на любую другую машину. Поэтому, ГВМ может использовать ICMP для связи со шлюзом или другим ГВМ. Главная выгода от разрешения ГВМ использовать ICMP заключается в том, что он обеспечивает простой механизм, используемый для всех управляющих и информационных сообщений.
Говоря техническим языком, ICMP - это механизм сообщения об ошибках. Он обеспечивает для шлюзов, обнаруживающих ошибки, способ сообщить об ошибке первоначальному источнику. Хотя спецификация протокола определяет допустимые способы использования ICMP и предлагает варианты возможных действий в ответ на ошибки, ICMP не специфицирует полностью действия, которые нужно предпринять в ответ на все возможные ошибки. Короче говоря:
ICMP только сообщает о возникших ошибках первоначальному источнику; источник сам должен связать ошибки с конкретными прикладными программами и предпринять действия по исправлению ошибок.
Большая часть ошибок исходит от первоначального источника, но другие - нет. Так как ICMP сообщает об ошибках первоначальному источнику, он не может использоваться, чтобы информировать промежуточные шлюзы об ошибках. Например, представим, что дейтаграмма следует по пути через шлюзы G1,G2,...,Gk. Если Gk содержит некорректную информацию о маршрутах и ошибочно отправит дейтаграмму на шлюз Gе, то Ge может лишь сообщить об ошибке первоначальному источнику. К сожалению, источник не отвечает за эту проблему и не может управлять некорректно ведущим себя шлюзом. Фактически, источник не сможет даже определить, какой шлюз вызвал эту проблему.
Зачем ограничивать ICMP взаимодействием с первоначальным источником ? Ответ должен быть очевиден, если вспомнить рассмотрение нами форматов дейтаграммы и маршрутизации в предыдущих главах. Дейтаграмма содержит поля, которые определяют только первоначального источника и конечного получателя; она не содержит полного описания своего пути через интернет(кроме необычных случаев, когда используется опция записи маршрута).
Более того, так как шлюзы могут создавать и менять свои таблицы маршрутизации, не существует глобального представления о путях. Поэтому, когда дейтаграмма достигает данного шлюза, нельзя узнать, какой путь она прошла до этого. Если шлюз обнаруживает ошибку, он не может узнать какие промежуточные машины обрабатывали эту дейтаграмму, и поэтому не может сообщить им об ошибке. Вместо простого удаления дейтаграммы этот шлюз использует ICMP, чтобы сообщить первоначальному источнику о возникшей проблеме, надеется на то, что администраторы ГВМ будут взаимодействовать с администраторами сети, чтобы локализовать и исправить ошибку.
Сообщения ICMP требуют двух уровней инкапсуляции, как показано на рисунке 9.1. Каждое сообщения ICMP передается по интернету в поле данных IP-дейтаграммы, которая сама передается по каждой физической сети в поле данных кадра. Дейтаграммы, несущие сообщения ICMP маршрутизируются точно так же, как и дейтаграммы, несущие информацию для пользователей; для них не используются дополнительные приоритет или надежность. Поэтому, сами сообщения об ошибках могут быть потеряны или удалены. Более того, в уже переполненной сети сообщения об ошибках могут вызвать дополнительное переполнение. Исключение делается для процедур обработки ошибок, если IP-дейтаграмма, несущая сообщение ICMP, вызвала ошибку. Это исключение, установленное для того, чтобы избежать проблемы появления сообщений об ошибках, вызванных в свою очередь сообщениями об ошибках, определяет, что сообщения ICMP не генерируются для ошибок, появившихся из-за дейтаграмм, несущих сообщения об ошибках ICMP.
Книги-online
--------------------------------------
|заголовок | данные ICMP |
| ICMP | |
--------------------------------------
V V
-------------------------------------------------
| заголовок| область данных дейтаграммы |
|дейтаграмм| |
-------------------------------------------------
V V
-----------------------------------------------------------
|заголовок| область данных кадра |
|кадра | |
-----------------------------------------------------------
Рисунок 9.1 Два уровня инкапсуляции ICMP. Сообщение ICMP инкапсулируется в IP-дейтаграмме, которая в свою очередь инкапсулируется в кадре для передачи. Для идентификации ICMP поле протокола дейтаграммы содержит значение 1.
Важно помнить, что несмотря на то, что сообщения ICMP инкапсулируются и посылаются, используя IP, ICMP не считается протоколом более высокого уровня - он является необходимой частью IP. Причина использования IP для транспортировки сообщений ICMP заключается в том, что им понадобиться пересечь несколько физических сетей для того, чтобы достичь своего конечного назначения. Поэтому, они не могут быть доставлены только с помощью физической передачи.
Хотя каждое сообщение ICMP имеет свой собственный формат, все они начинаются с трех одинаковых полей: 8-битового целочисленного поля ТИП, которое идентифицирует сообщение, 8-битового поля КОД, которое обеспечивает более точную информацию о типе сообщения, и 16-битового поля КОНТРОЛЬНАЯ_СУММА(ICMP использует тот же самый аддитивный алгоритм, что и IP, но контрольная сумма ICMP учитывает только сообщение ICMP). Помимо того, сообщения ICMP, сообщающие об ошибках, всегда включают заголовок и первые 64 бита данных дейтаграммы, вызвавшей ошибку.
Причиной возвращения не только заголовка дейтаграммы, вызвавшей ошибку, является желание позволить получателю более точно определять, какие протоколы и какие прикладные программы ответственны за появление этой дейтаграммы. Как мы увидим позже, протоколы более высокого уровня в связке TCP/IP разрабатывались таким образом, что критическая информация закодирована в первых 64 битах.
Поле ТИП ICMP определяет смысл сообщения, а также его формат. Эти типы включают:
| Поле ТИП | Тип сообщения ICMP |
|---|---|
| 0 | Ответ на эхо |
| 3 | Назначение недостижимо |
| 4 | Подавление источника |
| 5 | Переназначение(изменение маршрута) |
| 8 | Запрос эха |
| 11 | Превышено время для дейтаграммы |
| 12 | Ошибка параметра в дейтаграмме |
| 13 | Запрос временной отметки |
| 14 | Ответ для временной метки |
| 15 | Запрос информации(не действует) |
| 16 | Ответ на запрос информации(не действует) |
| 17 | Запрос маски адреса |
| 18 | Ответ на запрос маски адреса |
Следующие секции описывают каждое из этих сообщений, приводя при этом детальное описание формата сообщения и их смысл.
Протоколы TCP/IP обеспечивают средства, помогающие сетевым администраторам или пользователям идентифицировать проблемы в сети. Одно из самых наиболее используемых средств отладки вызывает сообщения ICMP запрос эха и ответ эха. ГВМ или шлюз посылает сообщение запроса эха указанному месту назначения. Любая машина, получившая запрос эха, генерирует ответ на эхо и возвращает его первоначальному отправителю. Этот запрос содержит необязательную область данных; ответ содержит копию данных, посланных в запросе. Запрос эха и связанный с ним ответ могут использоваться для проверки достижимости назначения и его способности отвечать на запросы. Так как и запрос эха, и ответ на него передаются в IP-дейтаграммах, успешный прием ответа свидетельствует о работоспособности основных частей транспортной системы. Во-первых, программное обеспечение IP на машине источника произвело маршрутизацию дейтаграммы. Во-вторых, промежуточные шлюзы между источником и получателем работоспособны и корректно маршрутизируют дейтаграммы. В-третьих, машина получателя работает (по крайней мере, она обрабатывает прерывания) и программное обеспечение как IP, так и ICMP выполняет свои функции. И наконец, таблицы маршрутов в шлюзах на всем обратном пути корректны.
Во многих системах команда, которую пользователи вызывают для посылки запроса эха ICMP, называется ping. Усложненные версии этой программы посылают серии запросов эха ICMP, принимают ответы и выдают статистику о потерях дейтаграмм. Они позволяют пользователю указывать длину посылаемых данных и интервалы времени между запросами. Менее сложные версии просто посылают запрос эха ICMP и ждут ответа.
Рисунок 9.2 содержит формат сообщений запроса эха и ответа на запрос эха.
0 8 16 ------------------------------------------------------------ |тип(8 или 0)| код(0) | Контрольная сумма | ------------------------------------------------------------ | идентификатор | последовательный номер | ------------------------------------------------------------ | необязательные данные | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.2 Формат сообщения запроса эха и ответа на него
Поле, названное НЕОБЯЗАТЕЛЬНЫЕ ДАННЫЕ имеет переменную длину и содержит данные, которые надо вернуть отправителю. Ответ на эхо всегда возвращает те же самые данные, что были получены им в запросе. Поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются отправителем для проверки соответствия ответов запросам. Значение поля ТИП определяет, является ли сообщение запросом(8) или ответом(0).
Когда шлюз не может доставить IP-дейтаграмму, он посылает сообщение "назначение недостижимо" обратно первоначальному отправителю, используя формат, приведенный на рисунке 9.3.
0 8 16 ------------------------------------------------------------ |тип(3) | код(0-5) | Контрольная сумма | ------------------------------------------------------------ | не используется(должно быть равно нулю) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.3 Формат сообщения о недостижимости назначения
Поле КОД в сообщении о недостижимости назначения содержит целое число, которое описывает причину. Возможны следующие значения:
| Значение | Смысл |
|---|---|
| 0 | Сеть недостижима |
| 1 | ГВМ недостижим |
| 2 | Протокол недостижим |
| 3 | Порт недостижим |
| 4 | Требуется фрагментация |
| 5 | Ошибка при маршрутизации источника |
| 6 | Сеть назначения неизвестна |
| 7 | ГВМ назначения неизвестен |
| 8 | ГВМ источника изолирован |
| 9 | Взаимодействие с сетью назначения административно запрещено |
| 10 | Взаимодействие с ГВМ назначения административно запрещено |
| 11 | Сеть недостижима из класса обслуживания |
| 12 | ГВМ недостижим из-за класса обслуживания |
Хотя IP является механизмом ненадежной доставки, дейтаграммы не уничтожаются просто так. Всякий раз, когда ошибка мешает шлюзу произвести маршрутизацию или доставку дейтаграммы, шлюз посылает сообщение о недостижимости назначения обратно его источнику, а затем уничтожает дейтаграмму. Ошибки недостижимости сети обычно являются следствием ошибок маршрутизации; ошибки недостижимости ГВМ - следствие ошибок при доставке(исключением является случай, когда шлюзы используют схему адресации подсетей, описанную в главе 16. Они сообщают об ошибке при маршрутизации к подсети с помощью сообщения ICMP о недостижимости ГВМ). Так как сообщение содержит короткий префикс дейтаграммы, вызвавшей ошибку, то источник будет точно знать, какой адрес недостижим.
Назначения могут быть недостижимыми из-за того, что оборудование было временно неработоспособно, из-за того, что отправитель указал несуществующий адрес назначения, или ( в редких случаях) из-за того, что у шлюза не указано маршрута к сети назначения. Отметим, что хотя шлюзы сообщают об ошибках, которые они обнаружили, они могут не знать обо всех ошибках доставки. Например, если машина получателя присоединена к сети Ethernet, то сетевое оборудование не предоставляет подтверждения получения дейтаграммы. Поэтому, шлюз может продолжать посылать пакеты назначению даже после того, как оно отключено, не получая при этом никакой информации о том, что пакеты не доставляются. Подведем итоги:
Хотя шлюзы посылают сообщения о недостижимости назначения, если они не могут произвести маршрутизацию или доставку дейтаграммы, не все подобные ошибки обнаруживаются.
Смысл сообщений о недостижимости порта и протокола станет ясен, когда мы изучим, как протоколы более высокого уровня используют абстракцию точки получения, называемую портом. Смысл большей части остальных сообщений понятен уже из их названия. Если дейтаграмма содержит опцию маршрутизации источника с некорректным маршрутом, то это может привести к появлению сообщения об ошибке маршрутизации источника. Если шлюзу нужно фрагментировать дейтаграмму, но установлен бит "не фрагментировать", то шлюз посылает сообщение "требуется фрагментация" обратно источнику.
Так как IP является протоколом без установления соединения, то шлюзы не могут резервировать память или коммуникационные ресурсы до получения дейтаграмм. В результате, траффик может вызвать перегрузку шлюзов, ситуацию, называемую переполнением сети(congestion). Важно понимать, что переполнение сети может возникать из-за двух совершенно разных причин. Во-первых, высокоскоростной компьютер может генерировать траффик быстрее, чем сеть может передавать его. Например, представим суперкомпьютер, генерирующий межсетевой траффик. Дейтаграммам, посылаемым им, может потребоваться передача в конечном счете по медленной глобальной сети(WAN), хотя сам суперкомпьютер может быть присоединен к высокоскоростной локальной сети. Переполнение будет возникать в шлюзе, присоединенном к глобальной сети, так как дейтаграммы будут прибывать быстрее, чем их можно послать. Во-вторых, если большому числу компьютеров одновременно нужно посылать дейтаграммы через один шлюз, этот шлюз может оказаться переполненным, хотя ни один источник в отдельности и не вызывает эту проблему.
Когда дейтаграммы прибывают на шлюз или ГВМ быстрее, чем он успевает их обрабатывать, он временно ставит их в очередь в своей памяти. Если эти дейтаграммы - это часть небольшого пика при передаче дейтаграмм, то такая буферизация решает проблему. Если же траффик продолжает поступать, то то в конечном счете ГВМ или шлюз займет всю память под очередь и вынужден будет удалять новые прибывающие дейтаграммы. Тогда машина использует сообщения о подавлении источника для выхода из состояния переполнения.
Сообщение о подавлении источника требует от источника уменьшить скорость передачи дейтаграмм. Обычно переполненные шлюзы посылают по одному сообщению о подавлении источника на каждую удаляемую дейтаграмму. Шлюзы могут также использовать более сложные технологии выхода из переполнения. Некоторые наблюдают за приходящим траффиком и подавляют источники с наивысшими скоростями передачи. Другие пытаются избежать переполнения в принципе, выдавая запросы подавления источника в том случае, когда их очереди начинают становиться слишком длинными, но до того, как они переполнятся.
Не существует сообщения ICMP, вызывающего эффект, обратный подавлению источника. Вместо этого ГВМ, принявший сообщения о подавлении источника от некоторой машины, М, снижает скорость, с которой он посылает дейтаграммы на М до тех пор, пока к нему не перестанут приходить сообщения о подавлении источника; затем он постепенно увеличивает скорость до тех пор, пока он снова не получит сообщения о подавлении источника.
Помимо обычных полей ICMP ТИП, КОД и КОНТРОЛЬНАЯ СУММА, и неиспользуемого 32-битового поля, сообщения о подавлении источника имеют поле, содержащее префикс дейтаграммы. Рисунок 9.4 иллюстрирует этот формат. Как и в других сообщениях об ошибках ICMP поле префикса дейтаграммы содержит префикс дейтаграммы, вызвавшей этот запрос подавления источника.
0 8 16 31 ------------------------------------------------------------ |тип(4) | код(0) | Контрольная сумма | ------------------------------------------------------------ | не используется(должно быть равно нулю) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.4 Формат сообщения о подавлении источника ICMP. Переполненные шлюзы посылают одно сообщение о подавлении источника каждый раз, когда они удаляют дейтаграмму; префикс дейтаграммы идентифицирует удаленную дейтаграмму.
Таблицы маршрутизации Интернета обычно не меняются в течение длинного промежутка времени. ГВМ инициализируют их с помощью файла конфигурации при загрузке системы, а сетевые администраторы лишь изредка вносят в них изменения при нормальной работе. При изменении топологии сети таблицы маршрутизации в ГВМ или шлюзе могут стать некорректными. Изменение может быть временным(например, нужно заменить неисправное оборудование) или постоянным(например, когда новая сеть добавляется к интернету). Как мы увидим позже, шлюзы периодически обмениваются информацией о маршрутизации, чтобы отслеживать изменения в сети и своевременно менять маршруты. Поэтому можно сформулировать общее правило:
Предполагается, что шлюзы знают корректные маршруты; ГВМ начинают работать, имея минимум информации о маршрутах, но впоследствии узнают новые маршруты от шлюзов.
Чтобы помочь придерживаться этого правила и чтобы избежать дублирования информации о маршрутизации в файле конфигурации каждого ГВМ, в начальной конфигурации ГВМ указывается минимум информации о маршрутизации, необходимый для взаимодействия (например, адрес одного шлюза). Поэтому ГВМ начинает работать, имея минимальную информацию, и полагается на то, что шлюзы помогут обновить ему таблицу маршрутизации. Если шлюз обнаруживает, что ГВМ использует неоптимальный маршрут, он посылает ГВМ сообщение ICMP, называемое "переназначением", запрашивающее изменение маршрута в таблице маршрутизации ГВМ. Этот шлюз также отправляет исходную дейтаграмму к ее назначению. Преимуществом схемы переназначения ICMP является ее простота: она позволяет ГВМ знать вначале адрес только одного шлюза в локальной сети. Этот начальный шлюз возвращает сообщение ICMP о переназначении всякий раз, когда ГВМ посылает дейтаграмму, для которой существует лучший маршрут. Таблица маршрутизации ГВМ останется маленькой, но будет содержать оптимальные маршруты для всех используемых назначений.
Сообщения о переназначении, тем не менее, не решают проблему распространения информации о маршрутах полностью, так как они предназначены только для взаимодействия между шлюзом и ГВМ в одной физической сети. Рисунок 9.5 иллюстрирует эту проблему. Согласно рисунку предполагается, что источник И посылает дейтаграмму назначению Н. Пусть шлюз Ш1 некорректно направляет дейтаграмму через шлюз Ш2 вместо шлюза Ш4(то есть Ш1 по ошибке выбрал более длинный путь). Когда шлюз Ш5 принимает дейтаграмму, он не может послать сообщение переназначения ICMP Ш1, так как он не знает адрес шлюза Ш1. Последующие главы рассмотрят проблему, как распространяется информация о маршрутах между несколькими сетями.
| -- | -- |
-- |--|Ш1|-|-|Ш2|-| -- | |
| И|--| -- | -- |-|Ш3|-| -- |
-- | | -- |---|Ш5|-| --
| | -- | -- |--| Н|
| |----|Ш4|-----| | --
| | -- |
Рисунок 9.5 Сообщения о переназначении ICMP не помогают маршрутизации между шлюзами. В этом примере шлюз Ш5 не может заставить Ш1 использовать более короткий путь для дейтаграмм между И и Н.
Помимо полей-реквизитов ТИП, КОД и КОНТРОЛЬНАЯ СУММА, каждое сообщение о переназначении содержит 32-битовое поле МЕЖСЕТЕВОЙ АДРЕС ШЛЮЗА и поле ПРЕФИКС ДЕЙТАГРАММЫ, как это показано на рисунке 9.6
0 8 16 31 ------------------------------------------------------------ |тип(5) |код(от 0 до 3)| Контрольная сумма | ------------------------------------------------------------ | межсетевой адрес шлюза | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.6 Формат сообщения о переназначении ICMP
Поле МЕЖСЕТЕВОЙ АДРЕС ШЛЮЗА содержит адрес шлюза, который должен использовать ГВМ при отправлении дейтаграммы к назначению, указанному в заголовке дейтаграммы. Поле МЕЖСЕТЕВОЙ ЗАГОЛОВОК содержит заголовок IP и следующие 64 бита дейтаграммы, которая привела к появлению этого сообщения. Поэтому ГВМ, принимающий сообщение о переназначении ICMP, должен выделить адрес назначения дейтаграммы из префикса дейтаграммы. Поле КОД в сообщении о переназначении ICMP более конкретно указывает, как интерпретировать адрес назначения, при этом значения имеют следующий смысл:
| Значение кода | Смысл сообщения |
|---|---|
| 0 | Переназначение дейтаграмм для этой сети(устарело) |
| 1 | Переназначение дейтаграмм для этого ГВМ |
| 2 | Переназначение дейтаграмм для этого типа сервиса и сети |
| 3 | Переназначение дейтаграмм для этого типа сервиса и ГВМ |
Замечание. Напомним, что каждый заголовок IP указывает тип сервиса, используемого при маршрутизации
Как правило, шлюзы посылают запросы переназначения ICMP только на ГВМ, а не на другие шлюзы. Позже мы увидим, что шлюзы используют другие протоколы для обмена информацией о маршрутизации.
Так как межсетевые шлюзы вычисляют адрес следующей машины для направления дейтаграммы на основе локальных таблиц, ошибки в таблице маршрутизации могут привести к циклу маршрутизации в некотором месте назначения, D. Цикл маршрутизации может состоять из двух шлюзов, каждый из которых отправляет дейтаграмму с адресом назначения D другому шлюзу, или может состоять из большего числа шлюзов. Когда несколько шлюзов формируют цикл маршрутизации, каждый из них отправляет дейтаграмму с назначением Н к следующему шлюзу из цикла. Если дейтаграмма входит в цикл маршрутизации, она будет передаваться по нему бесконечно. Как было отмечено ранее, для защиты дейтаграмм от бесконечного курсирования по Интернету TCP/IP каждая дейтаграмма имеет счетчик время жизни, иногда называемый число попыток. Шлюз декрементирует счетчик времени жизни всякий раз, когда он обрабатывает дейтаграмму, и удаляет дейтаграмму, когда счетчик становится нулевым.
Независимо от того, удалил ли шлюз дейтаграмму из-за обнуления счетчика времени жизни или из-за превышения времени ожидания фрагментов дейтаграммы, он посылает сообщение ICMP "превышено время" источнику дейтаграммы, используя формат, показанный на рисунке 9.7
0 8 16 31 ------------------------------------------------------------ |тип(11) |код(0 или 1) | Контрольная сумма | ------------------------------------------------------------ | не используется(должно быть нулем) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.7 Формат сообщения ICMP о превышении времени. Шлюз посылает это сообщение всякий раз, когда удаляет дейтаграмму из-за обнуления поля времени жизни в заголовке дейтаграммы или из-за обнуления таймера сборки при ожидании фрагментов дейтаграммы.
Поле КОД объясняет причину сообщения:
| Значение кода | Смысл |
|---|---|
| 0 | Превышено значение счетчика времени жизни |
| 1 | Превышено время ожидания фрагмента при сборке |
Сборкой фрагментов называют задачу сбора всех фрагментов дейтаграммы. Когда прибывает первый фрагмент дейтаграммы, принимающий ГВМ запускает таймер и считает ошибкой его обнуление до прихода всех фрагментов дейтаграммы. Значение кода 1 используется для того, чтобы сообщить отправителю о такой ошибке; для каждой ошибки посылается отдельное сообщение.
Когда шлюз или ГВМ сталкивается с проблемой, связанной с дейтаграммой, не укладывающейся в рамки описанных сообщений об ошибках ICMP( например, некорректный заголовок дейтаграммы), он посылает сообщение "ошибка параметров" первоначальному отправителю. Одной из возможных причин такой ситуации может быть некорректность аргументов опции. Сообщение, формат которого приведен на рисунке 9.8, посылается только в том случае, если дейтаграмма должна быть удалена из-за этой ошибки.
0 8 16 ------------------------------------------------------------ |тип(12) | код(0 или 1) | Контрольная сумма | ------------------------------------------------------------ |указатель | не используется(должно быть равно нулю) | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | ...... | ------------------------------------------------------------
Рисунок 9.8 Формат сообщения ICMP ошибка параметров. Такие сообщения посылаются только в том случае, когда из-за этой ошибки дейтаграмму удаляется.
Для однозначности сообщения отправитель использует поле УКАЗАТЕЛЬ в заголовке сообщения для идентификации октета в дейтаграмме, вызвавшего ошибку. Код 1 используется для случая, когда требуемая опция отсутствует( например, опция секретности в военной связи); поле указатель не используется при коде 1.
Хотя машины в интернете могут взаимодействовать, обычно они работают независимо друг от друга, причем у каждой машины свое понятие о текущем времени. Сильно отличающиеся часы могут смущать пользователей распределенных систем. Стек протоколов TCP/IP включает несколько протоколов, которые могут использоваться для синхронизации часов. Одна из простейших технологий использует сообщения ICMP для получения значения времени от другой машины. Запрашивающая машина посылает сообщение ICMP "запрос временной метки" другой машине, ожидая, что вторая машина вернет ей текущее значение времени. Принимающая машина возвращает "ответ временной метки" машине, выдавшей запрос. Рисунок 9.9 показывает формат сообщений запроса и ответа временной метки.
0 8 16 ------------------------------------------------------------ |тип(13, 14) | код(0) | Контрольная сумма | ------------------------------------------------------------ | идентификатор | последовательный номер | ------------------------------------------------------------ | межсетевой заголовок плюс первые 64 бита дейтаграммы | ------------------------------------------------------------ | временная метка отправителя | ------------------------------------------------------------ | временная метка приема | ------------------------------------------------------------ | временная метка передачи | ------------------------------------------------------------
Рисунок 9.9 Формат сообщений ICMP запроса и ответа временной метки
Поле ТИП идентифицирует сообщение как запрос(13) или ответ(14); поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР используются источником для связи между ответами и запросами. Оставшиеся поля специфицируют времена, указанные в миллисекундах после полуночи, по Гринвичу. Поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ заполняется первоначальным отправителем перед передачей пакета, поле ВРЕМЕННАЯ МЕТКА ПРИЕМА заполняется сразу после приема запроса, и поле ВРЕМЕННАЯ МЕТКА ПЕРЕДАЧИ заполняется непосредственно перед отправкой ответа.
ГВМ используют эти три поля временных меток для определения ожидаемого времени передачи между ними и синхронизации своих часов. Так как ответ включает поле ВРЕМЕННАЯ МЕТКА ОТПРАВИТЕЛЯ, ГВМ может вычислить общее время, требуемое для передачи запроса к назначению, формирования ответа на него и возвращения ответа. Так как ответ содержит как время прихода запроса на удаленную машину, так и время выдачи ответа, ГВМ может вычислить время передачи по сети, а на его основе - разницу между своими и удаленными часами. На практике бывает трудно точно оценить время передачи по сети, что ограничивает полезность сообщений ICMP о временных метках. Конечно, для получения точной оценки времени передачи по сети нужно сделать много измерений и усреднить их. Тем не менее, время передачи по сети между двумя машинами, присоединенными к большому интернету, может сильно меняться, даже за короткий отрезок времени. Более того, напомним, что так как IP является технологией с негарантированной доставкой, дейтаграммы могут быть потеряны, задержаны или доставлены не по порядку. Поэтому, простые измерения не гарантируют согласованности; требуется сложный статистический анализ для точной оценки.
Сообщения ICMP запроса информации и ответа информации( тип 15 и 16) считаются в настоящее время устаревшими и не должны использоваться. Они предназначались для обнаружения ГВМ своих межсетевых адресов при загрузке. Сейчас для определения адреса используется протоколы RARP(глава 6), и BOOTP(глава 19).
Глава 16 рассмотрит причины адресации подсетей, а также детали ее реализации. А пока только важно понимать, что когда ГВМ используют адресацию подсетей, некоторые биты в поле идентификатора ГВМ их IP-адреса идентифицируют физическую сеть. Для применения адресации подсетей ГВМ надо знать, какие биты их 32-битного межсетевого адреса соответствуют физической сети, а какие - идентификатору ГВМ. Информация, требуемая для интерпретации адреса, представляет собой 32-битовую величину, называемую маской подсети.
Чтобы узнать маску подсети, используемую в локальной сети, машина может послать сообщение запроса маски адреса шлюзу и получить ответ маски адреса. Машина, делающая запрос, может либо послать сообщение напрямую, если она знает адрес шлюза, или послать широковещательное сообщение, если не знает его. Рисунок 9.10 показывает формат сообщения маски адреса.
0 8 16 ------------------------------------------------------------ |тип(17, 18) | код(0) | Контрольная сумма | ------------------------------------------------------------ | идентификатор | последовательный номер | ------------------------------------------------------------ | маска адреса | ------------------------------------------------------------
Рисунок 9.10 Формат сообщений запроса маски адреса и ответа маски адреса. Обычно, ГВМ передают широковещательный запрос, не зная, какой шлюз будет отвечать им.
Поле ТИП в сообщении маски адреса указывает, является ли сообщение запросом(17) или ответом(18). Ответ содержит маску адреса подсети сети в поле МАСКА АДРЕСА. Как правило, поля ИДЕНТИФИКАТОР и ПОСЛЕДОВАТЕЛЬНЫЙ НОМЕР позволяют машине связать ответ с запросом.
Обычное взаимодействие через интернет включает посылку сообщений от пользовательского процесса на одной ГВМ пользовательскому процессу на другой ГВМ. Шлюзам может понадобиться прямое взаимодействие с сетевым программным обеспечением на конкретном ГВМ для сообщения ему об ошибках или для посылки ГВМ новой информации о маршрутах.
ICMP обеспечивает специальное взаимодействие между шлюзами и ГВМ; он является необходимой частью IP. ICMP включает в себя сообщения о "подавлении источника", регулирующие скорость передачи, сообщения "переназначения", требующие от ГВМ изменения таблиц маршрутизации, сообщения "запроса/ответа эха", которые ГВМ может использовать, чтобы определить, достижимо ли назначение. Сообщение ICMP передается в поле данных дейтаграммы IP и имеет три поля фиксированной длины в начале сообщения: поле типа сообщения ICMP, поле кода и поле контрольной суммы ICMP. Тип сообщения определяет формат остальной части сообщения и его смысл.
Как Tanenbaum[1981], так и Stallings[1985] рассматривают управляющие сообщения в-общем и связывают их с различными сетевыми протоколами. Главным вопросом является не то, как посылать управляющие сообщения, а когда. Grange и Gien[1979], а также Driver, Hopewell, и Iaquinto[1979] сосредотачиваются на проблеме управления потоком, для которой управляющие сообщения необходимы. Gerla и Kleinrock[1980] аналитически сравнивают стратегии управления потоком.
ICMP, описанный здесь как стандарт TCP/IP, разработан Postel[RFC 792]. Nae[RFC 896] рассматривает сообщения подавления источника и показывает, как шлюзы должны использовать их для ликвидации перегрузки сети. Prue и Postel[RFC 1016] рассматривают более новую технологию, которую используют шлюзы при подавлении источника. Nae[1987] доказывает, что перегрузка всегда является проблемой в сетях с пакетной коммутацией. Mogul и Postel[RFC 950] рассматривают сообщения запроса и ответа маски подсети. Наконец, Jain, Ramakrishnan и Chui [1987] показывают, как шлюзы и транспортные протоколы могут взаимодействовать для ликвидации перегрузки сети.
Более подробно протоколы синхронизации часов описаны в Mills[RFC 956, 957 и 958].
9.1 Попробуйте определить сколько сообщения ICMP и какого типа появляется в вашей локальной сети в течение дня.
9.2 Попробуйте, сможете ли вы посылать пакеты через шлюз так быстро, что получите сообщение ICMP о подавлении источника.
9.3 Разработайте алгоритм, синхронизирующий часы на основании сообщений ICMP о временных метках.
9.4 Посмотрите, содержит ли ваша операционная система команду ping. Можно ли создать ее самому ?
9.5 Предположим, что операционная система посылает сообщения ICMP о превышении времени прикладным программам. Используйте их для выполнения команды traceroute, выдающей список шлюзов между источником и конкретными назначениями.
9.6 Если вы присоединены к Интернету, попробуйте запустить утилиту ping для ГВМ 128.10.2.1 ( машина в Пурдью)
9.7 Должен ли шлюз давать сообщениям ICMP более высокий приоритет по сравнению с обычным траффиком ? Почему ?
9.8 Рассмотрим Ethernet, имеющий один ГВМ и 12 шлюзов, присоединенных к нему. Определите, какой кадр(немного неправильный), содержащий IP-пакет и посланный ГВМ, заставит ГВМ принять 24 пакета.
9.9 Сравните пакеты подавления источника ICMP с однобитовой схемой Jaina. Какая из стратегий более удобна для ликвидации перегрузки сети ? Почему ?
9.10 Не существует сообщений ICMP, позволяющих машине информировать источник, что ошибки передачи приводят к тому, что дейтаграммы принимаются испорченными. При каких условиях такое сообщение может быть полезным ?
9.11 Должны ли сообщения об ошибках ICMP содержать временные метки, определяющие, когда они были посланы ? Почему ?
Назад | Содержание | Вперед
|