Протоколы транспортного уровня модели TCP/IP

Основные функции протоколов транспортного уровня сводятся к обеспечению надежной доставки данных от отправителя к получателю, необходимой фрагментации исходящих сообщений перед их передачей и их повторной сборке перед доставкой на Прикладной уровень для последующей обработки. Таким образом, эталонная модель взаимодействия открытых сетей (OSI) и модель TCP/IP в большей или меньшей степени соответствуют друг другу.

На транспортном уровне модели TCP/IP можно выделить два популярных протокола: TCP (протокол управления передачей) и UDP (протокол передачи дейтаграмм пользователя). Эти транспортные протоколы существуют в двух вариантах: на основе соединений (connection-oriented) (TCP) и без установления соединения (connectionless) (UDP). Различие выражается в действиях протокола TCP по организации и поддержке соединения между отправителем и получателем перед отсылкой данных, получению положительного подтверждения об успешной их передаче или запроса на повторную пересылку отсутствующих или ошибочных данных. В то же время протокол UDP просто пересылает данные «оптимальными усилиями» и не выполняет последующей проверки их получения.

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

Протокол UDP

Протокол UDP (User Datagram Protocol — протокол пользовательских дейтаграмм, RFC 768) является одним из двух основных протоколов транспортного уровня. Протокол UDP предоставляет протоколам прикладного уровня услуги негарантированной доставки пакетов, что немногим отличается от услуги протокола IP. Поскольку для приложений, использующих протокол UDP, важна в первую очередь скорость доставки данных, протокол UDP имеет очень короткий заголовок. Заголовок UDP содержит только три поля Port (порт), Checksum (контрольная сумма) и Length (дли- на дейтаграммы), первое предназначено для мультиплексирования дейтаграмм по различным приложениям, второе — обеспечивает целостность каждой конкретной переданной дейтаграммы.

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

Формат UDP-дейтаграммы

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

Поля UDP-диаграммы.

Поле Source port (порт отправителя) указывает порт приложения, отправившего дейтаграмму. Это поле необязательное, если оно не используется, то содержит нуль.

Поле Destination port (порт получателя) указывает порт приложении, которое должно обрабатывать эту дейтаграмму у получателя.

Поле Length (длина) определяет число октетов (байтов) в UDP- дейтаграмме, включая заголовок.

Поле Checksum (контрольная сумма) указывает контрольную сумму UDP дейтаграммы. Поле необязательно содержит контрольную сумму. Для упрощения вычислений в поле Checksum записывается нуль, тогда получатель не проверяет контрольную сумму дейтаграммы. Однако это может привести к неприятным последствиям, поскольку протокол IP не вычислят контрольную сумму переносимых им данных (в частности, UDP-дейтаграммы). Если расчетная контрольная сумма равна нулю, она передается как поле, целиком состоящее из единиц (эквивалент при дополнении до единицы). Передача поля, целиком состоящего из нулей, означает, что отправитель дейтаграммы не вычислял контрольной суммы (при отладке, а также для тех протоколов, которые не требуют точности передачи). При доставке поверх IPv6 контрольная сумма в UDP обязательна.

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

Сам по себе псевдозаголовок не передается, поэтому размер

Формат псевдозаголовка UDP

UDP-дейтаграммы не увеличивается. Для проверки дейтаграммы на приемной стороне псевдозаголовок генерируется UDP-протоколом из соответствующих полей IP-пакета. Идентичность контрольных сумм гарантирует доставку пакета по правильному (указанному в поле Destination address) адресу и по указанному порту. В поле псевдозаголовка Protocol указывается код протокола UDP, равный 17.

Инкапсуляция UDP

Инкапсуляция-это вложение протокола более высокого уровня в ноле данных протокола более низкого уровня.

Протокол UDP согласно стекупротоколов TCP/IP должен взаимодействовать с протоколами прикладного уровня и протоколами межсетевого уровня. Протоколы прикладного уровня передают битовый (байтовый) поток протоколу UDP. Этот поток протокол UDP фрагментирует и вставляет в область данных своих дейтаграмм. Далее протокол UDP вычисляет контрольную сумму, добавляет свой заголовок и передает свои дейтаграммы нижележащему протоколу межсетевого уровня — протоколу IP. Протокол IP вставляет в область своих данных UDP дейтаграмму целиком, не изменяя, и добавляет свой IP-заголовок, таким образом, получая целостный IP-пакет. После чего IP-пакет передается протоколу нижележащего уровня сетевого интерфейса. В случае использования на этом уровне протокола Ethernet IP-пакет вставляет в область данных Ethernet кадра, после чего протокол Ethernet вычисляет свой заголовок и окончание и дописывает их к области данных. В результате получается полный Ethernet кадр с вложенными IP-пакетом и UDP-дейтаграммой, содержащий битовый поток от конкретного приложения. Процесс вложения называется инкапсуляцией пользовательских данных и показан на рис. 6.10.

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

Инкапсуляция UDP-дейтаграмм

