Адаптационные механизмы протокола

Протокол UDP

Адрес назначения в заголовке IP пакета определяет целевой сетевой узел, на котором, в общем случае, могут одновременно выполняться несколько приложений (для операционной системы хоста – процессов). Протокол межсетевого взаимодействия IP «умеет» доставлять пакеты взаимодействующим хостам, но ничего не «знает» о приложениях, данные которых он несет; он также не имеет почти никаких средств обеспечения надежности доставки сообщений, даже контрольная сумма в IP-пакете защищает лишь его заголовок. Протоколы транспортного уровня, UDP и TCP, должны обеспечить в IP-сети прозрачное взаимодействие прикладных процессов, выполняющихся на различных конечных станциях.

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

Порт задается целым положительным числом, назначаемым каждой прикладной программе при ее инициализации в сетевой операционной системе. Некоторые широко используемые сетевые приложения имеют постоянные, закрепленные за ними номера портов, например: 53 порт всегда назначается серверу DNS, 80 порт – web-серверу, 110 – POP-серверу, 25 – серверу SMTP, 23 – службе Telnet. Структура из пары переменных (IP-адрес, порт) однозначно идентифицирует прикладной сетевой процесс, выполняющийся в сети; эта структура называется сокетом.

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

Теоретически, при размерах IP заголовка 20 байт и UDP заголовка 8 байт, для данных приложения в UDP-сегменте остается 65507 байт. Однако, протокол оперирует сегментами значительно меньшего размера. Его максимальное значение задается конфигурационной переменной MSS (Maximum Segment Size).Значение MSS устанавливается не более min (MTU) - 68 байт. Предупреждая нежелательную фрагментацию пакетов IP-уровня, большинство приложений, использующих сервис UDP, ограничивают свои сообщения размером 504 байта. Так, например, протокол маршрутизации RIP всегда формирует сообщения размером не более 504 байт; аналогично поступают и другие UDP-приложения: DNS, TFTP, SNMP. Таким образом, размер сегмента UDP обычно не превышает 512 байт, поскольку IP-пакет размером 572 байт будет передан без фрагментации через любую комбинацию сетей.

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

Сегмент данных протокола UDP состоит из двух частей: заголовка и области данных (рис. 6.12). Заголовок имеет четыре 16-битных поля, в которых указываются порт отправителя, порт получателя, размер сегмента и контрольная сумма.

 

 

Поле «Размер UDP-сегмента» несет информацию о количестве байт в дейтограмме с учетом ее заголовка.

Вычисление контрольной суммы дейтаграммы UDP является опциональным. При работе в надежных локальных сетях она может не вычисляться и тогда это поле заполняется нулями. Расчет контрольной суммы ведется по тому же алгоритму, что и расчет контрольной суммы IP-пакета (сумма 16-битных слов с поразрядным дополнением). Поле «Контрольная сумма» заголовка сегмента на время ее вычисления заполняется нулями.

Сообщение приложения может иметь размер, не кратный 16 битам. Поэтому процедура расчета контрольной суммы требует дополнения сегмента нулевыми битами до размера, кратного 16. Это делается только для вычисления контрольной суммы и незначащие нули не передаются. Второй особенностью расчета контрольной суммы является дополнение заголовка сегмента псевдозаголовком. Его формат представлен на рис. 6.13. Псевдозаголовок включается перед заголовком исходного сегмента; его размер - 12 байт; поле «Протокол» содержит код протокола сетевого уровня (IP). Значения полей с IP-адресами источника и приемника должны быть известны передающему приложению.

 

 

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

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

Несмотря на то, что контрольная сумма UDP - необязательный параметр, она рассчитывается всегда. В конце 1980-х годов в некоторых стеках протоколов по умолчанию функция расчета контрольной суммы UDP стала отключаться. Делалось это во имя уменьшения издержек работы сетевой файловой системы (NFS - Network File System), которая использует сервис UDP. Такое решение еще можно было считать допустимым для обмена данными между системами в одной локальной сети, где кадры канального уровня защищаются контрольной суммой, рассчитанной на основании циклического избыточного кода (Ethernet, Token Ring). Однако, отключение вычисления контрольной суммы при обмене данными в распределенных территориальных и глобальных сетях существенно понижает надежность транспортной услуги. Заметим, что документы Host Requirements (RFC 1122 и 1123) предполагают расчет контрольной суммы UDP по умолчанию. Также они требуют, чтобы принятая контрольная сумма обязательно проверялась, если ее рассчитал отправитель (контрольная сумма в принятом сегменте не нулевая).

