Как написать протокол передачи данных

Написать протокол на java?

Подскажите как написать протокол на java, для передачи коротких данных (также интересна передача Rreal-time и Stream трафика). Передача должна осуществляться на основе транспортного протокола UDP.

Ну а чего тут особо сильно думать то? Транспортный протокол известен/задан UPD — соответственно теперь надо озаботиться следующим уровнем стека протоколов (согласно великой могучей науке) — фактически прикладным уровнем.

На одной стороне сервер принимаем/посылает массив байтов, а на другой стороне клиент аналогично принимает/посылает массив байтов.

Обычно массив байтов полагается структурировать в виде структуры/класса, например:

В общем все ограничено только вашей фантазией.

Update Посылка байтов также лишена романтики и выглядит примерно так (грубо):

Построение протокола обмена данными для встроенных систем управления Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Воробьев Ярослав Юрьевич, Клебан Виталий Олегович

Научный руководитель к. ф.-м. н., доцент М.В. Сухорукова. В настоящее время встроенная поддержка IP и Internet приобретает все большую популярность, широко используется в так называемых «умных домах», роботах, электросчетчиках и другой аппаратуре. В работе рассмотрены особенности выбора протоколов передачи данных для различных целей, проведена классификация типов взаимодействия устройств. Приводится способ математического описания протокола передачи данных. Рассматриваются примеры использования встроенных систем управления через Интернет и приводятся результаты практического применения рассмотренной методологии построения протоколов. Использование IP-сетей как коммуникационной среды позволит строить масштабируемые, гетерогенные и надежные системы.

Текст научной работы на тему «Построение протокола обмена данными для встроенных систем управления»

ПОСТРОЕНИЕ ПРОТОКОЛА ОБМЕНА ДАННЫМИ ДЛЯ ВСТРОЕННЫХ СИСТЕМ УПРАВЛЕНИЯ Я.Ю. Воробьев, В.О. Клебан Научный руководитель — к.ф.-м.н., доцент М.В. Сухорукова

В настоящее время встроенная поддержка IP и Internet приобретает все большую популярность, широко используется в так называемых «умных домах», роботах, электросчетчиках и другой аппаратуре. В работе рассмотрены особенности выбора протоколов передачи данных для различных целей, проведена классификация типов взаимодействия устройств. Приводится способ математического описания протокола передачи данных. Рассматриваются примеры использования встроенных систем управления через Интернет и приводятся результаты практического применения рассмотренной методологии построения протоколов. Использование IP-сетей как коммуникационной среды позволит строить масштабируемые, гетерогенные и надежные системы.

Комплекс протоколов Internet охватывает целое семейство протоколов и прикладные программы. В его состав входят UDP, ARP, ICMP, FTP и другие. Но поскольку TCP и IP — наиболее известные протоколы данного комплекса, то часто, ссылаясь на данный набор протоколов, используют термин TCP/IP.

TCP/IP — это семейство протоколов. Часть из них обеспечивает выполнение «низкоуровневых» сетевых функций для множества приложений, таких как работа с аппаратными протоколами, поддержка механизма доставки пакета, обеспечение достоверности и надежности соединения и т.д. Другая часть протоколов предназначена для выполнения прикладных задач — передача файлов, отправка почты, просмотр страниц и т.д. Например, при отправке почты используется протокол работы с почтой. Он определяет систему команд, которые обозначают, кто будет отправителем, кто — получателем, в какой форме идет сообщение. Этот протокол, как и все прикладные, подразумевает наличие надежного соединения между компьютерами. Именно за это и отвечают «низкоуровневые» протоколы TCP/IP. Подобно тому, как почтовый протокол использует TCP, так и ТСР использует IP протокол, который обеспечивает доставку пакета по адресу (адресацию и маршрутизацию). Вообще же семейство протоколов TCP/IP имеет 4 ярко выраженных уровня:

• уровень приложения (прикладной);

• уровень, реализующий транспортные функции (транспортный);

• уровень, обеспечивающий доставку и маршрутизацию пакетов (сетевой);

• уровень сопряжения с физической средой (канальный).

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

• сбор данных с удаленных датчиков;

• построение систем обработки данных и управления;

Появившиеся устройства фирмы Lantronix — Xport и WiPort предназначены для подключения к локальным вычислительным сетям практически любых устройств, имеющих последовательные порты, и обеспечения дистанционного контроля и управления этими устройствами по сетям Ethernet или Internet.

