Транспортный протокол TCP. RTP и RTCP: протоколы для IP-телефонии

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

Протокол IP относится к протоколам без установления соединений. Перед IP не ставится задача надёжной доставки сообщений от отправителя к получателю, он обрабатывает каждый IP-пакет как независимую единицу, не имеющую связи ни с какими другими пакетами. В протоколе IP нет механизмов, обычно применяемых для увеличения достоверности конечных данных: отсутствует квитирование, нет процедуры упорядочивания, повторных передач или других подобных функций. Если во время продвижения пакета произошла какая-либо ошибка, то протокол IP по своей инициативе ничего не предпринимает для её исправления. Все вопросы обеспечения надёжности доставки данных по составной сети в стеке TCP/IP решает протокол ТСР, работающий непосредственно над протоколом IP.

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

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

Структура IP-пакета

IP-пакет состоит из заголовка и поля данных. Заголовок, как правило, имеющий длину 20 байт, имеет следующую структуру рис.

Рис. 1. Структура заголовка IP-пакета.

Поле Номер версии (Version)указывает версию протокола IP, сейчас используется версия IPv4 и готовится переход на версию IРv6.

Поле Длина заголовка (IHL) указывает значение длины заголовка, измеренное в 32-битовых словах. Обычно заголовок имеет длину в 20 байт (пять 32-битовых слов), но при увеличении объёма служебной информации эта длина может быть увеличена за счёт использования дополнительных байт в поле Опции. Наибольший заголовок занимает 60 октетов.

Поле Тип сервиса (Type of Service) занимает один байт и задает приоритетность пакета и вид критерия выбора маршрута. Первые три бита этого поля образуют подполе приоритета пакета (Precedence). Приоритет может иметь значения от самого низкого - 0 (нормальный пакет) до самого высокого - 7 (пакет управляющей информации). Маршрутизаторы и компьютеры принимают во внимание приоритет пакета и обрабатывают более важные пакеты в первую очередь. Поле Тип сервиса содержит также три бита, определяющие критерий выбора маршрута. Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью. Установленный бит D (delay) говорит о том, что маршрут должен выбираться для минимизации задержки доставки данного пакета, бит Т - для максимизации пропускной способности, а бит R - для максимизации надёжности доставки. Во многих сетях улучшение одного из этих параметров связано с ухудшением другого, кроме того, обработка каждого из них требует дополнительных вычислительных затрат. Поэтому редко, когда имеет смысл устанавливать одновременно хотя бы два из этих трёх критериев выбора маршрута. Зарезервированные биты имеют нулевое значение.

Поле Общая длина (Total Lenth) означает общую длину пакета с учетом заголовка и поля данных. Максимальная длина пакета ограничена разрядностью поля, определяющего эту величину, и составляет 65 535 байт, однако в большинстве хост-компьютеров и сетей столь большие пакеты не используются. При передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP-пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной 1500 байт, умещающиеся в поле данных кадра Ethernet. В стандарте предусматривается, что все хосты должны быть готовы принимать пакеты вплоть до 576 байт длиной (приходят ли они целиком или по фрагментам). Хостам рекомендуется пакеты размером более чем 576 байт, только если они уверены, что принимающий хост или промежуточная сеть готовы обслужить пакет такой длины.

Поле Идентификатор пакета (Identification) используется для распознавания пакетов, образовавшихся путём фрагментации исходного пакета. Все фрагменты должны иметь одинаковое значение этого поля.

Поле Флаги (Flags) содержит признаки, связанные с фрагментацией. Установленный бит D (Do not Fragment) запрещает маршрутизатору фрагментировать данный пакет, а установленный бит М (More Fragments) говорит о том, что данный пакет является промежуточным (не конечным) фрагментом. Оставший ся бит зарезервирован.

Поле Смещение фрагмента (Fragment Offset) задаёт смещение в байтах поля данных этого пакета от начала общего поля данных исходного пакета, подвергнутого фрагментации. Используется при сборке и разборке фрагментов пакетов при передачах их между сетями с различными свойствами. Смещение должно быть кратно 8 байт.

Поле Время жизни (Time to Live) означает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни каждого пакета задаётся источником передачи и измеряется в секундах. На маршрутизаторах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается и в том случае, когда время задержки меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно считать равным максимальному числу узлов, которые разрешено пройти данному пакету до того, как он достигнет места назначения. Если параметр времени жизни станет нулевым до того, как пакет достигнет получателя, этот пакет будет уничтожен. Время жизни можно рассматривать как часовой механизм самоуничтожения. Значение этого поля изменяется при обработке заголовка IP-пакета.

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

Контрольная сумма (Header Checksum) рассчитывается только по заголовку. Поскольку некоторые поля заголовка изменяют своё значение в процессе передачи пакета по сети, контрольная сумма проверяется и повторно рассчитывается при каждой обработке IP-заголовка. Контрольная сумма - 16 бит - подсчитывается как дополнение к сумме всех 16-битовых слов заголовка. При её вычислении значение самого поля устанавливается в ноль. Если контрольная сумма не верна, то пакет будет отброшен, как только ошибка будет обнаружена.

Поле Опции (IP Options) является необязательным и используется обычно только при отладке сети. Механизм опций предоставляет функции управления, которые необходимы или просто полезны при определённых ситуациях, однако он не нужен при обычных коммуникациях. Это поле состоит из нескольких подполей, каждое из которых может быть одного из восьми типов. В этих подполях можно учитывать точный маршрут прохождения маршрутизаторов, регистрировать проходимые пакетом маршрутизаторы, помещать данные системы безопасности, а также временные отметки. Так как число подполей может быть произвольным, то в конце поля Опции должно быть добавлено несколько байт для выравнивания заголовка пакета по 32-битной границе.

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

Протокол TCP/IP (Transmission Control Protocol/Internet Protocol) в Windows NT 4.0 обеспечивает сетевое взаимодействие компьютеров под управлением Windows NT, и возможность подключения к ним сетевых устройств под управлением других ОС.

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

Протокол TCP

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

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

Приложения идентифицируют себя на компьютере посредством номера порта протокола. Например, FTP-сервер использует определенный TCP-порт, поэтому другие приложения могут связаться с ним.

Порты могут иметь любой номер от 0 до 65536. Номера портов для приложений клиентов динамически назначаются операционной системой при обработке запроса на обслуживание.

Порты протокола TCP

Порт протокола TCP указывает место доставки сообщения. Номера портов, меньшие 256, определены как широко используемые. В таблице перечислены некоторые из таких портов.

Установка связи по протоколу TCP.

