Компьютерные сети. 6-е изд.

7.4. Потоковая передача аудио и видео

Помимо электронной почты и веб-приложений, существует еще одна значительная область применения сетей. Для многих краеугольным камнем сетевых технологий стала передача аудио и видео. Слово «мультимедиа» одинаково будоражит и технарей, и коммерсантов. Одни видят в мультимедиа бесконечный источник интересных технических проблем, связанных с обеспечением качественной IP-телефонии или доставки видео по запросу, другие — столь же безграничный источник прибыли.

Хотя идея отправки мультимедиа через интернет появилась еще в 70-х годах прошлого столетия, только в начале XXI века передача аудио и видео в реальном времени (real-time audio; real-time video) стала возможной. Трафик в реальном времени отличается от обычного интернет-трафика: для такой передачи нужно обеспечить заранее определенную скорость воспроизведения, иначе передаваемые данные окажутся бесполезными. Никто не захочет смотреть видео в замедленном темпе и с постоянными прерываниями. Между тем при работе в интернете возникают короткие перебои, а на загрузку страницы может уйти некоторое время (в установленных пределах), но обычно это не является серьезной проблемой.

Такому развитию способствовали две вещи. Во-первых, значительно возросла мощность компьютеров; при этом они стали оснащаться микрофонами и камерами, что дает возможность легко вводить, обрабатывать и выводить аудио и видео. Во-вторых, кратно выросла пропускная способность интернета. Скорость на магистральных линиях в основе интернета достигает многих гигабитов в секунду, а широкополосные и беспроводные (802.11ac) сети обслуживают пользователей на его периферии. Все это позволяет провайдерам пересылать огромные объемы трафика, а пользователи могут подключаться к интернету в 100–1000 раз быстрее по сравнению с обычными телефонными модемами, работавшими на скорости 56 Кбит/с.

С расширением пропускной способности вырос аудио- и видеотрафик, хотя и по разным причинам. Телефонные разговоры занимают сравнительно небольшую часть полосы (64 Кбит/с, а при сжатии еще меньше), но телефонные услуги всегда были дорогими. Компании обнаружили, что можно передавать телефонный трафик по интернету, тем самым снижая свои расходы. Такие стартапы, как Skype, когда-то позволили пользователям звонить бесплатно, по интернет-соединению. Расторопные телефонные операторы нашли дешевый способ передавать обычные голосовые звонки, используя оборудование, предназначенное для выхода в сеть. В итоге многократно возрос объем передаваемых по интернету голосовых данных посредством так называемой интернет-телефонии (Internet telephony); мы поговорим о ней в разделе 7.4.4.

В отличие от аудио, видео занимает значительную часть пропускной способности канала. Интернет-видео приемлемого качества кодируется сжатием, что дает поток со скоростью около 8 Мбит/с в 4K (это 7 Гбайт для 2-часового фильма). До появления широкополосного доступа передача видео по сети была невозможна. Но все изменилось: теперь люди с большим удовольствием смотрят потоковые видео хорошего качества, не выходя из дома. Около четверти пользователей каждый день заходят на популярный видеохостинг YouTube. На смену прокату видеофильмов на кассетах и DVD пришло скачивание из интернета. Огромное количество размещенных в сети видеороликов совершенно изменило структуру интернет-трафика. Уже сегодня большая часть информации в интернете — это видеофайлы, а через несколько лет на их долю будет приходиться около 90 % трафика.

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

В качестве отступления следует сказать, что термин «мультимедиа» (multimedia) часто используется применительно к аудио и видео в интернете. Буквально слово «мультимедиа» означает использование нескольких видов данных. Согласно этому определению, данная книга тоже является мультимедийной презентацией, поскольку содержит текст и графику (иллюстрации). Однако вы вряд ли так себе представляли мультимедийные данные, поэтому здесь под словом «мультимедиа» мы будем понимать использование нескольких видов непрерывных данных (continuous media), для проигрывания которых требуется определенный интервал времени. На практике чаще всего это аудио и видео, то есть звук плюс движущееся изображение. Возможно, когда-нибудь удастся обеспечить непрерывное воспроизведение звука в сочетании с запахами. Многие также ошибочно относят к мультимедийным данным чисто звуковую информацию, используемую, например, в случае интернет-телефонии или интернет-радио. Строго говоря, в таких случаях уместнее термин «потоковые данные». Несмотря на это, мы поддадимся общей тенденции и тоже будем рассматривать аудио в реальном времени как мультимедиа.

7.4.1. Цифровой звук

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

Человеческое ухо способно слышать сигналы в диапазоне частот от 20 до 20 000 Гц, а некоторые животные, например собаки, могут слышать и более высокие частоты. Громкость, воспринимаемая ухом, изменяется логарифмически по отношению к амплитуде, поэтому отношение силы двух звуков с амплитудами A и B обычно измеряется в децибелах (дБ), как 10 log10(A/B). Если принять за 0 дБ нижний порог слышимости (звуковое давление на уровне 20 мкПа) для синусоидальной волны частотой 1 кГц, то громкости обычного разговора будет соответствовать 50 дБ, а болевой порог наступит при силе звука около 120 дБ. Динамический диапазон сигнала (отношение между самыми большими и самыми маленькими значениями) при этом будет больше 1 миллиона.

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

Цифровое аудио — это цифровое представление звуковой волны, которое можно использовать для ее воссоздания. Звук можно преобразовывать в цифровую форму при помощи аналогово-цифрового преобразователя (АЦП). На вход АЦП подается электрическое напряжение, а на выходе формируется двоичное число. На илл. 7.31 (а) показан пример синусоидальной волны. Чтобы представить этот сигнал в цифровом виде, мы можем измерять значения сигнала через равные интервалы времени ΔT (то есть производить квантование сигнала), как показано на илл. 7.31 (б). Если звуковая волна не является чисто синусоидальной, а представляет собой сумму нескольких синусоидальных волн и самая высокая частота ее составляющих равна f, тогда, согласно теореме Найквиста (см. главу 2), для последующего восстановления сигнала достаточно измерять его значения с частотой дискретизации 2f. Производить замеры сигнала с большей частотой нет смысла, так как более высокие частоты в нем отсутствуют.

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

Сжатие звука

Несмотря на то что аудиоданные требуют не такой большой пропускной способности, как видеоданные, звук часто сжимается для того, чтобы сократить требуемую полосу пропускания канала и время передачи. Во всех системах сжатия должно быть два алгоритма: один для сжатия данных на стороне источника и второй для их распаковки на стороне адресата. В литературе они называются алгоритмами кодирования (encoding) и декодирования (decoding). Мы также будем использовать эту терминологию.

Илл. 7.31. (а) Синусоидальная волна. (б) Дискретизация. (в) Квантование сэмплов 4 битами

