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. Причина, по которой эта проблема не поднималась прежде, в том, что потоковая передача может выполняться с существенным временем ожидания даже в случае живой трансляции. Если время ожидания не является поводом для беспокойства, то буфера оконечного хоста достаточно, чтобы решить проблему джиттера. Однако для конференций в реальном времени часто важно снизить как задержку, так и джиттер, чтобы оставаться в пределах допустимой задержки. Это не имеет