Как правило, для передачи последовательности данных используют протоколы TCP и UDP. Существует еще ряд протоколов транспортного уровня (например, SCTP), но большого распространения для решения этой задачи они не получили.

Каждый протокол имеет свои особенности и диапазон применения. Остановимся конкретно на каждом из них.

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

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

Возможные проблемы при использовании одного из протоколов

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

С применением протокола UDP могут быть связаны следующие проблемы.

• Пакеты, передаваемые по протоколу UDP, могут теряться. В одних случаях это может быть связано со сбоями оборудования, в других — с тем, что «время жизни» пакета истекло, и он был уничтожен на одном из маршрутизаторов.

• В процессе передачи возможны перестановки пакетов в потоке. Искажения потока пакетов связаны, как правило, с загруженностью сети.

• При большой генерации пакетов UDP сеть может быть достаточно быстро перегружена, особенно в случае многоканальных систем.

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

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

• Отсутствует абсолютная защита от потери пакетов во многих реализациях TCP.

Типы взаимодействия устройств

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

Для передачи файлов или каких-либо данных, в которых необходимо контролировать корректность данных и их последовательность, имеет смысл использовать протокол TCP. Примером подобной реализации могут быть устройства со встроенным WEB сервером, ADSL модемы и др.

Тип данных Протокол Пояснение

Команды UDP Для быстрой отправки команды устройству оптимально будет воспользоваться протоколом UDP

Сложные команды, структуры данных TCP (XML RPC, SOAP) Если устройство реализует ряд сложных функций, более удобно будет использовать сочетание TCP и одного из протоколов высокого уровня для обмена структурированными сообщениями

Видео / Аудио UDP (mms, rtmp, rtp, rstp) Как уже говорилось, для данных этого типа оптимально пользоваться протоколом UDP

Файлы TCP (FTP) Если передаваемым файлам необходимо обеспечить дополнительные сервисы (докачка, переименование, перенос) -оптимально использовать протокол FTP

Простые файлы UDP (TFTP) Если необходимо передать файл без каких-либо ухищрений, можно воспользоваться более простой реализацией протокола передачи файлов TFTP

Таблица. Устройства со встроенным WEB сервером

Разработка протокола обмена данными

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

Формирование пакета протокола происходит по определенным правилам и может быть представлено в терминах теории множеств.

Определим пакет как множество объектов, представляющих собой поля этого пакета, и обозначим их буквой C. Первым объектом, входящим в состав C, будут передаваемые данные D,

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

При реализации протоколов приходится иметь дело с необходимостью подтверждения приема пакета, для этого добавим к пакету новый объект N, сигнализирующий о необходимости отправки подтверждения, и объект T, обозначающий тип пакета (обычный, пакет-подтверждение): C = C u N