Зона ответственности протокола Ethernet — локальная сеть. Если узел находится за пределами локальной сети, кадр должен быть декапсулирован до IP-пакета, чтобы осуществить доставку по IP- адресу, указанному в IP-заголовке. Двух заголовков Ethernet и IP хватит, чтобы доставить UDP пакет до узла назначения, но не хватит, чтобы передать конкретному приложению переданный битовый поток. Поэтому необходимо на узле получателя декапсулировать пакет, сначала до UDP-дейтаграммы, заголовок которой может мультиплексировать битовый поток между приложениями по номеру порта, и затем отбросить и UDP-заголовок, передав приложению данные в чистом виде.

Протокол TCP

Наибольшую нагрузку на канал абонента вызывают интернет-приложения, основанные на TCP-протоколе. Все больший процент занимает потоковое интернет-видео. Протокол ТСР (Transmission Control Protocol — протокол управления передачей, RFC 793) обеспечивает гарантированную доставку данных. Это предусматривает защиту от повреждения, потери, дублирования и нарушения очередности поступления пакетов. Передача осуществляется сегментами, содержащими контрольные суммы, чтобы избежать потерю и нарушения пакетов. Все октеты, образующие ТСР-сегмент, пронумерованы. Сегменты ТСР передаются последовательно в объеме так называемого окна отправки, размер которого регулируется в за- висимости от качества канала. Тем самым приемная сторона может регулировать скорость передачи. Устанавливаемый коэффициент загрузки зависит от допустимого размера буферной памяти, который определяет допустимый размер очереди в канале. При превышении очередью допустимого размера происходит потеря пакетов. Приемная сторона сигнализирует передающей стороне о необходимости уменьшения скорости передачи. В результате уменьшения скорости передачи происходит уменьшение коэффициента загрузки, что приводит к уменьшению размеров очереди.

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

Таким образом, при наличии ТСР-трафика на канале абонента мы подразумеваем, что канал будет нагружен до теоретического максимума, доступного с учетом возможного приоритета других протоколов. И нагрузка, скорее всего, будет чередоваться с периодами отсутствия трафика, при этом трафик будет иметь пачечный характер с пачками, равными размеру окна отправки TCP.

При условии предоставления оператором связи абоненту услуг VoIP и IP-TV отдельными пунктами договора и прописанными параметрами качества, разумно вывести такой трафик в выделенные приоритетные очереди на коммутаторах доступа. Прочий ТСР-трафик будет получать оставшийся канал.

Основная задача протокола TCP обеспечить сквозную гарантированную доставку данных между прикладными процессами. Другими словами, если приложение на одном узле хочет передать данные без каких-либо изменений такому же приложению на другом узле, то задачу эту выполнить приложение доверяет протоколу TCP. Поскольку приложение полностью полагается на протокол TCP (зачастую, не имея собственных механизмов проверки данных), протокол TCP должен реализовать доставку собственными механизмами. Инкапсуляция данных при использовании протокола TCP происходит схожим с UDP образом, только ТСР-заголовок значительно отличается от заголовка UDP. Заголовок TCP несет себе множество полей служебной информации, служащей для управления переда-

чей данных по каналам связи.

Заголовок ТСР-сегмента состоит из 32-разрядных слов и имеет переменную длину, зависящую от размера полей «Опции» и «Заполнение», но всегда кратную 32 битам. Формат заголовка TCP- сегмента представлен на рис. 6.11. Поле «порт источника» и поле

«порт назначения» указывают номер портов приложения источника и приложения получателя соответственно.

Формат заголовка TCP-сегмента

Поле «номер последовательности» определяет порядковый номер первого байта в поле данных сегмента среди всех октетов потока данных для текущего логического соединения (TCP-сессия). Если в TCP-сегменте передаются октеты с 5-го по 87-й, то SEQ =

= 5. В случае начальной установки соединения (TCP-сегмент с флагом SYN) в поле SEQ записывается случайный номер ISN (Initial Sequence Number = начальный номер последовательности), в первом ТСР-сегменте без флага SYN поле SEQ = ISN+1.

Поле «номер подтверждения» указывает (в совокупности с флагом АСК) порядковый номер октета, который отправитель данного сегмента желает получить подразумевая тем самым, что все преды- дущие байты (с номерами от ISN+1 до АСК-1) были успешно получе- ны. Возможно использование опции «Выборочные подтверждения» (Selective Ack), тогда получатель имеет возможность перечислить несколько сегментов, которые по его мнению были потеряны.

Поле «смещение данных» (4 бита) указывает смещение начала данных TCP в сегменте относительно начала сегмента. Поле указывает длину ТСР-заголовка. Минимальная длина заголовка без опций может быть равна пяти 32-битовым словам или 160 байтам. Максимальная длина заголовка — 480 байтов.

Поле «Резерв» (4 бита) зарезервировано для дальнейшего использования, заполняется нулями.

Поле «флаги» (8 битов) содержит управляющие биты для контроля над соединением.

Флаг URG (urgent — срочно) указывает срочность доставки сегмента, данные этого сегмента от номера «SEQ» до номера из «Указателя Срочности» будут доставлены в приложение немедленно, от-

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

