Многие владельцы Android девайсов от Samsung жалуются, что у них возникают...
Протокол управления 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.
Из информации отправителя монитор третьей стороны без получения данных может вычислять среднюю на интервале скорость передачи трафика и среднюю частоту передачи пакетов. Отношение этих двух величин дает средний размер поля данных. Если вероятность потери пакета не зависит от его размера, то число пакетов, принятых конкретным получателем, умноженное на средний размер поля данных (или соответствующий размер пакета) дает производительность этого получателя.
В дополнение к кумулятивным счетчикам, которые обеспечивают определение потерь пакетов на протяжении длительных интервалов времени на основе разницы в отчетах, поле доли потерь обеспечивает краткосрочное измерение на базе одного отчета. Это становится более важным по мере роста числа участников телеконференции, поскольку информация о состоянии приема может не обеспечиваться для всех получателей, а интервал между отчетами становится достаточно длительным.
Поле джиттера прибытия обеспечивает второй краткосрочный критерий оценки перегрузки сети. Потери пакета отслеживают устойчивую перегрузку, в то время как на основе джиттера может прослеживаться кратковременная перегрузка. Критерий джиттера может указывать на перегрузку прежде, чем это приведет к потерям пакетов. Так как поле джиттера прибытия содержит только мгновенный срез джиттера в момент формирования отчета, может быть необходим анализ нескольких отчетов, поступивших от одного получателя через какое-то время или от множества получателей, например, внутри одной сети.
Протокол управления передачей (Transmission Control Protocol - TCP) обеспечивает надежную передачу данных в среде IP. TCP относится к транспортному уровню эталонной модели OSI (4-й уровень). TCP предоставляет такие службы, как потоковая передача данных, надежность, эффективное управление потоком, дуплексный режим и мультиплексирование.
При потоковой передаче данных TCP передает неструктурированный поток байтов, идентифицируемых по порядковым номерам. Эта служба полезна для приложений, поскольку им не приходится разбивать данные на блоки перед их передачей по протоколу TCP. TCP группирует байты в сегменты и передает их на уровень протокола IP для пересылки.
Надежность TCP обеспечивается сквозной, ориентированной на соединение, передачей пакетов по объединенной сети. Она достигается упорядочением байтов при помощи номеров подтверждения передачи, по которым получатель определяет, какой байт должен поступить следующим. Байты, не получившие подтверждения в течение определенного времени, передаются заново. Надежный механизм протокола TCP позволяет устройствам обрабатывать потерянные, задержанные, дублированные и неверно прочитанные пакеты. Механизм лимита времени позволяет устройствам распознавать потерянные пакеты и запрашивать их повторную передачу.
TCP обеспечивает эффективное управление потоком. При отправке подтверждений источнику данных принимающий TCP-процесс указывает наибольший порядковый номер, который он может принять без переполнения внутренних буферов.
В дуплексным режиме TCP-процесс может одновременно пересылать и принимать пакеты.
Наконец, мультиплексирование TCP означает одновременную передачу по одному соединению нескольких диалогов верхнего уровня.
Установка ТСР-соединения
Для использования надежных транспортных служб TCP-узлы должны устанавливать друг с другом сеансы, ориентированные на соединение. Установка соединения выполняется по механизму, называемому трехэтапной синхронизацией (three-way handshake).
Этот механизм синхронизирует обе стороны соединения, позволяя им согласовать начальные порядковые номера. Он также обеспечивает готовность обеих сторон к передаче данных и информированность каждой из сторон о готовности другой. Это необходимо во избежание передачи или повторной передачи пакетов в процессе установки сеанса или после его разрыва.
Каждый узел выбирает случайным образом порядковый номер, чтобы следить за приемом и передачей байтов потока. Затем механизм трехэтапной синхронизации работает следующим образом.
Первый узел (Узел А) инициирует соединение, отправляя пакет с начальным порядковым номером и битом синхронизации SYN для индикации запроса соединения. Второй узел (Узел В) получает SYN, записывает порядковый номер X и отвечает подтверждением SYN (вместе с АСК = X + 1). Узел В указывает собственный порядковый номер (SEQ = Y). Тогда, если АСК равен 20, то это означает, что узел принял байты с 0 по 19 и ожидает следующий байт 20. Эта технология называется подтверждением передачи. Затем Узел А подтверждает прием всех байтов, посланных Узлом В с подтверждением передачи, указывая следующий байт, который Узел А ожидает получить (АСК = Y + 1). После этого может начинаться передача данных.
Подтверждение приема и повторная передача
Простой транспортный протокол может обеспечивать надежность и такую технологию управления потоком, при которой исходный узел посылает пакет, запускает таймер и ждет подтверждения приема перед отправкой нового пакета. Если подтверждение не получено по истечении времени, узел передает пакет еще раз. Эта технология называется подтверждением приема и повторной передачей (Positive Acknowledgment and Retransmission - PAR).
Присваивая каждому пакету порядковый номер, PAR позволяет узлам отслеживать пакеты, потерянные или дублированные вследствие сетевых задержек и преждевременной повторной передачи. Номера последовательностей посылаются обратно как уведомления в возможности отслеживания подтверждений приема.
Однако PAR неэффективно использует пропускную способность, потому что перед отправкой нового пакета узел должен ждать подтверждения и, следовательно, пакет можно передавать только один за другим.
Скользящее окно TCP
Скользящее окно TCP позволяет использовать пропускную способность сети более эффективно, чем PAR, поскольку с его помощью узелы могут отправлять несколько байтов или пакетов, не дожидаясь подтверждения.
В TCP принимающий узел определяет текущий размер окна каждого пакета. Так как по TCP-соединению данные передаются в виде потока байт, размеры окон тоже выражаются в байтах. Таким образом, окнопредставляет собой количество байт данных, которые отправитель может послать до ожидания подтверждения приема. Начальные размеры окон определяются при настройке соединения, но могут изменяться при передаче данных для управления потоком. Например, нулевой размер окна означает запрет на передачу данных.
Предположим, что TCP-отправителю надо послать с помощью скользящего окна последовательность байт (пронумерованных от 1 до 10) получателю с размером окна 5. Отправитель помещает в окно первые 5 байт, передает их все сразу и ждет подтверждения приема.
Получатель отвечает с АСК, равным 6, показывая, что получил байты с 1 по 5 и ждет байта 6. В том же пакете получатель показывает, что размер его окна равен 5. Отправитель сдвигает скользящее окно на 5 байт вправо и передает байты с 6 по 10. Получатель отвечает АСК, равным 11, показывая, что он ожидает байта 11. В этом пакете получатель может указать, что его размер окна равен 0 (поскольку, например, его внутренние буферы заполнены). Тогда отправитель больше не сможет посылать байты, пока получатель не пошлет другой пакет с ненулевым размером окна.
Формат ТСР-пакета
Поля и полный формат TCP-пакета показаны на рис. 35.10.
Рис. 35.10. Формат ТСР-пакета
Описание полей ТСР-пакета
Ниже описаны поля TCP-пакета, показанные на рис. 35.10.
Порт источника и порт получателя. Точки, в которых процессы верхнего уровня источника и получателя принимают услуги TCP.
Порядковый номер. Обычно это номер, присвоенный первому байту данных в текущем сообщении. При установке соединения может также использоваться для обозначения исходного порядкового номера в предстоящей передаче.
Номер подтверждения. Порядковый номер следующего байта данных, который ожидает получить получатель.
Сдвиг данных. Число 32-разрядных слов в заголовке TCP.
Резервные. Область, зарезервированная для использования в будущем.
Флаги. Различная управляющая информация, в том числе биты SYN и АСК, используемые для установки соединения, и бит FIN для разрыва соединения.
Окно. Размер приемного окна получателя (объем буфера для входящих данных).
Контрольная сумма. Показывает, не был ли заголовок поврежден при передаче.
Указатель срочности. Указывает на первый байт срочных данных в пакете.
Параметры. Различные дополнительные параметры TCP.
Данные. Информация верхнего уровня.
Литература:
Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. - М.: Издательский дом «Вильяме», 2005. - 1040 с.: ил. – Парал. тит. англ.
Как уже было отмечено ранее, главная задача транспортного уровня заключается в передаче данных между прикладными процессами. Эту задачу решают протокол управления передачей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) .
Протоколы TCP/IP основа работы глобальной сети Интернет. Если быть более точным, то TCP/IP это список или стек протоколов, а по сути, набор правил по которым происходит обмен информации (реализуется модель коммутации пакетов).
В этой статье разберем принципы работы стека протоколов TCP/IP и попробуем понять принципы их работы.
Примечание: Зачастую, обревиатурой TCP/IP называют всю сеть, работающую на основе этих двух протоколов, TCP и IP.
В модель такой сети кроме основных протоколов TCP (транспортный уровень) и IP (протокол сетевого уровня) входят протоколы прикладного и сетевого уровней (смотри фото). Но вернемся непосредственно к протоколам TCP и IP.
Что такое протоколы TCP/IP
TCP — Transfer Control Protocol . Протокол управления передачей. Он служит для обеспечения и установление надежного соединения между двумя устройствами и надежную передачу данных. При этом протокол TCP контролирует оптимальный размер передаваемого пакета данных, осуществляя новую посылку при сбое передачи.
IP — Internet Protocol. Интернет протокол или адресный протокол — основа всей архитектуры передачи данных. Протокол IP служит для доставки сетевого пакета данных по нужному адресу. При этом информация разбивается на пакеты, которые независимо передвигаются по сети до нужного адресата.
Форматы протоколов TCP/IP
Формат IP протокола
Существуют два формата для IP адресов IP протокола.
Формат IPv4. Это 32-битовое двоичное число. Удобная форма записи IP-адреса (IPv4) это запись в виде четырёх групп десятичных чисел (от 0 до 255), разделённых точками. Например: 193.178.0.1.
Формат IPv6. Это 128-битовое двоичное число. Как правило, адреса формата IPv6 записываются в виде уже восьми групп. В каждой группе по четыре шестнадцатеричные цифры разделенные двоеточием. Пример адреса IPv6 2001:0db8:85a3:08d3:1319:8a2e:0370:7889.
Как работают протоколы TCP/IP
Если удобно представьте передаче пакетов данных в сети, как отправку письма по почте.
Если неудобно, представьте два компьютера соединенных сетью. Причем сеть соединения может быть любой как локальной, так и глобальной. Разницы в принципе передачи данных нет. Компьютер в сети также можно считать хостом или узлом.
Протокол IP
Каждый компьютер в сети имеют свой уникальный адрес. В глобальной сети Интернет, компьютер имеет этот адрес, который называется IP-адрес (Internet Protocol Address).
По аналогии с почтой, IP- адрес это номер дома. Но номера дома для получения письма недостаточно.
Передаваемая по сети информация передается не компьютером, как таковым, а приложениями, установленными на него. Такими приложениями являются сервер почты, веб-сервер, FTP и т.п. Для идентификации пакета передаваемой информации, каждое приложение прикрепляется к определенному порту. Например: веб-сервер слушает порт 80, FTP слушает порт 21, почтовый SMTP сервер слушает порт 25, сервер POP3 читает почту почтовых ящиков на порте 110.
Таким образом, в адресном пакете в протоколе TCP/IP, в адресатах появляется еще одна строка: порт. Аналог с почтой — порт это номер квартиры отправителя и адресата.
Пример:
Source address (Адрес отправителя):
IP: 82.146.47.66
Destination address (Адресполучателя):
IP: 195.34.31.236
Стоит запомнить: IP адрес + номер порта — называется «сокет». В примере выше: с сокета 82.146.47.66:2049 пакет отправляется на сокет 195.34.31.236: 53.
Протокол TCP
Протокол TCP это протокол следующего после протокола IP уровня. Предназначен этот протокол для контроля передачи информации и ее целостности.
Например, Передаваемая информация разбивается на отдельные пакеты. Пакеты доставят получателю независимо. В процессе передачи один из пакетов не передался. Протокол TCP обеспечивает повторные передачи, до получения этого пакета получателем.
Транспортный протокол TCP скрывает от протоколов высшего уровня (физического, канального, сетевого IP все проблемы и детали передачи данных).
| Скорость проводного сегмента | ||||||
| Скорость беспроводного сегмента | ||||||
| Работа WAN-интерфейса | ||||||
| Уровень сигнала и зона охвата | ||||||
| Программное обеспечение |
Компания TP-LINK стремительно вошла на отечественный рынок сетевых устройств и уверенно стала конкурировать с такими монополистами как ASUS, D-LINK, ZYXEL и др. Одним из флагманов компании стал беспроводной маршрутизатор TL-WR1043ND, который стал одним из самых дешевых и самых производительных устройств в классе домашнего маршрутизатора. Так чем же примечателен данный роутер и почему мы так поздно о нем написали попытаемся Вам рассказать.
Характеристики маршрутизатора TP-LINK TL-WR1043ND
| Интерфейс | 4 10/100/1000 Мбит/с LAN порта 1 10/100/1000 Мбит/с WAN порт 1 USB 2.0 порт |
| Стандарты беспроводной передачи данных | IEEE 802.11n, IEEE 802.11g, IEEE 802.11b |
| Процессор | Atheros AR9132 400 МГц |
| Память | RAM: 32 Мбайт (2 x 16 Мбайт) ROM: 8 Мбайт |
| Антенна | 3дБи*3 съемные всенаправленные антенны |
| Частотный диапазон | 2,4-2,4835 ГГц |
| Скороcть передачи сигналов | 11n: до 300 Мбит/с (динамическая) 11g: до 54 Мбит/с (динамическая) 11b: до 11 Мбит/с (динамическая) |
| Мощность беспроводного сигнала | <20 дБм (EIRP) |
| Безопасность беспроводной сети |
64/128/152-бит WEP / WPA / WPA2,WPA-PSK / WPA2-PSK DoS, SPI брандмауэр |
| WAN | Динамические IP/Статические IP/ PPPoE/ PPTP (Двойной доступ)/ L2TP (Двойной доступ)/ BigPond |
| Доп. возможности |
WMM, Контроль за пропускной способностью Виртуальный сервер, Запуск портов, UPnP, DMZ DynDns, Comexe, NO-IP PPTP, L2TP, IPSec (ESP Head) |
| источник питания | 12В пост. тока / 1,5A |
| Условия эксплуатации | Рабочая температура: 0℃~40℃ (32℉~104℉) Температура хранения: -40℃~70℃ (-40℉~158℉) Влажность (рабочий режим): 10%~90% без конденсации Влажность (при хранении): 5%~90% без конденсации |
| Габариты - Размеры, ШхДхВ |
200 x 140 x 28 мм |
Особое отличие данного устройства от его конкурентов, безусловно быстрый процессор 400 Мгц и достаточно большой объем оперативной памяти, чего вполне достаточно для создания гигабитной сети. Стоит отдельно отметить мощный радиомодуль и наличие трех антенн, благодаря чему можно организовать беспроводную сеть WiFi с уверенным приемом в квартире или небольшом офисе квадратов до 90.
Положительно
Очень добротно сделан, на высоте и качество сборки и соотношение характеристик и заявленные возможности программного обеспечения. Порадовали возможности встроенного USB порта, который можно использовать как принт-сервер или сетевой накопитель данных NAS. В последних версиях программного обеспечения доступна функция передачи медиа данных по сети. Также данное устройство будет интересно тем, у кого дома есть IPTV, потому что роутер прекрасно справляется с видео потоком, при этом не жертвуя скоростью интернета для подключенных устройств.
Отрицательно
Складывается впечатление, что роутер идеален и недорог, но есть у него минусы, которые не позволяли нам его сделать лучшим выбором и минусы его все кроются в программном обеспечении роутера. Так при большой нагрузке беспроводных клиентов, роутер переставал подключать новые устройства, следовала перезагрузка. Также не весьма впечатлило меню настройки, даже оказавшись самым быстрым среди роутеров!, так как уже все производители давно включили поддержку Русского языка, TP-LINK предложил только английский. Периодически роутер мог вообще беспричинно "зависнуть", после чего вернуть в работу его могла только перезагрузка. Конечно можно установить уже полюбившуюся многим custom firmware DD-WRT, которая также существует для , но... время вылечило детские болезни родного по!
Выводы
Несмотря на ошибки в работе, производитель совершенствует свое программное обеспечение и к счастью уже появилась новая версия прошивки для , которую можно скачать на официальном сайте. А нового в прошивке много и основные новшества это РУССКИЙ язык меню, дополнительные USB приложения и исправление множества ошибок. После месячного тестирования на новом ПО, роутер показал совершенно отличные от предыдущих версий ПО результаты! Ни одного зависания и более высокие скорости! На L2TP соединении с провайдером скорость с внешним миром составила заявленные 100 мб/с, когда ни D-LINK ни ASUS не дали таких результатов. Команда СЕРВИСОВ активно использует для построения малых сетей и ставит роутеру оценку ОТЛИЧНО!
- стабильное соединение как локальной так и внешней сети
- уверенный беспроводной прием
- расширенные USB приложения
- высокие скорости
