|
|
1. 1 История tcpIP
3.1.1 Поле Type of Service
Смысл поля Type of Service со временем немного изменился. Первоначально (RFC 791) оно предназначалось для обеспечения определенных функций качества обслуживания (QoS) для доставки IP-пакетов. Оно позволяло добавлять информацию о приоритете пакета и предпочтительных для его доставки характеристиках сети — задержке, пропускной способности и надежности.
Поле ToS состояло из нескольких подполей. Подполе Precedence, длиной 3 бита, определяло приоритет пакета. Однобитные поля D (Delay), T (Throughput), R (Reliability) использовались для определения требований к задержке, пропускной способности и надежности сети, по которой передавался IP-пакет. Первые коммерческие маршрутизаторы не поддерживали функции приоритизации. Однако по мере расширения сетей и повышения требований пользователей производители начали добавлять в свои устройства различные виды систем обслуживания очередей, включающие очереди приоритетов, которые обычно реализовывались в виде фильтров, анализирующих поля заголовков протоколов IP (включая Precedence), TCP или UDP.
Подполе Precedence широко использовалось, но не таким образом, как было определено в RFC 791. Биты D, T и R вовсе не применялись в реальных сетях в течение многих лет. В октябре 1989 года появился RFC 1122, в котором было дано новое определение байта ToS. Он был разделен на 2 части: поле Precedence размерностью 3 бита и поле Type-of-Service или ToS, длиной 5 бит. В 1998 году появился RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», который переопределил байт ToS для поддержки модели дифференцированного обслуживания (Differentiated Services, DiffServ).
Напомним, что функции качества обслуживания в современных сетях заключаются в обеспечении гарантированного или дифференцированного уровня обслуживания сетевого трафика, запрашиваемого теми или иными приложениями на основе различных механизмов распределения ресурсов, ограничения интенсивности трафика, обработки очередей и приоритизации.
Можно выделить три модели реализации QoS в сети:
Негарантированная доставка данных (Best Effort Service) — обеспечивает связь между узлами, но не гарантирует надежную доставку данных, время доставки, пропускную способность и определенный приоритет.
Интегрированные услуги (Integrated Services, IntServ) — эта модель описана в RFC 1633 и предполагает предварительное резервирование сетевых ресурсов с целью обеспечения предсказуемого поведения сети для приложений, требующих для нормального функционирования гарантированной выделенной полосы пропускания на всем пути следования трафика. Эту модель также часто называют жестким QoS (hard QoS) в связи с предъявлением строгих требований к ресурсам сети.
Дифференцированное обслуживание (Differentiated Service, DiffServ) — эта модель описана в RFC 2474, RFC 2475 и предполагает разделение трафика на классы на основе требований к качеству обслуживания. В архитектуре DiffServ каждый передаваемый пакет снабжается информацией, на основании которой принимается решение о его продвижении на каждом промежуточном узле сети в соответствии с политикой обслуживания трафика данного класса (Per-Hop Behavior, PHB). Модель дифференцированного обслуживания занимает промежуточное положение между негарантированной доставкой данных и моделью IntServ и сама по себе не предполагает обеспечение гарантий предоставляемых услуг, поэтому дифференцированное обслуживание часто называют мягким QoS (soft QoS).
Поле ToS в RFC 2474 было заменено на поле DS (Differentiated Services). Первые 6 битов поля DS называются Differentiated Services Codepoint (DSCP) и являются кодовой точкой (codepoint), ассоциированной с классами трафика. Классы определяют политику обслуживания пакета на каждом промежуточном устройстве (коммутаторе, маршрутизаторе), через которое он проходит (Per-Hop Behavior, PHB).
3.1.2 Фрагментация пакетов IPv4
Для того чтобы отправить сообщение, используя протокол IP, данные, полученные от вышележащего уровняб инкапсулируются в IP-пакет. Далее пакет опускается на уровень ниже и инкапсулируется в кадр канального уровня, который помещается в кадр физического уровня и передается по сети. Канальный уровень может использовать разные технологии — Ethernet, 802.11, xDSL, GPON и т. д. Каждая технология канального уровня имеет свой собственный формат кадра и размер поля данных, в которое помещается принятый с сетевого уровня IP-пакет. Например, максимальный размер поля данных стандартного кадра Ethernet составляет 1500 байт, кадра 802.11n — 3839 или 7935 байт. Максимальный размер пакета, который может быть передан через физическую сеть, называется Maximum Transmission Unit (MTU).
Обычно узлы стараются отправлять большие пакеты, так как это уменьшает издержки — например, количество служебной информации, такой как заголовки. Когда узел отправляет IP-пакет, он должен определить, не превышает ли размер пакета MTU нижележащего протокола. Если размер пакета больше, то он разбивается на фрагменты (fragments) и каждый фрагмент отправляется в виде отдельного пакета сетевого уровня.
Пакет на своем пути от источника до приемника может пройти через множество сетей различных технологий, имеющих разные MTU. Так при пересечении сети с меньшим значением MTU фрагменты могут быть разделены на более мелкие фрагменты.
Рисунок 3.6 иллюстрирует процесс фрагментации пакетов. Первоначальный размер IP-пакета равен 15 400 байт. Чтобы передать его через локальную линию связи, компьютер А должен разбить пакет на 4 фрагмента. Маршрутизатор 1 должен передать фрагменты через интерфейс, MTU которого равен 1500 байтам. Таким образом, он разбивает каждый фрагмент на более мелкие фрагменты. Несмотря на то, что MTU линии связи между маршрутизатором 2 и компьютером В выше, чем между маршрутизаторами 1 и 2, при получении фрагментов, размером 1500 байт, маршрутизатор 2 не собирает их перед передачей по линии связи с MTU 3839 байт.
Пакет не собирается до тех пор, пока не дойдет до устройства-получателя. Для того чтобы его можно было восстановить, фрагменты пакета должны определенным образом нумероваться. В протоколе IP каждому фрагменту присваивается идентификатор пакета, абсолютное смещение внутри пакета (в байтах) и флаг, показывающий, является ли этот фрагмент последним в пакете.
При повторной передаче (если не все фрагменты дошли до адресата) пакет может быть разбит на фрагменты по-другому. Размер фрагментов может быть произвольным, вплоть до одного байта плюс заголовок. В любом случае пакет будет восстановлен: идентификатор пакета и смещение помогут расположить данные в правильном прядке, а флаг укажет на его конец.
Существенным недостатком фрагментации является снижение производительности. Вместо полезной нагрузки передается множество сетевых заголовков, а при потере одного фрагмента требуется повторная передача всего пакета.
Для того чтобы избавиться от фрагментации, надо определить MTU на всем пути следования пакета. Это позволяет выполнить процесс, называемый Path MTU discovery. В своей работе он опирается на сообщения об ошибках протокола Internet Control Message Protocol (ICMP). При отправке каждого пакета IPv4 в его заголовок помещается информация о том, что фрагментация не разрешена (устанавливается флаг Don’t Fragment (DF)). Если маршрутизатор получает слишком большой пакет, он отбрасывает его и отправляет источнику сообщение об ошибке Destination Unreachable (рис. 3.7). Используя информацию, содержащуюся в сообщении об ошибке, источник уменьшает размер пакетов и отправляет их снова. Если такая же проблема возникнет на каком-нибудь из следующих маршрутизаторов, ситуация повторится.
Преимущество Path MTU discovery состоит в том, что в результате источник знает необходимый размер пакета. При изменении маршрута новое значение MTU станет известно отправителю из новых сообщений об ошибках. Недостатком Path MTU discovery является то, что отправка пакета может вызвать дополнительную задержку. Эта задержка может увеличиться в несколько раз в зависимости от того, сколько раз отправителю придется повторять отправку (меняя размер пакета), прежде чем пакет достигнет места назначения.
|
|
|
Скачать 340.83 Kb.