Фрагментация дейтаграммы IР необходима, когда она создается в локальной сети, которая допускает большой размер пакета, и, чтобы достичь места назначения, должна пересекать локальную сеть, ограничивающую пакеты до меньшего размера.
Дейтаграмма IР может быть помечена как "не фрагментировать". Любая помеченная таким образом дейтаграмма IР не будет фрагментироваться ни при каких обстоятельствах. Если дейтаграмма IР, помеченная "не фрагментировать", не может быть доставлена к своему месту назначения без фрагментации, она будет отбрасываться. Фрагментация, передача и сборка в локальной сети, которые не видны для модуля протокола IР, называются фрагментацией интрасети.
Фрагментация IР и процедура сборки должны иметь возможность разбить дейтаграмму на произвольное число фрагментов, которые можно в дальнейшем собрать снова. Получатель фрагментов использует поле идентификации для обеспечения того, что фрагменты различных дейтаграмм не смешиваются. Поле сдвига фрагмента и длина определяют часть исходной дейтаграммы, содержащейся в этом фрагменте. Флаг "дополнительные фрагменты" указывает (будучи сброшенным) последний фрагмент. Эти поля предоставляют достаточно информации для сборки дейтаграмм.
Поле идентификации используется для различения фрагментов одной дейтаграммы от фрагментов другой. Модуль исходного протокола дейтаграммы IР задает в поле идентификации значение, которое должно быть уникальным для этой пары источник-место назначения и протокола, пока дейтаграмма будет активной в системе Интернет. Модуль исходного протокола всей дейтаграммы задает флаг "дополнительные фрагменты" равным нулю и сдвиг фрагмента как ноль.
Чтобы фрагментировать длинную дейтаграмму IР, модуль протокола IР (например, в шлюзе) создает две новые дейтаграммы IР и копирует содержимое полей заголовка IР из длинной дейтаграммы в оба новых заголовка IР. Данные длинной дейтаграммы делятся на две части по границе восьми октетов (64 бита) (вторая часть, в отличие от первой, может не быть целым, кратным восьми октетам). Вызовите число восьмиоктетных блоков в первой части NFB (для числа блоков фрагментов). Первая часть данных размещается в первой новой дейтаграмме IР, и поле общей длины задается равным длине первой дейтаграммы. Флаг "дополнительные фрагменты" задается равным единице. Вторая часть данных помещается во второй новой дейтаграмме IР, и поле общей длины задается равным длине второй дейтаграммы. Флаг "дополнительные фрагменты" имеет то же самое значение, что и длинная дейтаграмма. Поле сдвига фрагмента второй новой дейтаграммы IР задается равным значению этого поля в длинной дейтаграмме плюс NFB.
Эта процедура может быть обобщена для разбиения на п частей. Чтобы собрать фрагменты дейтаграммы IР, модуль протокола IР (например, на хосте назначения) объединяет дейтаграммы IР, которые имеют одно и то же значение для четырех полей: идентификации, источника, места назначения и протокола. Сборка осуществляется помещением порции данных каждого фрагмента в относительную позицию, указанную сдвигом фрагмента в заголовке IР этого фрагмента. Сдвиг фрагмента равен нулю, а флаг "дополнительные фрагменты" последнего фрагмента будет сброшен в ноль.
На рис. показан пример заголовка IР, как он определен в сети \Vindows NT. Первое поле в заголовке IР предназначено для версии, которая имеет в длину четыре бита. Поле версии указывает формат заголовка IР и поэтому сообщает другим машинам, как интерпретировать данные. Здесь показана версия 4. Следующим полем является поле длины заголовка IР. Для этой информации выделены четыре бита. Это число является длиной заголовка
IР в 32-битных словах и поэтому указывает на начало данных. Отметим, что минимальное значение для правильного заголовка равно пяти, что составляет 20 байтов. В шестнадцатеричной панели внизу рис. выделенная область является заголовком IР. Первое число равно 45. Это означает, что-это заголовок 1Р версии 4, имеющий длину 5x32 битов.
Следующее поле использует восемь битов для типа службы, чтобы задать значения абстрактных параметров желаемого качества службы. Эти параметры должны использоваться при выборе параметров реальной службы во время передачи дейтаграммы через определенную сеть. Несколько сетей предлагают приоритет службы, которая считает трафик с высоким приоритетом более важным, чем остальной трафик (обычно принимая трафик только выше определенного приоритета во время высокой нагрузки). Основным выбором является трехсторонний компромисс между низкой задержкой, высокой надежностью и высокой пропускной способностью.
Если пакет IP с определенным размером максимального блока передачи (Maximum Transmission Unit, MTU) пересылается в сеть с размером MTU, который меньше, чем размер текущей дейтаграммы IP, дейтаграмма должна быть фрагментирована. Фрагментация не будет происходить, если размер дейтаграммы равен или меньше MTU сети, через которую передается пакет.
Фрагментация может происходить на посылающем хосте или на маршрутизаторе. Каждый фрагмент посылается со своим собственным заголовком IP с достаточной информацией для выполнения повторной сборки в конечном месте назначения. Инструкции по сборке содержатся в идентификации, флаге фрагментации и полях сдвига фрагмента заголовка IP.
На рис. можно видеть, что следующим является поле идентификации, занимающее два байта. Это идентифицирующее значение присваивается отправителем, чтобы помочь собрать фрагменты дейтаграммы. Оно используется в конечном месте назначения для рекомбинации всех фрагментов первоначальной дейтаграммы IP. Оно используется для группировки фрагментов. Поле идентификации выбирается посылающим узлом и помещается в исходную дейтаграмму IP вне зависимости от того, будет ли использоваться фрагментация.
Следующим полем является поле флагов, для которого выделено три бита. Первый бит зарезервирован и должен быть равен нулю. Следующие два бита сообщают о фрагментации дейтаграммы. Если этот бит равен О (флаг сброшен), дейтаграмма может быть фрагментирована, если требуется при передаче через маршрутизатор. Если этот бит равен 1, фрагментация запрещена. В этом случае маршрутизатор IP будет отбрасывать дейтаграмму и посылать источнику сообщение ICMP о том, что место назначения недоступно. Этот механизм используется при поиске маршрута MTU. Это делается с помощью PING, как показано на рис.
Трансляционный перенос (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.
Следующие рекомендации могут оказаться полезными при выделении проблемы.
• Можно видеть несколько идентификаторов сеансов, приходящих с одного компьютера. Попробуйте изолировать трассировку для определенного идентификатора сеанса, чтобы проверить его правильность.
• Посмотрите на число переходов и сравните физический уровень 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, означающий, что пакет является системным пакетом, который требует подтверждения от сервера при получении.