В общих чертах, взаимодействие приложений на основе UDP-протокола выглядит следующим образом. Сообщение прикладного процесса упаковывается в UDP-сегмент, в заголовке которого указываются номера портов приложений, выполняющихся на конечных (взаимодействующих) станциях. Эта адресная информация на сетевом уровне дополняется IP-адресами взаимодействующих станций. Модуль сетевого протокола приемной станции, получив пакет, в адресе назначения которого указан его IP-адрес и в поле «Протокол» - код UDP, передаёт содержимое поля данных IP-пакета своему UDP-модулю. Последний проверяет наличие зарегистрированного в операционной системе приложения, связанного с номером порта, указанным в поле «Порт назначения» заголовка сегмента. Если такого приложения не оказывается, то узлу-источнику отправляется ICMP-сообщение об ошибке "Порт недоступен", а соответствующий блок данных уничтожается. Если приложение, ассоциированное с указанным номером порта, в операционной системе зарегистрировано, то транспортный протокол добавляет полученный сегмент в очередь, из которой прикладная программа читает данные. Конечно, если очередь порта уже переполнена, то сегмент уничтожается.

Протокол TCP

В этом разделе будут рассмотрены механизмы, посредством которых обеспечивается надежный, требующий предварительного установления соединения, сервис виртуального канала над дейтаграмной IP-сетью. В число этих механизмов протокола ТСР входят ARQ с возвратом на N или, в более поздних версиях, ARQ с выборочным повторением и управление потоками на основе неявной обратной связи. Протокол описан в документах RFC 793 и RFC 1122.

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

Аналогично UDP, каждый прикладной процесс для TCP-модуля представляется номером порта.Соединение между прикладными процессами отправителя и получателя однозначно определяется двумя сокетами: (IP-адрес и номера порта)_{отправителя} и (IP-адрес и номера порта)_{получателя}

Сегменты ТСР

ТСР не сохраняет границы сообщений прикладного процесса и рассматривает данные, которые поступают ему от приложения, как поток байтов. Свои сегменты транспортный протокол формирует так, как считает необходимым, но с учетом свойств протокола сетевого уровня. Формально, сегмент ТСР вместе с заголовком IP не должен превосходить 65 535 байт (ограничение величины IP-пакета). Однако, сегменты столь большого размера никогда не формируются, поскольку не всегда столько данных генерирует приложение, велики потери при нарушении целостности такого сегмента, в каждой сети, которую пересекает пакет на пути к хосту-получателю, есть ограничение максимальной величины поля данных кадра (MTU), определяемое технологией канального уровня, и превышение которой потребует нежелательного сегментирования IP пакетов. TCP-передатчик при формировании размера сегмента учитывает значение параметра MSS (Maximum Segment Size), который является конфигурационной переменной протокола; максимальное значение этого параметра может было бы вычислить в соответствии с выражением

MSS = MTU – (maxIPhdrLen + maxTCPhdrLen).

Но ценность такого способа определения величины MSS не очень велика. Действительно, хост-отправитель знает величину MTU только того сетевого сегмента, к которому принадлежит сам, и не может сформировать сегменты, размер которых гарантировал бы отсутствие необходимости фрагментации сетевых пакетов на всех участках маршрута. Если размер IP-пакета, переносящего конкретный TCP-сегмент, оказываются больше MTU очередного перехода, то IP-модуль маршрутизатора выполнит процедуру фрагментации. Эти фрагменты IP-модулем хоста-приемника собираются в исходный сетевой пакет, благодаря чему TCP-модуль приемника получит исходный транспортный сегмент. Но существуют достаточно веские причины, по которым фрагментация сегментов транспортного протокола на IP-уровне является нежелательной. Для ее предотвращения IP-модуль хоста-передатчика на этапе установления соединения должен получить указание о запрете фрагментации всех пакетов данного соединения. Последнее, в условиях отсутствия сведений о максимально допустимом на маршруте значении MTU, приводит к необходимости вспомогательного механизма адаптации значения MSS.

