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

Цепочка от камеры до зрителя

Поток проходит четыре звена: захват, кодирование, доставку и воспроизведение. Слабым окажется любое – а узким становится то, о котором забыли.

Захват даёт сырой сигнал, и его сразу кодируют. Для веба сегодня это H.264 в контейнере FLV или MP4 – он держит приемлемое качество при 500–1500 кбит/с и понятен всем плеерам. Кодировщик ставят рядом с источником: гонять несжатый поток по сети нельзя.

Дальше – транскодирование в несколько битрейтов. Зритель на офисном канале и зритель через GPRS требуют разных версий одного эфира. Поэтому медиасервер (Wowza, Adobe Flash Media Server, Red5) готовит лесенку профилей: 240p, 360p, 480p. Это не роскошь, а способ не потерять половину аудитории на первой же буферизации.

Доставка: где живёт нагрузка

Один сервер раздать поток тысячам клиентов не способен – упрётся в полосу и в число соединений. Нагрузку снимают двумя приёмами.

Первый – протокол. RTMP через Flash даёт минимальную задержку и держит постоянное соединение, но плохо проходит через корпоративные фаерволы и нагружает сервер каждым коннектом. HTTP-стриминг (Apple HLS, нарезка потока на короткие сегменты) отдаётся обычными веб-серверами и кешируется как статика. Для массовой трансляции HLS выигрывает: его раздаёт любой кеширующий узел, а не специализированный медиасервер.

Второй приём – CDN и реверс-кеширование. Сегменты HLS складываются на edge-узлы ближе к зрителю. Origin-сервер обслуживает только промахи кеша, а это сотни запросов вместо десятков тысяч. Те же принципы горизонтального масштабирования и отсечения нагрузки на периферии мы разбирали в материале о высоконагруженных госуслугах – для видео они работают так же, только объёмы трафика на порядок выше.

Резервирование закладывают сразу: два независимых кодировщика, два аплинка, география edge-узлов с запасом. В прямом эфире повторного дубля не будет.

Плеер и совместимость

Раздать поток мало – его надо воспроизвести у максимума зрителей без установки плагинов. Здесь компромисс между охватом и контролем. Flash-плеер по-прежнему стоит почти везде и умеет RTMP «из коробки», но на мобильных устройствах Apple его попросту нет. HTML5-видео решает мобильную часть, но единого формата для живого потока в браузерах пока не сложилось. Практический выбор и его границы мы подробно сравнивали в разборе HTML5 против Flash.

Рабочая схема на сегодня – определять клиента и отдавать ему совместимый вариант: Flash + RTMP для десктопа, HLS для устройств Apple, деградация качества вместо обрыва на слабом канале.

Вывод

Трансляция под нагрузкой – это не «поставить сервер с видео», а спроектированная цепочка: кодирование рядом с источником, лесенка битрейтов, HTTP-доставка через кеширующие узлы и плеер под каждое устройство. Слабое звено проявится ровно в момент пика, когда исправлять уже поздно. Инфраструктуру трансляции под реальный, а не тестовый трафик стоит проектировать с расчётом нагрузки заранее: считать пик, закладывать резерв и проверять систему до эфира, а не во время него.