Важно понимать, что алгоритмы сжатия обладают некоторой асимметрией. Хотя сейчас мы говорим об аудио, это так же справедливо и для видео. В первую очередь, асимметрия проявляется в кодировании исходных данных. Обычно кодирование мультимедийного документа производится только один раз (при его сохранении на мультимедийном сервере), а его декодирование — тысячи раз (при его проигрывании пользователями). Эта асимметрия означает, что ситуа­ция, когда алгоритм кодирования работает медленно и нуждается в дорогом оборудовании, вполне допустима, при условии, что алгоритм декодирования будет быстрым и дешевым.

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

Для сжатия аудиофайлов было разработано множество алгоритмов. Пожалуй, наиболее популярными являются формат MP3 (MPEG audio layer 3 — MPEG36 аудио, уровень 3) и формат ACC (Advanced Audio Coding — усовершенствованное кодирование аудио) в том виде, как он используется в файлах MP4 (MPEG-4). Чтобы не путаться, запомните, что MPEG определяет сжатие аудио- и видеоданных. MP3 обозначает третью, относящуюся к аудиоданным, часть стандарта MPEG-1, а не третью версию стандарта MPEG, на смену которой пришла версия MPEG-4. AAC — это формат, призванный заменить MP3; он применяется по умолчанию для кодирования аудиоданных в стандарте MPEG-4. MPEG-2 позволяет использовать оба варианта кодирования аудиоданных, и MP3, и AAC. Теперь понятно? Что хорошо в стандартах, так это их разнообразие. А если вам не нравится ни один из них, просто подождите год-другой.

Существует два подхода к сжатию звука. При кодировании формы сигналов (waveform coding) сигнал раскладывается на компоненты при помощи преобразования Фурье. В главе 2 мы рассматривали пример разложения в ряд Фурье временной функции (см. илл. 2.12 (а)). Амплитуда каждой компоненты кодируется с минимальными искажениями. Задача в том, чтобы довольно точно воспроизвести форму сигнала, используя для этого как можно меньше битов.

Вторым подходом является перцепционное кодирование (perceptual coding). С учетом недостатков слухового аппарата человека сигнал кодируется так, чтобы слушатель не заметил никакой разницы в звучании, даже если на осциллографе результат выглядит совершенно иначе. В основе перцепционного кодирования лежит область науки, изучающая восприятие звука человеком, — психоакустика (psychoacoustics). И MP3, и AAC используют перцепционное кодирование.

Поскольку в современных мультимедийных системах главным образом применяется перцепционное кодирование, мы подробнее остановимся на этом подходе. Его ключевой особенностью является то, что одни звуки могут маскировать другие. Допустим, вы транслируете живой концерт флейты в теплый летний день. Вдруг, откуда ни возьмись, появляется бригада рабочих и начинает вскрывать на улице асфальт отбойными молотками. Расслышать флейту уже невозможно, и вы передаете только частоты отбойных молотков. Слушатели при этом слышат то же самое, как если бы вы передавали и звуки флейты, а вы экономите пропускную способность. Это называется частотным маскированием (frequency masking).

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

7.4.2. Цифровое видео

Теперь, когда мы узнали все об ушах, пора перейти к глазам. (И нет, в следующем разделе мы не будем обсуждать нос.) У человеческого глаза есть одна особенность: когда изображение появляется на сетчатке, оно сохраняется на ней на несколько миллисекунд, прежде чем исчезнуть. Если картинки сменяются со скоростью 50 изображений в секунду, глаз не замечает, что видит отдельные изображения. Этот принцип получения движущихся изображений используют все видеосистемы с тех пор, как в 1895 году братья Люмьер придумали первый кинопроектор.

Самое простое представление видео — это последовательность кадров, каждый из которых состоит из набора пикселей (прямоугольных элементов, составляющих изображение). Обычно размеры экранов составляют 1280 × 720 (обозначается как 720p), 1920 × 1080 (1080p или HD video), 3840 × 2160 (4K) или 7680 × 4320 (8K).

В большинстве систем используется 24 бита на пиксель, по 8 бит для красного, зеленого и синего (RGB — red, green, blue) компонентов. Красный, зеленый и синий — это первичные аддитивные цвета; любой другой цвет можно получить путем их наложения друг на друга при соответствующей интенсивности.

Раньше частота кадров варьировалась от 24 кадров/с (в традиционном пленочном кино) до 25 кадров/с (в системе PAL, используемой в большинстве стран мира) и 30 кадров/с (в американской системе NTSC). Если быть абсолютно точным, в системе NTSC скорость кадров равна 29,97, а не 30 кадров/с, из-за модификации, проведенной инженерами при переходе от черно-белого телевидения к цветному. Для управления цветом нужно было выделить еще немного полосы пропускания, что удалось сделать, снизив частоту кадров на 0,03 кадра/с. В системе PAL цвет использовался изначально, поэтому здесь частота кадров действительно составляет 25,00 кадра/с. Во Франции применяется слегка отличающаяся система под названием SECAM. Отчасти она была создана, чтобы защитить французские компании от немецких производителей телевизионной техники. Частота кадров в этой системе также составляет ровно 25,00 кадра/с. В 1950-е годы социалистические страны Восточной Европы внедрили у себя SECAM, чтобы население этих стран не могло смотреть передачи западногерманского телевидения (использующие PAL) и поддаваться влиянию «плохих идей».

Чтобы уменьшить полосу пропускания, необходимую для эфирного телевизионного вещания, телестанции взяли на вооружение схему, при которой кадр разделялся на два поля (одно с четными и одно с нечетными строками), передаваемых попеременно. При этом частота кадров фактически составляла не 25 кадров/с, а 50 полей/с. Эта схема называется чересстрочной разверткой (interlacing). Она обеспечивает меньший уровень мерцания, чем при последовательной передаче целых кадров. Современные видеосистемы не используют чересстрочную развертку и просто последовательно передают целые кадры, обычно с частотой 50 кадров/с (PAL) или 59,94 кадра/с (NTSC). Это называется прогрессивной разверткой.

Сжатие видео

Из сказанного выше очевидно, что при передаче видео по интернету критически важно его сжимать. Даже для видео формата PAL с прогрессивной разверткой и разрешением 720p требуется пропускная способность в 553 Мбит/с, а для видео формата HD с разрешением 4K и 8K требуется еще больше. Для разработки международного стандарта сжатия видео, который можно было бы использовать на платформах от любых производителей, комитеты по стандартизации создали Экспертную группу по кинематографии (Motion Picture Experts Group, MPEG). Эта группа разработала стандарты MPEG-1, MPEG-2 и MPEG-4, общий принцип действия которых выглядит следующим образом. С периодичностью в несколько секунд передается полный видеокадр. Кадр сжимается с помощью алгоритма, похожего на привычный алгоритм JPEG для неподвижных цифровых изображений. Затем в течение нескольких секунд вместо отправки полных кадров передатчик отправляет различия между текущим и базовым (последним полным) кадром.

