Packet loss

Потеря пакетов происходит, когда IP-пакет покинул отправителя, но не достиг получателя – был отброшен перегруженным маршрутизатором, повреждён шумным радиоканалом или заблокирован неправильно настроенным файрволом. Для TCP и QUIC потери незаметны для приложения: транспортный уровень сам выполняет повторную передачу, и приложение воспринимает лишь кратковременное увеличение задержки. В случае UDP-ориентированных протоколов реального времени (WebRTC, SRT, RIST) потери видны напрямую, и именно приложение само определяет, как на них реагировать.

У стриминговых протоколов три классических подхода. ARQ (automatic repeat request, в SRT и TCP) просит отправителя переслать потерянные данные – на восстановление уходит один RTT. FEC (forward error correction, в WebRTC и RIST) передаёт избыточные parity-пакеты, чтобы приёмник мог восстановить потерянное без ожидания – это требует дополнительной полосы пропускания. И, наконец, graceful degradation: специально для видео энкодер формирует кадры так, чтобы декодер мог отбросить потерянные и продолжить воспроизведение на пониженном качестве.

Потери редко бывают равномерными. В реальных сетях они bursty – короткая коллизия в Wi-Fi может привести к потере пяти пакетов подряд. Протоколы вроде SRT анализируют профиль потерь и подбирают размер окна ретрансмиссии под самый длинный ожидаемый burst. При потерях до 0,5 % большинство стриминговых протоколов работают стабильно. В диапазоне от 0,5 % до 3 % становится важным выбор между FEC и ARQ. При потерях выше 3 % требуется серьёзная инженерия – например, bonded-транспорт (SRT bonding, multi-path QUIC) или снижение битрейта до уровня, который укладывается в оставшуюся пропускную способность.