07. Війна із Затримкою (Latency)

1. Вступ та Контекст

Ви дивитесь футбольний матч онлайн. Раптом ваш сусід кричить "ГОООЛ!", а у вас на екрані м'яч ще в центрі поля. Це — затримка (Latency).

У світі стрімінгу є три категорії:

1. High Latency (30с - 1хв): Класичне ТБ, старий HLS. Максимальна надійність.
2. Low Latency (3с - 10с): Сучасний стрімінг (Twitch, YouTube Live). Компроміс.
3. Real-time (< 500мс): Zoom, Google Meet, WebRTC. Живе спілкування.

Чому ми не можемо мати все й одразу (якість 4K і нульову затримку)? Тому що Інтернет ненадійний.

2. TCP vs UDP: Надійність проти Швидкості

Уявіть, що ви надсилаєте листи (пакети) поштою.

TCP (Transmission Control Protocol)

Це "Рекомендований лист з повідомленням про вручення".

1. Ви відправляєте лист №1.
2. Чекаєте, поки одержувач скаже: "Отримав №1".
3. Тільки тоді відправляєте №2.
4. Якщо №2 загубився — ви відправляєте його знову. Результат: 100% листів дійдуть у правильному порядку. Але це довго. Використання: HLS, DASH (HTTP).

UDP (User Datagram Protocol)

Це "Викидання листівок з вікна потяга".

1. Ви кидаєте №1, №2, №3, №4...
2. Вам байдуже, чи дійшли вони.
3. Якщо №3 загубився — ну й грець з ним, ми вже на №10. Результат: Максимальна швидкість. Але можливі "артефакти" (розсипання картинки). Використання: WebRTC, RTP (Zoom, Skype).

3. Спектр Протоколів

Case Study: Twitch

Twitch використовує модифікований HLS (Low Latency). Чому не WebRTC? Тому що WebRTC важко масштабувати. Роздати UDP-потік на 1 мільйон глядачів — це інженерний кошмар. HLS (через TCP/HTTP) легко кешується на CDN. Тому Twitch має затримку ~5 секунд. Це компроміс: достатньо швидко, щоб чат реагував на стрімера, але достатньо надійно для мільйонів.

4. Демонстрація: Затримка в Реальному Часі

5. Резюме

• Latency — це ворог №1 для інтерактивності.
• Щоб зменшити затримку, ми жертвуємо буфером (надійністю) та якістю.
• WebRTC — для дзвінків (мало учасників, миттєво).
• LL-HLS/DASH — для трансляцій (багато учасників, невелика затримка).