ТСР-передатчик, выполняя процедуры регулирования сетевой нагрузки, может формировать сегменты, размер которых будет меньше MSS. Например, если приложение передает ТСР-передатчику 1000 байт (что меньше MSS), то оно может быть представлено двумя сегментами по 500 байт, тремя по 300, 300 и 400 байт и.т.д. Эти части собираются в требуемой последовательности TCP-приемником и передаются модулю прикладного протокола.

Адаптационные механизмы протокола

Надежную доставку данных протокол ТСР обеспечивает посредством своих адаптационных механизмов. Этот протокол работает поверх сетевой среды, в которой пакеты могут теряться, дублироваться, приходить в узел назначения с нарушением порядка их отправки. Для идентификации таких нарушений в протоколе введена последовательная нумерация байтов соединения. Диапазон возможных номеров ограничен значениями от 0 до 2³²-1. Порядковый номер первого байта сегмента передается в его заголовке, и он считается порядковым номером сегмента. Начальное значение нумерующей последовательности для каждого соединениявыбирается случайным образом в период установления соединения.

Надежность передачи данных протокол ТСР обеспечивает посредством механизма ARQ с возвратом на N или с выборочным повторением и только с положительным подтверждением приема (в отличие от протокола HDLC, где используются и отрицательные подтверждения). Собственно подтверждение приема имеет накопительный характер, т.е. подтверждение приема байта с номером N означает, что все байты с номерами N-1, N-2,… также успешно доставлены.

Поскольку каждый байт сегмента оказывается пронумерованным, то достаточно просто решается задача опознания на приемной стороне нарушений последовательности доставки сегментов. Но в этой части существует проблема длины нумерующей последовательности. При скорости передачи в 100 Мбит/с полный цикл использования допустимого диапазона номеров байтов составляет не менее 5,7 минуты, что вполне достаточно для того, чтобы любой сегмент был получен приемной станцией, а все его дубликаты были уничтожены (продолжительность жизни IP-дейтаграммы, обычно, не превышает двух минут, TTL=128). Легко убедиться, что 32-разрядного поля нумерации сегментов при TTL=128 достаточно для обеспечения полного цикла нумерации при скорости передачи не более 286 Мбит/с. При более высоких битовых скоростях, принципиально возможно появление в соединении двух разных сегментов, имеющих одинаковые порядковые номера. Это может быть как следствием недостатка длины нумерующей последовательности, так и получения дубликата уже принятого ранее, но не подтвержденного сегмента (ACK на него отправителем не был получен). Ясно, что обработка этих сегментов должна быть разной. Подобная неоднозначность интерпретации сегментов с одинаковыми номерами разрешается посредством временной метки, включаемой в заголовок сегмента в момент отправки. Благодаря ее наличию, два сегмента с одинаковыми номерами будут интерпретированы как разные протокольные блоки при несовпадении их временных меток. В то же время, дубликатные сегменты передаются со значением временной метки исходного блока данных. Поэтому, два сегмента с номером N и с одинаковыми временными метками являются дубликатами. Заметим, что для работы этого механизма не требуется синхронизация сетевого времени, достаточно и того, что временные метки в последовательно отправляемых сегментах образуют возрастающую последовательность. RFC 1323 рекомендует, чтобы значение временной метки увеличивалось на единицу в диапазоне от 1 миллисекунды до 1 секунды. Для надежной работы описанного механизма в высокоскоростных сетях требуются таймеры с мелким шагом (1 мс), построение которых связано с определенными трудностями.

TCP-модуль в составе очередного сегмента отправляет то число байт, которое позволяют текущие значения окна передачи и окна приема. Когда ТСР-модуль передает сегмент с номером M, он помещает его копию в буфер повторной передачи и запускает специальный таймер; при получении подтверждения о приеме сегмента М его копия уничтожается, а значения таймера обнуляется. В противном случае, т.е. при получении сигнала о потере сегмента или по истечении таймера повторной передачи, модульTCP снова отправляет сегмент с номером M, а в определенных реализациях и все последующие переданные за M - сегментом блоки.