Сначала кратко ознакомимся с алгоритмом JPEG (Joint Photographic Experts Group — Объединенная экспертная группа по фотографии) для сжатия одиночных неподвижных изображений. Вместо того чтобы работать с RGB-компонентами, он преобразует изображение в компоненты яркости (luminance) и цветности (chrominance). Тот факт, что глаз человека намного более чувствителен к яркости, чем к цветности, позволяет использовать для кодирования цветности меньшее количество битов без потери воспринимаемого качества изображения. Затем картинка делится на множество отдельно обрабатываемых блоков, размер которых обычно составляет 8 × 8 или 10 × 10 пикселей. Сигналы яркости и цветности по отдельности подвергаются дискретному косинусному преобразованию Фурье с получением спектра. После этого можно отбросить высокочастотные амплитуды. Чем больше амплитуд отбрасывается, тем более размытым является исходное изображение и тем меньше получаемое на выходе сжатое изображение. Затем к оставшимся амплитудам применяются стандартные методы сжатия без потерь, такие как кодирование по длинам серий или метод Хаффмана. Если этот процесс показался вам сложным, то это так и есть, однако компьютеры легко справляются с выполнением сложных алгоритмов.

Теперь посмотрим, как работают алгоритмы MPEG (в упрощенном виде). Кадр, идущий следом за полным (базовым) кадром JPEG, здесь выглядит почти так же, как в случае алгоритма JPEG. Поэтому вместо того, чтобы кодировать полный кадр, передаются только блоки с отличиями от базового кадра. Блок с фрагментом голубого неба, скорее всего, будет выглядеть так же и через 20 мс, и нет смысла отправлять его снова. Повторно следует передавать только те блоки, в которых произошли изменения.

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

Илл. 7.32. Три последовательных кадра

В реальности этот процесс чуть сложнее. Если блок (например, с актером) присутствует во втором кадре, но с некоторым смещением, алгоритм MPEG позволяет кодировщику сообщить следующее: «Блок 29 предыдущего кадра присутствует в новом кадре со смещением на расстояние (∆x, ∆y), и кроме того, шестой пиксель теперь содержит значения abc, а 24-й пиксель — значения xyz». Это обеспечивает еще большее сжатие.

Ранее мы упоминали об асимметрии между кодированием и декодированием. Здесь мы видим еще один случай такой асимметрии. Кодировщик может сколько угодно искать смещенные и измененные блоки. Так он решает, что лучше: отправить список обновлений предыдущего кадра или новый полный кадр JPEG. При этом поиск смещенного блока требует гораздо больше усилий, чем его копирование из предыдущего кадра и вставка в новый кадр с известным смещением (∆x, ∆y).

На самом деле для полноты картины в MPEG используются не два, а три разных вида кадров:

1. I-кадры (Intracoded — закодированные внутри), которые содержат непо­движные изображения, сжатые независимо от других кадров.

2. P-кадры (Predictive — предиктивные); отражают отличия от предыдущего кадра.

3. B-кадры (Bidirectional — двунаправленные); отражают отличия от следующего I-кадра.

B-кадры требуют, чтобы получатель останавливал обработку до поступления следующего I-кадра, а затем возвращался назад. Иногда это обеспечивает большую степень сжатия, но когда кодировщик постоянно проверяет, что даст результат с наименьшим размером — отличия от предыдущего кадра или отличия от одного из следующих 30, 50 или 80 кадров, это ведет к большим затратам времени на стороне кодирования без больших затрат на стороне декодирования. Эта асимметрия используется по максимуму для того, чтобы обеспечить на выходе файл минимально возможного размера. Стандарты MPEG не определяют, как и на каком расстоянии должен производиться поиск и какой должна быть степень совпадения, чтобы передавать отличия или новый полный блок. Все зависит от конкретной реализации.

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

Обратите внимание, что это несколько упрощенное описание. В реальности данный подход использует еще несколько способов повышения степени сжатия, но изложенные выше основные принципы при этом не меняются. Последняя версия данного формата — это MPEG-4 (MP4). Ее формальное описание представлено в стандарте H.264. Следующей версией H.264 (предназначенной для описания разрешений до 8K) является стандарт H.265. Формат H.264 используется большинством потребительских видеокамер. Поскольку камера должна записывать видео на SD-карту или другой носитель в режиме реального времени, у нее остается совсем немного времени на поиск слегка сместившихся блоков. Как следствие, степень сжатия при этом очень далека от того уровня, который может обеспечить голливудская киностудия, динамически выделив на облачном сервере 10 000 компьютеров для кодирования своего творения. Это еще один пример реального проявления асимметрии между кодированием и декодированием.

7.4.3. Потоковая передача сохраненных медиафайлов

Теперь перейдем к сетевым приложениям. В первую очередь следует обсудить просмотр потокового видео, которое уже хранится где-то на сервере, как в случае с YouTube или Netflix. Самый распространенный пример — онлайн-просмотр видео. Это одна из форм видео по запросу (Video on Demand, VoD). Другие формы VoD для передачи фильмов используют провайдерскую сеть, которая не является частью интернета (например, сеть кабельного телевидения).

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

Илл. 7.33. Воспроизведение медиафайлов по интернету путем обычного скачивания

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

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

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

Медиаплеер решает пять основных задач:

1. Управление интерфейсом пользователя.

2. Обработка ошибок передачи.

3. Декомпрессия сжатых данных.

4. Устранение джиттера.

5. Дешифрование файла.

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

Следующие три задачи связаны друг с другом и зависят от используемых сетевых протоколов. Рассмотрим их по очереди, начиная с обработки ошибок передачи. Ее сложность зависит от того, какой транспортный протокол используется для доставки медиаданных. Это может быть протокол, основанный на TCP (такой, как HTTP) или на UDP, например протокол реального времени (Real Time Protocol, RTP). При использовании транспортного протокола на основе TCP медиаплееру не придется исправлять ошибки, ведь TCP и так обес­печивает высокую надежность за счет повторной передачи. Это упрощает (по крайней мере, для медиаплеера) обработку ошибок, но в то же время усложняет удаление джиттера на более позднем этапе, поскольку тайм-ауты и повторная передача могут приводить к нестабильным и переменным задержкам при воспроизведении фильма.

В качестве альтернативы для передачи данных можно использовать транспортный протокол на основе UDP, например RTP. Такие протоколы не производят повторную передачу данных. То есть потеря пакетов из-за перегрузки или ошибок передачи приведет к тому, что часть медиаданных не будет доставлена. Решать эту проблему приходится медиаплееру. Можно просто игнорировать ее, допуская наличие ошибок в видео и аудио. Если ошибки случаются нечасто, такой подход будет работать и ошибки будут практически не заметны. Другой подход состоит в том, чтобы использовать упреждающую коррекцию ошибок (forward error correction), в частности, путем кодирования видеофайла с некоторой долей избыточности (например, с использованием кода Хэмминга или кода Рида — Соломона). В таком случае у медиаплеера будет достаточно информации для того, чтобы исправлять ошибки самостоятельно, и ему не потребуется запрашивать повторную передачу данных или пропускать поврежденные участки фильмов.

