Друзі, привіт. Як ваш день? Продовжуємо рубрику, де 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,а людина, яка реально розуміє мережу. Всім гарного дня і настрою)Сильні 💛💛💛