Инициализация TCP-соединения происходит в три этапа. Ниже перечислены операции, из которых состоит этот процесс.

Узел-отправитель запрашивает соединение, посылая с установленным флагом синхронизации.

Узел-адресат подтверждает получение запроса, отправляя обратно сегмент с:

установленным флагом синхронизации;

порядковым номером начального байта сегмента, который он может послать, или номером последовательности;

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

3. Запрашивающий узел посылает обратно сегмент с подтверждением номера последовательности и номером своего подтверждения (рис.2).

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

Структура TCP-пакета

Все пакеты протокола TCP имеют две части - заголовок и данные. В таблице представлены поля заголовка TCP-пакета.

Протокол IP

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

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

Маршрутизация (routing) - процесс выбора пути для передачи пакетов. Маршрутизация осуществляется на узле TCP/IP в момент отправки IP-пакетов, а затем - на IP-маршрутизаторе.

Маршрутизатор (router) - это устройство, которое перенаправляет пакеты из одной физической сети в другую. Маршрутизаторы также называют шлюзами (gateways).

Поля IP-пакета приведены в таблице.

Реализация IP на маршрутизаторе.

Маршрутизатор обрабатывает полученные им IP-пакеты следующим образом:

Уменьшает значение TTL на 1 секунду или больше, если пакет надолго задерживается на маршрутизаторе.

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

2. Пакет может быть фрагментирован, если его размер слишком велик для сети дальнейшего следования

Если может быть фрагментирован, то IP создает для каждого нового пакета (фрагмента) отдельный заголовок, устанавливая:

Flag(флаг), указывающий, что существуют и другие фрагменты, которые будут отправлены в след;

Fragment ID(Идентификатор фрагмента), идентифицирующий все фрагменты, составляющие один пакет;

Fragment Offset(Смещение фрагмента), обеспечивающий правильную сборку пакета на узле-получателе.

Вычисляет новую контрольную сумму.

Определяет адрес сетевого адаптера следующего маршрутизатора.

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

Протокол управления RTP (RTCP - Real-Time Control Protocol) основан на периодической передаче пакетов управления всем участникам сеанса связи при использовании того же механизма распределения, что и протокол RTP. Протокол нижележащего уровня должен обеспечить мультиплексирование информационных и управляющих пакетов, например, с использованием различных номеров портов UDP. Протокол RTCP выполняет четыре основные функции.

Функции с первой по третью являются обязательными, когда RTP используется в IP-мультивещании, и рекомендуемыми во всех остальных случаях. Разработчикам приложений RTP рекомендуется избегать механизмов, работающих только в двустороннем режиме и не масштабируемых для увеличения числа пользователей.

4.1. Требования к пакетам RTCP

Для передачи различного рода информации управления определено несколько типов пакетов RTCP, в том числе:

• SR: отчет отправителя, для статистической информации о передаче и приеме участников, которые являются активными отправителями;
• RR: отчет получателя, для статистики приема от участников, которые не являются активными отправителями;
• SDES: пункты описания источника, включая CNAME;
• BYE: указатель завершения участия в телеконференции;
• APP: функции, определяемые приложением.

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

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

Статистика приема (в пакетах отчета отправителя SR или получателя RR) должна посылаться так часто, как позволяет полоса пропускания, чтобы максимизировать точность статистики: следовательно, в каждый составной пакет RTCP должен включаться пакет отчета.

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

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

Таким образом, все пакеты RTCP должны передаваться в составном пакете, включающем, по крайней мере, два индивидуальных пакета (SR/RR и SDES), со следующим рекомендуемым форматом.

Префикс шифрования. Если и только если составной пакет должен быть зашифрован, то ему предшествует произвольная 32-разрядная величина, повторно передаваемая в каждом составном пакете.

SR или RR. Первый пакет RTCP в составном пакете должен всегда быть пакетом отчета, чтобы облегчить проверку корректности заголовка. Это требуется, даже если никакие данные не были ни посланы, ни получены и если единственный пакет RTCP в составном пакете - это пакет BYE (тогда посылается пустой пакет RR).

Дополнительные пакеты RR. Если число источников, для которых передается статистика приема, превышает 31 (максимальное число источников, отмечаемых в одном пакете SR или RR), то за начальным пакетом отчета должны следовать дополнительные пакеты RR.

SDES. Пакет SDES, содержащий пункт CNAME, должен включаться в каждый составной пакет RTCP. Если требуется конкретным приложением, то дополнительно и другие пункты описания источника могут быть включены в пакет SDES в соответствии с ограничениями полосы пропускания (см. ).

BYE или APP. Другие типы пакетов RTCP могут следовать в любом порядке, за исключением того, что пакет BYE должен быть последним пакетом, посланным с данным SSRC/CSRC.

Для трансляторов и микшеров желательно объединять индивидуальные пакеты RTCP из множества источников, с которыми они работают, в один составной пакет всякий раз, когда это возможно, чтобы уменьшить избыточность и не передавать лишние заголовки пакета (см. раздел 5). Если полная длина составного пакета превышает величину максимального блока передачи (MTU - maximum transmission unit) сетевого пути, то составной пакет может быть сегментирован на множество более коротких составных пакетов, которые будут переданы в отдельных блоках данных протокола нижележащего уровня. Заметим, что и в этом случае каждый из составных пакетов должен начинаться с пакета SR или RR.

Приложение может игнорировать входящие пакеты RTCP с неизвестными ему типами. Дополнительные типы пакетов RTCP могут быть зарегистрированы в Сообществе назначения номеров Internet IANA (Internet Assigned Numbers Authority).

4.2. Интенсивность передачи пакетов RTCP

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

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

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

Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола - передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов, и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP, должна быть установлена равной 5%. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP, так чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.

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

Отправители коллективно используют по крайней мере 1/4 полосы пропускания трафика управления так, как в сеансах с большим количеством получателей, но с малым числом отправителей; едва установив соединение, участники в течение короткого интервала времени получают CNAME передающих сайтов.

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

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

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

Этот алгоритм может использоваться для сеансов, в которых передача пакетов допустима для всех участников. В этом случае, параметр полосы пропускания сеанса - это произведение полосы пропускания индивидуального отправителя на число участников, и полоса пропускания RTCP составляет 5% от этой величины.

4.2.1. Учет числа участников сеанса связи

Вычисление величин интервалов передачи пакетов RTCP зависит от оценки числа участников сеанса связи. Новые участники учитываются, когда они отмечаются в работе и когда для каждого в таблице создается запись с соответствующим идентификатором SSRC или CSRC (см. раздел 6.2). Новые записи не могут иметь силу, пока не будет получено множество пакетов, содержащих новый SSRC. При получении пакета BYE с соответствующим идентификатором SSRC записи из таблицы удаляются.