Флаг ACK (Acknowledgment — подтверждение) подтверждает, что поле «номер подтверждения» указывает следующий октет, который предлагает принять получатель;

Флаг PSH (Push — протолкнуть) указывает на незамедлительность отправки данных из приемного буфера процессу прикладного уровня, даже, если приемный ТСР-буфер не полностью заполнен. Используется при передаче данных интерактивных приложений;

Флаг RST (Reset — сброс) указывает на необходимость сброса текущего TCP-соединения; соответствующий приемный сокет будет закрыт вне зависимости от статуса соединения и наличия необработанных данных в буферах.

Флаг SYN (Synchronization — синхронизация) указывает на то, что данный ТСР-сегмент является запросом на установление соединения;

Флаг FIN (Finish — конец) указывает на закрытие ТСР-соединения в соответствующем направлении; означает, что у данной стороны закончились данные для пересылки и больше данных в данном направлении не ожидается. Соединение в противоположном направлении остается открытым. Данные из буфера будут доставлены приложению.

Флаг ECE (ECN-Echo — эхо уведомления о перегрузке) указывает, что противоположная сторона получила IP-пакет с маркировкой перегрузки на линии; отправитель имеет возможность среагировать на перегрузку уменьшением скорости отправки.

Флаг CWR (Congestion Window Reduced — окно перегрузки уменьшено) означает, что отправитель получил и обработал флаг ECE, и среагировал уменьшением окна отправки.

Поле «Окно» указывает размер ТСР-окна в октетах. Размер окна указывает отправителю максимально возможное число ТСР- сегментов, которые могут быть отправлены не дожидаясь подтверждения каждого сегмента. Как правило размер окна индицирует объем свободного пространства в буфере получателя.

Поле «контрольная сумма» содержит контрольную сумму всего ТСР-сегмента. Обеспечивает поразрядную проверку целостности.

Поле «указатель срочности» используется для указания длины срочных данных, которые размещаются в начале поля данных сегмента. Число в этом поле указывает смещение последнего октета срочных данных относительно первого октета данных в сегменте. Например, если в ТСР-сегменте передаются окном с 5-го по 87-й и

первые 15 из них срочные, то поле Urgent Pointer = 15. Протокол TCP не регламентирует, как должны обрабатываться срочные данные, определено только, что они должны быть максимально быстро отправлены прикладному процессу. Операционная система просигнализирует приемному процессу о наличии срочных данных. Приложение может обработать их отдельно от основного потока. Поле

«указатель срочности» действует в совокупности флагом URG. Поле «опции» (опции, поле переменной длины) поле указыва-

ет на реализацию работы дополнительных услуг (опций) протокола TCP. Поле конкретной опции в поле Options состоит из октета Option Kind (тип опции), октета Option Length (длина опции) и октетов Option Octets (октетов с данными опции). Стандарт протокола TCP определяет семь опций:

• End of Option List (конец списка опций) имеет тип опции, равный 0, и длину в один октет. Определяет конец списка опций. Не используется, если набор опций TCP выходит за 32-битовую границу;

• No Operation (бездействие) имеет тип опции, равный 1, и длину в один октет. Используется между ТСР-опциями для 32- битового выравнивания;

• Maximum Segment Size имеет тип опции, равный 2, и длину в четыре октета. Описывает максимальный размер сегмента, который может быть передан по ТСР-соединению. Вычисляется на основании MТU (Maximum Transfer Unit — максимальный блок передачи), который может быть передан по соединению за вычетом IP- и TCP-заголовков. Данная опция включается только на стадии установки соединения, вместе с флагом SYN;

• «Масштаб окна» используется как битовое смещение влево для поля «размер окна», эффективно удваивая окно соответствующее число раз. Используется для повышения скорости передачи на скоростных каналах с малыми потерями;

• «Разрешены выборочные подтверждения» означает, что далее последует серия опций выборочных подтверждений;

• «Выборочное подтверждение» подтверждает получение данных выборочно от стартового до конечного октета. Таких опций отправитель может указать несколько, тем самым «запрашивая» несколько пропущенных сегментов;

• Поле «Заполнение» заполняется нулями до выравнивания по 32-битовой границе в случае, если поле «Опции» не укладывается в 32-битовое слово.

2) Мультиплексирование потоков

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

Следовательно,

Указанное соотношение справедливо при суммировании любого числа потоков заявок с одинаковыми приоритетами и одинаковыми временами обслуживания τ.

При суммировании Q одинаковых независимых потоков получим

Если суммируются потоки с различными временами обслуживания, то предлагается определить суммарные величины для каждого из значений τ_j, j = 1, 2 ,..., Q:

а затем определить их математические ожидания с учетом вероятностей появления заявки каждого типа:

Как и следовало ожидать, коэффициенты загрузки суммируются. Учитывая, что все характеристики определяются в зависимости от коэффициентов загрузки, возможен и другой способ мультиплексирования. Предлагается для каждого из потоков определять дисперсии D_mj (R Σ) и ковариации Cov _mj (R Σ) на интервалах времени τ Σ j = (R Σ /ρ_j) τ_j, соответствующих суммарному коэффициенту