Учебно-методическии комплекс дисциплины «Компьютерные сети» для специальности 6М011100 — «Информатика» (стр. 48 )

Когда хост-адресат получает серию дейтаграмм, он должен определить, являются ли данные дейтаграммы фрагментами некой исходной дейтаграммы большего размера. Если он выясняет, что некие дейтаграммы представляют собой фрагменты, ему нужно также идентифицировать последний фрагмент дейтаграммы, чтобы можно было собрать эти фрагменты вместе в оригинальную дейтаграмму и выяснить, как это делается. Чтобы хост-получатель мог осуществлять повторную сборку дейтаграмм, разработчики IPv4 поместили в дейтаграмму поля идентификации, флага и фрагментации. Когда дейтаграмма создается, хост-отправитель маркирует ее номером-идентификатором, а также помещает в нее адреса отправителя и получателя. Хост-отправитель увеличивает на единицу идентификационный номер для каждой следующей посылаемой дейтаграммы. Когда маршрутизатору необходимо фрагментировать дейтаграмму, каждый получающийся фрагмент помечается адресом отправителя, адресом получателя и идентификационным номером оригинальной дейтаграммы. Когда хост-адресат получает серию дейтаграмм от одного и того же передающего хоста, он изучает идентификационные номера дейтаграмм, чтобы определить, являются ли данные дейтаграммы фрагментами дейтаграммы большего размера. Поскольку протокол IP предоставляет ненадежную службу, один или несколько фрагментов могут не достичь адресата. Чтобы хост-адресат мог быть абсолютно уверен в том, что получил последний фрагмент оригинальной дейтаграммы, бит флага в последнем фрагменте устанавливается в 0, тогда как во всех остальных фрагментах он устанавливается в 1. Кроме того, чтобы хост-адресат мог определить, не был ли потерян какой-либо из фрагментов (а также иметь возможность собрать фрагменты оригинальной дейтаграммы в правильном порядке), в каждом фрагменте имеется поле смещения.

На рис. 10.12 изображен пример. Дейтаграмма из 4000 байт (20 байт IP-заголовка и 3980 байт полезной нагрузки) прибывает на маршрутизатор и должна быть переправлена далее по линии с максимальным размером поля данных в 1500 байт.

Это означает, что 3980 байт оригинальной дейтаграммы должны быть распределены между тремя отдельными фрагментами (каждый из которых также представляет собой IP-дейтаграмму). Предположим, что оригинальная дейтаграмма маркирована идентификационным номером 777. Характеристики трех фрагментов показаны в табл. 10.3.

Рис. 10.12 Фрагментация и повторная сборка IP-дейтаграммы

Таблица 10.3 IP-фрагменты

Полезная нагрузка дейтаграммы передается транспортному уровню получателя только после того, как IP-уровень полностью восстановит оригинальную дейтаграмму. Если один или несколько фрагментов не сумеют достичь адресата, вся дейтаграмма отбрасывается и не передается транспортному уровню. Но, как было показано в предыдущей главе, если в качестве транспортного уровня используется протокол TCP, тогда восстановлением после потери фрагмента занимается протокол TCP, повторяя передачу всех данных оригинальной дейтаграммы.

Фрагментация и повторная сборка накладывают дополнительное бремя на Интернет-маршрутизаторы (фрагментация) и на хосты-адресаты (повторная сборка). Поэтому желательно свести фрагментацию к минимуму. Для этого часто ограничиваются размеры TCP - и UDP-сегментов, что снижает вероятность фрагментации. Поскольку все протоколы передачи данных, поддерживаемые протоколом IP, должны обеспечивать транспортировку пакетов данных размером, по меньшей мере, 576 байт, фрагментации можно полностью избежать, если использовать максимальный размер сегмента (MSS), равный 536 байт, что вместе с двумя 20-разрядными IP - и TCP-заголовками составит 576 байт. По этой причине размер большинства TCP-сегментов для передачи данных больших объемов (например, HTTP-данных) находится в пределах от 512 до 536 байт (возможно, путешествуя в web, вы замечали, что данные поступают блоками примерно по 500 байт).

6. Протокол ICMP

Теперь мы рассмотрим протокол управляющих сообщений Интернета (Internet Control Message Protocol, ICMP), используемый хостами, маршрутизаторами и шлюзами для обмена информацией сетевого уровня друг с другом. Спецификация протокола ICMP содержится в RFC 792. Наиболее типичное использование протокола ICMP заключается в передаче сообщений об ошибках. Например, при работе с Telnet-, FTP - или HTTP-приложениями вы можете встретить сообщение об ошибке, например Destination network unreachable (сеть назначения недоступна). Это сообщение формирует протокол ICMP, если IP-маршрутизатор не может найти маршрут к хосту, указанному в вашем приложении. Маршрутизатор создает и отправляет вашему хосту ICMP-сообщение об ошибке. Ваш хост получает ICMP-сообщение и возвращает пытающейся связаться с удаленным хостом TCP-программе код ошибки. Протокол TCP, в свою очередь, возвращает код ошибки вашему приложению.

Протокол ICMP часто рассматривается как часть протокола IP, однако с точки зрения архитектуры он работает поверх протокола IP, так как ICMP-сообщения переносятся внутри IP-пакетов. То есть ICMP-сообщения переносятся как полезная нагрузка IP-дейтаграмм. Аналогично, когда хост получает IP-пакет, в котором протокол ICMP указан в качестве протокола более высокого уровня, хост передает пакет протоколу ICMP, так же как он передает пакет протоколам TCP и UDP.

