Загрузка...



  • 6.1 Введение
  • 6.2 Датаграммы IP
  • 6.3 Основные функции IP
  • 6.4 Использование маски подсети
  • 6.5 Хост в таблице маршрутизации IP
  • 6.6 Маршрутизация по следующему попаданию
  • 6.7 Еще один пример таблицы маршрутизации хоста
  • 6.8 Правило просмотра таблицы маршрутизации
  • 6.9 Таблицы маршрутизатора
  • 6.10 Таблица маршрутизации филиала компании
  • 6.11 Операции глобальной маршрутизации
  • 6.12 Возможности IP
  • 6.12.1 Адаптивная маршрутизация
  • 6.12.2 MTU, фрагментация и сборка
  • 6.13 Механизмы протокола IP
  • 6.13.1 Заголовок датаграммы
  • 6.13.2 Поля назначения, поле источника и поле протокола
  • 6.13.3 Версия, длина заголовка и длина датаграммы
  • 6.13.4 Приоритет и тип обслуживания
  • 6.13.5 Поле времени жизни
  • 6.13.6 Заголовок контрольной суммы
  • 6.14 Фрагментация
  • 6.14.1 Поле идентификации
  • 6.14.2 Поле Флагов
  • 6.14.3 Поле смещения фрагмента
  • 6.14.4 Сборка фрагментированной датаграммы
  • 6.14.5 Тайм-аут сборки датаграммы
  • 6.14.6 Фрагментировать или не фрагментировать
  • 6.15 Просмотр статистики IP
  • 6.16 Варианты
  • 6.16.1 Маршрутизация от источника
  • 6.16.2 Обратный маршрут
  • 6.16.3 Описание маршрута
  • 6.16.4 Маршрутизация от источника и безопасность
  • 6.16.5 Запись пути
  • 6.16.6 Временная метка
  • 6.16.7 Базовая и улучшенная безопасность для Министерства обороны
  • 6.16.8 Конец списка вариантов и отсутствие операций
  • 6.16.9 Кодирование вариантов
  • 6.16.10 Кодирование Strict Source Route
  • 6.16.11 Кодирование Loose Source Route
  • 6.16.12 Кодирование Record Route
  • 6.16.13 Кодирование Timestamp
  • 6.16.14 Кодирование Basic и Extended Security Options
  • 6.17 Пример заголовка IP
  • 6.18 Сценарий обработки датаграммы
  • 6.18.1 Обработка в маршрутизаторе
  • 6.18.2 Обработка в хосте назначения
  • 6.19 Средства защиты и безопасность
  • 6.20 Замечания о производительности IP
  • 6.20.1 Полоса пропускания
  • 6.20.2 Использование буфера
  • 6.20.3 Ресурсы центрального процессора
  • 6.21 Дополнительные сведения о многоадресных рассылках
  • 6.22 Рекомендуемая литература
  • Глава 6

    Протокол интернета

    6.1 Введение

    Вспомним, что интернет — это набор сетей, соединенных маршрутизаторами (во многих ранних документах RFC использовался термин "шлюз" вместо "маршрутизатор"), a IP — это протокол сетевого уровня, обеспечивающий маршрутизацию данных в интернете. При создании IP исследователи и разработчики руководствовались следующими требованиями Министерства обороны США:

    ■ Приспособить к взаимодействию хосты и маршрутизаторы различных производителей

    ■ Объединить расширяющееся множество сетей различного типа

    ■ Обеспечить расширение сети без прерывания работы сетевых служб

    ■ Реализовать поддержку высокоуровневых сеансов и служб, ориентированных на сообщения

    Всем этим требованиям удовлетворяет архитектура сетевого уровня IP.

    Более того, она позволяет интегрировать островки локальных сетей (разбросанных по различным организациям) таким образом, чтобы обеспечить подключение новых островков без изменений в уже объединенных.

    Все это сделало IP основным сетевым протоколом для правительственных агентств, университетов и коммерческих организаций.

    6.2 Датаграммы IP

    Протокол IP предоставляет механизм для пересылки по интернету элементов, называемых датаграммами IP (IP datagram). Как показано на рис. 6.1, датаграмма IP формируется из заголовка IP и перемещаемой по сети порции данных.

    Рис. 6.1. Формат датаграммы

    Протокол IP можно назвать "протоколом наилучшей попытки". Это означает, что IP гарантирует не целостность доставки датаграммы в пункт назначения, а только наилучшую попытку выполнить доставку (см. рис. 6.2). Датаграмма может разрушиться по следующим причинам:

    ■ Ошибка в одном из битов во время пересылки в носителе.

    ■ Перегруженный маршрутизатор отбросил датаграмму, чтобы освободить свое буферное пространство.

    ■ Временно недоступен путь к точке назначения.

    Рис. 6.2. Доставка в IP по принципу наилучшей попытки

    Все операции по обеспечению надежности доставки данных осуществляются на уровне TCP. Восстановление испорченных данных зависит от действий на этом уровне.

    6.3 Основные функции IP

    Основными функциями IP являются: прием данных от TCP или UDP, создание датаграммы, маршрутизация ее по сети и доставка приложению-получателю. Каждая датаграмма IP маршрутизируется отдельно. Для маршрутизации датаграммы в IP существуют два средства:

    ■ маска подсети

    ■ таблица маршрутизации IP (таблица маршрутов)

    6.4 Использование маски подсети

    Предположим, что компьютер имеет IP-адрес 130.15.12.131 и подключен к локальной сети, а данные нужно послать:

    Из: 130.15.12.131

    В: 130.15.12.22

    Можно предположить, что обе системы находятся в одной и той же подсети. Компьютер должен проверить, верно ли такое предположение. Проверка выполняется по маске подсети. Допустим, что хост имеет маску подсети:

    255.255.255.0

    т.е. есть маска состоит из 24 единиц и 8 нулей:

    11111111111111111111111100000000

    Вспомним, что единицы в маске подсети идентифицируют сеть и часть адреса для подсетей. Так как части для сети и подсети в адресах источника и назначения — 130.15.12, значит оба хоста находятся в одной подсети.

    Компьютер фактически выполняет операцию "логическое И" между маской и каждым из IP-адресов. В результате нули маски подсети очищают часть адреса для хоста, оставляя только части для сети и подсети.

    В этом примере маршрутизация является прямой. Это означает, что датаграмма должна быть помещена в кадр и передана непосредственно в точку назначения локальной сети, как показано на рис. 6.3.

    Рис. 6.3. Обрамление кадром и передача датаграммы

    Адрес назначения, помещенный в заголовок кадра, должен быть физическим адресом системы назначения. Чтобы определить существование элемента для физического адреса 130.15.12.22, проверяется таблица протокола ARP. Если в таблице нет нужной записи, для ее формирования используется протокол ARP.

    6.5 Хост в таблице маршрутизации IP

    Предположим, что нужно переслать данные:

    Из: 130.15.12.131

    В: 192.45.89.5

    Быстрая проверка маски подсети показывает, что система назначения не принадлежит локальной подсети. В этом случае IP должен обратиться к локальной таблице маршрутизации.

    Таблица маршрутизации хоста обычно очень проста. На рис. 6.4 показана локальная сеть, которая связана с удаленными сайтами посредством единственного маршрутизатора. Если точка назначения не находится в локальной сети, у хоста нет другого выбора, как обратиться к маршрутизатору.

    Рис. 6.4. Перенаправление трафика через маршрутизатор по умолчанию

    Каждый настольный компьютер или хост локальной сети имеет таблицу маршрутизации, которая сообщает IP, как маршрутизировать датаграммы к системам, не подключенным к локальной сети. Для указания пути к удаленному месту эта таблица нуждается в единственной записи (для маршрутизации по умолчанию):

    default 130.15.12.1

    Другими словами, нужно направлять любые нелокальные датаграммы на маршрутизатор по умолчанию с IP-адресом 130.15.12.1 (отметим, что адрес назначения 0.0.0.0 используется в таблице маршрутизации для значения по умолчанию).

    6.6 Маршрутизация по следующему попаданию

    Для сохранения простоты таблицы маршрутизации хоста IP может не анализировать полный маршрут к точке назначения. Требуется только выяснить следующее попадание (next hop иногда переводится как следующий участок. — Прим. пер.) и направить датаграмму туда.

    Чтобы отправить датаграмму на интерфейс маршрутизатора 130.15.12.1, ее надо поместить в кадр, заголовок которого содержит физический адрес сетевого адаптера этого маршрутизатора.

    Когда маршрутизатор получит кадр, он удалит заголовок и завершающую часть кадра, а также исследует заголовок датаграммы IP, чтобы решить, куда ее нужно направить далее.

    6.7 Еще один пример таблицы маршрутизации хоста

    Иногда таблицы маршрутизации хостов не столь просты. Рассмотрим, например, два маршрутизатора подсети 128.121.50.0 (см. рис. 6.5). Второй маршрутизатор управляет небольшой локальной сетью с несколькими рабочими станциями.

    Рис. 6.5. Выбор маршрутизатора

    Маршрутизатор tigger управляет локальной сетью, и его таблицу маршрутизации можно вывести командой netstat -nr. В выводе используется термин шлюз — gateway, а не маршрутизатор — router. (Другие компьютеры могут выводить таблицу в несколько ином формате. Она будет содержать похожую, но не идентичную информацию. Например, некоторые системы могут выводить столбец со сведениями о расстоянии до следующей точки назначения.)

    > netstat -nr

    Routing tables

    Destination  Gateway        Flags Refcnt     Use Interface

    127.0.0.1    127.0.0.1      UH         6   62806 lo0

    Default      128.121.50.50  UG        62 2999087 le0

    128.121.54.0 128.121.50.2   UG         0       0 le0

    128.121.50.0 128.121.50.145 U         33 1406799 le0

    Командой netstat выводятся сведения о том, где и как будет маршрутизироваться трафик tigger.

    ■ Первое место назначения в таблице — это кольцевой адрес 127.0.0.1, который служит обозначением для трафика между клиентами и серверами в пределах системы tigger.

    ■ Запись default используется для выполнения маршрутизации к любой точке назначения, которая не указана в таблице. Трафик должен быть направлен на интерфейс маршрутизатора по IP-адресу 128.121.50.50.

    ■ Датаграммы к любой системе подсети 128.121.54.0 должны быть направлены на интерфейс маршрутизатора по IP-адресу 128.121.50.2.

    ■ Последняя запись не обеспечивает получения новой информации для маршрутизации, но позволяет получить интересную статистику о местном трафике. Чтобы маршрутизировать трафик к любой системе подсети 128.121.50.0, нужно направить его на адрес 128.121.50.145. При этом 128.121.50.145 — это собственный адрес tigger, а 128.121.50.0 — собственный адрес локальной сети tigger.

    Команда netstat выводит и другую интересную информацию:

    ■ Флаги (Flags) сообщают, является ли маршрут пригодным для использования и будет ли следующее попадание хостом (H) или шлюзом (G).

    ■ REFcnt отслеживает текущее количество активных применений маршрута.

    ■ Столбец Use подсчитывает число датаграмм, которые были посланы по маршруту (после последней инициализации).

    ■ Интерфейс lo0 является логическим интерфейсом для кольцевого трафика. Весь внешний трафик проходит через один интерфейс Ethernet — le0.

    Отметим, что включение в отчет локальной подсети 128.121.50.0 позволило обнаружить, что посланный вовне трафик вдвое больше, чем трафик, направленный к системам локальной сети.

    6.8 Правило просмотра таблицы маршрутизации

    Каждая запись в таблице маршрутизации обеспечивает информацию о маршрутизации к отдельной точке назначения, которая может быть отдельным хостом, сетью, суперсетью или значением по умолчанию.

    Существует общее правило использования в протоколе IP таблицы маршрутизации независимо от расположения этой таблицы — на хосте или маршрутизаторе. Выбираемый в таблице элемент должен наиболее точно соответствовать IP-адресу назначения. Другими словами, когда IP просматривает адреса хостов назначения, концептуально выполняются следующие действия:

    ■ Сначала в таблице ищется адрес, полностью совпадающий с IP-адресом назначения. Если он будет найден, эта запись используется для маршрутизации трафика.

    ■ Если такого адреса нет, в таблице ищется запись для подсети системы назначения.

    ■ Если нет и такого адреса, в таблице проводится поиск сети назначения.

    ■ Если отсутствует и этот адрес, в таблице проводится поиск элемента с соответствующим префиксом маршрутизации.

    ■ Если не будет найден и этот адрес, используется маршрутизатор по умолчанию.

    Разумеется, реальное выполнение предполагает однократный просмотр таблицы с отбрасыванием всех найденных, но менее точных совпадений.

    6.9 Таблицы маршрутизатора

    В отличие от таблиц маршрутизации хостов, которые могут быть очень простыми, таблицы маршрутизаторов часто содержат намного больше информации. Маршрутизатор имеет два или более интерфейсов, и каждая датаграмма должна быть передана через соответствующий ей интерфейс. Маршрутизатору могут потребоваться записи о следующих попаданиях для множества различных сетей и подсетей (см. рис. 6.6).

    Рис. 6.6. Маршрутизация по многим направлениям

    6.10 Таблица маршрутизации филиала компании

    Некоторые маршрутизаторы имеют очень простые таблицы маршрутизации. Например, маршрутизатор филиала компании (см. рис. 6.7) направляет трафик из главного офиса в локальные сети и перенаправляет весь выходящий трафик по региональной сети в главный офис компании.

    Рис. 6.7. Маршрутизация в филиале компании

    Этот маршрутизатор имеет два интерфейса:

    Интерфейс IP-адрес
    1 130.15.40.1
    2 130.15.201.2

    Таблица маршрутизации будет содержать:

    Назначение Интерфейс Следующее попадание Тип Протокол
    130.15.40.0 1 130.15.40.1 Прямая Вручную
    0.0.0.0 2 130.15.201.1 Косвенная Вручную

    Первая запись описывает только прямое соединение с локально подключенной подсетью 130.15.40.0. Подсеть достигается непосредственно через собственный интерфейс.

    Вторая запись указывает маршрут по умолчанию к остальной части сети. Маршрутизатор для следующего попадания — 130.15.201.1 — доступен через интерфейс 2. Главный офис компании достигается косвенным путем, через маршрутизатор следующего попадания. Оба маршрута были введены вручную.

    6.11 Операции глобальной маршрутизации

    Пока мы рассматривали только выбор единственного направления к точке назначения. Рисунок 6.8 поясняет действия при глобальной маршрутизации в IP. Если протоколы TCP или UDP хоста А захотят послать данные своему партнеру на хосте В, они передадут эти данные IP, сопроводив их IP-адресом хоста назначения. IP добавит заголовок, содержащий IP-адрес назначения для данных.

    ■ IP хоста А исследует адрес назначения, чтобы проверить, не находится ли он в локальной подсети. Если нет, IP выполнит поиск в таблице маршрутизации.

    ■ Из таблицы видно, что следующим попаданием является маршрутизатор X. Датаграмма будет заключена в кадр, а в его заголовок будет помещен физический адрес локальной сети для маршрутизатора X.

    ■ Когда датаграмма прибудет на маршрутизатор X, удаляется ее обрамление кадром. IP маршрутизатора X сравнивает IP-адрес назначения со всеми своими адресами (по маске подсети) и проверяет, не находится ли точка назначения в локально подключенной подсети.

    Рис. 6.8. Глобальная маршрутизация

    ■ Если нет, IP выполнит поиск в таблице маршрутизации. Следующим попаданием станет маршрутизатор Y, куда и будет направлена датаграмма после обрамления ее новым кадром.

    ■ Когда датаграмма поступит на маршрутизатор Y, будет удалено обрамление кадром. Протокол IP маршрутизатора Y сравнит IP-адрес назначения со всеми своими адресами (по маске подсети) и проверит, не находится ли точка назначения в локально подключенной подсети. Для нашего примера поиск будет успешным и датаграмма будет послана хосту B.

    Маршрут от хоста А к хосту В содержал три попадания (участка): A-X, X-Y и Y-B.

    6.12 Возможности IP

    В IP существует несколько возможностей, обеспечивающих гибкость и пригодность этого протокола к различным окружениям. Среди прочих следует упомянуть адаптивную маршрутизацию (adaptive routing), а также фрагментацию и сборку датаграммы (datagram fragmentation and reassembly).

    6.12.1 Адаптивная маршрутизация

    Маршрутизация датаграмм адаптивна по своей природе. Лучший вариант для следующего попадания в любом из устройств выполняется при поиске в таблице маршрутизации текущего сетевого узла. Записи таблицы маршрутизации могут изменяться с течением времени, отражая текущее состояние сети.

    Если одна из связей (см. рис. 6.9) будет разорвана, датаграмма может переключиться на другой маршрут (если он будет доступен).

    Рис. 6.9. Адаптивная маршрутизация

    Изменение в топологии сети приводит к автоматическому перенаправлению датаграммы по другому маршруту. Адаптивная маршрутизация характеризуется гибкостью и надежностью.

    С другой стороны, заголовок IP может содержать точный маршрут для перемещения к точке назначения. Это позволяет маршрутизировать важный трафик по засекреченному сетевому пути.

    6.12.2 MTU, фрагментация и сборка

    Перед тем как датаграмма отправится по сети к участку следующего попадания, она инкапсулируется внутри заголовка (заголовков) второго уровня, требующегося для данной сетевой технологии (см. рис. 6.10). Например, для прохождения сети 802.3 или 802.5 добавляются: заголовок LLC, подзаголовок SNAP, MAC-заголовок и завершающая часть MAC.

    Рис. 6.10. Формат пересылки кадра локальной сети

    Как было показано в главе 4, каждая технология локальной или глобальной сети имеет собственные ограничения на длину кадров. Датаграмма должна размещаться внутри кадра, и, следовательно, его максимальная длина будет ограничивать размер датаграммы, пересылаемой по носителю.

    Максимальная длина датаграммы для конкретного носителя вычисляется как разность максимального размера кадра, длины заголовка кадра, длины завершающей части кадра и размера заголовка уровня связи данных:

    Максимальный размер кадра – длина заголовка кадра – длина завершающей части кадра – размер заголовка уровня связи данных

    Максимально возможная длина датаграммы в заданном носителе называется максимальным элементом пересылки (Maximum Transmission Unit — MTU). Например, для DIX Ethernet значение MTU равно 1500 октетам, для 802.3 — 1492 октетам, для FDDI — 4352, для SMDS — 9180 октетам.

    В больших сетях интернета хост источника может не знать размеров всех ограничений по пути пересылки датаграммы. Что же произойдет, если хост отправит слишком большую для одной из промежуточных сетей датаграмму?

    Когда такая датаграмма достигнет маршрутизатора, подключенного к промежуточной сети, IP решит проблему с размером датаграммы, разделив ее на несколько небольших фрагментов. Хост назначения далее должен будет провести сборку всех полученных кадров и восстановить исходную датаграмму.

    Фрагментация наиболее часто выполняется в маршрутизаторах, однако приложения UDP могут разделить длинное сообщение на фрагменты датаграмм сразу в хосте источника.

    6.13 Механизмы протокола IP

    Рассмотрим более детально характеристики протокола IP версии 4, в том числе элементы формата этого протокола — формат заголовка IP и правила управления датаграммой, пересылаемой по сети. Протокол IP версии 6 рассмотрен в главе 22 (IP версии 5 не существует).

    6.13.1 Заголовок датаграммы

    Заголовок датаграммы организован как 5 или более 32-разрядных слов. Максимальная длина заголовка — 15 слов (т.е. 60 октетов), но на практике большинство заголовков датаграмм имеют минимально возможную длину в 5 слов (20 октетов).

    Поля заголовка показаны на рис. 6.11. Они структурированы как последовательность слов. Отметим, что биты слов пронумерованы от 0 до 31.

    Рис. 6.11. Формат датаграммы протокола IP

    6.13.2 Поля назначения, поле источника и поле протокола

    Наиболее важными полями заголовка являются: Destination IP Address (IP-адрес назначения), Source IP Address (IP-адрес источника) и Protocol (протокол).

    IP-адрес назначения позволяет маршрутизировать датаграмму. Как только она достигает точки назначения, поле протокола позволяет доставить ее в требуемую службу, подобную TCP или UDP, Кроме TCP и UDP, существует еще несколько протоколов, способных посылать и получать датаграммы. Организация IANA отвечает за координацию присваивания значений параметрам TCP/IP, включая значения в поле протокола. Некоторые значения из этого поля имеют лицензионный, специфичный для конкретного производителя смысл.

    В таблице 6.1 показаны наиболее распространенные значения из поля протокола.


    Таблица 6.1 Общепринятые номера из поля протокола заголовка IP

    Номер Название Протокол Описание
    1 ICMP Internet Control Message Protocol Переносит сообщения об ошибках и поддерживает отдельные сетевые утилиты
    2 IGMP Internet Group Management Protocol Обеспечивает группы для многоадресных рассылок
    6 TCP Transmission Control Protocol Обслуживает сеансы
    8 EGP Exterior Gateway Protocol Устаревший протокол для маршрутизации во внешней сети
    17 UDP User Datagram Protocol Обслуживает доставку независимых блоков данных
    88 IGRP Interior Gateway Routing Protocol Обеспечивает взаимный обмен информацией о маршрутизации между маршрутизаторами компании Cisco

    6.13.3 Версия, длина заголовка и длина датаграммы

    В настоящее время используется четвертая версия IP (версия "Следующее поколение" имеет номер 6).

    Длина заголовка измеряется в 32-разрядных словах. Если не нужны дополнительные варианты, можно ограничиться длиной заголовка в 5 слов (т.е. 20 октетов). Если задействованы один или больше дополнительных вариантов, может потребоваться заполнить конец заголовка незначащими нулями до границы 32-разрядного слова.

    Поле длины датаграммы определяет размер датаграммы в октетах. В это значение включается как заголовок, так и часть данных датаграммы. В таком 16-разрядном поле можно указывать значения до 216-1 октет = 65 535 октетов.

    Сетевые технологии — не единственная причина ограничений на размер датаграмм. Различные типы компьютеров, поддерживающих IP, имеют разные ограничения, связанные с размером буферов памяти, используемых для сетевого трафика (стандарт IP требует, чтобы все хосты были способны принимать датаграммы не менее чем из 576 октетов).

    6.13.4 Приоритет и тип обслуживания

    Первоначальным спонсором набора протоколов TCP/IP было Министерство обороны США, для которого было важно задание приоритетов датаграмм. Приоритеты мало используются вне военных и правительственных организаций. Для приоритета предназначены 3 бита, обеспечивающие 8 различных уровней.

    Стандарт IP не регламентирует действия с битами приоритета. Первоначально они предназначались для установки параметров подсетей, которые будет пересекать датаграмма при следующем попадании. Например, на основе битов приоритета управляется протокол Token-Ring. В этом случае IP должен отображать биты приоритета в соответствующие уровни Token-Ring.

    Тип обслуживания (Type of Service — TOS) содержит биты, определяющие качество обслуживания информации, которое может повлиять на обработку датаграмм. Например, когда маршрутизатору не хватает памяти, он вынужден отклонять некоторые датаграммы. Он мог бы рассматривать только датаграммы, у которых бит надежности установлен в единицу, и отбрасывать датаграммы с нулевым битом надежности.

    Положение приоритета и типа обслуживания:

    Биты Тип Описание
    0-2 Приоритет Уровни 0-7
    Уровень 0 — обычный приоритет
    Уровень 7 — самый высокий приоритет
    3-6 TOS Задержка, надежность, пропускная способность, стоимость или безопасность
    7 Зарезервировано для будущего использования

    Тип обслуживания определяет (как описано в текущем документе Assigned Numbers) значения, приведенные в таблице 6.2. Это взаимоисключающие значения — для любой IP-датаграммы требуется только одно значение TOS. Стандарт Assigned Numbers рекомендует использовать специальные значения для каждого из приложений. Например для telnet — минимизировать задержку, для копирования файлов — максимизировать производительность и надежность при доставке управляющих сетевых сообщений.


    Таблица 6.2 Значения поля типа обслуживания (TOS)

    Значение TOS Описание
    0000 По умолчанию
    0001 Минимизировать денежную стоимость
    0010 Максимизировать надежность
    0100 Максимизировать производительность
    1000 Минимизировать задержку
    1111 Максимизировать безопасность

    Некоторые маршрутизаторы полностью игнорируют поле типа обслуживания, в то время как другие могут использовать его при выборе трафика, который следует предохранить на случай недостатка оперативной памяти. Можно надеяться, что в будущем поле типа обслуживания будет играть гораздо большую роль. Рекомендуемые в документе Assigned Numbers значения представлены в таблице 6.3.


    Таблица 6.3 Рекомендуемые значения поля типа обслуживания

    Протокол Значение TOS Описание
    Telnet и другие протоколы для регистрации 1000 Минимизировать задержку
    Управляющий сеанс FTP 1000 Минимизировать задержку
    Сеанс FTP по пересылке данных 0100 Максимизировать производительность
    TFTP 1000 Минимизировать задержку
    Фаза команд SMTP 1000 Минимизировать задержку
    Фаза данных SMTP 0100 Максимизировать производительность
    Запрос DNS к UDP 1000 Минимизировать задержку
    Запрос DNS к TCP 0000 Без специального управления
    Преобразование зон в DNS 0100 Максимизировать производительность
    NNTP 0001 Минимизировать денежную стоимость
    Ошибки ICMP 0000 Без специального управления
    Запросы ICMP 0000 Обычно 0000, но иногда посылаются с другим значением
    Ответы ICMP То же, что и у запроса, для которого формируется ответ
    Любые IGP 0010 Максимизировать надежность
    EGP 0000 Без специального управления
    SNMP 0010 Максимизировать надежность
    BOOTP 0000 Без специального управления

    6.13.5 Поле времени жизни

    Когда в интернет-системе IP происходит изменение топологии, например обрыв связи или инициализация нового маршрутизатора, некоторые датаграммы могут сбиться со своего маршрута за тот короткий период времени, пока не будет выбран новый маршрутизатор.

    Более серьезные проблемы возникают из-за ошибок при ручном вводе информации о маршрутизации. Такие ошибки могут привести к потере датаграммы или зацикливанию ее по круговому маршруту на длительное время.

    Поле времени жизни (Time-To-Live — TTL) ограничивает время присутствия датаграммы в интернете. TTL устанавливается хостом-отправителем и уменьшается каждым маршрутизатором, через который проходит датаграмма. Если датаграмма не достигает пункта назначения, а ее поле TTL становиться нулевым, она отбрасывается.

    Хотя формально время жизни оценивается в секундах, реально TTL реализуется как простой счетчик попаданий, значение которого уменьшается (обычно на единицу) в каждом маршрутизаторе. Можно указывать большее уменьшение счетчика для датаграмм, которые перемещаются по очень медленным соединениям или требуют длительного времени для пересылки.

    Рекомендуемое значение по умолчанию для TTL — примерно в 2 раза больше, чем максимально возможный путь в сети. Длина такого максимального пути часто называется диаметром (diameter) интернета.

    6.13.6 Заголовок контрольной суммы

    Контрольная сумма (checksum) находится в 16-разрядном поле и вычисляется по значению остальных полей заголовка IP как сумма всех дополнений до единицы 16-разрядных слов заголовка. До вычисления поле контрольной суммы содержит 0. Контрольная сумма должна пересчитываться при перемещении датаграммы по сети, поскольку в датаграмме изменяется поле TTL. Могут изменяться и другие значения из заголовка вследствие фрагментации или записи информации в дополнительные поля.

    6.14 Фрагментация

    Поля идентификации (Identification), флагов (Flags) и смещения фрагмента (Fragment Offset) позволяют фрагментировать и восстанавливать (собирать) датаграмму. Когда IP нужно переслать датаграмму большего размера, чем MTU следующего участка, то:

    1. Сначала проверяется содержимое поля флагов. Если значение "Не фрагментировать" установлено в 1, ничего делать не нужно — датаграмма отбрасывается и перестает существовать.

    2. Если флаг "Не фрагментировать" установлен в 0, то поле данных разделяется на отдельные части в соответствии с MTU следующего участка. Полученные части выравниваются по 8-октетной границе.

    3. Каждой части присваивается заголовок IP, подобный заголовку исходной датаграммы, в частности копируются значения полей источника, назначения, протокола и идентификации. Однако следующие поля устанавливаются индивидуально для каждой из частей:

     a. Длина датаграммы будет отражать текущую длину полученной датаграммы.

     b. Флаг More из поля флагов устанавливается в 1 для всех частей, кроме последней.

     c. Поле смещения фрагмента будет указывать позицию полученной части относительно начала исходной датаграммы. Начальная позиция принимается за 0. Смещение фрагмента равно реальному смещению, разделенному на 8.

     d. Для каждого фрагмента вычисляется собственная контрольная сумма.

    Теперь настало время более подробно рассмотреть поля при фрагментации датаграммы.

    6.14.1 Поле идентификации

    Поле идентификации содержит 16-разрядное число, помогающее хосту назначения распознать фрагмент датаграммы при сборке.

    6.14.2 Поле Флагов

    Поле флагов содержит три бита:

    Бит 0 Бит 1 Бит 2
    0=Зарезервировано 0=Можно фрагментировать 1=Нельзя фрагментировать 0=Последний фрагмент (Last) 1=Есть еще фрагменты (More)

    Бит 0 зарезервирован, но должен иметь значение 0. Отправитель может указать в следующем бите значение 1, и датаграмму нельзя будет фрагментировать. Если ее нельзя будет доставить без фрагментации, а бит фрагментации равен 1, то датаграмма будет отброшена с посылкой сообщения отправителю.

    Бит 2 устанавливается в 0 для последней или единственной части датаграммы. Бит 2, установленный в 1, указывает, что датаграмма фрагментирована и имеет следующие далее части.

    6.14.3 Поле смещения фрагмента

    Блок фрагментации (fragment block) — это 8-октетная порция данных. Число в поле смещения фрагмента (Fragment Offset) указывает величину смещения данного фрагмента (относительно начала датаграммы) в единицах блоков фрагментирования. Это поле имеет длину 13 бит (т.е. смещение может быть от 0 до 8192 блоков фрагментирования — или от 0 до 65 528 октетов). Предположим, что маршрутизатор разделил датаграмму (с идентификатором 348) из 3000 байт данных на три датаграммы по 1000 байт. Каждый фрагмент будет содержать собственный заголовок и 1000 байт данных (125 блоков фрагментирования). Содержимое полей идентификации, флагов и смещений фрагментов будет следующим:

    Фрагмент Идентификатор Флаги Смещение фрагмента
    1 348 Можно фрагментировать, More 0 блоков от начала
    2 348 Можно фрагментировать, More 125 блоков (1000 октетов) от начала
    3 348 Можно фрагментировать, Last 250 блоков (2000 октетов) от начала

    Когда датаграмма доставляется без фрагментации, значения полей будут следующими:

    Идентификатор Флаги Смещение фрагмента
    348 Можно фрагментировать, Last 0 блоков от начала

    Хост получателя, приняв датаграмму, помеченную как "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.2

    6.16.4 Маршрутизация от источника и безопасность

    Маршрутизация от источника стала у сетевых хакеров частью арсенала инструментов для взлома. Этот метод может быть использован для проникновения из Интернета в сети, администраторы которых не беспокоятся о безопасности.

    Маршрутизаторы, фильтрующие поступающий в организацию трафик, должны позволять блокировать трафик с маршрутизацией от источника или проверять поле Source Route на соответствие реальной точке назначения датаграммы.

    Еще одна проблема возникает с многоадресными хостами, подключенными к одной или нескольким подсетям. Дело в том, что такие хосты могут пропускать датаграммы с маршрутизацией от источника, открывая доступ к трафику сети с "черного хода". Многоадресные хосты также должны уметь запрещать маршрутизацию от источника.

    6.16.5 Запись пути

    Поле записи пути (Record Route) содержит список IP-адресов маршрутизаторов, пройденных датаграммой. Каждый встретившийся по пути следования маршрутизатор пытается добавить свой выходной адрес в такой список.

    Но длина списка задается отправителем, и, возможно, что для записи всех адресов по пути следования датаграммы может не хватить места. В этом случае маршрутизатор будет просто пересылать датаграмму без добавления своего адреса.

    6.16.6 Временная метка

    Существуют три формата для поля временной метки (Timestamp), которое может содержать:

    ■ Список 32-разрядных временных меток

    ■ Список IP-адресов и соответствующих им пар временных меток.

    ■ Список предварительно выбранных в источнике адресов со следующим за ним пространством для записи временной метки (сетевые узлы будут записывать туда временные метки, только когда их адреса будут совпадать с адресами из списка)

    В первом и втором случаях может не хватить места для записи. Тогда создается подполе переполнения (overflow) для подсчета узлов, которые не смогли записать свои временные метки.

    6.16.7 Базовая и улучшенная безопасность для Министерства обороны

    Вариант базовой безопасности (Basic Security) используется для проверки того, что источник имеет право на отправку датаграммы, маршрутизатор — на трансляцию, а приемник — на ее получение.

    Параметр Basic Security состоит из классификационных уровней, изменяющихся от Unclassified (не секретно) до Top Secret (совершенно секретно) и флагов идентификации авторства. Эти уровни определяют правила для датаграммы. Авторство присвоено нескольким организациям, например Агентству национальной безопасности США, ЦРУ и Министерству энергетики.

    Датаграмма с Basic Security может содержать и поле Extended Security. Для этих полей существует несколько различных подформатов, определяющих требования различных владельцев авторства.

    Маршрутизатор или хост должен уничтожить информацию, на которую у него нет права авторства. Системы безопасности конфигурируются с различными классификационными уровнями и могут посылать и получать сведения об авторстве (авторствах), если это разрешено. Отметим, что многие коммерческие продукты не поддерживают таких возможностей.

    6.16.8 Конец списка вариантов и отсутствие операций

    Вариант "без операций" (No Operation) применяется для заполнения промежутков между вариантами датаграмм. Например, он используется для выравнивания следующего варианта по 16- или 32-разрядной границе.

    Конец списка вариантов (End of Option List) служит для заполнения полей вариантов до 32-разрядной границы.

    6.16.9 Кодирование вариантов

    Существуют два однобайтовых варианта, кодируемых следующим образом:

    No Operation 00000001

    End of Option List 00000000

    Оставшиеся варианты задаются несколькими битами. Каждый начинается октетом типа и октетом длины.

    Для рассматриваемых вариантов возникает следующий вопрос: нужно ли их копировать в заголовки получаемых при фрагментации датаграмм? Копирование выполняется для Security, Strict Source Route и Loose Source Route. Поля Record Route и Timestamp копируются только в первый фрагмент датаграммы.

    Октет типа подразделяется на:

    Биты Функция Описание
    0 Флаг копирования Устанавливается в 1 для копирования при фрагментации
    1-2 Класс варианта 0 — для датаграмм или сетевых управляющих сообщений, 2 — для отладки и измерений
    3-7 Номер варианта Уникальное значение для каждого из вариантов

    В таблице 6.5 показаны значения октета типа и его деление на поля Copy (копирование), Class (класс) и Option Number (номер варианта) для каждого стандартного варианта.


    Таблица 6.5 Поля Copy, Class и Option Number

    Значение Copy Class Number Имя
    0 0 0 0 End of Options List
    1 0 0 1 No Operation
    137 1 0 9 Strict Source Route
    131 1 0 3 Loose Source Route
    7 0 0 7 Record Route
    68 0 2 4 Timestamp
    130 1 0 2 Security
    133 1 0 5 Extended Security

    Форматы наиболее общих полей вариантов представлены на рис. 6.13.

    Рис. 6.13. Форматы полей вариантов

    6.16.10 Кодирование Strict Source Route

    Вариант Strict Source Route (точный маршрут от источника) содержит указатели на список адресов. Указатель определяет позицию следующего обрабатываемого адреса. Первоначально указатель имеет значение 4, которое увеличивается на 4 при каждом попадании.

    6.16.11 Кодирование Loose Source Route

    Вариант Loose Source Route (произвольный маршрут от источника) содержит указатели на список адресов. Исходное положение указателя, как в предыдущем случае, здесь 4 и увеличивается на 4 при достижении каждого из адресов списка.

    6.16.12 Кодирование Record Route

    Вариант Record Route (запись маршрута) содержит указатели и место для записи адресов. Первоначально указатель имеет значение 4, а место, предназначенное для записи адреса, пусто.

    При достижении каждого маршрутизатора его адрес записывается по указателю, а значение указателя увеличивается на 4. Когда будет занято все выделенное для записи место, датаграмма продолжит путь к точке назначения без записи дополнительных адресов.

    6.16.13 Кодирование Timestamp

    Вариант Timestamp (временная метка) содержит указатель, подполе переполнения и подполе флага. Подполе флага определяет один из трех возможных для временной метки форматов.

    Если в подполе флага содержится 0, то при каждом попадании в выделенном месте записывается временная метка, а значение указателя увеличивается на 4. Когда будет заполнено все предварительно выделенное пространство, значение подполя переполнения увеличивается на единицу и все поступающие датаграммы отбрасываются.

    Если подполе флага хранит 1, то при каждом попадании по IP-адресу на пустое место будет записываться временная метка, а значение указателя увеличиваться на 8. Когда будет заполнено все предварительно выделенное пространство, значение подполя переполнения увеличивается на единицу и запись меток прекращается. Предположим, что отправитель хочет записать временные метки для списка предварительно выбранных узлов. В этом случае в поле флага нужно указать 3 и заполнить список выбранных адресов интернета. Если в текущий момент указатель установлен на адрес маршрутизатора, это устройство заполнит место для временной метки и увеличит значение указателя на 8.

    6.16.14 Кодирование Basic и Extended Security Options

    Значения этих полей устанавливаются военными и правительственными агентствами. Дополнительные сведения можно получить в RFC 1108.

    6.17 Пример заголовка IP

    На рис. 6.14 показан результат работы анализатора Sniffer компании Network General для заголовка MAC-кадра сети DIX Ethernet и для заголовка IP.

    DLC: - DLC Header -

    DLC:

    DLC: Frame 14 arrived at 10:26:10.5797; size is 61 bytes

    DLC: Destination = Station Sun 076A03, Sun Atlantis

    DLC: Source = Station Sun 07FD89, Sun Jupiter

    DLC: Ethertype = 0800 (IP)

    DLC:


    IP: - IP Header -

    IP:

    IP: Version = 4, header length = 20 bytes

    IP: Type of Service = 00

    IP:  000. .... = routine

    IP:  ...0 .... = normal delay

    IP:  .... 0... = normal throughput

    IP:  .... .0.. = normal reliability

    IP: Total length =47 bytes

    IP: Identification = 4458

    IP: Flags = 0X

    IP: .0.. .... = may fragment

    IP: ..0. .... = last fragment

    IP: Fragment offset = 0 bytes

    IP: Time to Live = 30 seconds/hops

    IP: Protocol = 6 (TCP)

    IP: Header checksum = 12F4 (correct)

    IP: Source address = [192.42.252.1]

    IP: Destination address = [192.42.252.20]

    IP: No options

    IP:


    HEX


    MAC Header

    06 00 20 07 6A 03 (Destination physical address)

    08 00 20 07 FD 89 (Source physical address)

    08 00             (Protocol Type for IP)


    IP Header

    45 00 00 2F (Version, Hdr Length, Prec/TOS, Total Length)

    11 6A 00 00 (Identification, Flags, Fragment Offset)

    1E 06 12 F4 (Time to Live, Protocol, Header Checksum)

    C0 2A FC 01 (Source IP Address)

    C0 2A FC 14 (Destination IP Address)

    Рис. 6.14. Интерпретация заголовков MAC и IP

    Заголовок MAC начинается 6-байтовыми физическими адресами систем источника и назначения. Отметим, что анализатор Sniffer заменяет первые 3 байта каждого физического адреса на соответствующее имя компании — производителя сетевого адаптера (в нашем случае это Sun). Поле типа содержит код X'0800, что означает: "данную информацию доставлять в IP".

    На рисунке датаграмма IP следует сразу за коротким MAC-заголовком сети DIX Ethernet. Это кадр стандарта 802.3, а за MAC-заголовком располагаются 8-байтовый заголовок LLC с подзаголовком SNAP.

    Размер кадра — 61 байт. В эту величину включается 14-байтовый MAC-заголовок кадра, но не учитывается 4-байтовая завершающая часть MAC, поэтому полный кадр имеет длину 65 байт. Кадры Ethernet или 802.3 для носителя на коаксиальном кабеле должны иметь длину не менее 64 байт, следовательно, кадр едва не стал меньше допустимого минимального размера. Датаграмма кадра имеет общую длину только 47 байт.

    Как и многие заголовки IP, рассматриваемый в примере заголовок не содержит вариантов и, следовательно, имеет длину 20 байт. На практике поле Type of Service имеет, как правило, значение 0.

    Можно заметить, что датаграмма не является фрагментом более длинной датаграммы, поскольку поле Fragment Offset хранит 0, показывая начало датаграммы, и второй флаг установлен в 0, указывая на ее конец.

    Датаграмма зафиксировала информацию о 30 попаданиях в поле TTL. Поле Protocol имеет значение 6, что указывает на доставку датаграммы TCP на хост назначения.

    Анализатор Sniffer транслировал IP-адреса источника и назначения в общепринятый формат с точками.

    Шестнадцатеричные октеты, создающие исходный заголовок MAC и заголовок IP, показаны в нижней части рисунка. Заданный в Sniffer вывод в шестнадцатеричном формате был заменен на соответствующие, но более простые значения в формате с точками.

    6.18 Сценарий обработки датаграммы

    Для лучшего понимания работы IP рассмотрим операции по обработке датаграммы в маршрутизаторе и хосте назначения. Выполняемые при этом шаги показаны на рис. 6.15.

    Рис. 6.15. Обработке датаграммы

    Возникающие проблемы и ошибки приводят обычно к отбрасыванию датаграммы и посылке источнику сообщения об ошибке. Эти процессы будут рассмотрены в главе 7, посвященной протоколу Internet Control Message Protocol (ICMP).

    6.18.1 Обработка в маршрутизаторе

    После получения датаграммы маршрутизатор проводит серию проверок, чтобы узнать, не нужно ли отбросить данную датаграмму. Вычисляется контрольная сумма заголовка и сравнивается со значением из поля контрольной суммы.

    Просматриваются поля версии, длины заголовка, общей длины и протокола для выявления имеющих смысл значений. Уменьшается значение из поля времени жизни. При ошибке в контрольной сумме, параметрах или нулевом значении времени жизни, а также в том случае, когда маршрутизатор не имеет достаточного объема памяти для продолжения ее обработки, датаграмма отбрасывается.

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

    Далее маршрутизатор выполняет процедуру маршрутизации датаграммы. По указанию в заголовке датаграммы выбирается вариант точного или произвольного маршрута от источника. Затем, если это необходимо и разрешено, осуществляется фрагментирование. Если датаграмма не может быть передана дальше без фрагментации, но поле "Не фрагментировать" имеет значение 1, она отбрасывается.

    Имеющиеся варианты обрабатываются. Измененные заголовки должны быть построены для каждой датаграммы или ее фрагмента. Наконец повторно вычисляется контрольная сумма заголовка и датаграмма пересылается системе следующего попадания. Это наиболее общий сценарий обработки датаграммы маршрутизатором. Однако иногда он является конечной точкой назначения датаграммы. Например, запрос сетевой управляющей информации может посылаться на сам маршрутизатор.

    6.18.2 Обработка в хосте назначения

    В хосте назначения вычисляется контрольная сумма, и полученный результат сравнивается с соответствующим полем. Проверяется адрес назначения на принадлежность данному хосту. Проверяется также корректность полей версии, длины заголовка, общей длины и протокола. Датаграмма отбрасывается при любой ошибке или при недостатке буферного пространства для ее обработки хостом.

    Если датаграмма фрагментирована, то хост проверяет четыре поля: идентификации, адреса источника, адреса назначения и протокола для выявления фрагментов с идентичными значениями (т.е. принадлежащих одной датаграмме). Далее используется значение из поля смещения фрагмента для позиционирования фрагментов относительно друг друга.

    Целая датаграмма пересылается соответствующей службе высокого уровня, например TCP или UDP.

    Хост не ожидает полного завершения сборки датаграммы из фрагментов. Когда поступает первый фрагмент, таймер устанавливается в локально конфигурируемое значение (обычно между 1 и 2 минутами). Фрагменты датаграммы, не собранные за это время, отбрасываются.

    6.19 Средства защиты и безопасность

    Все хотят получить максимальные преимущества от коммуникаций, но благоразумный сетевой администратор всегда принимает меры, чтобы защитить ресурсы компьютеров от воздействия извне, в первую очередь от хакеров. Маршрутизаторы со средствами защиты (firewall router; иногда используется дословный перевод — брандмауэр, т.е. противопожарная стенка. — Прим. пер.) стали наиболее популярными устройствами в оборонительном арсенале сетевого администратора.

    Маршрутизаторы со средствами защиты устанавливаются для фильтрации трафика с целью обеспечения безопасности сайта. Как показано на рис. 6.16, такие маршрутизаторы могут конфигурироваться на разрешение или запрещение трафика на основе:

    ■ IP-адреса источника

    ■ IP-адреса назначения

    ■ Протокола

    ■ Приложения

    Рис. 6.16. Маршрутизатор со средствами защиты

    Например, внутренним пользователям можно разрешить посылку и прием сообщений электронной почты и доступ к внешним серверам WWW, а внешним пользователям — только к небольшому подмножеству серверов сайта.

    Дополнительная защита обеспечивается интеллектуальным фильтрующим хостом со средствами защиты. В некоторых реализациях внутренние пользователи должны соединится со средством защиты и аутентифицировать себя для соединения с внешним миром. Пользователям могут индивидуально присваиваться привилегии. Весь трафик из внешнего мира будет фильтроваться средством защиты хоста и может анализироваться по определенным критериям.

    Некоторые хосты со средствами защиты работают как прокси. Когда внутренний пользователь запрашивает информацию из внешнего мира, производится соединение с прокси, который и получает эту информацию, а затем передает ее внутреннему пользователю.

    Для большей защиты сайты можно установить в режим "демилитаризованной зоны" локальной сети, разместив хосты защиты и все внутренне доступные прикладные серверы в локальной сети, защищенной фильтрующим маршрутизатором. На рис. 6.17 показана такая зона локальной сети, используемая для защиты от внешнего вторжения.

    Рис. 6.17. Защита сайта с помощью демилитаризованной зоны

    Применение защитного прокси позволяет присваивать компьютерам сайта личные IP-адреса (не известные внешним пользователям, которым доступен только адрес прокси или средства защиты. — Прим. пер.). В этом случае только для систем из демилитаризованной зоны локальной сети потребуются уникальные общедоступные адреса.

    6.20 Замечания о производительности IP

    Производительность интернета зависит от количества доступных ресурсов на хостах и маршрутизаторах и от эффективности их использования. К таким ресурсам относятся:

    ■ Полоса пропускания пересылки информации

    ■ Объем буферной памяти

    ■ Скорость работы центрального процессора (ЦП)

    Совершенных механизмов работы протоколов не существует. Разработка протоколов требует компромисса между широтой возможностей и эффективностью.

    6.20.1 Полоса пропускания

    IP эффективно использует полосу пропускания. Датаграммы помещаются в очередь для пересылки в точку следующего попадания, как только станет доступна полоса пропускания (bandwidth; по традиции мы будем использовать термин "полоса пропускания", хотя больший смысл имеет термин "доля производительности сети". — Прим. пер.). В результате удается избежать потерь от резервирования полосы пропускания для конкретного трафика или ожидания подтверждения пересылки.

    Более того, существуют новые протоколы маршрутизации IP с большими возможностями: они могут распараллеливать трафик по нескольким путям и динамически выбирать маршрутизаторы, чтобы исключить перегрузки на отдельных участках пути следования датаграмм. Применение таких протоколов позволяет улучшить использование доступных ресурсов для пересылки информации.

    Однако появляется небольшая перегрузка из-за управляющих сообщений, единственным источником которых становится протокол ICMP.

    В результате проявляются и некоторые негативные свойства. Когда трафик направляется из высокоскоростной локальной сети в линию "точка-точка" с малой полосой пропускания, датаграммы начинают скапливаться в очереди маршрутизатора. Увеличивается время доставки от источника к точке назначения, и некоторые датаграммы отбрасываются. В этом случае требуется повторная пересылка датаграмм, еще более увеличивающая нагрузку на сеть и уменьшающая ее пропускную способность.

    Отметим также, что при перегрузке сети, доставка датаграмм замедляется и становится менее надежной. Однако некоторые очень эффективные алгоритмы позволяют TCP немедленно реагировать на перегрузки посредством сокращения объема пересылаемых данных и снижения уровня ретрансляции.

    Эти алгоритмы оказывают существенное влияние на производительность сети и поэтому стали неотъемлемой частью стандарта TCP (см. главу 10).

    Производители маршрутизаторов энергично создают все более совершенные устройства, позволяющие обрабатывать десятки тысяч датаграмм в секунду. Для получения высокой производительности следует также внимательно отнестись к конфигурированию сети, чтобы предполагаемое максимальное использование памяти составляло примерно 50% от общего объема буферной памяти.

    6.20.2 Использование буфера

    Протокол IP, производящий пересылку датаграммы, несет ответственность за ее доставку. Для тех случаев, когда датаграмма по тем или иным причинам не попала в точку назначения, предусмотрен буфер датаграмм, позволяющий произвести операцию пересылки снова. В свою очередь, IP хоста назначения должен выделить некоторое буферное пространство для сборки фрагментированных датаграмм.

    6.20.3 Ресурсы центрального процессора

    Обработка датаграмм не приводит к большой загрузке центрального процессора (ЦП). Анализ заголовка достаточно прост. Не требуется сложного программного обеспечения для обслуживания тайм-аутов и повторной трансляции.

    Вследствие динамических изменений и отсутствия соединений протокол IP требует обработки информации о маршрутизации на каждой системе попадания. Однако это реализуется простым просмотром таблицы, что выполняется достаточно быстро даже при большом размере таблиц.

    Выполняемый маршрутизаторами анализ безопасности замедляет обработку, особенно при длинном списке условий для проверки каждой датаграммы.

    6.21 Дополнительные сведения о многоадресных рассылках

    Существует класс IP-адресов, используемых в многоадресных рассылках (см. главу 5), позволяющий маршрутизировать датаграмму от источника к группе систем, заданной одним из адресов класса D. Технологии и протоколы поддержки многоадресных рассылок в приложениях (например, в конференциях) существенно улучшились и расширили свои возможности за последние несколько лет.

    В этом разделе мы кратко рассмотрим некоторые из используемых в настоящее время реализаций многоадресных рассылок. Но сначала приведем следующие факты:

    ■ Отправитель многоадресной рассылки может не являться членом группы этой рассылки.

    ■ Некоторые адреса для многоадресной рассылки стандартизированы и неизменны. Они зарегистрированы в IANA и опубликованы в RFC Assigned Numbers.

    ■ Временные адреса многоадресной рассылки выбираются некоторым текущим процессом администрирования — их уникальность не гарантируется.

    ■ Адрес многоадресной рассылки "все хосты" — 224.0.0.1 — уникален. Датаграммы, посланные группе всех хостов, никогда не могут покинуть локальную подсеть.

    ■ Протокол IGMP обеспечивает механизм для разрешения многоадресным маршрутизаторам определять принадлежность хостов к группе многоадресной рассылки. IGMP рассматривается как составная часть IP. Сообщения IGMP переносятся датаграммами IP со значением 2 в поле протокола.

    ■ Многоадресный маршрутизатор — это любая система, выполняющая специальное программное обеспечение многоадресной маршрутизации, которое может выполняться на обычных маршрутизаторах или хостах, сконфигурированных для выполнения многоадресной рассылки.

    Рассмотрим сценарий работы многоадресного хоста:

    ■ Хост, который хочет подключиться к группе и получать многоадресные рассылки, начинает прослушивать адрес многоадресной рассылки для всех хостов (224.0.0.1).

    ■ Если хост хочет подключиться к конкретной группе, он должен сообщить об этом всем многоадресным маршрутизаторам по локальной связи. Для этого он отправляет сообщение-отчет IGMP по адресу нужной группы многоадресной рассылки. Поле TTL такого сообщения установлено в 1, и сообщение не может покинуть локальную подсеть.

    ■ Затем хост начинает прослушивать датаграммы, посланные по адресу многоадресной рассылки.

    ■ Кроме того, хост реагирует на периодические запросы от локальных маршрутизаторов и отвечает соответствующим отчетом.

    ■ Для выхода из группы хост просто прекращает прослушивание на адрес этой группы и перестает направлять отчеты в группу.

    Рассмотренные действия хоста слишком прямолинейны. Маршрутизация должна быть несколько сложнее и поэтому находится в стадии совершенствования. Рассмотрим действия в маршрутизаторе:

    ■ Многоадресный маршрутизатор прослушивает все интерфейсы для получения отчетов от хостов. Для каждого из его интерфейсов создается список всех многоадресных групп, имеющих не менее одного активного члена в подсети, доступ к которой выполняется через данный маршрутизатор.

    ■ Маршрутизатор должен посылать другим маршрутизаторам список адресов активных групп для каждой из подключенных к нему подсетей.

    ■ Поскольку хосты достаточно молчаливы, маршрутизатору приходится периодически проверять локальные системы на принадлежность к конкретной группе. Для этого он время от времени отправляет запрос по адресу "все хосты". Каждый хост группы будет ожидать в течение произвольного промежутка времени. Первый из откликнувшихся укажет в своем ответе адрес группы. Маршрутизатор и все системы этой группы услышат такой ответ. Поскольку маршрутизатор после этого уже знает, что в группе есть хотя бы один активный член, остальные ответы уже не требуются.

    ■ Когда маршрутизатор получает датаграмму многоадресной рассылки, он пересылает ее в каждую подключенную к нему подсеть, в которой находится член этой группы. Маршрутизатор может также переслать датаграмму другому многоадресному маршрутизатору.

    IGMP-сообщение хоста имеет формат, показанный на рис. 6.18. Значение типа 1 определяет Host Membership Query (запрос о членстве хоста), а значение 2 — Host Membership Report (отчет о членстве хоста).

    Рис. 6.18. Формат сообщения IGMP от хоста

    6.22 Рекомендуемая литература

    Протокол IP определен в RFC 791. Изменения, корректировки и требования совместимости специфицированы в RFC 1122. RFC 1812 подробно описывает требования IP версии 4 к маршрутизаторам и содержит подробные сведения об операциях таких маршрутизаторов.

    Варианты безопасности Министерства обороны обсуждаются в RFC 1108. Вычислению контрольной суммы в Интернете посвящены RFC 1071, 1141 и 1624. RFC 815 представляет эффективные алгоритмы для сборки после фрагментации датаграммы в хосте получателя.

    RFC 1112 специфицирует расширения хостов для многоадресных рассылок в IP.








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх