Мережі

TCP/IP і шлях запиту

Моделі OSI і TCP/IP, IP, порти, TCP проти UDP

Модель OSI має 7 рівнів, TCP/IP — 4. На співбесіді не потрібно перелічувати всі рівні напам'ять; корисно вміти віднести проблему до рівня:

Канальний/мережевий доступ (Ethernet, Wi-Fi): кабель, MAC-адреси, якість радіоканалу;
Мережевий (IP): адресація та маршрутизація пакетів між мережами. «Хост недоступний», втрата пакетів, MTU;
Транспортний (TCP, UDP): порти, надійність, порядок. «Connection refused», «timeout», розриви з'єднання;
Прикладний (HTTP, DNS, TLS, WebSocket): те, з чим QA працює щодня: методи, заголовки, коди відповіді.

Коли тест падає з «ECONNREFUSED», це транспортний рівень (на порту ніхто не слухає), а не «баг у HTTP». Коли ж приходить 500, TCP і HTTP справні, проблема в застосунку.

IP і порти. IP-адреса (IPv4 або IPv6) вказує на хост, порт (0–65535) — на процес на цьому хості. Звичні порти: 80 (HTTP), 443 (HTTPS), 53 (DNS), 22 (SSH), 5432 (PostgreSQL). Пара «IP + порт» називається сокетом; з'єднання однозначно задають адреси й порти обох сторін. localhost — це 127.0.0.1 (IPv6: ::1); сервіс, що слухає лише 127.0.0.1, недоступний ззовні контейнера чи машини, а 0.0.0.0 означає «усі інтерфейси».

TCP проти UDP.

TCP: з'єднання, гарантована доставка, порядок, контроль потоку й перевантаження. Ціна: handshake і затримка при втратах. HTTP/1.1, HTTP/2, WebSocket, бази даних;
UDP: без з'єднання, без гарантій і порядку, мінімум накладних витрат. DNS-запити, відео/голос, ігри, а також QUIC (на ньому HTTP/3), який надійність реалізує сам.

DNS: розв’язання імені, записи, TTL і кеш

DNS перетворює ім'я на IP-адресу. Типовий ланцюжок: браузер → кеш ОС (і файл hosts) → рекурсивний резолвер провайдера чи корпоративний (8.8.8.8, 1.1.1.1) → за потреби кореневі сервери → сервери TLD (.com) → авторитативний сервер домену, який і дає відповідь. Кожен рівень кешує результат.

A — ім'я → IPv4; AAAA — ім'я → IPv6;
CNAME — псевдонім на інше ім'я (www → app.example.net). На корені домену (apex) CNAME звичайно не ставлять, бо він не може співіснувати з іншими записами;
MX — поштові сервери, TXT — довільний текст (SPF, перевірка власності домену), NS — авторитативні сервери;
HTTPS/SVCB — підказки для клієнта (наприклад, що сервер підтримує HTTP/3).

TTL — скільки секунд відповідь можна тримати в кеші. Довгий TTL — менше запитів, але повільніше застосування змін. Тому перед міграцією сервера TTL зменшують заздалегідь. Негативні відповіді (NXDOMAIN) теж кешуються.

Що це означає для QA.

«На моїй машині працює, а в колеги ні» після зміни DNS — стара відповідь у кеші (ОС, браузера, корпоративного резолвера, JVM/Node-процесу);
Різні відповіді в різних регіонах — геобалансування чи CDN;
ENOTFOUND у Node чи ERR_NAME_NOT_RESOLVED у Chrome — домен не розв'язався (друкарська помилка, відсутній запис, недоступний резолвер, VPN);
Перевірка: dig example.com, dig +short example.com AAAA, dig @1.1.1.1 example.com (інший резолвер), nslookup example.com. Очистити кеш ОС: ipconfig /flushdns (Windows).

TCP handshake, TLS 1.3 і сертифікати

TCP: трикрокове рукостискання. Клієнт надсилає SYN, сервер відповідає SYN-ACK, клієнт — ACK. Після цього дані можна передавати; це коштує один RTT (повний обхід туди й назад). Закриття — через FIN з обох боків, а RST обриває з'єднання негайно. Саме тому:

