Сподіваюсь ви та ваші близькі в безпеці.
Давайте сьогодні трохи спустимось нижче браузера, Postman і красивих UI-кнопочок. всеж кінець тижня треба чучуть подумати?)))
Протоколи для QA
Що я маю вам сказати одразу: іноді проблема виглядає так: “апка не конектиться” “дзвінок не стартує” “дані не приходять” “сервер живий, але клієнт каже timeout” тощо - причин мільон і ви без мене з цим стикалися і знаєте
І дуже часто це не UI, не API і навіть не завжди бекенд. Це може бути рівень нижче: порт не слухається/ TCP-з’єднання не встановилось або UDP пакети не доходять ну і DNS резолвиться не туди чи краше firewall ріже трафік тобто стільке же причин як і проблем - ага?))
давайте коротко ще раз TCP - це коли важлива доставка, порядок і контроль.
тобто це все що HTTP / HTTPS/ SSH / WebSocket і деякі REST API. Працює вроді складно, але просто)
Клієнт каже типо щось я хочу підключитись і ось мій SYN
Сервер відповідає: ок, бачу тебе ось мій SYN-ACK
Клієнт підтверджує: ACK, погнали працювати І тільки після цього нормально йдуть дані.
UDP -це вроді одна історія але це вже інша історія. Тут вже швидкість важливіша за гарантії. тут вже буде DNS/ VoIP/ RTP/ WebRTC media/ стрімінг/ і UDP просто відправив пакет і далі вже як життя складеться)
Для кастомерів це може виглядати типо так нема звуку/ нема відео / дзвінок підключився, але медіа не йде/ realtime працює нестабільно а для КУА це вже сигнал: треба дивитись нижче.
Реально знати на рівні лінукса корисно і мати цим користуватися)
ss -tulnp
Показує вам, які TCP/UDP порти слухаються і який процес їх використовує.
Типо щось
ss -tan
Показує TCP-з’єднання і їх стани. Тут можна побачити:
- ESTAB - з’єднання встановлено
- SYN-SENT - клієнт стукає, але відповіді нема
- TIME-WAIT - з’єднання вже закривалось
- CLOSE-WAIT - апка могла не закрити connection нормально
Можно ще 1 корисну штуку
nc -vz server.com 443
Це перевірка, чи доступний TCP-порт і тут важливо не плутати:
- Connection refused - хост доступний, але порт закритий або сервіс не слухає.
- Connection timed out - відповіді нема. Може бути firewall, routing або network issue.
а ось це окремий кайф це tcpdump або udp
sudo tcpdump -i any port 443
sudo tcpdump -i any udp
це тут коли треба розуміти чи пакет взагалі виходить чи приходить відповідь або є DNS-запит чи UDP реально йде ну і сервер сам закриває з’єднання
Це як 1 криклад вам розбору умовно є баг: “Клієнт не може підключитись до сервера” ну і тут І замість просто написати “не працює”, можна перевірити:
ping server.com
nslookup server.com
nc -vz server.com 443
ss -tan | grep 443
sudo tcpdump -i any host server.com
І потім у баг-репорті написати вже нормально: типо щось “Під час спроби підключення клієнт відправляє TCP SYN на server.com:443, але SYN-ACK у відповідь не приходить. З’єднання залишається в SYN-SENT і завершується timeout.” Оце вже звучить як куа, який прийшов не просто кнопку натиснути)
Що я хочу до вас донести Linux-рівень для КУА - це не про “стати адміном”. Це про те, щоб коли апка каже: “Something went wrong” і ви могли зрозуміти, де саме проблема
Іноді один
ss або tcpdump дає більше, ніж 30 хвилин кліків по UI.Всім гарного дня і наближення вихідних)
Сильні💛
Обняв 🤗