19.02.2016 14:18
Прежде чем, мы расскажем вам о новом стандарте вещания UDT (UDP-based Data Transfer Protocol), который мы включили с для наших клиентов с 1 сентября 2015 года, хотелось бы рассмотреть несколько исторических фактов, которые привели нас к решению разработки нового стандарта вещания.
История развития русскоязычного ОТТ TV сервиса "Картина.ТВ" начинается в октябре 2007 года. В попытках реализовать стабильное вещание русскоязычных ТВ каналов через сети провайдеров интернета, экспериментальным путём был выбран протокол вещания HTTP. Видеосигнал упаковывался в контейнер MPEG-2 TS. Для кодирования использовался редкий тогда кодек MPEG H.264 (видео) и для сжатия звука кодек AAC (аудио). В 2010 году был добавлен адаптивный стандарт вещания HLS, который и до сих пор используется для лайв-вещания в Apple-устройствах.
К сожалению, оба протокола передачи данных не решали проблему плохого качества в случае HLS и замираний картинки в случае с HTTP для клиентов, находящихся на большом расстоянии от наших точек вещания. Также эти проблемы были и у абонентов даже с самой незначительной потерей пакетов на линии между нашим сервером вещания и устройством для просмотра у абонента.
Несмотря на значительное расширение сети за последние 7 лет, открытие новых точек вещания по всему земному шару, статистика показывает наличие в сети "медленных" абонентов. "Медленными абонентами" мы называем тех клиентов, у которых буфер отдачи пакетов переполняется, а значит, имеющих в данный момент проблемы с просмотром.
В далёком 2008 году процент таких клиентов составлял около 7%. На данный момент нам удалось его уменьшить до 1.5-2.5% в зависимости от состояния интернета.
Частично проблемы у клиентов могут быть решены путём увеличения буфера в настройках абонемента, выбором более низкого качества вещания, сменой сервера вещания. Но это влечёт за собой более долгое переключение каналов, большее отставание от реального лайв-вещания или недовольство качеством видеоизображения.
В целях уменьшить процент "медленных абонементов", облегчить работу нашей 24 часовой тех. поддержи было принято решение начать разработку нового протокола для передачи данных — нового стандарта вещания.
В следующем разделе мы объясним проблематику работы протоколов передачи данных на большие расстояния или же с потерей пакетов на линии.
Проблема протокола TCP
Всем известно, что скорость Интернета принято измерять в мегабитах в секунду. И любой вам скажет, что чем больше этих мегабит — тем лучше. Если быть более точным, то речь идет о максимальной скорости со стороны провайдера, предоставляющего услугу. В настоящее время провайдеры интернета предлагают для своих абонентов широкий выбор тарифов со скоростями от 20 и до 100Мбит/сек, а некоторые и ещё больше. Но даже при таких скоростях иногда происходят замирания видео или сильно падает скорость загрузки файлов. Провайдер в таких случаях отвечает, что он не несет ответственность за качество работы других ресурсов интернета. Да, не несет. Но несет ли ответственность хозяин ресурса и может ли он что-то сделать для решения этой проблемы.
Большинство TV-сервисов интернета работают по протоколу HTTP или HLS. А они в свою очередь используют транспортный протокол TCP, как это видно на модели стека TCP/IP:
Характерная особенность TCP заключается в гарантии и целостности передаваемых данных при помощи уведомлений отправителя о результатах передачи.
Огромную роль при этом играет время, которое проходит между отправкой сообщения и получением ответа. Это время называется RTT (Round Trip Time). Оно зависит не только от физических параметров, таких как скорость распространения света в оптических проводах, скорость движения электронов в медных проводах, а также от загруженности узлов, которые проходят пакеты на своём пути между клиентом и сервером.
RTT в миллисекундах можно измерить при помощи команды "ping".
В данном случае RTT составляет 26ms.
Ещё одна черта TCP — механизм контроля перегрузок. Он необходим, чтобы отправитель не передавал больше данных, чем получатель сможет получить и обработать. Механизм работает на основе оповещений о состоянии буфера обмена информацией. Отправителю (серверу) возвращается информация с подтверждением о получении, а также информация о текущем размере буфера у получателя. Если буфер у пользователя заполнен или же отправитель не получил этого оповещения, то сервер будет ждать пока не получит этот пакет с информацией.
Передача всей этой информации для управления потоком данных требует времени, которое необходимо на передачу пакетов. В следствии с этим максимальную скорость передачи данных черех протокол TCP можно вычислить по следующей формуле:
(BS x 8) / (RTT x 1024) = максимальная скорость Мбит/сек, где BS — размер приемного буфера в Килобайтах, а RTT — время ответа в секундах
Если время ответа (RTT — Round Trip Time) будет составлять 5 мс или 0.005 секунды, по сети можно будет передать максимум:
(64 * 8 ) / ( 0,005 * 1024 ) = 100 Мбит/с
Но увы RTT даже до шлюза не всегда ниже 5 мс. В лучшем случае RTT до сервера будет составлять 20-50 мс. При этом максимальная скорость будет 10-25 Мбит/с.
Ниже приведен график на котором изображена зависимость максимальной скорости по TCP от времени ответа RTT.
Скорость подключения клиента 30 Мбит/с. Этой скорости более чем достаточно чтобы смотреть видео в самом высоком качестве. Но из графика видно, что при RTT более 100 мс пользователь уже не сможет смотреть FullHD видео, HD уже на 150 мс, а с RTT более 350 мс о просмотре видео вообще можно забыть. Конечно, бывает видео с более низким разрешением и соответственно битрейтом, но мы не будем брать их в расчет.
Проблема TCP c большим расстоянием и потерей пакетов
Еще не маловажным фактором является потеря пакетов. Этот фактор также влияет на пропускную способность, накладывая ограничения независимо от размера буфера у получателя. Это ограничение можно рассчитать по формуле:
(MSS / RTT) * (1 /P) >= Максимальная скорость Мбит/сек,
где MSS — это максимальный размер сегмента (обычно 1460 байт), RTT — Round Trip Time (ms), а P — потеря пакетов (%)
Для быстрой проверки возможности просмотра Картина.ТВ при выборе стандарта вещания "HTTP/H.264″ мы разработали следующую таблицу, которая в цвете показывает, в каком качестве возможен просмотр ТВ:
Таблица доступных качеств вещания при стандарте вещания "HTTP/H.264″
Пример: При RTT в 40мс и потери пакетов в 1-2% максимальная скорость, на которую можно рассчитывать, является 2-3 Мбит/сек. При 0% потерь при этом RTT мы бы могли получить максимальную скорость в 27Мбит/сек.
Разница колоссальная. Так что если у вас есть потери пакетов, советуем вам в первую очередь заняться поиском решения этой проблемы.
Предположим, что у нас нет проблемы потери пакетов, а есть только большой RTT. Что в этой ситуации может сделать владелец сервиса? Первое что приходит на ум — уменьшить RTT. Да, это можно сделать. Разместить свои сервера территориально поближе к пользователям, организовать пиринговые соединения с местными провайдерами интернета. Либо воспользоваться услугами сторонних компаний, специализирующихся на доставке контента, которые уже имеют сеть территориально распределенных серверов. Но и этого не всегда бывает достаточно. Все равно найдутся клиенты, у которых задержки до ближайшего сервера будут достаточно высокие.
Второй вариант — попробовать поменять транспортный протокол на более подходящий в данной ситуации, например, на UDP. В этом протоколе нет контроля перегрузок. UDP подразумевает что эта проблема а также проблема проверки ошибок, должны решаться уже на программном уровне. UDP отправляет данные сразу, не зная о том получает ли их кто-нибудь или нет. Даже при RTT в одну секунду, после начала передачи данные начнут поступать к клиенту через пол секунды но будут поступать дальше постоянно без остановок.
Остается решить несколько проблем:
1. Контроль скорости потока. Сервер может с легкостью послать данных более чем сможет обработать клиент.
2. Проверку целостности данных.
3. Работа через NAT. В UDP нет механизма предварительной установки соединения. Большинство пользователей работают через домашние роутеры и имеют серые адреса.
UDT
Для решения этих проблем идеально подходит протокол прикладного уровня UDT (UDP-based Data Transfer Protocol). В текущей 4й версии протокола есть система управления потоком, система контроля целостности данных и реализован механизм работы с клиентами за NAT.
UDT работает поверх транспортного протокола UDP:
Протокол устанавливает два UDP соединения. Одно — для передачи данных получателю, второе — для передачи контрольной информации отправителю.
Каждый UDT пакет имеет порядковый номер. Получатель отправляет подтверждение и отчет о не дошедших пакетах. Не дошедшие пакеты передаются заново.
В отличие от TCP, который для управления потоком использует механизм с указанием размера окна, UDT использует частоту отправки пакетов, изменяя интервал между ними. Оба протокола для расчета изменений используют AIMD алгоритм (aддитивное увеличение и мультипликативное уменьшение). Этот алгоритм позволяет рассчитать на сколько стоит увеличить количество пакетов передаваемых в единицу времени чтобы увеличить скорость и на сколько надо уменьшить в случае перегрузок в сети. Для TCP и UDT событием о перегрузке является сообщение о потере пакетов. AIMD алгоритм может быть представлен в виде функции для увеличения частоты α(x) и понижающего коэффициента β.
x=x+α(x) — увеличение количества пакетов через каждую единицу времени
x=(1-β)x — уменьшение количества пакетов в единицу времени (в случае обнаружения потери пакетов).
Для TCP α(x) всегда равна 1, а β равна 0,5.
В UDT используется более сложный алгоритм расчета. С каждым увеличением x
α(x) стремится к нулю
limx→∞α(x)=0
Пропускная способность канала фиксирована и по мере приближения к этому порогу UDT будет увеличивать количество пакетов на меньшее число. Это позволит максимально приблизиться к пропускной способности канала и снизить колебания в момент перегрузки и потери пакетов.
Увеличение скорости рассчитывается по формуле
α(x)=10log(B-x)*c
где B — пропускная способность канала Мбит/c,
x — скорость Мбит/с
с — константа SYN (0,01 сек)
α(x)- количество пакетов на единицу времени SYN
На графиках видно что примерно за 7,5 секунд скорость увеличивается до 90% от пропускной способности канала. Затем, пор мере приближения к максимальной границе, увеличение скорости становится все менее интенсивным.
Скорость канала B = 10 Гб/с, размер пакета = 15000 байтов
Для определения пропускной способности канала (B) UDT использует специальный механизм. UDT отправляет пакеты максимального размера с случайными интервалами. При прохождении узкого места в сети, интервал между пакетами изменяется. Зная эти параметры, принимающая сторона может вычислить пропускную способность канала.
В случае перегрузки в сети
β = 1 — (8/9)n
n — это случайное число от 1 до M
M — количество не дошедших пакетов в случае перегрузки
Ниже приведены испытания на интернет-сервисе Kartina.tv. Компания предоставляет трансляцию видео контента по обоим протоколам HTTP и UDT и имеет сеть серверов по всему миру. Это позволит нам сравнить работу обоих протоколов при онлайн просмотре видео на разных размерах RTT.
Для испытания были выбраны видео-поток FullHD и 5 серверов со следующим RTT мин/сред/макс:
3/12/18
68/68/72
82/96/175
158/166/244
328/385/464
По очереди с каждого сервера был запущен FullHD видео поток. Сначала по HTTP.
Битрейт потока приблизительно 7Мбит/с. По расчетам с RTT более 70 мс мы уже должны испытывать проблемы.
Сервера 1 и 2 (RTT 12 и 70 мс )- видео проигрывалось без проблем. На графиках присутствуют кратковременные падения. Они связаны изменяющимся битрейтом видео-потока.
Сервер 3 (RTT 96 мс) — видео сначала запустилось нормально, потом начались проблемы. Картинка то и дело останавливалась, видео рассыпалась. Качество было хуже чем предполагалось. Это было связано с периодическими увеличениями RTT аж до 175 мс.
Сервера 4 и 5 (RTT 166 и 385) — посмотреть видео не удалось. Периодически появлялись кадры, звук но толком даже несколько секунд видео не проигрывалось.
По UDT на всех пяти серверах видео работало без проблем. На пятом сервере при старте присутствовала пауза, как раз чуть менее полу секунды, но затем видео поток запустился и далее проигрывался без проблем.
UDT
В дополнение мы провели тестирование видео потоков при различных потерях пакетов. Результаты по протоколу HTTP полностью подтвердили наши расчеты представленные в таблице доступных качеств вещаний. Результаты по протоколу UDT приведены ниже.
Таблица результатов при стандарте вещания "UDT/H.264″
Данные испытания показали значительное преимущество UDT над HTTP. Главными факторами послужило независимость UDT от времени ответа RTT а также намного лучшая работа на плохих соединениях с потерей пакетов.
Заключение
Интернет развивается каждый день. UDT — это еще одна ступенька в его развитии. Этот протокол позволит значительно ускорить работу интернет-сервисов, работающих с передачей больших объемов информации.
Владельцы интернет-ресурсов могут влиять и влияют на проблемы, возникающие у пользователей. Так что если у вас есть проблемы — звоните, пишите в поддержку, оставляете свои фидбеки. Для них это важно.
Что касается нашего сервиса, то мы и в дальнейшем намерены следовать последним трендам и новациям в развитии OTT-среды, в частности, на 2016 год мы запланировали включение в контентное предложение "Картины ТВ" UHD-версий каналов "Первый музыкальный" и Fashion TV, и закупку поддерживающих UHD 4K-формат ресиверов у компаний Dune HD и Comigo.
Темы
- Войдите или зарегистрируйтесь, чтобы оставлять комментарии
Об авторе