Участник может пометить другой сайт как неактивный или удалить соответствующую ему запись, если никаких пакетов RTP или RTCP не было получено для некоторого числа интервалов передачи отчетов RTCP (предлагается пять интервалов). Это обеспечивает некоторую устойчивость к потерям пакетов. Все сайты для того, чтобы работать правильно, должны вычислять приблизительно одну и ту же величину периода передачи отчетов RTCP в соответствии с заданным таймаутом.

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

4.2.2. Выделение полосы пропускания для пакетов описания источника SDES

В дополнение к обязательному пункту CNAME пакетов описания источника (SDES - source description) в данной статье рассмотрены и другие пункты, такие как NAME (персональное имя), EMAIL (адрес электронной почты) и т.п. Приложения должны учитывать возможность передачи дополнительных пунктов при распределении полосы пропускания RTCP, потому что это замедлит скорость, с которой будут передаваться отчеты о приеме и CNAME, таким образом, ухудшая характеристики протокола. Рекомендуется, чтобы для передачи дополнительной информации использовалось не более 20% полосы пропускания RTCP, выделенной одному участнику. Кроме того, не требуется, чтобы все пункты SDES использовались каждым приложением. За теми из них, которые включены в использование, должны быть закреплены некоторые части полосы пропускания.

Например, приложение может быть разработано так, чтобы включать в пакеты SDES только пункты CNAME, NAME, EMAIL и никаких других. Пункту NAME может быть назначен гораздо более высокий приоритет, чем пункту EMAIL, потому что NAME будет индицироваться непрерывно в интерфейсе пользователя данного приложения, в то время как пункт описания пользователя EMAIL будет показываться только по требованию. В каждом интервале RTCP посылается пакет RR и пакет SDES с пунктом CNAME. Для сеанса с малым числом пользователей, работающего с минимальным интервалом отчетности, это было бы в среднем каждые 5 секунд. Каждый третий интервал (15 секунд), один дополнительный пункт был бы включен в пакет SDES. Семь из восьми раз это будет пункт NAME, а каждый восьмой раз (2 минуты) - пункт EMAIL.

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

4.3. Пакеты отчетов отправителя и получателя (SR и RR)

Получатели RTP обеспечивают обратную связь - оценку качества приема, используя пакеты отчета RTCP, которые могут принимать одну из двух форм в зависимости от того, является получатель также и отправителем или нет. Единственная разность между формами отчета отправителя (SR - sender report) и отчета получателя (RR - receiver report), помимо кода типа пакета, - это то, что отчет отправителя включает 20-байтовый раздел информации отправителя для использования активными отправителями. SR передается, если сайт посылал любые пакеты данных в течение интервала, начиная с передачи последнего или предыдущего отчета, в противном случае передается RR.

Формы SR и RR включают нуль или более блоков отчета приема, один для каждого из источников синхронизации, от которых получатель принял пакеты данных RTP, начиная с последнего отчета. Для включаемых источников, перечисленных в списке CSRC, отчеты не выпускаются. Каждый блок отчета приема обеспечивает статистику относительно данных, полученных от конкретного источника, обозначенного в этом блоке. Так как максимум 31 блок приемных отчетов возможен в пакетах SR или RR, то дополнительные пакеты RR могут быть помещены в стек после начальных пакетов SR или RR. Это необходимо, чтобы содержать отчеты приема для всех источников, отмечаемых в течение интервала отчетности, начиная с последнего отчета.

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

4.3.1. Формат пакета отчета отправителя (SR)

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

Версия (V - version): 2 бита. Идентифицирует версию RTP, которая является одинаковой в пакетах RTCP и информационных пакетах RTP. В данной статье рассматривается протокол версии 2.

Дополнение (P - padding): 1 бит. Если бит дополнения установлен в 1, то этот пакет RTCP в конце содержит некоторые октеты дополнения, которые не являются частью информации управления. Последний октет дополнения - это счетчик дополнительных октетов, которые должны игнорироваться. Дополнение может требоваться некоторыми алгоритмами шифрования с фиксированными размерами блока. В составном пакете RTCP дополнение должно использоваться только в последнем индивидуальном пакете, потому что составной пакет шифруется в целом.

Счетчик отчетов приема (RC - reception report count): 5 бит. Число блоков отчетов приема, содержащихся в данном пакете. Нуль - возможное значение RC.

Тип пакета (PT - packet type): 8 бит. Содержит константу 200 для идентификации пакета, как пакета SR протокола RTCP.

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

SSRC: 32 бита. Идентификатор источника синхронизации для источника данного пакета SR.

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

Временная метка NTP: 64 бита. Указывает абсолютное время, когда был послан этот отчет, так, что она может использоваться в комбинации с временными метками, возвратившимися в отчетах приема от других получателей, чтобы измерить время передачи на маршруте туда и обратно для этих получателей. Получатели должны ожидать, что точность измерения временной метки может быть принята гораздо меньшей, чем разрешение временной метки NTP. Неопределенность измерения для временной метки не обозначается, поскольку она не может быть известна. Отправитель, который может следить за прошедшим временем, но не имеет данных об абсолютном времени, вместо этого может использовать время, прошедшее с начала соединения сеанса. Оно должно быть меньше, чем 68 лет, - тогда старший разряд будет иметь нулевое значение. Для оценки прошедшего абсолютного времени допустимо использование таймера дискретизации. Отправитель, который не имеет никаких данных об абсолютном или прошедшем времени, может устанавливать временную метку NTP в нуль.

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

Счетчик пакетов отправителя: 32 бита. Общее количество информационных пакетов RTP, переданных отправителем от момента начала передачи вплоть до времени генерации пакета SR. Счетчик сбрасывается, если отправитель изменяет свой идентификатор SSRC.

Счетчик октетов отправителя: 32 бита. Общее число октетов трафика (то есть октетов пакета, не включая заголовок и дополние), переданных в информационных пакетах RTP отправителем с момента начала передачи вплоть до времени генерации этого пакета SR. Счетчик обнуляется, если отправитель изменяет свой идентификатор SSRC. Это поле может использоваться для оценки средней скорости передачи трафика.

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

SSRC_n (идентификатор источника): 32 бита. Идентификатор SSRC источника, к которому относится информация в этом блоке отчета приема.

Доля потерь: 8 бит. Часть информационных пакетов RTP из источника SSRC_n, потерянных, начиная с момента отправки предыдущего пакета SR или RR, представленная в виде целого числа с фиксированной точкой без знака (в виде целой части числа после умножения доли потерянных пакетов на 256). Эта доля определяется как число потерянных пакетов, разделенное на число ожидаемых пакетов. Если величина потерь - отрицательная из-за наличия дубликатов пакетов, то доля потерь приравнивается к нулю.