Недостатком этого метода является то, что внесение избыточности в файл ведет к увеличению его размера. Еще один подход сводится к выборочному повтору передачи наиболее важных для воспроизведения контента частей видеопотока. Например, в случае сжатого видеоряда потеря пакета в I-кадре имеет самые серьезные последствия, поскольку ошибки декодирования, возникающие в результате такой потери, могут распространяться на целую группу изображений. С другой стороны, потери в производных кадрах (P- и B-кадрах) наносят гораздо меньший урон. Схожим образом, ценность повторной передачи также зависит от того, успеет ли заново отправленный контент поступить к моменту его воспроизведения. В результате некоторые повторные передачи намного важнее других, и одна из возможных стратегий сводится к тому, чтобы выборочно повторять передачу определенных пакетов (например, пакетов внутри I-кадра, которые придут к моменту воспроизведения). Над RTP и QUIC был надстроен ряд протоколов, обеспечивающих неравномерную защиту от потерь при потоковой передаче видео по UDP; см. работу Фимстера и др. (Feamster et al., 2000), а также Палмера и др. (Palmer et al., 2018).

Третья задача медиаплеера — декомпрессия сжатых данных; это достаточно просто, хотя и затратно с точки зрения вычислений. Сложным моментом является лишь декодирование медиаданных в том случае, когда сетевой протокол не исправляет ошибки передачи. Во многих схемах сжатия данные, полученные позже, невозможно декодировать, пока не будут декодированы предыдущие данные (поскольку более поздние данные кодируются относительно более ранних). Как вы помните, P-кадр строится на основе последнего I-кадра (и всех последующих I-кадров). Если I-кадр поврежден и его не удается декодировать, то все последующие P-кадры бесполезны. При этом медиаплеер вынужден ждать следующего I-кадра, просто пропуская несколько секунд видео.

Из-за этого кодировщик вынужден делать выбор. Если I-кадры идут вплотную, например, с интервалом в 1 с, то пауза в случае ошибки будет незначительной, но видеофайл будет крупнее, поскольку I-кадры намного больше, чем P- или B-кадры. Если I-кадры идут, скажем, с интервалом в 5 с, то видеофайл гораздо меньше, но мы получаем 5-секундную паузу при повреждении I-кадра и паузу меньшего размера при повреждении P-кадра. В силу этого, когда в качестве базового протокола применяется TCP, интервал между I-кадрами может быть намного больше, чем при RTP. Поэтому многие сайты потокового видео используют TCP, чтобы получать файлы меньшего размера с крупными интервалами между I-кадрами и меньшей полосой пропускания, необходимой для плавного воспроизведения.

Четвертой задачей является устранение джиттера, главной проблемы всех систем реального времени. Использование TCP серьезно ее усложняет, поскольку оно вносит случайные задержки каждый раз, когда требуется выполнить повторную передачу. Распространенное решение, к которому прибегают все системы потоковой передачи, сводится к использованию буфера воспроизведения. Перед проигрыванием система буферизует медиаданные для 5–30 с воспроизведения (илл. 7.34). Медиаданные постоянно извлекаются из буфера для отчетливого и плавного воспроизведения звука и видео. Задержка при запуске позволяет заполнить буфер до нижнего предела (low-water mark). При этом ожидается, что в дальнейшем новые данные будут поступать достаточно регулярно для того, чтобы буфер не оказался пустым. Если это все же произойдет, воспроизведение будет остановлено.

Илл. 7.34. Медиаплеер буферизует входящую информацию с медиасервера и воспроизводит медиаданные из буфера, а не напрямую из сети

Буферизация еще больше усложняет процесс. Медиаплеер поддерживает буфер в частично заполненном состоянии, в идеале где-то между нижним и верхним пределами. Это значит, что если объем данных в буфере достигает верхнего предела, плеер сообщает источнику о необходимости прекратить отправку данных, чтобы они не потерялись из-за отсутствия места для их размещения. Верхний предел при этом должен немного не доходить от конца буфера, поскольку потоковая передача данных продолжается, пока медиасервер не получит запрос остановки (STOP). После того как сервер прекращает отправку и канал становится пустым, объем данных в буфере начинает уменьшаться. Когда он достигает нижнего предела, плеер отправляет серверу команду запуска (START), чтобы возобновить потоковую передачу.

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

Механизм запуска и остановки обладает еще одной приятной особенностью: с ним скорость передачи сервера не привязана к скорости воспроизведения. Допустим, плееру нужно воспроизвести видео со скоростью 8 Мбит/с. Когда объем данных в буфере опустится до нижнего предела, плеер запросит у сервера доставку дополнительных данных. Если сервер способен производить доставку со скоростью 100 Мбит/с, это не вызовет проблем. Поступающие данные будут просто сохраняться в буфере. При достижении верхнего предела плеер сообщит серверу о необходимости остановки. Таким образом, скорость передачи сервера и скорость воспроизведения совершенно не зависят друг от друга. То, что изначально было системой реального времени, стало обычной системой передачи файлов. Избавление от всех требований к передаче в реальном времени — одна из причин, почему Youtube, Netflix, Hulu и другие сервисы потоковой передачи используют TCP. Это существенно упрощает дизайн всей системы.

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

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

DASH и HLS

Далее мы коснемся проблем, возникающих из-за многообразия устройств для просмотра мультимедийного контента. Если пользователь купил себе яркий, блестящий и очень дорогой монитор с разрешением экрана 8K, ему нужно предоставлять видео с разрешением 7680 × 4320 и частотой кадров 100 или 120 кадров/с. Но если в ходе просмотра интересного фильма он отправится к врачу и будет досматривать этот фильм в приемной на смартфоне с разрешением 1280 × 720 и максимальной частотой кадров 25 кадров/с, возникнет проблема. Перед сайтом потокового вещания встает вопрос о том, какое разрешение и частоту кадров использовать при кодировании фильмов.

Самый простой выход — использовать все возможные комбинации. В худшем случае место на диске тратится на кодирование каждого фильма с использованием семи разрешений экрана (в формате смартфона, форматах NTSC, PAL, 720P, HD, 4K, 8K) и шести частот кадров (25, 30, 50, 60, 100 и 120). В совокупности мы получаем 42 варианта, но дисковое пространство сегодня стоит не так уж дорого. Более крупной сопутствующей проблемой является вопрос о том, что произойдет, если зритель останется дома со своим большим блестящим монитором, но из-за перегрузок сети пропускная способность канала между ним и сервером будет сильно колебаться, не всегда позволяя использовать полное разрешение.

