Сетевые протоколы предоставляют так называемые службы канала данных и составляют нижние три уровня модели OSI. Эти протоколы обрабатывают информацию адресации и маршрутизации, контроль ошибок и запросы повторной пересылки. Сетевые протоколы определяют также правила для коммуникации в сетевом окружении, таком как Ethernet или Token Ring. Наиболее популярные сетевые протоколы перечислены ниже:
1. IP (Internet Protocol), протокол TCP/IP для маршрутизации и пересылки пакетов.
2. IPX (Internetwork Packet Exchange), протокол NetWare для пересылки пакетов и маршрутизации.
3. NWLink, реализация Microsoft протокола IPX/SPX.
4. NetBEUI, транспортный протокол, который предоставляет службы транспорта данных для сеансов NetBIOS и приложений.
5. DDP (Datagram Delivery Protocol), протокол транспорта данных AppleTalk.
Мы увидели, как эти протоколы укладываются в модель OSI, и получили представление о функциях каждого из них. Теперь следует рассмотреть, как все это отображается в совокупности, после чего можно исследовать различия в поведении этих протоколов, как используется каждый из них, а также различные уровни функциональности.
Второй бит является флагом дополнительных фрагментов, сообщающим, остались ли дополнительные фрагменты для передачи. Если он сброшен в О, то это означает, что это последний фрагмент; если он установлен в 1, то существуют дополнительные фрагменты для передачи. Флаг дополнительных фрагментов всегда установлен в 1 в первом фрагменте и во всех срединных фрагментах. Он сброшен в 0 в последнем фрагменте.
Поле сдвига фрагмента имеет в длину 13 битов и указывает, где в дейтаграмме расположен этот фрагмент. Сдвиг фрагмента измеряется в единицах по восемь байтов (64 бита). Первый фрагмент имеет сдвиг ноль. Это используется для правильной сборки первоначальной полезной нагрузки 1Р. Полезная нагрузка фрагментируется по восьмибайтовым границам, называемым блоками фрагмента, и значение сдвига фрагмента является блоком фрагмента, где фрагмент начинается. 13 битов в поле сдвига фрагмента и каждое число в счетчике, представляющее восемь октетов, допускают общую нагрузку 65536 октетов, фрагментированных на 8192 фрагментов. На практике полезная нагрузка 1Р может иметь максимальный размер только 65515 (1Р МТ1Л, равное 65535 байтов, минус минимальный размер заголовка 1Р, равного 20 байтам.)
1. Предположим, что имеется пакет ГР в 1500 байтов с 20-байтовым заголовком 1Р и 1480-байтовой полезной нагрузкой. При фрагментиро-вании для переноса по 576-байтовой сети каждый фрагмент будет иметь свой собственный 20-байтовый заголовок 1Р и максимальную нагрузку 1Р в 522 байта (что соответствует 69 блокам фрагментов). При создании фрагментов первоначальный заголовок 1Р копируется (хотя не все параметры обязательно будут скопированы), и затем изменяются следующие поля: длина заголовка, ТТЬ, общая длина, МЕ, сдвиг фрагмента и контрольная сумма заголовка.
2. В приведенном выше примере нагрузка в 1480 байтов делится на три фрагмента. Первый фрагмент состоит из 69 блоков фрагментов, второй — из 69 блоков фрагментов, а последний имеет 47 блоков фрагментов.
3. Заголовки 1Р для трех фрагментов будут содержать следующую информацию: фрагмент 1 будет иметь общую длину 572, флаг МР будет установлен в 1 и сдвиг фрагмента будет установлен в 0. Фрагмент 2 будет иметь общую длину 572, флаг МР будет установлен в 1 и сдвиг фрагмента будет равен 69. Фрагмент 3 будет иметь общую длину 396, флаг МР будет сброшен в 0 и сдвиг фрагмента будет задан как 138.
Повторная сборка Фрагменты передаются промежуточным маршрутизатором 1Р по 1Р-адресу места назначения. Фрагменты могут следовать различными маршрутами к месту назначения и прибывать в порядке, отличном от того, в котором они были посланы. Сами фрагменты могут быть фрагментированы во время их перемещения к конечному пункту назначения. Для повторной сборки фрагментов в исходный вид 1Р использует поля идентификации и адрес 1Р источника.
Когда узел места назначения получает фрагменты, он выделяет ресурсы для повторной сборки. Ресурсы повторной сборки состоят из буфера данных, буфера заголовка, таблицы битов блоков фрагментов, поля общей длины данных и таймера. Если это первый фрагмент (со сдвигом фрагмента, равным 0), то его заголовок помещается в буфер заголовка. Если это последний фрагмент (с флагом МР, равным 0), то вычисляется общая длина данных.
Стандарты IP задают по умолчанию таймер повторной сборки на 15 секунд. Если все фрагменты не будут получены в течение этого времени, они будут отброшены и источнику может быть послано сообщение ICMP о превышении времени ожидания. При получении фрагментов таймер задается как максимум текущего значения времени таймера и значения поля времени жизни из полученного фрагмента.
Прибывающие дополнительные фрагменты помещаются в буфер данных в порядке, согласно сдвигу фрагмента и длине, и соответствующие биты задаются в таблице битов блоков фрагментов. Когда приходит последний фрагмент (если все фрагменты в таблице битов блоков заданы как 1 для общей длины первоначальной нагрузки), повторная сборка завершена и полученная реконструированная полезная нагрузка доставляется соответствующему протоколу верхнего уровня.
Трансляционный перенос (translational bridging) используется для соединения сетей со смешанной средой передачи, таких как сеть Token Ring и Ethernet. При этом может возникнуть проблема, связанная с тем, что MTU двух сетей существенно различаются. В сегменте Token Ring допустимо MTU от 4464 до 17914, в то время как в сегменте Ethernet MTU ограничено 1500. Если два сегмента соединены мостом, то может возникнуть ситуация, когда пакеты отбрасываются, потому что мост не может фрагментировать данные, как это делает маршрутизатор. Одно из решений — задать MTU на серверах NT, соединенных с сетью Token Ring, равным 1500, для гарантии, что пакеты не будут отброшены в связи с чрезмерным размером. Конечно, прежде чем это сделать, необходимо выполнить мониторинг сети, чтобы увидеть, были ли отброшены пакеты. Если это так, то может помочь следующая запись в реестре.
Поле времени жизни (TTL — time-to-live) имеет восемь битов в длину и следует за полем сдвига фрагмента. Это поле указывает максимальное время, в течение которого дейтаграмма может оставаться в Интернете. Если это поле содержит значение ноль, то дейтаграмма должна быть разрушена. Это поле изменяется при обработке заголовка IР. Время измеряется в единицах секунд, но так как каждый модуль, обрабатывающий дейтаграмму, должен уменьшить ТТL по крайней мере на единицу, даже если он занят этим менее секунды, TTL должно рассматриваться только как верхняя граница времени, в течение которого сможет существовать дейтаграмма. Цель состоит в том, чтобы отбрасывать дейтаграммы, которые невозможно доставить, связав это с максимальным временем жизни дейтаграммы. По умолчанию TTL в Windows NT версии 3.5Х равно 32 секундам; в Windows NT 4.0 оно было поднято до 128 секунд. Это значение по сути является пределом того, сколько маршрутизаторов может пройти дейтаграмма IP, прежде чем будет отброшена. Это значение можно изменить в реестре, как показано дальше:
Далее следует поле протокола, указывающее на протокол следующего уровня, используемый данными дейтаграммы IP. Для переноса этой информации используется восемь битов. Значения для различных протоколов определены в "Assigned Numbers" (Присвоенных номерах).
Потом идет поле контрольной суммы заголовка с 16 битами, выделенными для контрольной суммы только заголовка. Так как некоторые поля заголовка изменяются (например, время жизни), то она вычисляется повторно и проверяется в каждой точке, в которой обрабатывается заголовок IP. Для вычисления контрольной суммы суммируются дополнения до единиц всех 16-битных слов в заголовке, и к полученной сумме применяется операция 16-битного дополнения до единиц. Значение поля контрольной суммы задается равным нулю.
Следующие два поля являются адресом IP источника и адресом IP места назначения. Каждое из них имеет четыре октета. Именно здесь адреса IP включаются в обмен данными. Хотя это и важное поле, мы не собираемся тратить на него много времени, так как это может легко привести к обсуждению маршрутизации, широковещания и т.п. Эти вопросы будут рассмотрены позже, при обсуждении сетевого трафика.
Затем следует поле параметров, которое может появиться или не появиться в дейтаграммах. Они должны быть реализованы всеми модулями IP (хостом и шлюзами). Необязательным моментом является их передача в каждой конкретной дейтаграмме, а не их реализация. В некоторых средах параметр безопасности может потребоваться во всех дейтаграммах. Поле параметров имеет переменную длину. Параметры IP будут иметь размер от одного до 40 октетов. Это будет давать максимальный размер заголовка IP в 60 байтов. Может быть ноль или большее количество параметров. Каждый параметр начинается с кода типа параметра. Этот код делится на три поля, первое из которых является полем копирования. Если это поле задано как 1, то параметр должен быть скопирован во все фрагменты. Если оно задано как 0, то он используется только в первом фрагменте. Следующие два бита в октете кода параметра используются для указания класса используемого параметра. Если он задан как 0, то это управление дейтаграммой или сетью, если как 2, то он используется для отладки или измерения. Другие являются зарезервированными. Следующие пять битов используются для указания номера параметра в классе параметров.
Второй октет является длиной параметра, которая включает код типа параметра и октет длины, октет указателя и длину трех байтов данных о маршруте. Третий октет является указателем на данные о маршруте, указывающим октет, где начинается адрес следующего источника, который будет обрабатываться. Указатель связан с этим параметром, наименьшее законное значение для него равно 4. Некоторые из этих параметров перечислены в таблице 2.2.
Параметр записи маршрута позволяет посылающей стороне создать заголовок 1Р с рядом пустых адресов 1Р в качестве параметров 1Р. Когда дейтаграмма 1Р перемещается по сети, каждый встреченный маршрутизатор добавляет в список свой адрес 1Р, тем самым записывая пройденный к месту назначения маршрут. В параметре записи маршрута 1Р должно быть выделено достаточно места для хранения адресов 1Р. Размер каждого поля определяется посылающим компьютером. Как можно видеть в списке ниже, посылающий компьютер задает поле параметров как 0x7, что указывает на использование параметра записи маршрута. Следующее поле - это поле длины параметра, которое является полем переменной длины, заданной в октетах посылающей машиной. Затем следует поле указателя следующего слота, которое используется для указания сдвига октета в поле параметра записи маршрута, где начинается следующий доступный слот для записи адресов IP маршрута.
Теперь посмотрим на ответ, который приходит из места назначения. Как можно видеть в приведенной ниже распечатке, большая часть информации выглядит точно так же, однако теперь она дополнена некоторой дополните льной информацией. Мы в наибольшей степени заинтересованы в маршруте к месту назначения. Мы видим адреса IP, которые были использованы для записи информации маршрутизатора, когда дейтаграмма IP перемещалась к своему месту назначения. Существуют максимум девять доступных слотов, которые могут распределяться посылающим компьютером. В этом примере использованы три из них.
Приведенные выше листинги были сделаны с помощью команды PING Windows NT с параметром команды -г. Она посылает сообщение с запросом Echo ICMP, который записывает маршрут.
Обычно маршрутизаторам и Windows NT разрешается принимать решения о маршрутизации на основе таблиц маршрутизации. Однако иногда при поиске неисправностей, тестировании и отладке сетей необходимо определить маршрут к месту назначения, не беспокоясь о модификации таблиц маршрутизации. Когда мы переопределяем путь доступа, который будет обычно использоваться, мы вмешиваемся в маршрутизацию IP от источника. IP поддерживает два вида маршрутизации от источника: неопределенную и точную. Сначала рассмотрим неопределенную маршрутизацию от источника.
При неопределенной маршрутизации от источника IP-дейтаграмма адресуется следующему маршрутизатору с помощью IP-адреса места назначения из заголовка IP. При неопределенном источнике маршрута хорошо то, что можно определить маршрутизатор, который находится в нескольких переходах. Посмотрим на поле параметров при использовании неопределенной маршрутизации от источника. В распечатке ниже можно видеть, что поле кода параметра задано равным 131. Это значит, что используется параметр неопределенной маршрутизации от источника
Поле длины параметра, приведенное выше, равно длине в байтах, полученной 131 параметром. Это поле задается посылающей машиной. В данном случае используется семь байтов для параметра неопределенной маршрутизации источника. Указатель маршрутизации используется для определения сдвига октета в полях параметра 131 для указания, где начинаются данные маршрутизатора. Здесь мы пропускаем четыре байта с начала поля параметра и видим IP-адрес первого маршрутизатора в шестнадцате-ричном представлении. Это выделено на рис. 2.7. Если посмотреть на шест-надцатеричную панель (внизу экрана), можно увидеть, что поле параметра начинается с 83 (шестнадцатеричного значения 131, кода параметра неопределенной маршрутизации источника). Теперь сдвиг определен как 04, что сообщает, где в данных расположен IP-адрес первого маршрутизатора. Отсчитывая от 83 четыре числа, мы получаем OA (10 в шестнадцатеричном представлении), что будет первым октетом IP-адреса маршрутизатора.
Можно заставить PING использовать неопределенный маршрут от источника, применяя параметр -j. Команда будет выглядеть как PING -j 10.0.0.10 10.0.0.60. Первый адрес определяет место назначения, а второй и следующие адреса являются маршрутизаторами для использования в направлении к месту назначения.
