Термин
Pull-протокол
Стриминговый протокол, в котором приёмник сам инициирует соединение и запрашивает медиау данные у отправителя. К классическим протоколам типа «pull» относятся HLS, DASH и RTSP-из-камеры.
В протоколе pull инициативу берёт потребитель. Плеер или downstream-сервер устанавливает TCP-соединение с URL и читает байты; сервер отправляет нужный сегмент, манифест или RTP-пакет. Pull-архитектура естественна для распространения контента миллионам плееров: каждый плеер – отдельный потребитель, а сервер просто ждёт запросов. HLS и DASH по своей сути являются pull-протоколами, включая live-трансляции: плеер периодически обновляет манифест и запрашивает новые сегменты по мере их появления.
У pull есть два существенных операционных преимущества при масштабировании доставки. Во-первых: на пути может отвечать любой HTTP-кэш, поэтому CDN легко размещается перед origin. Во-вторых: сервер не хранит состояние для каждого зрителя – он не отслеживает, какой клиент получил какой байт, поскольку каждый запрос самодостаточен. Push-каналы вынуждены поддерживать сессии, что усложняет масштабирование и ухудшает отказоустойчивость между регионами.
Слабое место pull – задержка. Каждый сегмент должен быть сначала опубликован, прежде чем плеер сможет его запросить, и каждый запрос добавляет round-trip. LL-HLS и LL-DASH решают эту проблему с помощью HTTP/2 с chunked transfer и блокирующей перезагрузки плейлиста, но pull всегда проиграет push в минимальных задержках – поэтому WebRTC и WHEP, хотя и начинаются с HTTP-рукопожатия, после установления SCTP/SRTP работают как push-стриминг.
Считаете параметры для своего продукта?
Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.