К счастью, в настоящее время уже реализовано несколько решений этой проблемы, в частности протокол динамической адаптивной потоковой передачи данных по HTTP (Dynamic Adaptive Streaming over HTTP, DASH). Он основан на простой идее и совместим с HTTP (и HTTPS), благодаря чему его можно использовать для потоковой передачи на веб-странице. Сначала сервер потокового вещания кодирует свои фильмы с разным разрешением и частотой кадров, сохраняя их на своих хранилищах. Каждая версия сохраняется в виде множества файлов (вместо одного), которые содержат, скажем, 10 с видео и аудио. Это значит, что для 90-минутного фильма, кодируемого с использованием семи разрешений экрана и шести частот кадров (что дает 42 варианта), потребуется 42 × 540 = 22 680 отдельных файлов с контентом для 10 с воспроизведения. Другими словами, каждый файл содержит сегмент фильма в конкретном разрешении и с определенной частотой кадров. С фильмом ассоциируется манифест — описание представления медиаданных (Media Presentation Description, MPD) — с именами всех файлов и их параметрами, включая разрешение, частоту кадров и номер кадра в фильме.

Чтобы этот подход работал, протокол DASH должен использоваться и плеером, и сервером. В качестве пользовательской стороны может выступать либо непосредственно браузер, либо плеер, встроенный в него в виде JavaScript-кода, либо специальное приложение (например, для мобильного устройства или телеприставки). Перед просмотром фильма DASH прежде всего доставляет манифест для него. Это небольшой файл, поэтому достаточно обычного HTTPS-запроса GET.

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

Но это еще не конец истории. По мере воспроизведения фильма плеер продолжает запускать проверки пропускной способности. Каждый раз, когда ему нужен дополнительный контент (если объем медиаданных в буфере опускается до нижнего предела), он снова сверяется с манифестом и запрашивает подходящий файл в зависимости от того, какая часть фильма требуется и какое разрешение и частоту кадров нужно при этом использовать. Если пропускная способность сильно колеблется по мере воспроизведения, формат фильма может переключаться несколько раз в минуту от 8K при 100 кадрах/с к HD при 25 кадрах/с и обратно. При данном подходе система быстро адаптируется к изменению параметров сети и обеспечивает наилучший опыт просмотра видео в соответствии с имеющимися ресурсами. Такие компании, как Netflix, опубликовали информацию о том, как они корректируют битрейт видеопотока в зависимости от степени заполненности буфера воспроизведения (Хуан и др.; Huang et al., 2014). Пример показан на илл. 7.35.

Илл. 7.35. Использование DASH для изменения формата видео во время просмотра фильма

На илл. 7.35 по мере снижения пропускной способности плеер запрашивает версии со все более низким разрешением. Однако он также мог использовать и другие способы уменьшения объема данных. Например, отправка 300 кадров для 10 с воспроизведения потребует гораздо меньше пропускной способности, чем отправка 600 или 1200 кадров для тех же 10 с (даже с высокой степенью сжатия). В крайнем случае плеер мог запросить черно-белую версию с частотой 10 кадров/с, разрешением 480 × 320 и одноканальным звуком при наличии такой версии в манифесте. Протокол DASH позволяет плееру корректировать воспроизведение согласно меняющимся условиям, тем самым обеспечивая наилучший пользовательский опыт в конкретной ситуации. Логика работы плеера и способ запрашивания сегментов варьируются в зависимости от характера сервиса воспроизведения и особенностей устройства. Сервисы, избегающие повторной буферизации, могут запрашивать множество сегментов целыми группами; если же сервис стремится к максимальной интерактивности, он извлекает DASH-сегменты в более постоянном, размеренном темпе.

Протокол DASH продолжает развиваться. Например, ведется работа по снижению задержки (Ле Февр и др.; Le Feuvre et al., 2015), улучшению надежности (Ван и Рен; Wang and Ren, 2019), повышению равнодоступности (Алтамини и Ширмохаммади; Altamini and Shirmohammadi, 2019), обеспечению поддержки виртуальной реальности (Рибеццо и др.; Ribezzo et al., 2018), а также по эффективной обработке видео формата 4K (Куинлан и Сринан; Quinlan and Sreenan, 2018).

DASH сегодня является самым распространенным протоколом потоковой передачи видео, хотя существуют и другие методы, о которых стоит упомянуть. Протокол потоковой передачи в реальном времени на основе HTTP (HTTP Live Streaming, HLS) от компании Apple также работает в браузере с использованием HTTP. Он рекомендуется для просмотра видео в браузере Safari на устройствах компании Apple (iPhone, iPad, MacBook и т.д.). Он также широко используется браузерами Microsoft Edge, Firefox и Chrome, на платформах Windows, Linux и Android. Кроме того, его часто поддерживают игровые консоли, «умные» телевизоры и другие устройства, способные воспроизводить мультимедийный контент.

Как и DASH, HLS требует, чтобы сервер кодировал фильм с разным разрешением и частотой кадров и каждый сегмент охватывал лишь несколько секунд видео. Это позволяет быстро адаптироваться к изменению условий. Протокол HLS также предлагает и ряд дополнительных функций, включая быструю прокрутку вперед и назад, субтитры на нескольких языках и многое другое. Он описан в RFC 8216.

Несмотря на одинаковые базовые принципы, протоколы DASH и HLS все же имеют некоторые различия. DASH инвариантен к кодеку: он может работать с видео, используя любой алгоритм кодирования. HLS работает только с теми алгоритмами, которые поддерживаются Apple, но поскольку туда входят H.264 и H.265, то этим различием можно пренебречь, ведь с их помощью сегодня сжимаются почти все видео. Протокол DASH позволяет третьей стороне легко вставлять рекламу в видеопоток, в то время как HLS не позволяет этого. С DASH можно использовать любую схему управления цифровыми правами, а HLS поддерживает только систему от Apple.

Протокол DASH — это открытый официальный стандарт, а HLS является проприетарным продуктом. При этом и у первого и у второго есть свои плюсы и минусы. Благодаря тому, что за HLS стоит мощный спонсор, он доступен на гораздо большем числе платформ, чем DASH, и его реализации отличаются чрезвычайной стабильностью. Однако, несмотря на то что на устройствах с iOS нет встроенной поддержки DASH, его используют и YouTube, и Netflix. По всей видимости, в ближайшие годы эти два протокола продолжат существовать параллельно.

Потоковое видео было одной из главных движущих сил интернета на протяжении десятилетий. Ретроспективный анализ этой технологии можно найти в работе Ли и др. (Li et al., 2013).

