ARQ (Automatic Repeat reQuest)

ARQ – самый простой механизм надёжности: каждый пакет нумеруется, получатель подтверждает приём или сообщает о пропущенных пакетах, отправитель повторно передаёт то, что было потеряно. Стоимость каждого восстановления – один RTT: получатель должен заметить пропуск, отправить NACK, отправитель – прочитать NACK и переотправить пакет. Для стриминга это означает, что у ARQ-протоколов есть нижняя граница задержки, равная RTT: при RTT 200 мс требуется минимум 200 мс буферизации, чтобы восстановить любой одиночный потерянный пакет.

Противоположность ARQ – это FEC, который заранее передаёт избыточные данные, чтобы приёмник мог восстановить потерянную информацию без round-trip. ARQ экономичен по полосе пропускания (передаётся только то, что потеряно), но чувствителен к задержкам (каждое восстановление требует RTT). FEC требует больше полосы (избыточность передаётся всегда, нужна она или нет), но обеспечивает стабильность по задержкам (не требует дополнительных round-trip). Большинство современных протоколов комбинируют оба подхода: базовый слой FEC компенсирует короткие всплески потерь, а ARQ исправляет то, что FEC не смог восстановить.

SRT и RIST явно настраивают ARQ через окно задержки – 200-миллисекундное окно означает, что «ARQ восстановит всё, что можно ретранслировать за 200 мс; более длительные потери будут отброшены». Оператор подбирает размер окна исходя из RTT канала и допустимого уровня потерь. В TCP ARQ скрыт в ядре и не имеет верхней границы задержки – поэтому стриминговые протоколы на основе TCP, такие как RTMP, ведут себя непредсказуемо на нестабильных соединениях.