Общее число потерянных пакетов: 24 бита. Общее число информационных пакетов RTP из источника SSRC_n, которые были потеряны с момента начала приема. Это число является разностью между числом пакетов, ожидаемых к получению, и числом фактически полученных пакетов. В число полученных пакетов входят любые пакеты, в том числе опоздавшие и дубликаты. Таким образом, пакеты, которые прибывают поздно, не причисляются к числу потерянных, а число потерь может быть отрицательным, если имеются дубликаты. Число ожидаемых пакетов определяется как разность последнего полученного порядкового номера и начального полученного порядкового номера.

Расширенный наибольший полученный порядковый номер: 32 бита. Младшие 16 битов содержат наибольший порядковый номер, полученный в информационном пакете RTP из источника SSRC_n, а старшие 16 битов расширяют этот порядковый номер соответствующим счетчиком циклов порядкового номера. Заметим, что различные получатели в рамках одного и того же сеанса генерируют различные расширения порядкового номера, если время начала для них значительно различается.

Джиттер прибытия: 32 бита. Это - статистическая оценка разницы относительного времени прибытия информационных пакетов RTP, измеряемая в единицах временной метки и выражаемая целым числом без знака. Джиттер прибытия J определяется как средняя величина (сглаженное абсолютное значение) разности D времени между поступлениями двух пакетов получателю и времени между моментами передачи этих пакетов. Как показано в уравнении ниже, это эквивалентно разности относительного времени передачи для двух пакетов (относительное время передачи - это разность между временной меткой пакета RTP и значением таймера получателя во время поступления, выраженным в тех же самых единицах).

Если Si - это временная метка RTP из пакета i, а Ri - время поступления в единицах временной метки RTP для пакета i, то для двух пакетов i и j, D может быть выражено как

D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si).

Джиттер прибытия вычисляется непрерывно по мере того, как каждый информационный пакет i поступает от источника SSRC_n, с использованием этой разности D для этого пакета и предыдущего пакета i-1 в порядке поступления (не обязательно в последовательности передачи), согласно формуле

J=J+(|D(i-1,i)|-J)/16.

Всякий раз, когда передан отчет приема, определяется текущая величина J. Вычисление джиттера, описанное здесь, позволяет независимым от профиля мониторам делать корректные интерпретации отчетов, поступающих от различных реализаций. Этот алгоритм является оптимальным оценивателем первого порядка, и весовой коэффициент 1/16 дает хороший коэффициент уменьшения шума при поддержании приемлемой скорости сходимости.

Временная метка последнего SR (LSR): 32 бита. Средние 32 бита из 64 битов временной метки NTP (как показано в разделе 2.4), полученные как часть самых последних пакетов отчетов отправителя RTCP (SR) из источника SSRC_n. Если SR еще не был получен, то временная метка LSR имеет нулевое значение.

Задержка с момента последнего SR (DLSR): 32 бита. Задержка в приемнике пакетов, выраженная в единицах, равных 1/65536 секунды, между получением последнего пакета SR из источника SSRC_n и посылкой этого блока отчета о приеме. Если пакет SR еще не был получен от SSRC_n, то поле DLSR имеет нулевое значение.

С помощью значений временной метки последнего SR (LSR) и задержки в приемнике с момента последнего SR (DLSR) источник SSRC_n может вычислять задержку распространения пакетов на пути к получателю SSRC_r и обратно (круговую задержку). При поступлении отчета приема источник SSRC_n фиксирует время этого события Т. Затем он вычисляет общее время двойного прохода Т-LSR с использованием поля временной метки последнего SR (LSR) и вычитает задержку DLSR, в результате получая время распространения пакета туда и обратно (Т-LSR-DLSR). Это может использоваться как приблизительная мера расстояния до кластера получателей, хотя некоторые линии имеют очень асимметричные задержки. отчета

Формат пакета отчета получателя RR (receiver report) такой же, как и формат пакета SR, за исключением того, что поле типа пакета содержит константу, равную 201, а пять слов информации отправителя отсутствуют (временные метки NTP и RTP и счетчики пакетов и октетов отправителя). Оставшиеся поля имеют то же самое значение, что и для пакета SR.

Когда нет никакой передачи данных или приема, о которых можно было бы сообщить, во главу составного пакета RTCP помещается пустой пакет RR (RC = 0).

4.3.3. Расширение отчетов отправителя и получателя

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

• меньше октетов в пакете (не требуется ни заголовка RTCP, ни поля SSRC);
• более простой и быстрый анализ, потому что приложения, выполняющиеся в соответствии с данным профилем, могут программироваться так, чтобы всегда рассматривать поля расширения в непосредственно доступном месте после отчетов приема.

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

4.3.4. Анализ отчетов отправителя и получателя

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

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

Рассмотрим пример вычисления интенсивности потерь пакета на интервале между двумя отчетами приема. Разность значений кумулятивных счетчиков потерянных пакетов дает количество пакетов, потерянных в течение этого интервала. Разность в последних полученных расширенных порядковых номерах дает число пакетов, ожидаемых в течение интервала. Отношение этих двух величин - это доля потерь пакетов на интервале. Это отношение должно равняться значению поля доли потерь, если эти два отчета являются последовательными, в противном случае - нет. Число потерь пакетов за 1 секунду может быть получено путем деления доли потерь на разность временных меток NTP, выраженную в секундах. Количество полученных пакетов - это число ожидаемых пакетов минус число потерянных. Количество ожидаемых пакетов может также использоваться для определения статистической достоверности любых оценок потерь. Например, потеря одного пакета из пяти имеет более низкую представительную ценность, чем потеря 200 пакетов из 1000.

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

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

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

1. TCP протокол семейства TCP/IP

