Продовжуємо рубрику, де QA перестає вірити “на слово” і починає розуміти, що реально відбувається в мережі.
Протоколи для QA - STUN
Що я маю вам сказать.
STUN - це той самий протокол, про який згадують тільки тоді, коли дзвінки не дзвонять, відео не стартує, а WebRTC “чомусь не працює”.
STUN (Session Traversal Utilities for NAT) - це спосіб для клієнта зрозуміти: яка в мене зовнішня IP або через який порт я виходжу чи я взагалі доступний ззовні
Якщо прям супер просто то
STUN допомагає клієнту сказати серверу:
«Ось як я виглядаю в інтернеті, а не в себе вдома за роутером».
Бо 90% проблем у WebRTC виглядають однаково: я думаю ви і сами на таке натрапляли коли чорний екран/ нема аудіо/ камера “німа”/ reconnect без кінця
І дуже часто це не баг ЮА і не бекенд а це NAT + STUN.
Виглядає в реальності це саме так
Клієнт відправляє STUN-запит на STUN-сервер
Сервер відповідає:
- типо твій public IP такий
- а ось твій public port такий
І вже з цим WebRTC пробує побудувати пряме з’єднання.
Якщо STUN не працює: то WebRTC навіть не стартує ну і ICE-кандидати не формуються і далі хоч 100 разів refresh - нічого не буде
Дуже типові баги, які насправді STUN: і на які ви точно потряплали це
- працює в офісі, не працює вдома
- працює через Wi-Fi, не працює через мобільну мережу
- працює у девів, не працює у клієнтів
- після VPN все ламається
Куа повинен хотяб мінімум знати як такі базові речі перевірити
Подивитись STUN-трафік у Wireshark:
stun
Або разом з WebRTC:
stun turn rtp || rtcp
Перевірити, чи взагалі йдуть STUN-запити:
- якщо їх нема → WebRTC навіть не стартував
- якщо є, але нема відповіді → мережа або firewall
Знати стандартні STUN-сервери (для тестів):
- stun.l.google.com:19302
- stun1.l.google.com:19302
Що я хочу донести
STUN - це не “щось для девів”.
Це базова частина діагностики real-time систем.
Без STUN:
КУА бачить “не працює”.
З STUN:
КУА бачить чому не працює.
І в цей момент ви вже не просто QA,
а людина, яка реально розуміє мережу.
Всім гарного дня і настрою)
Сильні 💛💛💛