Актуальная проблема потоковой передачи видео — оценка QoE (то есть того, насколько пользователь доволен работой приложения). Измерить QoE напрямую довольно сложно: для этого пришлось бы опрашивать пользователей. Однако многие операторы сетей стремятся выявлять ситуации, когда потоковые приложения попадают в условия, влияющие на пользовательский опыт. Обычно операторы стараются оценить разрешение и величину задержки при запуске (как долго начинается воспроизведение видео), а также любые случаи остановки («повторной буферизации»). При зашифрованном видеопотоке получение этой информации осложняется, особенно если интернет-провайдер не имеет доступа к клиентскому ПО. В таких случаях оценка качества приложения сегодня все чаще производится с помощью методов машинного обучения (Мангла и др.; Mangla et al., 2018; Бронзино и др.; Bronzino et al., 2020).

7.4.4. Потоковая передача в реальном времени

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

Сегодня живую аудио- и видеотрансляцию осуществляют как отдельные люди, так и компании самых разных масштабов. Вещание в реальном времени стало колыбелью инноваций, возникли новые стандарты и технологии. Чтобы обеспечить онлайн-присутствие, крупные телеканалы транслируются в интернете; это называется IP-телевидением (IP TeleVision, IPTV). Радиостанции также работают онлайн; такое вещание называют интернет-радио. И IPTV, и интернет-радио используются по всему миру для освещения самых разных событий, от показов мод до мировых чемпионатов по футболу и отборочных состязаний по крикету. Помимо этого, с помощью технологии живого IP-вещания провайдеры кабельного телевидения создают собственные вещательные системы. Эта технология широко используется малобюджетными проектами от сайтов для взрослых до зоопарков. При современном уровне технологий практически любой человек может быстро и без значительных затрат начать живое вещание.

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

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

IP-телефония

Хорошим примером потоковой трансляции в реальном времени, при которой невозможна буферизация, является передача телефонного разговора по интернету (иногда с видео, как в случае Skype и FaceTime). Когда-то голосовые звонки передавались коммутируемой телефонной сетью общего пользования, а сетевой трафик был преимущественно голосовым (с небольшим количеством данных). Затем появились интернет и Всемирная паутина. С годами объем данных возрастал, и к 1999 году информационный трафик сравнялся с голосовым (сегодня речь оцифрована, поэтому и то и другое можно измерить в битах). К 2002 году информационный трафик на порядок превысил голосовой, и его экспоненциальный рост продолжается. Между тем объем голосового трафика сохраняется практически неизменным.

В результате телефонные сети стали вытесняться интернетом. На сегодняшний день голосовой трафик передается с помощью интернет-технологий и занимает лишь малую часть пропускной способности сети. Эта прорывная технология известна как IP-телефония (Voice over IP — передача голоса по протоколу IP), или интернет-телефония. Это название относится и к видеоконференциям, когда при разговоре используется видео или в нем участвует больше двух человек.

Самое главное отличие интернет-телефонии от потоковой онлайн-передачи фильмов в том, что в данном случае необходим низкий уровень времени ожидания. В телефонной сети оно составляет не более 150 мс в одном направлении; при превышении этого порога задержка становится заметной и начинает раздражать абонентов. (У международных звонков время ожидания иногда доходит до 400 мс, что дает не слишком приятный пользовательский опыт.)

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

Однако некоторые виды времени ожидания невозможно снизить даже c UDP. Например, расстояние между Сиэтлом и Амстердамом составляет около 8000 км. Задержка распространения со скоростью света в оптическом волокне для этого расстояния равна 40 мс. Пожелаем удачи тому, кто попробует ее сократить! На практике задержка распространения по сети будет больше, поскольку она покроет еще большее расстояние (биты идут не по кратчайшему пути). Кроме того, имеются задержки передачи, так как каждый IP-маршрутизатор сохраняет и пересылает пакет. Эти фиксированные задержки съедают общее допустимое время задержки.

Другой источник времени ожидания связан с размером пакета. Как правило, большие пакеты являются наилучшим способом использования пропускной способности сети, поскольку они эффективнее. Но для звукового сигнала с частотой дискретизации 64 Кбит/с пакет размером 1 Кбайт будет заполняться 125 мс (и даже дольше, если сэмплы сжаты). Такая задержка превысит общее время ожидания. Кроме того, если пакет в 1 Кбайт будет отправлен по широкополосному каналу, скорость которого равна 1 Мбит/с, передача займет 8 мс. Затем добавятся еще 8 мс, чтобы пакет прошел через широкополосное соединение на другом конце. Очевидно, что большие пакеты не подходят.

Вместо этого в системах IP-телефонии используются небольшие пакеты, чтобы сократить время ожидания за счет снижения эффективности использования пропускной способности. Звуковые сэмплы доставляются небольшими блоками, обычно по 20 мс. При скорости 64 Кбит/с это 160 байт данных (и еще меньше при сжатии). Однако задержка при использовании такого пакета составит всего 20 мс. Задержка передачи также будет меньше, потому что пакет короче. В нашем примере она сократится примерно до 1 мс. Минимальная задержка в одном направлении для небольшого пакета Сиэтл — Амстердам снижается с недопустимой — 181 мс (40 + 125 + 16) до приемлемой — 62 мс (40 + 20 + 2).

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

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

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

В главе 5 мы описали два механизма QoS, которые помогают достичь этой цели. Первым механизмом являются дифференцированные службы: пакеты распределяются по классам, получают соответствующую метку и обрабатываются в сети по-разному. Для пакетов IP-телефонии подходит метка низкой задержки. На практике системы устанавливают точки кода дифференцированных служб в общеизвестные значения следующим образом: класс обслуживания — Expedited Forwarding (Беспрепятственная пересылка); тип обслуживания — Low Delay (Низкая задержка). Это особенно полезно для каналов широкополосного доступа, так как они могут перегружаться из-за конкуренции веб-трафика (или какого-либо другого) за линию. При устойчивом сетевом пути задержка и джиттер увеличиваются из-за перегрузки. Для передачи пакета в 1 Кбайт по каналу со скоростью 1 Мбит/с нужно 8 мс, и пакет IP-телефонии примет на себя эти задержки, если он находится в очереди после веб-трафика. Но при наличии метки низкой задержки пакеты IP-телефонии перейдут в начало очереди, обойдя пакеты веб-трафика и снизив задержку.

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

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

Любой из упомянутых выше факторов может сделать время ожидания неприемлемым, поэтому конференц-связь в реальном времени требует внимания к каждому из них. Краткий обзор IP-телефонии вместе с анализом этих факторов можно найти в работе Сан и др. (Sun et al., 2015).

Теперь, когда мы обсудили проблему времени ожидания для потокового мультимедиа, мы перейдем к другому важному вопросу систем проведения конференций: как устанавливать и прекращать вызовы. Мы рассмотрим два протокола, которые широко используются для этой цели, H.323 и SIP. Еще двумя важными системами являются Skype и FaceTime, но поскольку они проприетарные, информация об их внутреннем устройстве закрыта.