У ICMP-сообщений есть поле типа и кодовое поле. Кроме того, ICMP-сообщения содержат первые 8 байт IP-дейтаграммы, вызвавшей генерацию ICMP-сообщения (так, чтобы отправитель мог определить, который пакет вызвал ошибку). Некоторые типы ICMP-сообщений показаны в табл. 10.4. Обратите внимание, что ICMP-сообщения используются не только для сигнализации об ошибках. Хорошо известная команда ping посылает указанному хосту ICMP-сообщение типа 8 с кодом 0. Хост-адресат, получив запрос эха, посылает обратно ICMP-сообщение типа 0 с кодом 0. Еще одним интересным ICMP-сообщением является сообщение гашения источника. Это сообщение редко используется на практике. Изначально оно предназначалось для борьбы с перегрузкой — испытывающий перегрузку маршрутизатор отправлял это ICMP-сообщение передающему хосту, чтобы заставить его снизить скорость передачи. У протокола TCP есть собственный механизм борьбы с перегрузками, действующий на транспортном Уровне и не требующий обратной связи (как ICMP-сообщения гашения источника) от сетевого уровня.

Таблица 10.4ТипыIСМP-сообщений

Мы познакомились с программой (командой) Traceroute, позволяющей проследить маршрут от одного хоста до другого. Интересно отметить, что программа Traceroute реализована при помощи ICMP-сообщений. Чтобы определить имена и адреса маршрутизаторов между отправителем и получателем, программа Traceroute на хосте-отправителе посылает хосту-адресату серию обычных IP-дейтаграмм. У первой из этих дейтаграмм значение поля времени жизни равно 1, у второй оно равно 2, у третьей — 3, и т. д. Кроме того, для каждой из этих дейтаграмм отправитель запускает таймер. Когда п-я дейтаграмма прибывает на n-й маршрутизатор, n-й маршрутизатор видит, что время жизни этой дейтаграммы только что истекло. В соответствии с правилами протокола IP, маршрутизатор отбрасывает эту дейтаграмму и посылает источнику предупреждающее ICMP-сообщение (тип 11 код 0). Это сообщение содержит имя маршрутизатора и его IP-адрес. Когда это ICMP-сообщение прибывает к отправителю, тот по значению таймера узнает время оборота пакета, а также (из ICMP-сообщения) имя и IP-адрес п-то маршрутизатора. Теперь, когда вы понимаете, как работает программа Traceroute, возможно, вам захочется с ней поэкспериментировать.

7. Протокол DHCP

Протокол DHCP (DynamicHostConfigurationProtocol — протокол динамической конфигурации хоста) часто используется для назначения хостам IP-адресов в динамическом режиме. Мы кратко упомянули службы, предоставляемые хосту протоколом DHCP. В данном подразделе мы несколько подробнее поговорим о том, как протокол DHCP предоставляет свои службы.

Протокол DHCP представляет собой протокол для связи клиента с сервером. Клиентом, как правило, выступает только что подключившийся к сети новый хост, желающий получить информацию о конфигурации сети и собственный IP-адрес. В простейшем случае в каждой сети (имеется в виду IP-сеть, см. рис. 10.3) есть свой DHCP-сервер. Если в сети нет сервера, необходим промежуточный DHCP-агент (как правило, маршрутизатор), которому известен адрес DHCP-сервера для этой сети. На рис. 10.13 показан DHCP-сервер, соединенный с сетью 233.1.2/24, и маршрутизатор, выступающий в роли промежуточного DHCP-агента для новых клиентов, присоединяющихся к сетям 223.1.1/24 и 223.1.3/24.

Рис. 10.13 Сценарий взаимодействия DHCP-клиента и DHCP-сервера

При появлении в сети нового клиента протокол DHCP запускает процесс из четырех этапов.

1. Обнаружение DHCP-сервера. Первым делом только что подключившийся хост должен найти DHCP-сервер, с которым можно взаимодействовать. Это делается при помощи сообщения о поиске DHCP-сервера, которое клиент посылает UDP-дейтаграмме через порт 67. Но кому он должен посылать эту дейтаграмму? Хосту не известен даже IP-адрес сети, к которой он подключился, а уж тем более адрес DHCP-сервера, обслуживающего эту сеть. Поэтому DHCP-клиент в поле адреса получателя дейтаграммы указывает широковещательный адрес 255.255.255.255, а себя (отправителя) обозначает как 0.0.0.0. Сообщение о поиске DHCP-сервера будет получено всеми машинами сети, включая все DHCP-серверы (и/или промежуточные агенты). В этом сообщении содержится идентификатор транзакции, позволяющий соотнести последующие ответы с запросом обнаружения DHCP-сервера.

2. Предложение DHCP-сервера. Получив сообщение о поиске DHCP-сервера DHCP-сервер отвечает клиенту сообщением с DHCP-предложением. Поскольку в сети могут находиться несколько DHCP-серверов, может случиться, что клиенту придется выбирать из нескольких предложений. Каждое DHCP-предложение содержит идентификатор транзакции полученного сообщения о поиске DHCP-сервера, предлагаемый IP-адрес клиента, маску сети и срок действия IP-адреса, называемый обычно сроком аренды IP-адреса. Как правило, сервер предоставляет новому хосту IP-адрес на срок от нескольких часов до нескольких дней. Затем прибывшему клиенту посылается кадр канального уровня с IP-дейтаграммой, в которой содержится UDP-сегмент с DHCP-предложением (прекрасная иллюстрация многоуровневой иерархии протоколов). Как кадр канального уровня посылается клиенту, мы рассмотрим в главе 5, посвященной канальному уровню.