Передача данных в протоколе ТСР управляется механизмом скользящего окна (рис. 6.14). Регулирование величины окна передачи (W_s) имеет двоякую цель: максимально полно использовать пропускную способность соединения с одной стороны и не допустить перегрузок сети – с другой.

 

 

Для управления потоком данных передающий ТСР-модуль фиксирует значения трех указателей:

· S_last - наименьший номер еще неподтвержденных, но отправленных байтов,

· S_resent - номер последнего из отправленных байтов,

· S_last+W_s–1 – наибольший номера байта, который передающий модуль может отправить в сеть до изменения значения указателя S_last.

В свою очередь, ТСР-приемник фиксирует значения следующих указателей:

· R_last - наименьший номер принятого, но еще не переданного приложению байта,

· (R_next -1) - номер последнего подтвержденного байта,

· R_new - наибольший номер корректно принятого байта.

Обычно R_new = R_next -1. Однако, R_new может оказаться и больше R_next. Такая ситуация возникает когда приемный модуль сохраняет в своем буфере байты, принятые в сегментах, не содержащих ошибок, но пришедших с нарушением естественного порядка их следования.

Если размер буферной памяти приемного модуля равен W_R байт (максимальный размер окна приема), то всегда существует возможность принять байты с номерами, не превышающими R _last+W_R -1. При этом учитывается, что приложение не обязательно «забирает» байты немедленно после их поступления в TCP-буфер. Прибывший сегмент проверяется на целостность данных и, при положительном результате такой проверки, его байты записываются в соответствующую область памяти приемника. Если первый байт принятого сегмента имел номер R_next, то значение указателя R_next обновляется (увеличивается на число байт поля данных этого сегмента). Обновленное значение отсылается передающему приложению в качестве положительного подтверждения успешного приема всех байт с порядковыми номерами меньшими этого значения. Передающий модуль устанавливает и, тем самым, передающее окно перемещается вперед, позволяя принимать от приложения дополнительную порцию байт.

Протокол ТСР располагает возможностью управления интенсивностью потока передаваемых данных. Это управление необходимо для предотвращения переполнения приемного буфера и для недопущения перегрузки сети. Информирование передатчика о степени заполнения приемного буфера обеспечивается посредством, так называемого, объявляемого окна (advertised window). Его значение, передаваемое в специальном поле заголовка сегмента, несет информацию о доступной величине буферной памяти приемника. Эта величина определяется выражением

.

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

Для иллюстрации эффекта регулирования интенсивности генерируемого приложением потока в соответствии с возможностями приемника, рассмотрим ситуацию, когда приложение на приемной стороне прекращает читать данные из буфера своего модуля TCP. Ясно, что величина R_new будет увеличиваться, а R_last оставаться постоянной; такая динамика приводит к уменьшению величины объявляемого окна и передающий модуль TCP вынужден уменьшать размер отправляемых сегментов. В конце концов, W_A станет равным нулю и передающий модуль ТСР прекратит отправку данных. Однако, запись данных приложения в буфер передающего модуля будет продолжаться до тех пор, пока он не примет W_s байт. В этот момент работа приложения будет полностью заблокирована. Заметим также, что для предотвращения формирования малых сегментов передатчик отправляет блок данных в сеть лишь после получения от приложения некоторого числа байтов, превышающего заранее установленный порог, либо после истечения определенного интервала времени (500 мс) после отправки предыдущего сегмента.

Если величина объявляемого окна приема W_A является механизмом адаптации интенсивности потока к возможностям приемника, то величина окна передачи (W_s) выполняет функции адаптации интенсивности исходящего потока к возможностям сети. Сигналом о перегрузках в сети может служить отсутствие подтверждения приема сегмента в заданный интервал времени, или несколько подряд полученных подтверждений с неизменным значением , или увеличение времени полного оборота (неявные сигналы обратной связи). Значение W_s уменьшается под воздействием этих факторов. Ясно, что длительная работа с малым значением W_s ведет к неэффективному использованию потенциальной пропускной способности сетевого пути, поэтому исключительную важность имеет алгоритм регулирования окна передачи.