TCP - это один из самых широко используемых протоколов транспортного уровня. IP не предполагает установление соединения. Он просто передает дейтаграмму от узла к узлу, а при каком-либо нарушении она просто отбрасывается, о чем отправитель уведомляется ICMP-сообщением. Проверка принятых данных и повторная передача данных, не дошедших до получателя, ложится на TCP. Он следит за доставкой данных протоколом IP.
Главная функция TCP заключается в доставке сообщений без потерь. Для этого предварительно устанавливается соединение между приложением-отправителем и приложением-получателем, осуществляя надежную доставку дейтаграмм. Именно TCP производит повторную передачу искаженного или утерянного пакета.
TCP регламентирует передачу данных с прикладного уровня на уровень межсетевого взаимодействия и обратно. TCP должен отвечать за соблюдение приоритетов и защиту данных, за завершение приложения на более высоком уровне, ожидающего дейтаграммы, за обработку ошибок нижних уровней. за ведение таблиц состояний для всех потоков как в самом TCP, так и на других уровнях. Выделение всех этих функций в отдельный уровень освобождает разработчиков прикладных программ от решения задач управления потоком и обеспечения надежности передачи данных. Без TCP перечисленные функции пришлось бы реализовывать в каждой прикладной программе.
TCP является протоколом, ориентированным на соединение, обеспечивая сквозную передачу данных от машины-отправителя машине-получателю. Поскольку в нем применяется соединение, адресат, получивший дейтаграмму, должен уведомить отправителя об этом. Обычно используется термин виртуальный канал, чтобы указать, что машина-отправитель и машина-получатель обмениваются сообщениями, большинство из которых являются подтверждениями о получении или кодами ошибок.
TCP получает поток байтов и собирает его в пакеты, называемые также сегментами, добавляя заголовки в начало сегментов. В заголовок записывается контрольная сумма и порядковый номер пакета данных. Длина сегмента обычно определяется TCP или выбирается администратором системы. (В большинстве случаев длины сегмента TCP и дейтаграммы IP никак не связаны друг с другом.)
Процесс установления соединения начинается с передачи запроса на установления соединения от машины-отправителя машине-получателю. В запросе содержится число, называемое номером сокета. В ответ приложение-получатель посылает номер своего сокета. Номера сокетов отправителя и получателя однозначно определяют соединение между приложениями.
После установления соединения TCP начинает передавать сегменты сообщения IP-модулю, который преобразует каждый из них в одну или несколько дейтаграмм. Эти операции производятся без какого-либо участия TCP. Пройдя через сеть от машины-отправителя к машине-получателю, дейтаграммы поступают к IP-уровню последней. Он собирает из них отправленный сегмент и передает его TCP. В свою очередь сообщение от TCP поступает к приложению-получателю через используемый протокол прикладного уровня.
Если сообщение состоит из нескольких ТСР-сегментов (не путайте с IP-дейтаграммами), TCP на машине-получателе собирает его, исходя из порядковых номеров сегментов, хранящихся в заголовке. Если сегмент утерян или поврежден (последнее обнаруживается с помощью контрольной суммы в заголовке сегмента), отправителю посылается сообщение, содержащее порядковый номер ошибочного или потерянного сегмента. В этом случае отправитель повторно передает сегмент.
Если сообщение состоит только из одного сегмента TCP, то после сравнению полученной и вычисленной контрольных сумм программное обеспечение TCP на машине-получателе посылает отправителю подтверждение-квитанцию (АСК - acknowledgement). Выдача квитанции в ответ на принятый сегмент называется квитированием.
Как и для большинства протоколов с установлением соединения, важную роль в TCP играют таймеры. Сообщение считается переданным не полностью, если квитанция не поступила в течение заданного периода ожидания. Тем самым сокращаются затраты времени на бесполезное ожидание подтверждения в случае потери данных. При этом обычно производится повторная передача соответствующих сегментов.
В TCP не предусмотрена передача квитанции, если сегмент доставлен искаженным. Пропажу сегмента обнаруживают с помощью таймера повторной передачи: если квитанция на сегмент не поступила вовремя, он считается потерянным и передается повторно.
Вместе с тем применение таймеров обусловливает ряд проблем. Согласно протоколу TCP, квитанция на принятый сегмент выдается только после поступления всех отправленных ранее сегментов того же сообщения. Иначе говоря, квитанция подтверждает получение всех ранее отправленных сегментов сообщения. Так как сегменты доставляются машине-получателю в произвольном порядке, выдача квитанции может задержаться до получения всего сообщения, а это в свою очередь может привести к повторной передаче правильно принятых сегментов.
Повторно доставленные копии сегментов, отправленные из-за истечения установленного времени ожидания квитанций, отбрасываются программным обеспечением машины-получателя. При этом уведомление отправителю не высылается, так как ему важно лишь знать, что сегмент получен.
В передающей машине данные, получаемые программным обеспечением TCP от прикладного уровня, накапливаются в буфере. Момент их упаковки в сегмент обычно определяется на уровне TCP. Данные из буфера могут быть также отправлены в срочном порядке по требованию обслуживаемого процесса прикладного уровня. Эта операция называется выталкиванием. Ее применение вызывается установкой специального флажка в заголовке протокола прикладного уровня.

2. Порты и сокеты

Приложение, использующие TCP (или UDP), однозначно определяется некоторым числом, которое называется номером порта. В принципе номера портов можно выбирать произвольно, но для облегчения взаимодействия между различными реализациями программного обеспечения TCP, приняты соглашения о номерах портов, закрепленных за определенными службам.
Как правило, порты между 0 и 255 отводят системным процессам, а порты выше 255 - пользовательским. В Internet распределением портов занимается Управление Internet по нумерации (Internet Assigned Numbers Authority, IANA). Список номеров портов для служб Internet может быть найден в соответствующем рабочем предложении (RFC). Выдержки из него приведены в таблице. Порты 0 и 255 зарезервированы.

Любой канал связи в слое TCP однозначно определяется двумя числами, эта комбинация называется сокетом. Сокет определяется IP-адресом машины и номером порта, используемым программным обеспечением TCP. При соединении любая машина однозначно определена IP-адресом, а каждый выполняющийся процесс - портом, таким образом, соединение между двумя / процессами однозначно определяется сокетом.

3. Таймеры TCP

