Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Хост получателя, приняв датаграмму, помеченную как "Last" и имеющую смещение 0, знает, что она не фрагментирована.
6.14.4 Сборка фрагментированной датаграммы
Сборка фрагментированной датаграммы выполняется хостом-получателем. Отдельные части такой датаграммы могут прибывать в произвольном порядке. Когда в точке назначения появляется первый фрагмент, IP выделяет определенную область памяти для последующей сборки всей датаграммы. Поле смещения фрагмента указывает на байтовую границу для данных полученного фрагмента.
Совпадающие по полям идентификации, IP-адреса источника, IP-адреса назначения и протокола фрагменты составляются вместе по мере их поступления. Однако в протоколе IP имеется небольшой недостаток: хост получателя не может узнать общей длины датаграммы, пока не получит последний фрагмент. Поле общей длины (Total Length) содержит сведения только о данном фрагменте, а не об общей длине датаграммы.
Таким образом, система-получатель должна иметь возможность предвидеть, сколько именно буферного пространства нужно зарезервировать для принимаемой датаграммы. Разработчики решают эту проблему различными способами. Некоторые последовательно выделяют для буфера небольшие части памяти, другие сразу предоставляют единый большой буфер.
В любом случае при реализации необходимо обслуживать поступающую датаграмму с общей длиной, как минимум, в 576 октетов. Или, что более точно, система должна быть способна обрабатывать датаграммы с общим размером не менее чем MTU интерфейса, по которому поступают датаграммы.
6.14.5 Тайм-аут сборки датаграммы
Рассмотрим следующую последовательность событий:
■ Пересылается датаграмма.
■ Пославший ее процесс аварийно завершается.
■ Датаграмма фрагментируется при пересылке.
■ По пути следования теряется один из фрагментов.
При потере отправленного фрагмента хост получателя должен ждать, пока этот фрагмент не будет отправлен повторно. При этом, разумеется, необходимо ограничить время ожидания. Когда тайм-аут сборки завершится, хост назначения отбросит уже полученные фрагменты и отправит источнику сообщение об ошибке. Обычно величину тайм-аута сборки можно конфигурировать. Ее значение рекомендуется устанавливать в диапазоне от 60 до 120 с.
6.14.6 Фрагментировать или не фрагментировать
Учитывая все проблемы поддержки фрагментации, можно сказать, что она приводит к снижению производительности. Поэтому многие программисты стремятся аккуратно разрабатывать приложения, чтобы формируемые датаграммы были достаточно малы и не фрагментировались при пересылке.
В главе 7 мы познакомимся с протоколом исследования MTU, позволяющим исключить фрагментировать датаграмм и использовать наибольший размер MTU при пересылке информации.
6.15 Просмотр статистики IP
Узнать о том, как работает IP, можно по достаточно приблизительным статистическим отчетам. Команда netstat -s выводит содержимое счетчиков для наиболее важных событий в IP. Нижеприведенный отчет получен на сервере tigger.jvnc.net, который доступен хостам всей сети Интернет. Ответим, что в отчете вместо более точного термина "датаграмма" используется термин "пакет" (packet).
> netstat -s
ip:
13572051 total packets received
0 bad header checksums
0 with size smaller than minimum
8 with data size < data length
0 with header length < data size
0 with data length < header length
90 fragments received
0 fragments dropped (dup or out of space)
2 fragments dropped after timeout
0 packets forwarded
10 packets not forwardable
0 redirects sent 0
ip input queue drops
За отчетный период не было ни одной датаграммы с плохой контрольной суммой (checksums) и tigger не отбросил ни одной датаграммы из-за недостатка памяти. Было принято 90 фрагментов, что составляет 0,00066% от общего объема информации. Два фрагмента отброшены по тайм-ауту, а 10 непересылаемых (nonforwardable) датаграмм, возможно, возникли при попытке маршрутизации от источника через tigger.
6.16 Варианты
Для одного или нескольких дополнительных вариантов доступно 40 специальных октетов в заголовке IP. Варианты датаграмм выбираются отсылающими их приложениями. Применяются они крайне редко. Список вариантов включает:
■ Strict Source Route (Точный маршрут от источника)
■ Loose Source Route (Произвольный маршрут от источника)
■ Record Route (Запись маршрута)
■ Timestamp (Временная метка)
■ Department of Defense Basic Security (Базовая безопасность Министерства обороны)
■ Department of Defense Extended Security (Улучшенная безопасность Министерства обороны)
■ No Operation (Без операций)
■ End of Option List (Padding) — Конец списка вариантов (заполнитель)
Варианты безопасности используются Министерством обороны и некоторыми правительственными агентствами. Предложено также несколько других вариантов (полный список вариантов и их текущий статус можно найти в последних изданиях Assigned Number и Internet Official Protocol Standard).
6.16.1 Маршрутизация от источника
Существуют два источника: Strict Source Route, определяющий полный путь к точке назначения, и Loose Source Route, идентифицирующий контрольные точки по пути следования (milestones). Между контрольными точками можно использовать любые маршруты.
Strict Source Routes иногда применяется для повышения безопасности данных. Однако, как мы увидим далее, этот источник используется и хакерами при взломе систем компьютерной безопасности.
Иногда этот вариант используется при тестировании сетей. Loose Source Route предназначен для помощи при маршрутизации в удаленную точку.
Механизмы обоих вариантов похожи. Единственным отличием является то, что в Strict Source Route можно посещать только системы из заранее заданного списка.
6.16.2 Обратный маршрут
Если используется маршрутизация от источника, обратный трафик от точки назначения к источнику должен повторять тот же путь (набор маршрутизаторов), но в обратном порядке.
При этом возникает одна сложность: с точки зрения источника и системы назначения адреса маршрутизаторов различны. На рис. 6.12 показан путь между двумя хостами. Маршрут от хоста А к хосту В предполагает прохождение через маршрутизаторы, адресами которых для хоста А являются 130.132.9.29 и 130.132.4.11. Путь от хоста В к хосту А проходит через маршрутизаторы с IP-адресами, известными хосту В как 128.36.5.2 и 130.132.4.16. Адреса интерфейсов маршрутизатора различны, поскольку они подключены к разным подсетям.
Рис. 6.12. Пути с точки зрения хостов А и В
Решить эту проблему просто: при каждом посещении маршрутизатора входной адрес заменяется в поле Source Route на выходной адрес, а система назначения получает уже результирующий список в обратном порядке и может использовать маршрутизацию от источника для обратного перемещения.
6.16.3 Описание маршрута
Можно подумать, что для маршрутизации от источника достаточно создать список маршрутизаторов между источником и точкой назначения. Однако это не так. В таблице 6.4 представлено содержимое полей IP-адреса источника (Source IP Address), IP-адреса места назначения (Destination IP Address) и поля маршрутизации от источника (Source Route) на каждом шаге по пути перемещения:
■ На шаге 1 поле IP-адреса назначения содержит адрес первого маршрутизатора. Указатель из поля Source Route определяет следующее попадание (в таблице — полужирным шрифтом).
■ На шаге 2 поле IP-адреса назначения содержит адрес второго маршрутизатора. Указатель из поля Source Route определяет следующее попадание. В нашем примере — это реальная точка назначения датаграммы.
■ На шаге 3 датаграмма достигает назначения. Ее поля IP-адреса источника и назначения содержат правильные значения, а в Source Route перечислены все пройденные маршрутизаторы.
Таблица 6.4 Маршрутизация от источника
Шаг IP-адрес источника IP-адрес назначения Поле Source Route 1 130.132.9.44 130.132.9.29 130.132.4.11 128.36.5.76 2 130.132.9.44 130.132.4.11 130.132.4.16 128.36.5.76 3 130.132.9.44 128.36.5.76 130.132.4.16 128.36.5.26.16.4 Маршрутизация от источника и безопасность