Алгоритм Tacho. Размер окна от своего минимального значения (пусть равного условной единице) увеличивается вначале достаточно быстро, но при достижении некоторого порогового значения скорость его роста существенно уменьшается. Так, например, если последняя потеря сегмента была зафиксирована при , то в следующем цикле величина W быстро увеличивается от 1 до значения (например, по закону ). После достижения указанного значения и до момента фиксации потери очередного сегмента величина W растет медленно (например, на единицу за время полного оборота). При фиксации потери, окно уменьшается до единичного значения и цикл регулирования повторяется. Иллюстрация этого процесса приведена на рис. 6.15.

На интуитивном уровне указанным фазам регулирования можно дать следующую интерпретацию. Фаза быстрого увеличения окна (называется фазой медленного старта) – это оценка «емкости» соединения, т.е. числа сегментов данных, которые могут одновременно находиться в канале между конечными узлами. Эта оценка должна быть проведена аккуратно (отсюда отказ от установления величины окна сразу в значение ), но достаточно быстро (отсюда удвоение текущего значения окна за время RTT). Фаза предупреждения перегрузки – это очень аккуратная попытка заполнить канал максимально возможным числом блоков данных (поскольку ACK-и приходят, то можно аккуратно «дозагружать» соединение).

 

 

Дальнейшим развитием алгоритма Tacho явилось ускорение начала повторной передачи. Сигналом для ускоренной повторной передачи сегмента, т.е. передачи его ранее истечения соответствующего тайм-аута (RTO), служит получение трех АСК с неизменным значением . Это заметно сокращает время «простоя» передатчика и способствует лучшему использованию пропускной способности соединения. При этом, индикация потери блока данных по истечению таймера повторной передачи также сохраняется.

Алгоритм Reno исключает фазу медленного старта и вводит быстрое восстановление окна передачи после потери. В каждом цикле алгоритм стартует при , аккуратно увеличивает окно до значения (фаза предупреждения перегрузки) и сбрасывает его к после фиксации потери пакета по трем дубликатным ACK. При определении потери блока данных по признаку истечения тайм-аута величина окна устанавливается равной 1.

В алгоритме Reno введено еще одно усовершенствование – быстрое восстановление размера окна передачи (Fast Recovery). Оно имеет целью уменьшить задержки пакетов в канале и повысить коэффициент использования его пропускной способности. Достоинством алгоритма Reno, в сравнении с Tacho, является лучшее использование пропускной способности канала в фазе повторной передачи и почти полное исключение фазы медленного старта.

Транспортный протокол ТСР в своих первых версиях использовал алгоритм, включающий медленный старт, предотвращение перегрузки и быструю повторную передачу (TCP-Tahoe). В последующей версии (TCP-Reno) было добавлено и быстрое восстановление окна передачи.

Время доставки сегментов в сетевой среде, в которой работает протокол ТСР (Интернет, например), является важным индикатором ее состояния и может изменяться в значительных пределах даже в течение времени жизни одного соединения. Поэтому выбор значения таймера повторной передачи сегментов должно быть связано с реальным значением времени доставки сегментов. В протоколе ТСР для этого предусмотрена адаптивная процедура, базирующаяся на постоянном измерении интервала времени от посылки сегмента до получения подтверждения его приема (τ _n). Это измерение обычно выполняется в отношении одно сегмента из окна отправки. Эти значения непрерывно усредняется с весовыми коэффициентами, уменьшающимися от последнего к предшествующим замерам. В результате получают значение параметра «время полного оборота» (round-trip time, t_RTT).

,

где , типичное значение . Значение таймера повторной передачи (t_out) учитывает также дисперсию значения t_RTT:

,

где k - некоторая константа. Таким образом, если девиация значений времени полного оборота значительна, то и значения таймера повторной передачи будут увеличены в сравнении со значением t_RTT. Поскольку вычисление значения стандартного отклонения относительно трудоемко, то в практически используемых процедурах оценка вариации значений t_RTT базируется на вычислении абсолютного отклонения :

,

,

при типичном значении .