H.323

Еще до того как голосовые и видеозвонки стали совершаться по интернету, всем было понятно, что если каждый производитель изобретет собственный стек протоколов, система никогда не будет работать. Чтобы этого избежать, заинтересованные стороны приступили к разработке единых стандартов под руководством МСЭ. В 1996 году МСЭ выпустил рекомендации H.323 под заголовком «Видеотелефонные системы и оборудование для локальных вычислительных сетей, не предоставляющих гарантированный уровень QoS». Такое название могло родиться только в телефонной индустрии. С учетом критики, при пересмотре этих рекомендаций в 1998 году им было присвоено новое название: «Системы мультимедийной коммуникации на основе пакетов». Стандарт H.323 лежал в основе первых распространенных в интернете систем конференций и до сих пор широко используется.

H.323 представляет собой скорее общий обзор архитектуры систем интернет-телефонии, чем конкретный протокол. В данном документе можно найти множество ссылок на различные специализированные протоколы кодирования речи, установления вызова, сигнализации, передачи данных и т.п., однако их описание не приводится. Общая модель изображена на илл. 7.36. В центре находится шлюз (gateway), соединяющий интернет с телефонной сетью. Он поддерживает протоколы стандарта H.323 на стороне интернета и протоколы телефонной сети общего пользования на «телефонной» стороне. Коммуникационные устройства называются терминалами. В LAN может быть привратник (gatekeeper), управляющий конечными узлами, находящимися в ее «юрисдикции», которая называется зоной.

Илл. 7.36. Модель архитектуры H.323 для интернет-телефонии

Работу телефонной сети обеспечивает множество протоколов. Во-первых, необходим протокол кодирования и декодирования аудио и видео. Стандартное телефонное представление одного голосового канала кодируется как цифровое аудио с потоком 64 Кбит/с (8000 сэмплов, 8 бит/с), что определено в рекомендации МСЭ G.711. Все системы H.323 обязаны поддерживать G.711. Поддержка других протоколов кодирования речи разрешена (но необязательна). Они используют иные алгоритмы сжатия и дают другое соотношение между качеством и пропускной способностью. Для сжатия видео выбран формат MPEG, который мы обсуждали ранее (он поддерживается в том числе в H.264).

Поскольку разрешено несколько алгоритмов сжатия, необходим отдельный протокол, который позволил бы терминалам договориться об использовании одного из них. Такой протокол называется H.245. Также он позволяет согласовать другие параметры соединения, например битрейт.

RTCP требуется для управления каналами RTP. Кроме того, нужен протокол для установления и разрыва соединений, обеспечения тонального вызова, генерирования звуков звонков и других стандартных функций телефонной системы. Для этого используется стандарт МСЭ Q.931. Терминалам требуется протокол для ведения переговоров с привратником (если он есть). Для этого разработан протокол H.225. Он управляет каналом между ПК и привратником, который называется каналом RAS (Registration/Admission/Status — Регистрация/Доступ/Статус). Помимо прочего, RAS позволяет терминалам входить в зону и покидать ее, запрашивать и освобождать полосу пропускания, обновлять данные о состоянии и т.п. Наконец, нужен протокол для непосредственной передачи данных. На этом участке работает RTP на основе UDP, и управляется он, как обычно, RTCP. Иерархия всех этих протоколов показана на илл. 7.37.

Аудио

Видео

Управление

G.7xx

H.26x

RTCP

H.225 (RAS)

Q.931

(Передача сигналов)

H.245

(Управление вызовами)

RTP

UDP

TCP

IP

Протокол канального уровня

Протокол физического уровня

Илл. 7.37. Стек протоколов H.323

Чтобы понять, как эти протоколы взаимодействуют между собой, рассмотрим следующий пример. Допустим, ПК (терминал LAN с привратником) совершает вызов на удаленный телефон. Вначале компьютеру нужно найти привратника, поэтому он рассылает специальный широковещательный UDP-пакет через порт 1718. В ответ привратник сообщает свой IP-адрес. Теперь ПК должен у него зарегистрироваться путем отправки RAS-сообщения в пакете UDP. После регистрации компьютер отсылает привратнику RAS-сообщение допуска (запрос на резервирование полосы). Только после выделения этого ресурса можно устанавливать соединение. Предварительное резервирование пропускной способности позволяет привратнику ограничить число соединений на исходящей линии, что обеспечивает необходимое качество обслуживания.

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

Теперь ПК устанавливает TCP-соединение с привратником, чтобы осуществить телефонный звонок. Для этого используются существующие протоколы телефонной сети, ориентированные на установление соединения (поэтому и требуется TCP). Для сравнения, в телефонной системе нет RAS, которые позволяли бы телефонным аппаратам заявлять о своем присутствии. Разработчики H.323 могли выбрать для передачи RAS-сообщений как UDP, так и TCP. Они остановились на UDP — протоколе с наименьшими издержками.

Когда терминалу уже выделена пропускная способность, он может отослать по TCP-соединению сообщение SETUP (стандарт Q.931). В нем указывается номер вызываемого абонента (или IP-адрес и порт, если вызывается удаленный компьютер). Привратник отвечает Q.931-сообщением CALL PROCEDING, подтверждая корректный прием запроса. Затем он пересылает сообщение SETUP на шлюз.

Шлюз (наполовину компьютер, наполовину — телефонный коммутатор) осуществляет стандартный звонок на обычный телефон. Оконечная телефонная станция вызываемого абонента выполняет привычную работу (у абонента раздается звонок), а также отсылает обратно Q.931-сообщение ALERT, извещая ПК о том, что началась серия звонков. Когда абонент поднимает трубку, оконечная телефонная станция отправляет сообщение CONNECT, сообщая компьютеру, что соединение установлено.

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

Для переговоров о параметрах звонка применяется протокол H.245. Он использует всегда открытый управляющий канал H.245. Прежде всего, стороны сообщают о своих возможностях, например о поддержке видео (H.323 может это делать), конференц-связи, используемых кодеках и т.п. После этого создаются два однонаправленных канала, с которыми ассоциируются определенные кодеки и которым присваиваются заданные параметры. Поскольку на каждой из сторон может быть разное оборудование, возможна ситуация, когда каждый однонаправленный канал использует свой кодек. После достижения договоренности по всем вопросам можно начинать передачу данных (по протоколу RTP). Управление производится RTCP, контролирующим перегрузку. Если передаются видеоданные, RTCP занимается синхронизацией аудио- и видеоряда. На илл. 7.38 показаны различные виды логических каналов. Когда на одной из сторон вешают трубку, по каналу Q.931 передается сигнал окончания связи, чтобы высвободить ресурсы, которые больше не нужны после завершения звонка.

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