N = [ack, nack>,\ N| = 2 .

T = [general, ack>, — = 2

Передача данных в IP-сетях может сопровождаться помехами, такими, как потеря пакета, получение пакетов в другом порядке. Для предотвращения этих ошибок введем в пакет уникальный идентификатор U:

Для определения мощности множества воспользуемся следующим выражением:

где — — время жизни пакета, Ttmnsmtt — время передачи пакета.

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

Примеры встроенных систем

В качестве примера встроенной системы рассмотрим мобильный робот КВАРК, созданный авторами и представленный на фестивале «Мобильные роботы-2006» как экспериментальный полигон для отладки алгоритмов навигации.

Рис. 1. Мобильный робот КВАРК

Система управления роботом состоит из бортовых систем, ответственных за работу задач реального времени, и автоматизированного рабочего места (АРМ), служащего

для ручного управления роботом и наблюдения за состоянием сенсоров робота. В качестве канала связи между роботом и АРМ используется IP-сеть, выполненная по технологии WiFi.

Пропускная способность сети составляет около 10Мбит/с. По данному каналу связи передаются разнородные данные, такие, как видео, состояния датчиков, управляющие команды, команды синхронизации и проверки оборудования. Применены протоколы как потоковой передачи данных, так и типа запрос-ответ.

Разработана система, позволяющая пользователю управлять мобильным роботом по сети Intranet. Разработанная система не требует от клиента никакого специализированного ПО, кроме установленного Macromedia Flash Player. Система позволяет удаленно управлять платформой, наблюдая за ее действиями с помощью камеры (для передачи видео используется протокол RTMP).

Шведская фирма AXIS наладила серийный выпуск IP-камер видеонаблюдения. Камера имеет встроенный web-сервер, который служит для настройки и управления камерой, а также просмотра видео в формате MJPEG. Камера передает видеопоток, используя протокол RTSP. Использование IP-сети и стандартизированных протоколов передачи данных позволяет создавать универсальное программное обеспечение для управления камерами видеонаблюдения.

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

Создание протокола надежной передачи данных

Надежная передача данных по каналу, допускающему искажение битов и потерю пакетов

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

0 comments
Создание протокола надежной передачи данных

Надежная передача данных по каналу, допускающему искажение битов

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

0 comments
Создание протокола надежной передачи данных

Надежная передача данных по абсолютно надежному каналу

Сначала рассмотрим простейший случай, когда канал, по которому передаются данные, является абсолютно надежным. Протокол rdt 1.0, обеспечивающий передачу по такому каналу, также является тривиальным. На рис. 3.8 приведена схема конечных автоматов, описывающая этот протокол. Фрагмент а соответствует передающей стороне, фрагмент б — принимающей. При описании протокола важным является наличие двух моделей конечных автоматов, соответствующих каждой из его сторон. В данном

Пишем свой протокол поверх UDP

Первые прямые трансляции с места событий появились в России почти 70 лет назад и вели их из передвижной телевизионной станции (ПТС), которая внешне походила на «троллейбус» и позволяла вести эфиры не из студии. А всего лишь три года назад Periscope позволил вместо «троллейбуса» использовать мобильный телефон.

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

Еще через полгода, летом 2016, Одноклассники запустили свое мобильное приложение OK Live для стриминга, в котором постарались решить эти проблемы.

Александр Тоболь отвечает за техническую часть видео в Одноклассниках и на Highload++ 2017 рассказал про то, как писать свой UDP протокол, и зачем это может потребоваться.

Из расшифровки его доклада вы узнаете все про другие протоколы стриминга видео, какие есть нюансы, и про то, какие уловки иногда требуются.

Архитектура и ТЗ

На слайде ниже схема архитектуры любого стримингового сервиса: видео подается на вход, преобразуется и передается на выход. К этой архитектуре мы добавили еще немножко требований: видео должно подаваться с десктопов и мобильных телефонов, а на выход — попадать на те же десктопы, мобильные телефоны, smartTV, Chromcast, AppleTV и другие устройства — все, на чем можно играть видео.

Дальше переходим к техническому заданию. Если у вас есть заказчик, у вас есть ТЗ. Если вы — социальная сеть, ТЗ у вас нет. Как его составить?

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

Мы решили пойти методом от противного и посмотрели, что пользователи НЕ хотят видеть от сервиса трансляции.

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

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

Что у конкурентов?

Мы начали с изучения сервисов конкурентов. Открываем Periscope — что у них?

Как всегда, главное — архитектура.

Сара Хайдер, ведущий инженер Periscope, пишет, что для бэкенда они используют Wowza. Если еще немножко почитать статьи, то мы увидим, что стрим они делают с использованием протокола RTMP, а раздают его либо в RTMP, либо в HLS. Посмотрим, что это за протоколы и как они работают.

Протестируем Periscope на три наших главных требования.

Скорость старта у них приемлемая (меньше секунды на хороших сетях), постоянноекачество порядка 600 px (не HD) и при этом задержки могут составлять до 12 секунд.

Кстати, как померить задержку в трансляции?

Это фотография измерения задержки. Есть мобильный телефон с таймером. Мы включаем трансляцию и видим изображение этого телефона на экране. За 0,15 миллисекунд изображение попало на сенсор камеры и вывелось из видеопамяти на экран телефона. После этого мы включаем браузер и смотрим трансляцию.

Ой! Она немножко отстала — примерно на 12 секунд.

Чтобы найти причины задержки, попрофилируем стриминг видео.

Итак, есть мобильный телефон, видео идет с камеры и попадает в видеобуфер. Тут задержки минимальны (≈0,15 мс). Потом кодировщик кодирует сигнал, упаковывает в пакет и отправляет в socket-буфер. Это все летит в сеть. Дальше на принимающем устройстве происходит все то же самое.

В принципе, есть две основные трудные точки, которые нужно рассмотреть:

кодирование/декодирование видео;
сетевые протоколы.

Кодирование/декодирование видео

Немного расскажу про кодирование. Вы все равно с ним столкнетесь, если будете делать Low Latency Live Streaming.

Что такое видео? Это набор кадров, но не совсем простых. Кадры бывают трех типов: I, P и B-frame:

I-frame — это просто jpg. По сути, это опорный кадр, он ни от кого не зависит и содержит четкую картинку.
P-frame зависит исключительно от предыдущих кадров.
Хитрые B-frame могут зависеть от будущего. Это означает, что чтобы посчитать b-frame, нужно, чтобы с камеры пришли еще и будущие кадры. Только тогда с некоторой задержкой можно декодировать b-frame.

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

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

Надо включать CBR. Не все кодеки на Android будут его корректно поддерживать, но они будут к этому стремиться. То есть нужно понимать, что с CBR идеальной картины мира, как на нижней картинке, вы не получите, но включить его все-таки стоит.

4. А на бэкенде необходимо добавить к H264 кодеку zerolatency — это позволит как раз не делать зависимости в кадрах на будущее.

Протоколы передачи видео

Рассмотрим, какие протоколы стриминга предлагает индустрия. Я их условно разбил на два типа:

потоковые протоколы;
cегментные протоколы.

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

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

Потоковые протоколы

Periscope использует RTMP. Этот протокол появился в 2009 году, и Adobe сначала не полностью его специфицировал. Потом у него были определенного рода трудности с тем, что Adobe хотел продавать исключительно свой сервер. То есть RTMP развивался довольно трудно. Его основная проблема в том, что он использует TCP, но почему-то именно его выбрал Periscope.

Если почитать детально, то оказывается, что Periscope использует RTMP для трансляции с малым количеством зрителей. Как раз такие трансляции, если у вас недостаточный канал, скорее всего, вы не сможете посмотреть.

Рассмотрим на конкретном примере. Есть пользователь с узким каналом связи, который смотрит вашу трансляцию. Вы с ним договариваетесь по RTMP о низком битрейте и начинаете персонально для него стримить.

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

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

Но все равно RTMP у нас поверх TCP, и никто нас от блокировки начала очереди не застраховал.

На рисунке это проиллюстрировано: к нам поступают аудио и видео фреймы, RTMP их пакует, возможно их как-то перемешивает, и они улетают в сеть.

Но допустим, мы теряем один пакет. Возможно, что тот самый желтый потерянный пакет — это вообще P-frame от какого-то предыдущего — его можно было бы дропнуть. Возможно, как минимум, можно было бы играть аудио. Но TCP нам не отдаст остальные пакеты, так как он гарантирует доставку и последовательность пакетов. С этим надо как-то бороться.

Существует еще одна проблема использования протокола TCP в стриминге.

Допустим, у нас есть буфер и высокая пропускная способность сети. Мы генерируем туда из нашего кодека пакеты в высоком разрешении. Потом — оп! — сеть стала работать хуже. На кодеке мы уже указали, что битрейт нужно понизить, но готовые пакеты уже в очереди и никаким образом изъять их оттуда нельзя. TCP отчаянно пытается пропихнуть HD-пакеты через наш 3G.

У нас нет никакого управления буфером, нет приоритезации, поэтому TCP крайне не подходит для стриминга.

Давайте теперь взглянем на мобильные сети. Возможно для жителей столиц это будет удивительно, но наша средняя мобильная сеть выглядит примерно так:

1,1 Мбит/с трафика;
0,1% packet loss;
300 мс средний RTT.

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

В определенных регионах packet loss доходит до 1%, тогда у пользователя остается порядка 10% процентов пропускной способности.

Поэтому на TCP делать не будем.

Посмотрим, что есть еще в мире стриминга из UDP.

Протокол WebRTC очень хорошо зарекомендовал себя для p2p звонков. На очень популярных сайтах пишут, что использовать для звонков его очень здорово, а вот для доставки видео и музыки — не хорошо.

Его основная проблема в том, что он пренебрегает потерями. При всех непонятных ситуациях он просто дропает.

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

RTP-стриминг — это базовый протокол передачи данных по UDP. Ниже на слайде справа приведен набор расширений и RFC, которые пришлось реализовать в WebRTC для того, чтобы адаптировать этот протокол для звонков. В принципе, можно попробовать сделать что-то подобное — набрать набор расширений к RTP и получить UDP стриминг. Но это очень сложно.

Вторая проблема в том, что если кто-то из ваших клиентов не поддерживает какой-либо extension, то протокол не заработает.

Сегментные протоколы

Хорошим примером сегментного протокола видео является MPEG-Dash. Он состоит из manifest-файла, который вы выкладываете у себя на портале. Он содержит ссылки на файлы в разных качествах, в начале файла есть некоторый индекс, который говорит, в каком месте файла начинается какой сегмент.

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

Еще одним примером сегментного стриминга является HLS.

MPEG-Dash — решение от Google, оно хорошо работает в Android, а Apple-решение более старое, у него есть ряд определенных недостатков.

Первый из них — это то, что основной манифест содержит ссылки на вторичные манифесты, вторичные манифесты по каждому конкретному качеству содержат ссылки на каждый отдельный сегмент, а каждый отдельный сегмент представлен отдельным файлом.

Если взглянуть еще более детально, то внутри каждого сегмента находится MPEG2-TS. Этот протокол делали еще для спутника, размер его пакета 188 байт. Упаковывать видео в такой размер очень неудобно, особенно потому, что вы все время его снабжаете небольшим хедером.

На самом деле это трудно не только серверам, которые для того, чтобы обработать 40 Гб трафика должны собрать 26 млн пакетов, но это еще трудно и на клиенте. Поэтому, когда мы переписали iOS плеер на MPEG-Dash, мы даже увидели некоторый прирост производительности.

Но Apple не стоит на месте. В 2016 году они наконец-то анонсировали, что у них есть возможность запихнуть фрагмент от MPEG4 в HLS. Тогда они обещали это добавить только для разработчиков, но вроде бы сейчас должна появиться поддержка на macOS и iOS.

То есть, казалось бы, фрагментный стриминг удобный — приходите, берете нужный фрагмент, с опорного кадра стартуете — работает.

Минус: понятно, что опорный кадр, с которого вы стартовали — это не тот кадр, который сейчас у того, кто стримит. Поэтому всегда появляется задержка.

Вообще есть возможность допилить HLS до задержек порядка 5 секунд, кто-то говорит, что ему удалось получить 4, но в принципе решение использовать фрагментный стриминг для трансляции не очень хорошее.

Сложность vs задержка

Посмотрим на все имеющиеся протоколы и рассортируем их по двум параметрам:

latency, который они дают между трансляцией и смотрящим;
complexity (сложность).

Что мы хотим?

Мы хотим сделать UDP-протокол для стриминга от 1 к N с задержкой, сравнимой с p2p связью, с возможностью опционального шифрования пакетов в зависимости от того, приватная или публичная трансляция.

Какие есть еще варианты? Можно подождать, например, когда Google выпустит свой QUIC.

Расскажу немного, что это такое. Google позиционирует Google QUIC, как замену TCP — некий TCP 2.0. Его разрабатывают с 2013 года, сейчас спецификации у него нет, зато он полностью доступен в Google Chrome, и мне кажется, что они иногда включают его некоторым пользователям для того, чтобы посмотреть, как он работает. В принципе, можно зайти в настройки, включить себе QUIC, зайти на любой Google сайт и получить этот ресурс по UDP.

Мы решили не ждать, пока они все специфицируют, и запилить свое решение.

Требования к протоколу:

Многопоточность, то есть мы имеем несколько потоков — управляющий, видео, аудио.
Опциональная гарантия доставки — управляющий поток имеет 100% гарантию, видео нам нужно меньше всего — мы там можем дропать фрейм, аудио нам все-таки бы хотелось.
Приоритезация потоков — чтобы аудио уходило вперед, а управляющий вообще летел.
Опциональное шифрование: или все данные, или только заголовки и критичные данные.

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

Если сортировать протоколы по такому принципу, то видно, что чем меньше время ожидания, тем хуже качество — довольно простой вывод.

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

Разработка

Давайте уже начнем писать UDP протокол, но сначала посмотрим на статистику.

Это наша статистика по мобильным сетям. Тут видно, что средний интернет чуть больше мегабита, packet loss около 1% — это нормально, и RTT в районе 600 мс — на 3G это просто средние величины.

Будем на это ориентироваться при написании протокола — поехали!

UDP-протокол

Открываем socket UDP, забираем данные, упаковываем, отправляем. Берем вторую пачку от кодека, еще отправляем. Вроде бы все здорово!

Но мы получим такую картину: если мы начинаем беспорядочно слать UDP пакеты в socket, то по статистике к 21-му пакету вероятность того, что он дойдет, будет всего лишь 85%. То есть packet loss уже будет 15%, что никуда не годится. Это нужно исправлять.

Исправляется это стандартно. На рисунке проиллюстрирована жизнь без Pacer и жизнь с Pacer.

Pacer — это такая штука, которая раздвигает пакеты во времени и контролирует их потерю; смотрит, какой сейчас packet loss, в зависимости от этого адаптируется под скорость канала.

Как мы помним, для мобильных сетей 1-3% packet loss — это норма. Соответственно, надо с этим как-то работать. Что делать, если мы теряем пакеты?

Retransmit

В TCP, как известно, есть алгоритм fast retransmit: мы отправляем один пакет, второй, если пакет потеряли, то через некоторое время (retransmit period) отправляем этот же пакет.

Какие здесь плюсы? Никаких проблем, никакой избыточности, но есть минус — некоторый retransmit period.

Кажется, что очень просто: через какое-то время нужно повторить пакет, если вы не получили на него подтверждение. Логично, что это может быть время равное времени пинга. Но ping — это величина не стабильная, и поэтому точно через средний RTT time определить, что потерян пакет, мы не можем.

Для того, чтобы это оценить можно, например, использовать такую величину, как jitter: мы считаем разницу между всеми нашими ping-пакетами. Например, в примере выше, средняя величина равна 46 мс. На нашем портале средний jitter — 50.

Посмотрим на распределение вероятности приходов пакетов ко времени. Есть некоторый RTT и некоторая величина, после которой мы можем действительно понять, что acknowledge не пришел и повторить отправку пакета. В принципе, есть RFC6298, который в TCP говорит, как это можно хитро посчитать.

Мы это делаем через jitter. На портале у нас jitter по ping примерно 15%. Понятно, что retransmit period должен быть, как минимум, на 20% больше, чем RTT.

Еще один кейс с retransmit. С прошлого раза у нас был acknowledge на второй пакет. Мы отправляем третий пакет, который теряется, другие пакеты пока ходят. После этого наступает retransmit period, и мы отправляем третий пакет еще раз. Он еще раз дропнулся, и мы еще раз отправляем его.

Если у нас случается двойная потеря пакета, то на retransmit появляется новая проблема. Если у нас, например, packet loss 5%, и мы отправляем 400 пакетов, то на 400 пакетов у нас 1 раз точно будет ситуация двойного packet-drop, то есть, когда мы через retransmit period отправили пакет, и он еще раз не дошел.

Эту ситуацию можно исправить, добавив некоторую избыточность. Можно начать отправлять пакет, например, если мы получили acknowledge от другого пакета. Считаем, что опережение — это редкая ситуация, можем начать отправку третьего пакет в момент, обозначенный speculative retransmit на слайде выше.

Можно еще пошаманить со спекулятивным retransmit, и все будет неплохо работать.

Но тут мы заговорили про избыточность. А что, если добавить Forward Error Correction? Давайте просто все наши пакеты снабдим, например, XOR. Если мы точно знаем, что в мобильных сетях все так печально, то давайте просто добавим еще один пакетик.

Здорово! Нам не нужны никакие round trip, но у нас уже появилась избыточность.

А что, если пропадет не один пакет, а сразу два? Давайте вместо XOR возьмем другое решение — например, есть код Reed-Solomon, Fountain codes и т.д. Идея такая: если есть K пакетов, можно добавить к ним N пакетов так, что любые N можно было потерять.

Вроде бы классно!

Хорошо, если у нас такая плохая сеть, что пропали просто все пакеты, то к нашему Forward Error Correction очень удобно добавляется negative acknowledgement.

Если мы потеряли столько пакетов, что наш parity protection (назовем его так) нас уже не спасает, запрашиваем этот пакет дополнительно.

Простой в реализации, правда можно потерять и сам negative acknowledgement, но это мелкая проблема.
Хорошо совместим с FEC.

С одной стороны, FEC + NACK;
С другой стороны, Fast retransmit.

Оказывается, что пакеты теряются не равномерно по одной штучке, а пачками (выше график распределений). Причем есть интересные пики, например, на 11 пакетах, есть еще пики на 60-80 пакетах. Они повторяются, и мы изучаем, откуда они берутся.

В среднем на нашем портале теряется по 6 пакетов.

Детальное рассмотрение по сетям показывает, что чем хуже сеть, тем больше это количество. В таблице указано время, которое сеть была недоступна. Например, Wi-Fi недоступен 22 мс и теряет 5 пакетов, 3G может за 34 мс потерять 8 пакетов.

Вопрос: если мы знаем, что у нас 90% packet loss на портале укладывается в 10 пакетов, и при этом средний gap равен 25 мс, что будет работать лучше — FEC + NACK или Fast retransmit?

Тут, наверное, надо рассказать, что Google, когда делал свой протокол QUIC в 2013 году, ставил Forward Error Correction во главу, думая, что он решит все проблемы. Но в 2015 они его отключили.

Мы протестировали оба варианта и у нас не получилось завести FEC + NACK, но мы еще пытаемся и не отчаиваемся.

Рассмотрим, как он работает.

Это цифры, близкие к средней сети, проcто чтобы было удобно считать:

1 Мб/с сеть;
1% packet loss;
300 мс RTT;
1 000 байт — размер пересылаемых пакетов;
1 000 пакетов в секунду уходит.

Мы начинаем делать такие добавки, и вроде бы все здорово. И тут на 500-м пакете, теряем ту самую пачку из 10 штук.

У нас есть варианты:

Дождаться оставшиеся 500 пакетов и восстановить данные через Forward Error Correction. Но на это у нас потратится примерно полсекунды, а пользователь эти данные ждет.
Можно воспользоваться NACK, причем это дешевле, чем дожидаться кодов коррекции.
А еще можно просто взять Fast Retransmit, не добавлять никаких кодов коррекции и получить тот же самый результат.

Fast Retransmit

Это работает так: после того, как мы потеряли пачку в 10 пакетов, отправив пока другие пакеты, понимаем, что у нас retransmit period прошел, и отправляем эти пакеты заново.

Самое интересное в том, что retransmit period на такой сети будет 350 мс, а средняя длительность этого packet gap — 25-30 мс, пусть даже 100. Это означает, что к моменту, когда retransmit начнет обрабатывать пакеты, в большинстве случаев сеть уже восстановится и они уйдут.

У нас получилось, что эта штука работает лучше и быстрее.

Дополнительные опции

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

Есть буфер отправки, в нем лежит опорный кадр, к нему p/b-кадры. Они равномерно уходят в сеть. Тут они перестали уходить в сеть, а в очередь прилетели еще пакеты.

Вы понимаете, что на самом деле все пакеты, которые лежат в очереди, уже больше не интересны клиенту, потому что прошло, например, больше 0,5с и надо на клиенте просто склеить разрыв и жить дальше.

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

Так как мы сами пишем протокол, то придется столкнуться с IP fragmentation. Думаю, многие про это знают, но на всякий случай вкратце расскажу.

У нас есть сервер, он отправляет какие-то пакеты в сеть, они приходят к маршрутизатору и на его уровне MTU (maximum transmission unit) становится ниже, чем размер пакета, который пришел. Он дробит пакет на большой и маленький (здесь 1100 и 400 байт) и отправляет.

В принципе, проблемы нет, это все соберется на клиенте и будет работать. Но если мы теряем 1 пакет, мы дропаем все пакеты, плюс получаем дополнительные издержки на header’ы пакетов. Поэтому, если вы пишете свой протокол, идеально работать в размере MTU.

Как его посчитать?

На самом деле Google не заморачивается, ставит порядка 1200 байт в своем QUIC и не занимается его подбором, потому что IP фрагментация потом все пакетики соберет.

Мы делаем точно также — сначала ставим какой-то дефолтный размер и начинаем слать пакеты — пусть он их фрагментирует.

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

Таким образом, имея MTU интернет интерфейса, который есть на устройстве, и какое-то минимальное MTU, просто одномерным поиском подбираем правильный MTU. После этого корректируем размер пакета в протоколе.

На самом деле, он иногда меняется. Мы были удивлены, но в процессе переключения Wi-Fi и пр. MTU меняется. Этот параллельный процесс лучше не останавливать и время от времени подправлять MTU.

Выше распределение MTU в мире. У нас на портале получилось около 1100 байт.

Шифрование

Мы говорили, что мы хотим опционально управлять шифрованием. Делаем самый простой вариант — Diffie-Hellman на эллиптических кривых. Делаем его опционально — шифруем только управляющие пакеты и заголовки, чтобы man-in-the-middle не мог получить ключ трансляции, перехватить и так далее.

Если трансляция приватная, то можем добавить еще и шифрование всех данных.

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

Приоритезация

Помните, мы хотели от протокола еще приоритезацию.

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

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

Дополнительная плюшка по поводу UDP

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

На слайде как раз времена, когда не удалось достучаться до клиента с сервера по UDP.

Многие скептики говорят, что маршрутизаторы устроены так, что NAT Unbinding вытесняет в первую очередь именно UDP маршруты. Но выше видно, что если Keep-Alive или ping будет меньше 30 секунд, то с вероятностью 99% будет возможно достичь клиента.

Доступность UDP на мобильных устройствах в мире

Google говорит, что 6%, но у нас получилось, что 7% мобильных пользователей не могут пользоваться UDP. В этом случае мы оставляем наш прекрасный протокол с приоритезацией, шифрованием и всем, только на TCP.

На UDP сейчас работает VOIP по WebRTC, Google QUIC, и многие игры работают по UDP. Поэтому верить, что UDP на мобильных устройствах закроют, я бы не стал.

Снизили задержку между стримером и смотрящим до 1 с.
Избавились от накопительного эффекта в буферах, то есть трансляция не отстает.
Снизилось количество stall’ов у зрителей.
Смогли поддержать на мобильных устройствах FullHD стриминг.

Задержка в нашем мобильном приложении OK Live 25 мс — на 10 мс дольше, чем работает сканер камеры, но это не так страшно.
Трансляция на Web показывает задержку всего 690 мс — космос!

Что еще умеет стриминг на Одноклассниках

Принимает наш протокол OKMP с мобильных устройств;
может принимать RTMP и WebRTC;
выдает на выходе HLS, MPEG-Dash и т.д.

Тут есть нюанс. На самом деле WebRTC — протокол, ориентированный на дроп пакетов, и у него используется аудио кодек OPUS. В RTMP использовать OPUS нельзя.

На серверах бэкенда мы везде используем RTMP. Поэтому нам пришлось сделать еще некоторый фикс в FF MPEG, который позволяет запихнуть OPUS в RTMP, его сконвертировать в AAC и отдать пользователям уже в HLS или еще в чем-то.

Как это выглядит у нас внутри?

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

Расскажу еще немного про отказоустойчивость:

Upload-сервера распределены по разным дата-центрам, стоят за разными IP.
Пользователи приходят, по DNS получают IP.
Upload-сервер отправляет видео на серверы нарезки, те нарезают и отдают серверам раздачи.
Под более популярные трансляции мы начинаем добавлять большее количество серверов раздачи.
Все, что пришло от пользователя, сохраняем в хранилище, чтобы потом создать архив трансляций и ничего не потерять.
Хранилище отказоустойчивое, распределенное по трем дата-центрам.

Тестировать отказоустойчивость будем по-быстрому. Начнем сразу же с пропадания всего дата-центра.

Что при этом произойдет?

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

Использование протокола в продукте

Мы сделали мобильное приложение для стриминга OK Live. Оно полностью интегрировано с порталом. Пользователи там могут общаться, вести прямые эфиры, есть карта эфиров, список популярных эфиров — в общем, все, что можно хотеть.

Также мы добавили возможность вести эфиры в FullHD. К Android-устройству можно подключать action-камеру на Android.

Теперь у нас есть механизм, который позволяет вести прямые трансляции. Например, мы проводили прямую линию с Президентом через OK Live и транслировали ее на всю страну. Пользователи смотрели и через встречный стрим могли попадать в эфир и задавать свои вопросы.

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

На самом деле мы уложились где-то в 2 секунды — секунда туда и секунда обратно. Помните тот «троллейбус», про который я рассказывал в начале статьи — он сейчас выглядит как 2 огромных грузовика. Для ТВ эфира снять с камеры и просто все смикшировать с задержкой в порядка 1-2 с совершенно нормально.

В действительности нам удалось у себя воспроизвести что-то сравнимое с текущими современными ПТС.

Прямые эфиры — это текущий тренд. За последние полтора года на портале ОК они выросли в три раза (не без помощи приложения OK Live).

Все трансляции по умолчанию записываются. У нас порядка 50 тысяч стримов в сутки, это генерирует порядка 17 терабайт трафика в сутки, а вообще все видео на портале генерирует около петабайта данных в месяц.

Что получили мы:

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

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

На Highload++ Siberia Александр Тоболь обещает рассказать про сервис звонков на ОК, будет интересно узнать, что из рассмотренного в этой статье удалось применить, а что пришлось реализовывать совершенно заново.