Таймеры нужны для того, чтобы избежать чрезмерных задержек и состояний ожидания. Они позволяют легко обойти некоторые подводные камни при передаче данных. Роль различных таймеров, используемых TCP, в передаче данных рассматривается в последующих разделах.
Таймер повторной передачи. Таймер повторной передачи отмеряет время ожидания квитанции на отправленный сегмент (retransmission timeout, RTO). Этот параметр устанавливается с учетом типа сети и скоростей доставки сообщений. Если квитанция не поступает вовремя, сегмент отправляется вновь, а период повторной передачи увеличивается по экспоненциальному закону. Так повторяется несколько раз пока период повторной передачи не достигнет некоторого заданного предела, после чего обслуживаемому процессу выдается сообщение об ошибке.
Начальное время ожидания квитанции путем устанавливается измерения времени между отправлением сегмента и получением квитанции на него. Эта величина называется временем двойного прохода. Математическое ожидание (то есть среднее значение) измеренных значений называется сглаженным временем двойного прохода. Оно вычисляется по формуле и может быть увеличено, чтобы учесть непредвиденные задержки.
Таймер задержки. Получателю могут поступать сегменты и после того, как соединение было им закрыто. Таймер задержки (quiet timer) исключает повторное открытие только что закрытого порта, вызываемое прибывшими сегментами. Длительность задержки обычно выбирают равной удвоенному значению максимального времени жизни сегмента (оно совпадает со значением поля времени жизни в заголовке IP-дейтаграммы). Задержка может достигать 30 секунд. В ответ на каждый пришедший в этот период сегмент, отправляется сообщение об ошибке.
Таймер запросов. Таймер запросов (persistence timer) предусмотрен для такого довольно редкого случая, когда получатель, приостановивший передачу данных путем посылки сегмента с нулевым размером окна, отправляет своему партнеру сообщение о возобновлении работы, но тот его не получает. Чтобы продолжить передачу, отправитель с периодом, задаваемым таймером, посылает запросы с одним байтом данных. В ответ на них он получает сегменты, где указан размер окна. Если размер окна нулевой, адресат по-прежнему занят, а если нет, то он готов принимать полезную информацию, после чего передача данных возобновляется. Период повторения запросов определяются таймером запросов.
Таймер контроля и таймер разъединения. Эти таймеры предназначены для проверки соединения. Таймер контроля (keep-alive timer) вызывает периодическую выдачу сегментов без поля данных, а таймер разъединения (idle timer) задает максимальное время ожидания ответа. По истечении этого срока соединение считается разорванным.
Как правило период таймера контроля устанавливается на прикладном уровне, его значения лежат между 5 и 45 секундами. Максимальное время ожидания обычно принимается равным 360 секундам.

4. Сегменты данных протокола TCP

TCP взаимодействует с нижележащим уровнем по протоколу IP и с прикладным уровнем, расположенным выше, с помощью сервисных примитивов. Кроме того он должен взаимодействовать с программным обеспечением TCP на других машинах. Для последней задачи используются протокольные блоки данных, которые на языке TCP называются сегментами. Заголовок сегмента состоит из следующих полей:
Порт отправителя (Source Port), 16-разрядное поле, идентифицирующее локальный порт-источник (обычно это пользовательский процесс прикладного уровня).
Порт получателя (Destination Port), 16-разрядное поле с номером порта-получателя
Позиция сегмента (Sequence Number). Поле содержит порядковый номер j первого байта данных сегмента в сообщении.
Первый ожидаемый байт (Acknowledgement Number). Используется 1 тогда, когда сегмент служит квитанцией (флаг АСК=1). Содержит по- / рядковый номер первого ожидаемого байта. Все байты сообщения с меньшими порядковыми номерами считаются квитированными.
Смещение данных (Data Offset). Длина заголовка, измеренная в 32-раз- / рядных словах. Служит указателем на начало поля данных.
Резерв (Reserved). Пока не используется и должно быть обнулено. Размер поля 6 бит.
Флаги. В состоянии 1 они означают следующее.
Флаг URG. Поле срочности данных подлежит обработке. Флаг АСК. Сегмент служит квитанцией.
Флаг PSH. Сегмент должен быть "вытолкнут" - послан в первую очередь.
Флаг RST. Сегмент служит запросом на установку первоначальных параметров соединения.
Флаг SYN. Сегмент служит для синхронизации счетчиков переданных данных при установлении соединения.
Флаг FIN. Означает, что отправлен последний байт сообщения. Эквивалент маркера конца передачи (EOT) в кодировке ASCII.
Размер окна (Window). Указывает, сколько байтов готов принять получатель.
Контрольная сумма (Checksum), 16-разрядная контрольная сумма определяется для блока данных, состоящего из псевдозаголовка и самого сегмента, 96-разрядный псевдозаголовок, предшествует заголовку TCP и создается в процедуре вычисления контрольной суммы. Псевдозаголовок содержит IP-адрес отправителя, IP-адрес получателя, идентификатор протокола и длину сегмента. Эти параметры передаются IP при отправке сегмента и используются протоколом IP при его получении. Процедура подсчета контрольной суммы занимает довольно много времени.
Указатель срочности данных (Urgent Pointer). Используется, когда флаг URG=1. Представляет собой смещение относительно номера последовательности в заголовке. Специальная обработка срочных данных производится на прикладном уровне, а не на уровне TCP.
Опции (Options). Подобно одноименному полю в IP-заголовке каждая опция содержит свой номер (один байт), свою длину в байтах и значение. В настоящее время имеется только три опции:
О - Конец списка опций (End of Option List);
1 - Отсутствие операции (No Operations);
2 - Максимальный размер сегмента (Maximum Segment Size).
Заполнитель (Padding). Дополняет заголовок до целого числа 32-разрядных слов.
За заголовком следует поле данных, длина которого не фиксирована. Благодаря опции Максимальный размер сегмента программное обеспечение TCP получателя может выбрать подходящий размер буфера данных.

5. Соединение по протоколу TCP

Обмен данными по протоколу TCP регулируется многочисленными правилами. Процедуры установления соединения, передачи полезной информации и разрыва соединения обычно представляют конечными автоматами. (TCP - это протокол, управляемый состояниями, и потому его операции зависят от состояний флагов или аналогичных структур). Вместо них я буду использовать простые схемы взаимодействия.
Существует два варианта установления соединений: собственно соединение и принятие соединения. Перед запуском соединения необходимо инициализировать и запустить WSA - Windows Socket Architecture. Выполним для этого функцию
1. WSAStartup (wVersionRequested, lpWSAData): Integer;

где:
wVersionRequested - необходимый номер версии для запуска приложения. В нашем случае этот параметр должен быть равен $0101.
lpWSAData - сруктура, в которой разъём WSA возвращает: номер версии, описание, статус, максимальное количество разъёмовсокетов, информация разработчика и т. д. Эта структура значения для нас не имеет.
Код ошибки, прозошедшей в случае неудачного выполнения любой функции, связанной с разъёмами сокетами можно получить с помощью функции WSAGetLastError. Расшифровка этих кодов находится в файле sock.hlp, входящем в поставку Delphi.

Вариант "Соединение"
Прежде чем соединять разъёмы,сокеты, нужно создать разъём сокет функцией
2. Socket (af, type, protocol) : Integer;