Мы до сих пор не касались качества обслуживания применительно к H.323, а ведь на самом деле это довольно важный фактор для успешной передачи конференций в реальном времени. Дело в том, что QoS не входит в область рассмотрения H.323. Если сеть способна обеспечить между ПК и шлюзом стабильное соединение без джиттера, значит, нам повезло и QoS во время звонка будет хорошим; в противном случае — плохим. Однако любой телефонный звонок будет лишен перебоев благодаря дизайну телефонной сети.

Илл. 7.38. Логические каналы между звонящим и вызываемым абонентами во время разговора

SIP — протокол установления сеанса

Стандарт H.323 был разработан МСЭ. Многим представителям интернет-сообщества он показался типичным телекоммуникационным продуктом: громоздким, сложным и недостаточно гибким. Было решено организовать специальный комитет IETF для создания более простой и гибкой системы передачи речи поверх IP. Основным результатом деятельности комитета стал протокол установления сеанса (Session Initiation Protocol, SIP), последняя версия которого описана в RFC 3261. Данный протокол определяет способы установления телефонного интернет-соединения, организации видеоконференций и создания других мультимедийных соединений. В отличие от стандарта H.323, представляющего собой целый набор протоколов, SIP — это единый модуль, способный взаимодействовать с разнообразными интернет-приложениями. Например, номера телефонов определяются в виде URL-адресов, то есть на веб-страницах можно размещать гиперссылки, щелкнув по которым пользователь может начать телефонный звонок (аналогично схема mailto позволяет написать e-mail и отправить его по указанному в ссылке адресу).

SIP позволяет устанавливать и двусторонние сеансы (обычные телефонные соединения), и многосторонние (когда каждый из участников может слушать собеседников и говорить), и широковещательные (когда один из участников говорит, а остальные могут только слушать). Во время сеанса связи может передаваться звук, видео или другие данные. Эта возможность используется, например, в сетевых многопользовательских играх в реальном времени. SIP занимается только установлением, управлением и разрывом соединений. Для передачи данных используются другие протоколы, например, RTP/RTCP. SIP — это протокол прикладного уровня, работающий поверх TCP или UDP.

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

Телефонные номера в SIP представлены в виде URL с помощью sip-схемы. Например, sip:ilse@cs.university.edu свяжет вас с пользователем по имени Ilse, хост которого имеет DNS-имя cs.university.edu. SIP URL могут содержать также адреса формата IPv4, IPv6 или реальные номера телефонов.

Протокол SIP является текстовым и построен по модели HTTP. Одна из сторон отсылает ASCII-сообщение, в котором первая строка содержит имя метода, а ниже следуют дополнительные строки с заголовками для передачи параметров. Многие заголовки взяты из стандарта MIME, что позволяет SIP взаимодействовать с существующими интернет-приложениями. Шесть методов базовой спецификации перечислены на илл. 7.39.

Метод

Описание

INVITE

Запрос установления сеанса связи

ACK

Подтверждение установления сеанса

BYE

Запрос окончания сеанса

OPTIONS

Опрос возможностей хоста

CANCEL

Отмена запроса

REGISTER

Информирование сервера переадресации о текущем местоположении пользователя

Илл. 7.39. Методы SIP

Для установки сеанса связи звонящий должен либо создать TCP-соединение с вызываемым абонентом и передать по нему сообщение INVITE, либо отправить это же сообщение в UDP-пакете. В обоих случаях заголовки во второй и всех последующих строках описывают структуру тела сообщения, содержащего информацию о возможностях звонящего, типах мультимедиа и форматах. Если вызываемый абонент принимает звонок, он отсылает в качестве ответа трехзначный код результата, подобный HTTP (группы этих кодов перечислены на илл. 7.26, код 200 означает прием вызова). Следом за строкой с кодом результата вызываемый абонент может также сообщить данные о своих возможностях, типах мультимедиа и форматах.

Соединение устанавливается по протоколу «тройного рукопожатия»; звонящий высылает ACK для окончания работы протокола и подтверждения приема кода 200.

Любая из сторон может отправить запрос окончания сеанса связи, для этого используется метод BYE. Сеанс считается завершенным после получения подтверждения от противоположной стороны.

Метод OPTIONS применяется для опроса возможностей устройства. Обычно это делается перед запуском сеанса связи, чтобы определить, поддерживается ли тип сеанса, на который рассчитывает вызывающая сторона (например, передача голоса по IP).

Метод REGISTER связан со способностью протокола SIP находить пользователя и соединяться с ним, даже если его нет дома. Сообщение с данным методом отправляется на SIP-сервер определения местонахождения, который отслеживает, кто и где находится в данный момент. Позднее с помощью этого сервера можно попробовать найти абонента. Используемая при этом операция переадресации показана на илл. 7.40. Здесь мы видим, что звонящий отправляет сообщение INVITE на прокси-сервер. Это делает возможную переадресацию незаметной. Прокси пытается разыскать абонента и отсылает INVITE по найденному адресу. Далее он действует в качестве ретранслятора для последующих сообщений в «тройном рукопожатии». Сообщения LOOKUP и REPLY не входят в SIP; на этой стадии может использоваться любой подходящий протокол в зависимости от типа сервера определения местонахождения.

Илл. 7.40. Использование прокси-сервера и переадресации в протоколе SIP

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

Сравнительный анализ H.323 и SIP

H.323 и SIP поддерживают как двустороннюю, так и многостороннюю связь. Оконечным оборудованием могут служить как компьютеры, так и обычные телефоны. И там и там стороны предварительно договариваются о параметрах; возможно использование шифрования данных и протоколов RTP/RTCP. Сводная информация о сходствах и различиях представлена на илл. 7.41.

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

Аспект

H.323

SIP

Разработчик

МСЭ

IETF

Совместимость с телефонной системой

Полная

В большой мере

Совместимость с интернетом

Присутствует, с течением времени

Присутствует

Архитектура

Монолитная

Модульная

Завершенность

Полный стек протоколов

SIP обеспечивает лишь установление соединения

Переговоры относительно параметров

Есть

Есть

Сигналы при вызове

Q.931 поверх TCP

SIP поверх TCP или UDP

Формат сообщений

Двоичный

ASCII

Передача мультимедийных данных

RTP/RTCP

RTP/RTCP

Многосторонняя связь

Есть

Есть

Мультимедийные конференции

Есть

Нет

Адресация

URL или номер телефона

URL

Разрыв связи

Явный или разрыв TCP-соединения

Явный или по тайм-ауту

Обмен мгновенными сообщениями

Нет

Есть

Шифрование

Есть

Есть

Объем описания стандарта

1400 страниц

250 страниц

Реализация

Громоздкая и сложная

Умеренно сложная, с отдельными проблемами

Статус

Широко распространен, особенно видео

Хорошая альтернатива, особенно для речи

Илл. 7.41. Сравнение H.323 и SIP

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

36 Motion Picture Experts Group — Экспертная группа по кинематографии. — Примеч. ред.