Второй бит является флагом дополнительных фрагментов, сообщающим, остались ли дополнительные фрагменты для передачи. Если он сброшен в О, то это означает, что это последний фрагмент; если он установлен в 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.
Заголовок SPX состоит из следующих семи полей:
• Управление соединением — 1 байт
• Тип потока данных — 1 байт
• Идентификатор соединения источника — 2 байта
• Идентификатор соединения места назначения — 2 байта
• Номер последовательности - 2 байта
• Номер подтверждения — 2 байта
• Номер размещения — 2 байта
Управление соединением Остановимся на некоторых функциях, предоставляемых полем управления соединением. Эквивалент флагов TCP, которые были показаны в главе 2, управление соединением предоставляет механизм двунаправленного потока данных, управления перегрузкой и другие связанные с этим возможности. Поле управления соединением указывает три типа пакетов управления соединением. Эти значения могут быть либо логическими, либо могут быть заданы вместе с несколькими флагами. Сначала рассмотрим флаг конца сообщения.
• Флаг "Конец сообщения" (End-of-message). Этот флаг устанавливается, когда в поле управления соединением появляется 0x10. Он используется для указания конца сообщения партнеру по передаче. Так как SPX является транспортным протоколом на основе сообщений, посылающая сторона задает этот флаг для указания, что сообщение завершено. После того как получающая сторона получит этот пакет, она передаст данные в буфер сообщения вышележащего приложения. Это не запрос конца соединения, но скорее указание, что текущий обмен сообщениями закончился.
• Флаг "Требуется подтверждение" (Acknowledgment-Required). Флаг требования подтверждения устанавливается, когда в поле управления соединением появляется 0x40. Он используется для указания, что данные были посланы партнеру по передаче и требуется подтверждение. Прежде чем будут отправлены новые данные, должно быть получено подтверждение для этого пакета.
• SPX требует подтверждения посланных данных; когда они получены, устанавливает флаг, сигнализирующий "конец сообщения" для партнера. Число является комбинацией 0x40 и 0x10 и равно 0x50.
• Флаг "Системный пакет" (System-Packet). Флаг системного пакета устанавливается, когда в поле управления соединением появляется 0x80. Это пакет подтверждения, используемый внутренне протоколом SPX для подтверждения, что партнер по сеансу работает и соединение существует. Это сообщение типа "Я здесь".
• Флаг "Комбинация системных пакетов" (System-Packet combination). Флаг комбинации системных пакетов устанавливается, когда в поле управления соединением появляется ОхСО. ОхСО является суммой 0x80 и 0x40. Он используется внутренне протоколом SPX, показывая, что соединение все еще существует, требуя подтверждения (АСК) от партнера по коммуникации. Это пакет типа "Вы еще здесь?".
Тип потока данных (DataStream) сообщает, какой тип данных переносится внутри пакета. Он может быть задан как специальное число, определенное приложением через Winsock. Самой важной функцией этого поля является обеспечение аккуратного разъединения сеанса. По умолчанию это будет одно из двух следующих сообщений:
• Конец соединения (End-of-Connection). Если тип потока данных задан как OxFE, то партнер по сеансу хочет прекратить сеанс.
• Конец соединения (End-of-Connection). Если тип потока данных задан как OxFF, то пакет передается, так как был получен запрос конца соединения.
Некоторые из других записей, встречающиеся в этом поле, включают числа, перечисленные в таблице
Идентификатор соединения источника и места назначения Это третье и четвертое поля из семи полей заголовка SPX. Поля идентификаторов сое динения источника и места назначения занимают два байта и используются для демультиплексирования сеансов SPX через единственный сокет на уровне IPX. Если идентификатор соединения места назначения задан как 0XFFFF, значит, это пакет начального соединения.
Порядковый номер Пятое поле в заголовке SPX является полем порядкового номера. Это двухбайтовое поле, содержащее счетчик переданных пакетов данных. Это число будет увеличиваться после получения подтверждения о передаче пакета данных.
Номер подтверждения Шестое поле является полем номера подтверждения, сообщающим номер последовательности следующего пакета SPX, который ожидается от партнера SPX.
Номер размещения Последнее поле заголовка SPX является полем номера размещения. Это поле сообщает номер буфера получения, который доступен на рабочей станции. Этот номер почти всегда больше, чем номер подтверждения. Доступность свободных буферов вычисляется, как размер окна, который равен номеру размещения минус номер подтверждения плюс один. Это поле используется как механизм управления потоком. Он работает следующим образом. Когда получающая сторона посылает номер размещения меньше номера подтверждения, отправитель не будет больше посылать данные, пока получающая сторона не пошлет пакет с номером размещения больше номера подтверждения.
Пример создания соединения Трассировка сетевого монитора, приведенная ниже, показывает последовательность успешной инициализации сеанса. Отметим, что идентификатор соединения места назначения задан как OxFFFF, а номер размещения как OxFFFF. Эта последовательность пакетов называется квитированием SPX.
Следующие рекомендации могут оказаться полезными при выделении проблемы.
• Можно видеть несколько идентификаторов сеансов, приходящих с одного компьютера. Попробуйте изолировать трассировку для определенного идентификатора сеанса, чтобы проверить его правильность.
• Посмотрите на число переходов и сравните физический уровень Ethernet с Token Ring. Проблема может быть связана с промежуточными маршрутизаторами или с размером пакета. Помните, что SPX не выполняет согласования пакетов.
• Обратите внимание на номер размещения и проверьте, что он больше номера подтверждения. Это проверка того, что отсутствует какая-либо проблема, связанная с переполнением буфера. В основном это происходит с 16-разрядными клиентами в реальном режим .
• Проверьте все повторные передачи пакетов данных. Обычно проблема повторной передачи проявляется как вопрос производительности. Проверьте интервал времени между отправкой данных и получением пакета АСК, чтобы проверить наличие временной задержки.
Ограничения протокола SPX Хотя SPX предоставляет транспорт с поддержкой соединения, SPX имеет несколько ограничений.
• Только один пакет может ожидать в любой момент времени.
• Коммуникация на основе SPX не делает никакого согласования пакета.
• SPX II использует максимальный размер пакета, допустимый сетью. Пример: 1518 байтов для Ethernet (SPX имеет максимум 576 байтов).
• Окна SPX II допускают несколько ожидающих пакетов и позволяют передавать отрицательное подтверждение (NAK), чтобы указать, что некоторые пакеты не были получены.
• SPX II допускает согласование пакетов. Пакет запроса согласования размера может посылаться в любое время в процессе коммуникации, если пакеты не доходят до места назначения.
Идентификатор соединения с источником Это поле содержит двухбайтовый номер соединения SPX, присвоенный станцией источника SPX и используемый для отслеживания различных виртуальных соединений SPX, которые может поддерживать сокет. Этот номер появится в идентификаторе соединения места назначения, когда прибудут пакеты от партнера по соединению для этой станции.
Идентификатор соединения с местом назначения Это поле содержит двухбайтовый номер соединения SPX, присвоенный станции места назначения SPX. Он используется для отслеживания различных виртуальных соединений SPX, которые может поддерживать сокет. Этот номер появится в идентификаторе соединения источника, когда пакеты посылаются партнеру по соединению.
Порядковый номер SPX присваивает порядковый номер каждому пакету данных, посланных партнеру по соединению. Этот номер увеличивается, когда пакет данных подтверждается, что обеспечивает упорядоченную передачу пакетов из источника в место назначения партнера по соединению. Это поле не увеличивается для пакетов, которые не содержат данных (системных пакетов).
Номер подтверждения Это ожидаемый номер последовательности для следующего пакета данных от партнера по соединению в месте назначения. Это поле не увеличивается для пакетов, которые не содержат данных (системных пакетов).
Номер размещения Этот номер используется для вычисления количества доступных для получения пакетов буферов, посланных из места назначения соединения. Он соответствует номеру последовательности пакета, который подготовлен для отправки, но еще не послан. Источник соединения не может превысить номер размещения. Когда источник соединения генерирует ЕСВ (блок управления событиями) приема, SPX увеличивает номер размещения. Это поле не увеличивается для пакетов, которые не содержат данных (системных пакетов).
Данные Запись данных (если они присутствуют) содержит любые данные или коды, которые посылаются на сервер и с сервера.
Поле сокета указывает пакет SPX, посылаемый клиентом на сервер. Со-кет клиента сервера будет 8060. Пакет содержит также некоторые имеющие отношение к SPX данные для целей соединения. Запись управления соединением в заголовке SPX показывает код COh, означающий, что пакет является системным пакетом, который требует подтверждения от сервера при получении.