где:
af - семейство адресов, в нашем случае af:= PF_INET.
type - тип разъёма сокета (SOCK_STREAM, базирующийся на семействе адресов TCP и ориенти рованный на соединения и SOCK_DGRAM, базирующийся на семействе адресов UDP и работающий без соединений (используем SOCK_STREAM, т. к., он более надежный)).
protocol - параметр, определяющий некоторые особенности протокола, в нашем случае - 0.
После выполнения функция возвращает значение типа Integer, который является указателем на новый разъёмсокет. Далее, следует становить опции структуры TSockAddrIn, в которой содержится информация о соединении. У этой структуры много полей, нас же интересуют только три из них:
sin_family - содержит имя семейства адресов. Этот параметр аналогичен af.
sin_port - адрес номер порта, через который идет обмен с разъёмомсокетом. Адрес порта должен быть больше 1024, т. к. меньшие значения зарезервированы для существующих приложений. Номер порта должен быть задан в так называемом сетевом формате, когда старшие байты идут по младшим адресам. Это отличается от принятом в x86 (Intel) архитектуре хранении, поэтому необходимо выполнить преобразование с помощью функции htons() из формата данной архитектуры в сетевой (htons расшифровывается, как Host To Network, Short (т.е. 16-бит)). Обратный перевод можно выполнить с помощью функции ntohs().
sin_addr - у этого поля есть подполе s_addr: integer, которому мы должны присвоить значение функции inet_addr(iAddr). Эта функция преобразует строковый адрес IP в 4-байтовое число, т. е., iAddr - адрес компьютера, с которым мы хотим связаться. Получить адрес можно, выполнив на искомом компьютере команду NETSTAT -r. Адрес также должен быть представлен в сетевом формате, однако функция inet_addr() уже возвращает результат в сетевом формате и выполнять преобразование в этом случае не нужно. Если это необходимо выполнить, то можно использовать функции htonl() и ntohl(). Примечание: при передаче по сети данных в двоичном формате следует помнить о разной интерпретации порядка байт в слове на различных архитектурах и преобразовывать данные в сетевой формат.
Теперь, когда мы заполнили структуру адреса, выполняем функцию
3. Connect(Sock, SA, SASize): Integer;

где:


SASize - размер SA.
Если в результате выполнения Connect"a возвратился SOCKET_ERROR, то функция выполнилась неправильно. (см. Пример) В противном случае, возвращается 0.
После установления соединения можно применять функции приема и пересылки данных, такие, как recv, send.
Функция коннект через API посылает сообщение к драйверу протокола ТСР, а тот, в свою очередь, через протоколы нижнего уровня посылает инициализационный пакет компьютеру-адресату для установления соединения. Функция завершается, когда соединение установлено.
4. Recv(Sock, Buf, BufSize, Flags) : Integer;

где:
Sock - результат выполнения функции Socket.
Buf - буфер, куда попадут принятые данные.
BufSize - размер буфера.
Flags - флаги. Может иметь значения MSG_PEEK или MSG_OOB. Установим это поле в 0.

5. Send(Sock, Buf, BufSize, Flags) : Integer;

где:
Sock - результат выполнения функции Socket.
Buf - буфер посылаемых данных.
BufSize - размер буфера.
Flags - флаги. Равно 0.
Если не произошло ошибки, возвращается количество принятых байт, если произошло корректное закрытие соединения - 0, иначе в случае разрыва - возвращается отрицательное число.
Для завершения работы соединения применим функцию
6. CloseSocket(Sock) : Integer;

где:
Sock - результат выполнения функции Socket.

Вариант "Принятие cоединения"
Другим вариантом установления соединения является его принятие. Вообще говоря, в любом соединении должны присутствовать оба варианта - соединения и приема соединения (один компьютер является сервером, он выполняет прием, друго клиентом, он инициирует прием) . Порядок действий по инициализации сервера такой же, как и у клиента, с той разницей, что:
вместо адреса другого компьютера в структуру TSockAddrIn мы заносим свой адрес или "0.0.0.0" для принятия всех приходящих соединений.
вместо Connect"a выполняем функци:
7. Bind(Sock, SA, SASize) : Integer;

где:
Sock - результат выполнения функции Socket.
SA - заполненная нами структура TSockAddrIn.
SASize - ее размер.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
Эта функция привязывает наш разъём сокет к указанному нами адресу.
8. Listen(Sock, Backlog) : Integer;

где:
Sock - результат выполнения функции Socket.
Backlog - максимальный размер очереди ожидающих соединений.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
Эта функция устанавливает разъём сокет в режим прослушивания канала.
9. Accept(Sock, SA, SASize) : Integer;

где:
Sock - результат выполнения функции Socket.
SA - заполненная нами структура TSockAddrIn.
SASize - размер SA.
Если в результате выполнения Accept"a возвратился SOCKET_ERROR, то функция выполнилась неправильно. (см. Пример) В противном случае, возвращается 0.
После установления соединения можно применять функции приема и пересылки данных, такие, как recv, send. Функция завершается, когда устанавливается соединение.

После соединения
После соединения можно приступать к обмену информацией с помощью вышеуказанных функций recv и send. Можно также добавить, что разъёмы сокеты классифицируются, как блокирующиеся и неблокирующиеся. Первые ждут окончания операции, вторые - не ждут.
Для установки разъёмов сокетов в неблокируемое состояние используют функцию:
ioctlsocket(Sock, CMD, Value) : Integer;

где:
Sock - результат выполнения функции Socket.
CMD - команда управления разъёмом сокетом (в нашем сучае - константа FIONBIO).
Value - ее значение 0 - вкл, 1 - выкл.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
При непосредственной работе с разъемами сокетами вы далеко не всегда получите на приёмнике именно то количество байт, которое посылали, и вы должны через некоторое время "дочитать" байты из разъёмасокета. Это объясняется принципом организации потоковых разъемовсокетов, которые воспринимаются в данном случае как файлы. Можно, однако отключить алгоритм NAGLE, который управляет разбиением сообщений на дейтаграммы с помощью следующей функции:
setsockopt(Sock, Level, Parameter, PChar(Value), ValueSize) : Integer;

где:
Sock - результат выполнения функции Socket.
Level - уровень команды.
Parameter - команда управления разъёмом сокетом (в нашем сучае - константа TCP_NODELAY).
Value - ее значение (0 - вкл, 1 - выкл).
ValueSize - размер Value.
Если не произошло ошибок, возвращается 0, иначе - SOCKET_ERROR.
Определить адрес корреспондента можно из структуры TSockAddrIn после выполнения команды accept (см. Выше) либо с помощью функции getpeername (см. Delphi sock.hlp).
Определить имя компьютера по адресу можно с помощью функции GetHostByAddr (см. Delphi sock.hlp).

В процессе передачи размер окна варьируется. По значению W можно определить готовность принятия данных. Если W=0, то окно не принимает. Через определенный период t таймер повторения запросов посылает полноценный сегмент с размером 1 байт и ждем подтверждения. Если принимающая сторона готова к приему, то она отправляет на этот байт положительную квитанцию с размером окна > 0.