Connection refused: на порту ніхто не слухає, ОС відповідає RST одразу;
Timeout: відповіді немає взагалі (пакети відкидає фаєрвол, хост вимкнено, маршруту немає);
Connection reset: з'єднання було, але друга сторона його обірвала (RST): падіння процесу, таймаут простою на балансувальнику, закриття сокета.

TLS дає три речі: шифрування, цілісність і автентифікацію сервера (а за потреби й клієнта, mTLS). У TLS 1.3 повний handshake займає один RTT: клієнт у ClientHello одразу надсилає підтримувані шифри, ключову частку та SNI (ім'я хоста, щоб один IP міг обслуговувати багато доменів); сервер відповідає своєю часткою, сертифікатом і підтвердженням; далі все зашифровано. При відновленні сесії можливий 0-RTT, але ці ранні дані вразливі до повтору, тому їх дозволяють лише для безпечних запитів. Застарілі TLS 1.0/1.1 вимкнено.

Сертифікат прив'язує відкритий ключ до імені. Клієнт перевіряє: ланцюжок підписів до довіреного кореневого центру, термін дії, відповідність імені запиту записам SAN (а не лише CN) і статус відкликання (часто через OCSP stapling). Типові помилки:

ERR_CERT_DATE_INVALID — сертифікат прострочений (або неправильний час на машині);
ERR_CERT_COMMON_NAME_INVALID — ім'я не збігається з сертифікатом (звернення за IP чи за іншим доменом);
ERR_CERT_AUTHORITY_INVALID — самопідписаний сертифікат чи відсутній проміжний у ланцюжку;
У корпоративній мережі TLS-інспекція підміняє сертифікати власним коренем: інструменти без цього кореня скаржаться на довіру.

У Playwright самопідписані сертифікати на тестових стендах дозволяють опцією ignoreHTTPSErrors: true (у use або в контексті). Вмикати її слід лише для нешкідливих тестових оточень, а не «на всяк випадок».

Що відбувається, коли ввести URL у браузері

Класичне питання. Сильна відповідь — це не список слів, а послідовність із витратами часу та точками відмови.

Розбір URL: схема (https), хост, порт (443 за замовчуванням), шлях, query. Браузер перевіряє HSTS-список: якщо хост у ньому, http:// одразу замінюється на https://;
Кеші: HTTP-кеш браузера (свіжа відповідь за Cache-Control може віддатися без жодного запиту), Service Worker;
DNS: кеш браузера → ОС → резолвер → авторитативний сервер. Результат — IP (A/AAAA). Вартість: від 0 до сотень мс; точка відмови: NXDOMAIN, недоступний резолвер;
TCP handshake (1 RTT) з IP на порт 443. Точки відмови: refused, timeout;
TLS handshake (1 RTT у TLS 1.3): SNI, перевірка сертифіката, узгодження ключів. Тут же узгоджується протокол прикладного рівня (ALPN): h2 чи http/1.1. Для HTTP/3 браузер дізнається про QUIC з заголовка Alt-Svc чи DNS-запису HTTPS і пробує його паралельно чи при наступному запиті;
HTTP-запит: GET /path із заголовками (Host, Cookie, Accept, ...). Він може пройти CDN, балансувальник, реверс-проксі та інші вузли, перш ніж потрапить до застосунку;
Відповідь: перший байт (TTFB) показує час обробки на сервері й дороги; далі завантаження тіла. Редиректи (3xx) повторюють частину ланцюжка;
Рендер: розбір HTML, завантаження підресурсів (CSS, JS, зображення, API-виклики): кожен може вимагати власного DNS/TCP/TLS (на інший домен) або повторно використати вже відкрите з'єднання; подальше виконання JS.

Як це використовувати: на вкладці Network у DevTools видно, на якому саме кроці йде час (DNS Lookup, Initial connection, SSL, Waiting, Content Download), тому «сайт повільний» перетворюється на конкретну гіпотезу.