Используется механизм таймаута. Размер ожидания положительной квитанции фиксируется значением времени двойного оборота. Timeout=2 ср.зн.t двойного оборота = 2τ.

• Структура заголовка сегмента протокола tcp

  Порт отправитель 16									Порт приемник 16
  Позиция сегмента 32											Псевдо-заголовок (96)
  Первый ожидаемый байт 32
  Смещение 4								Размер окна 16
  Контрольная сумма 16									Указатель важности данных 16
  Опции и заполнитель

Позиция сегмента – порядковый номер первого байта данных в исходном сообщении.

Первый ожидаемый байт – поле задает порядковый номер того байта, который ожидает принимающая сторона, одновременно подтверждая правильность приема байтов с меньшими номерами. Данное поле заполняется только тогда, когда сегмент положительной квитанцией. Флаг ASK будет при этом равен единице.

Смещение данных – задает длину заголовка в 32-х разрядных словах.

Резервное поле – не используется. Содержимое – нули.

Флаги – эти поля активны, когда в них единица

• URG=1 – указатель важности данных. Если в полученном сегменте URG=1, то принимающая сторона должна принять «важные» данные, независимо от того, что буфер может быть заполнен.

  ASK=1 – данный сегмент является положительной квитанцией

  PCH=1 – указатель срочности данных. Данные сегмента должны быть переданы а первую очередь.

  RST=1 – сегмент служит запросом для установление соединения и его первоначальных параметров.

  SYN=1 – сегмент служит для синхронизации счетчиков передаваемых данных.

  FIN=1 – сегмент является последним в передаваемом сообщении.

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

Контрольная сумма – определяется для всего сегмента (включая данные, псевдозаголовок и IP адреса отправителя и получателя). Разрядность псевдозаголовка = 96.

Указатель важности данных – заполняется только тогда, когда флаг URG=1. Данные будут обрабатываться только на прикладном уровне.

Опции и заполнитель (дополнитель) – опции используются для согласования параметров устанавливаемого соединения (размер сегмента, размер окна итд). Опции не ограничены в размерах, поле дополнитель дополняет опции до 32-х разрядного слова.

• Сети х.25

Сети х.25 – это самые распространенные сети с коммутацией пакетов. Изначально был разработан стек протоколов Х.25, от которого и появилось название сетей. Протокол был разработан в 1974 году международным консультативным комитетом по телефоии и телеграфии (МККТТ).

В 1984 этот протокол был занесен в «Красную книгу», то есть принят как ISO – стандарт

С тех пор каждые 4 года данный стандарт рассматривался без значительных изменений.

Данная технология получила распространение по двум причинам:

Долгое время Х.25 были единственные доступные сети с коммутацией пакетов коммерческого типа.

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

ЦКП – центр коммутации пакетов

PAD – сборщик-разборщик пакетов. Является удаленным.

М-М – модем

М (который отдельно) - маршрутизатор

К – компьютер

* - встроенные сборщик-разборщик пакетов

** - телефонная сеть

Сборщик-разборщик пакетов (СРП) поддерживает 8, 16, 24, 32 и 64 асинхронных терминалов.

Терминал как правило выходит -> на обычную телефонную сеть и далее -> к СРП через специальный интерфейс RS-232C

Основные функции, регламентированные протоколом Х.3:

Установление и разъединение сети Х.25 с нужным ресурсом

Сборка байтов или символов от низкоскоростных терминалов в пакеты необходимой длины и передача их в сеть

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

Как уже было отмечено ранее, главная задача транспортного уровня заключается в пере­даче данных между прикладными процессами. Эту задачу решают протокол управ­ления передачейTCP (Transmission Control Protocol) и протокол пользовательских дейтаграмм UDP (User Datagram Protocol). Протоколы TCP и UDP имеют много общего. Тот и другой обеспечивают интерфейс с вышележащим прикладным уровнем, передавая дан­ные, поступающие на входной интерфейс хоста, соответствующему приложению. При этом оба протокола используют концепции «порт» и «сокет». Оба они так­же поддерживают интерфейс с нижележащим сетевым уровнем IP, упаковывая свои пакеты в IP-пакеты.

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

Существует и обратная задача: пакеты, которые отправляют в сеть разные при­ложения, работающие на одном конечном узле, обрабатываются общим для них протоколом IP. Следовательно, в стеке должно быть предусмотрено средство «сбора» пакетов от разных приложений дляпередачи протоколу IP. Эту работу выполняют протоколы TCP и UDP.

Процедура приема протоколами TCP и UDP данных, поступающих от несколь­ких различных прикладных служб, называется мультиплексированием. Обрат­ная процедура – процедура распределения протоколами TCP и UDP поступающих от сетевого уровня пакетов между набором высокоуровневых служб – называется демультиплексированием .

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

Если процессы представляют собой популярные общедоступные службы (например, FTP, telnet, HTTP, DNS и т. п.), то за ними закрепляются стандарт­ные, назначенные номера, также называемые хорошо известными (well-known) номерами портов .Эти номера закрепляются и публикуются в стандартах Ин­тернета RFC. Так, номер 21 закреплен за службой удаленного доступа к файлам FTP, a 23 – за службой удаленного управления telnet. Назна­ченные номера являются уникальными в пределах Интернета и выделяются приложениям централизованноиз диапазона от 0 до 1023.

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

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

Нет никакой зависимости меж­ду назначением номеров для приложений, использующих протокол TCP, и при­ложений, работающих с протоколом UDP. Приложения, которые передают дан­ные на уровень IP по протоколу UDP, получают номера, называемые UDP-портами. Аналогично приложениям, обращающимся к протоколу TCP, выделя­ются ТСР-порты.

В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, из которых выделяются номера TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65535 для динамических. Однако никакой связи между назначенными номерами TCP- и UDP-портов нет. Даже если номера TCP- и UDP-портов совпадают, они идентифицируют разные приложения. Например, одному приложению может быть назначен ТСР-порт 1750, а другому – UDP-порт 1750. В некоторых случаях, когда приложение может об­ращаться по выбору к протоколу TCP или UDP (например, таким приложением является DNS), ему, исходя из удобства запоминания, назначаются совпадаю­щие номера TCP- и UDP-портов (в данном примере – это номер 53) .

2.5.1 Протокол UDP

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

Заголовок UDP, состоящий из четырех 2-х-байтовых полей, содержит номера пор­тов отправителя и получателя , контрольную сумму и длину дейтаграммы (рис.2.11) .