DNS, IP, порти та мережа

Що таке IP-адреса і навіщо вона потрібна?

IP-адреса — це числовий ідентифікатор вузла в мережі, за яким пакети даних знаходять дорогу до потрібного компʼютера. Аналогія проста: як лист знаходить будинок за поштовою адресою, так пакет знаходить машину за IP. Домени, порти й протоколи вищого рівня — це надбудова: на мережевому рівні маршрутизація йде саме за IP. Для тестувальника це означає, що будь-який запит із тесту зрештою летить на конкретну IP-адресу, навіть якщо в конфігу написано красиве імʼя app.example.com.

Чим відрізняються IPv4 та IPv6?

Це дві версії протоколу IP з різною довжиною адреси. IPv4 використовує 32 біти й записується як чотири десяткові октети від 0 до 255 через крапку (192.168.0.14) — це дає приблизно 4,3 мільярда адрес, яких сучасному інтернету не вистачає. IPv6 використовує 128 біт і записується як вісім груп шістнадцяткових цифр через двокрапку, зі скороченнями: провідні нулі опускають, а один ланцюжок нульових груп згортають до :: (наприклад, 2001:db8:85a3::8a2e:370:7334). Дефіцит IPv4-адрес породив NAT і сам перехід на IPv6, де адрес вистачає з величезним запасом. Багато вузлів сьогодні двостекові (dual-stack): мають обидві адреси, і клієнт пробує їх майже паралельно за алгоритмом Happy Eyeballs — з невеликою перевагою для IPv6.

Що таке localhost і чим він відрізняється від 127.0.0.1?

localhost — це імʼя, яке за угодою резолвиться в loopback-адресу: 127.0.0.1 для IPv4 або ::1 для IPv6, тобто «сам до себе». Відповідність зазвичай прописана в системному файлі hosts, тому працює навіть без DNS. Loopback означає, що трафік не виходить за межі машини: сервіс на 127.0.0.1:3000 видно лише зсередини цієї машини чи контейнера. В автотестах localhost — типовий baseURL для локально піднятого застосунку, і саме тут ховається класична пастка «у мене працює, а в CI ні», коли сервіс у контейнері слухає loopback замість усіх інтерфейсів.

Що таке DNS і яку проблему він вирішує?

DNS (Domain Name System) — розподілена ієрархічна система, що перекладає доменні імена в IP-адреси, як телефонний довідник перекладає імʼя в номер. Але зручність запамʼятовування — не єдина мета: DNS розвʼязує звʼязок «імʼя — адреса», і цей рівень непрямості дає гнучкість. Один сайт може стояти за багатьма IP (балансування навантаження), адресу сервера можна змінити, не чіпаючи імені, а за одним IP можуть жити десятки доменів. Крім адрес, DNS зберігає й інші записи: A (IPv4), AAAA (IPv6), CNAME (псевдонім), MX (пошта), NS (авторитетні сервери зони), TXT (довільний текст для верифікації домену тощо).

Що таке порт і навіщо він потрібен, якщо вже є IP-адреса?

IP-адреса веде до машини, але на машині одночасно працюють десятки програм — порт визначає, до якого саме сервісу йде зʼєднання. Це 16-бітне число від 0 до 65535; аналогія: IP — адреса будинку, порт — номер квартири. IANA ділить порти на діапазони: 0–1023 — well-known (системні сервіси), 1024–49151 — registered (порти застосунків), 49152–65535 — динамічні/ефемерні для клієнтських зʼєднань. Типові номери варто знати напамʼять: 80 — HTTP, 443 — HTTPS, 22 — SSH, 53 — DNS, 5432 — PostgreSQL, 6379 — Redis, 8080 — альтернативний HTTP для dev-серверів. Локально перевірити, хто зайняв порт, можна командою lsof -i :3000, а доступність порту на віддаленому хості — nc -zv host 443.

Чому https://example.com і https://example.com:443 — це те саме?

Для стандартних схем порт мається на увазі за замовчуванням: 80 для http і 443 для https, тому його можна не писати. Браузер сам підставляє потрібний порт, виходячи зі схеми URL. А ось нестандартний порт треба вказувати явно: якщо dev-сервер слухає 8080, а в тесті написано просто http://localhost, браузер піде на порт 80 і зʼєднання не відбудеться. Це типова причина «сервер запущений, а тест не конектиться» — варто першим ділом звірити порт у baseURL з портом, який реально слухає процес.

Розкажи покроково, як DNS резолвить домен, коли кешу ще немає.

Застосунок через системний stub resolver питає рекурсивний резолвер (провайдерський або публічний на кшталт 8.8.8.8 чи 1.1.1.1) — і далі той бере всю чорнову роботу на себе. Резолвер питає кореневі сервери, ті не знають кінцевої адреси, але вказують TLD-сервери зони .com; TLD-сервери відсилають до авторитетних серверів домену example.com; авторитетний сервер повертає A-запис із реальним IP. Відповідь їде назад до застосунку й осідає в кешах — браузера, ОС, самого резолвера, — тому наступні запити віддаються майже миттєво. Ключова різниця в термінах: рекурсивний резолвер зобовʼязаний дійти до кінцевої відповіді, а кореневі/TLD/авторитетні сервери відповідають лише за свій шматок ієрархії і часто повертають referral — «питай далі отам». Для тестів наслідок практичний: «холодний» перший резолв додає час до відкриття сторінки, і на тісних таймаутах це вже привід для flaky.

Що таке TTL у DNS-записі й до яких проблем він призводить у тестових середовищах?

TTL (Time To Live) — число секунд, скільки DNS-відповідь дозволено тримати в кеші; поки TTL не вичерпано, використовують кешоване значення, після — перезапитують. Побачити його можна у відповіді dig +noall +answer app.example.com — число поруч із типом запису. TTL — компроміс: великий зменшує навантаження й пришвидшує відповіді, малий дає швидко перемкнути трафік на нову адресу. Практична проблема: якщо тестовий стенд нещодавно змінив IP, а десь у ланцюжку кешів живе старий запис із довгим TTL, тести стукають за застарілою адресою й падають без видимої причини в застосунку. Обхідний шлях — прописати домен у файл hosts на CI-раннері, але про такий запис легко забути й потім довго дивуватись загадковій поведінці.

Чим відрізняються TCP і UDP? Коли обирають один, а коли інший?

TCP дає надійний упорядкований потік байтів: встановлює зʼєднання рукостисканням, перевідправляє загублені пакети, збирає їх у правильному порядку, контролює швидкість (flow/congestion control) — ціною вищих накладних витрат і затримки на старті. UDP робить мінімум: шле датаграми без зʼєднання й без гарантій — пакет може зникнути або прийти не по черзі, зате швидко. Логіка вибору: важлива цілісність — TCP (HTTP/1.1 і HTTP/2, пошта, файли); важлива швидкість і невеликі втрати терпимі — UDP (живе відео, де перепитувати старий кадр немає сенсу, ігри). DNS зазвичай ходить по UDP на порт 53, а на TCP переходить для великих відповідей (з прапорцем truncated) і передачі зон. Окремий випадок — HTTP/3: він працює поверх QUIC на UDP, але надійність і впорядкування QUIC реалізує власними засобами.

Що таке трикрокове TCP-рукостискання і чому воно важливе для швидкості тестів?

Перш ніж передати хоч байт даних, TCP встановлює зʼєднання за три кроки: клієнт шле SYN (хочу зʼєднатися, ось мій початковий номер послідовності), сервер відповідає SYN-ACK (згоден, ось мій номер), клієнт підтверджує ACK — і канал готовий. Для HTTPS поверх цього накладається ще TLS-рукостискання з обміном ключами, тож до першого корисного байта проходить кілька round trips. Кожне рукостискання — це затримка, помножена на відстань до сервера, тому відкриття першого зʼєднання помітно довше за наступні запити тим самим зʼєднанням (keep-alive, а в HTTP/2 — ще й мультиплексування). Звідси типова картина в автотестах: перший крок повільніший за решту, перший прогін «холодний», і якщо таймаути виставлені без запасу на встановлення зʼєднання — тести миготять.

У чому різниця між доменом та IP-адресою? Чи завжди це «один до одного»?

Домен — людиночитане імʼя, IP — числова адреса, куди реально йде трафік, і звʼязок між ними не один-до-одного. Один домен може резолвитись у багато IP (балансування навантаження між серверами), багато доменів можуть жити на одному IP (віртуальний хостинг — сервер розрізняє їх за іменем із заголовка Host або SNI), а той самий домен у різних місцях світу дає різні IP (CDN). Практичний висновок для тестів двобічний. Якщо звертатися напряму за IP замість домену, можна не потрапити на потрібний віртуальний хост або зламати перевірку сертифіката — він виданий на імʼя, а не на IP. І навпаки: підмінивши в hosts домен на IP конкретного стенда, можна детерміновано спрямувати всі тести саме туди, обійшовши балансування й CDN.

Сервіс піднято на 127.0.0.1:3000 — локально тести проходять, а в CI в контейнері не достукуються. У чому справа?

Це класична плутанина між 127.0.0.1 та 0.0.0.0. Адреса 127.0.0.1 — loopback: сервер, що слухає її, приймає зʼєднання лише зсередини тієї самої машини або контейнера. 0.0.0.0 означає «слухати всі інтерфейси» — такий сервер доступний і ззовні контейнера. Коли тести й застосунок живуть в окремих контейнерах CI, сервіс на loopback для сусіднього контейнера просто не існує — зʼєднання відхиляється, хоча локально (де все в одній машині) усе працює. Рішення — запускати сервіс під тести на 0.0.0.0 або зводити тести й застосунок в один мережевий простір; головне — розуміти, що це не «магія CI», а детермінована поведінка адрес.

Що таке приватні діапазони IP-адрес і NAT?

Діапазони 10.0.0.0/8, 172.16.0.0/12 і 192.168.0.0/16 — приватні: вони не маршрутизуються в публічному інтернеті й використовуються в домашніх, офісних і CI-мережах, у docker-мережах. Запис через скісну риску — CIDR-нотація: число після риски каже, скільки старших біт зафіксовано як префікс мережі; /16 лишає 16 біт під адреси вузлів — приблизно 65 тисяч. Щоб машина з приватної мережі вийшла назовні, роутер підміняє її адресу на свою публічну — це NAT (Network Address Translation), один із механізмів, завдяки яким IPv4 досі живий попри дефіцит адрес. Для AQA це буденність: тестові стенди часто живуть у приватних мережах, і достукатися до них із публічного інтернету без VPN неможливо — це треба закладати в налаштування CI.

Що таке ефемерні порти і чому браузер може тримати багато зʼєднань до одного сервера?

Коли клієнт відкриває зʼєднання, ОС виділяє йому тимчасовий (ephemeral) порт як зворотну адресу. Кожне TCP-зʼєднання унікальне четвіркою «джерело-IP : джерело-порт — призначення-IP : призначення-порт», тому браузер спокійно тримає багато паралельних зʼєднань до одного сервера: у кожного свій локальний порт, і четвірки не збігаються. Тонкість, яку цінують на співбесідах рівня senior: фактичний ефемерний діапазон залежить від ОС і часто відрізняється від рекомендованого IANA 49152–65535 — у Linux за замовчуванням це 32768–60999, керується параметром net.ipv4.ip_local_port_range. Тож на цільовій системі діапазон варто перевіряти, а не покладатися на теоретичні межі. Суміжна CI-проблема — фіксований порт сервера: якщо попередній прогін не завершився і порт зайнятий, запуск падає з address already in use, тому фреймворки або підбирають вільний порт динамічно, або вимагають чистого стану між прогонами.

Чим затримка (latency) відрізняється від пропускної здатності (bandwidth)?

Затримка — час, за який дані доходять від точки до точки (часто міряють як RTT, round-trip time, у мілісекундах); пропускна здатність — скільки даних канал пропускає за одиницю часу (Mbps). Аналогія з трубою: пропускна здатність — діаметр (скільки води за секунду), затримка — довжина (скільки летить перша крапля); широка труба не скоротить подорож однієї краплі, тому канал може мати величезну смугу й водночас велику затримку — типовий приклад, супутниковий інтернет. Для тестів розрізнення прикладне: сценарії з багатьма дрібними API-викликами страждають насамперед від затримки (кожен запит платить свій RTT, і вони складаються), а завантаження великих файлів впирається у смугу. Емуляція мережі в браузері (throttling) дозволяє штучно підняти затримку чи обрізати смугу — корисний спосіб відтворити flaky-поведінку, яка на швидкій машині розробника ніколи не виникає.

Що таке проксі? Чим forward proxy відрізняється від reverse proxy і як проксі використовують у тестуванні?

Проксі — сервер-посередник: клієнт звертається до нього, а він говорить із цільовим сервером від свого імені й повертає відповідь. Прямий проксі (forward) стоїть з боку клієнта — через нього виходять у мережу, він кешує, фільтрує, логує. Зворотний (reverse) стоїть перед серверами сервісу — приймає зовнішні запити, розподіляє їх між внутрішніми серверами, термінує TLS, кешує статику; приклади — nginx, HAProxy. Оскільки проксі бачить увесь трафік, він може його інспектувати та змінювати — на цьому будується головний сценарій для AQA: перехоплювальний проксі (mitmproxy, Charles, Fiddler) показує реальні запити й відповіді та дозволяє їх підмінити. Той самий принцип вбудований у фреймворки автотестів: у Playwright page.route перехоплює запит усередині браузера й через route.fulfill повертає фейкову відповідь чи імітує 500-ту, а route.abort — обрив мережі. Усе це — способи прибрати зовнішні джерела флаку й зробити перевірку детермінованою.

Що робить VPN із трафіком і чого він не робить? Як VPN впливає на автотести?

VPN створює зашифрований тунель між машиною і VPN-сервером: локальна мережа й провайдер бачать лише факт зʼєднання з VPN, а для цільового сайту джерелом запиту виглядає VPN-сервер, а не ти. Це дає три речі: захист у ненадійних мережах, підміну видимого географічного розташування (корисно тестувати геозалежну поведінку — мову, ціни, редиректи) і доступ до закритих корпоративних мереж із внутрішніми стендами. Чого VPN не робить: не дає анонімності й не шифрує весь шлях — після VPN-сервера трафік іде до сайту звичайним чином, захищений хіба що власним TLS. Для AQA VPN виступає у двох ролях: без нього тести часто просто не достукаються до внутрішнього середовища, але водночас він сам — джерело флаку, бо додає затримку (трафік робить гак) і власну точку відмови. Якщо тести падають по таймауту саме з увімкненим VPN — це серйозний кандидат у підозрювані, а не «магія мережі».

Як за одним IP можуть жити десятки HTTPS-сайтів? Що таке SNI?

Сервер розрізняє домени за іменем, яке клієнт повідомляє в запиті — це віртуальний хостинг. Для звичайного HTTP імʼя їде в заголовку Host, але з HTTPS є проблема: сертифікат треба підібрати ще до того, як зашифрований канал встановлено і будь-які заголовки взагалі відправлено. Тому в TLS існує розширення SNI (Server Name Indication): клієнт повідомляє потрібне імʼя хоста прямо під час TLS-рукостискання, і сервер обирає правильний сертифікат та віртуальний хост. Практичний наслідок для тестів: якщо звертатися до сервера напряму за IP, SNI не передасть очікуване імʼя — можна потрапити не на той віртуальний хост або зловити помилку перевірки сертифіката, бо сертифікат виданий на імʼя, а не на IP.

Що відбувається, коли ти відкриваєш https://app.example.com/login? Розклади по етапах.

Спершу браузер перетворює імʼя на адресу: DNS-резолв із кешу або повним рекурсивним обходом (root — TLD — авторитетний сервер), свіжість визначає TTL. Далі за отриманим IP і портом 443 (бо схема https) відкривається TCP-зʼєднання трикроковим рукостисканням SYN / SYN-ACK / ACK. Поверх TCP проходить TLS-рукостискання, де клієнт через SNI повідомляє імʼя хоста — критично для віртуального хостингу. Лише тепер летить власне HTTP-запит GET /login і повертається відповідь. Якщо на шляху стоїть проксі чи VPN — трафік іде крізь них, додаючи затримку й, можливо, змінюючи вміст. Сильна відповідь підкреслює висновок для AQA: кожна ланка — потенційне джерело затримки та флаку, і розуміння цього ланцюжка дозволяє діагностувати повільний чи мигаючий тест прицільно, а не навмання.

Тест періодично падає по таймауту на першому кроці. Як зʼясувати, який саме мережевий шар гальмує?

Треба розкласти час запиту по етапах, а не гадати. Найпростіший інструмент — curl із форматом виводу таймінгів: curl -w з плейсхолдерами time_namelookup, time_connect, time_appconnect, time_starttransfer показує окремо DNS-резолвінг, TCP-рукостискання, завершення TLS і час до першого байта відповіді. Важливо памʼятати, що всі значення відлічуються від старту запиту наростаючим підсумком, тому кожне наступне включає попереднє — дивитись треба на прирости між сусідніми. Типові знахідки: «холодний» DNS зʼїдає час першого запиту (кеш порожній, TTL вичерпано), рукостискання довге через далекий сервер чи VPN-гак, порт закритий — зʼєднання взагалі не встановлюється (перевіряється nc -zv host 443). Далі рішення підбирається під шар: запас у таймаутах на встановлення зʼєднання, hosts-привʼязка до конкретного стенда, перехоплення мережі в тесті замість залежності від нестабільного зовнішнього сервісу.

Три кейси, які показують мережевий шар у роботі AQA: розкладання часу відкриття сторінки на DNS / TCP / TLS через curl, боротьба з address already in use та 127.0.0.1 vs 0.0.0.0 при піднятті сервера під тест, і відтворення повільної мережі через перехоплення й throttling у Playwright. Скрізь — що дивитися і чому.

Кейс 1. Розкладаєш flaky-таймаут на шари через curl

Тест періодично падає по таймауту на першому кроці, а в застосунку жодної помилки. Перш ніж звинувачувати код, треба зрозуміти, ЯКА саме ланка гальмує: резолвінг імені, TCP-рукостискання, TLS чи вже відповідь бекенда. curl вміє відлічити кожен шар окремо:

curl -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n" \
     -o /dev/null -s https://app.example.com/login

dns=0.031 connect=0.052 tls=0.108 ttfb=0.216

Що дивитися і чому:

• Значення наростають від старту. connect уже містить dns, tls містить connect і так далі. Тому дивись не на абсолютні числа, а на різницю між сусідніми: connect − dns — це власне TCP-рукостискання, tls − connect — обмін ключами TLS, ttfb − tls — час, поки бекенд готував відповідь.
• Великий dns. «Холодний» резолвінг першого запиту додається до відкриття сторінки. Якщо тестове середовище нещодавно змінило IP, а десь у ланцюжку живе старий запис із довгим TTL — стукаєш за застарілою адресою. Повтори dig +noall +answer app.example.com і глянь TTL та реальний IP.
• Розрив на connect. Порт закритий або зайнятий рукостисканням — а не бекенд. Перевір досяжність порту напряму: nc -zv app.example.com 443.
• Великий розрив tls − connect, а приріст ttfb − tls малий. Проблема в TLS-рукостисканні (сертифікат, SNI), а не в застосунку — бекенд після рукостискання відповів швидко.
• VPN у грі. Якщо dns/connect стрибають саме коли ввімкнено VPN — трафік робить гак через VPN-сервер і додає RTT. Це кандидат у підозрювані, а не «магія мережі».

Висновок: якщо запас у таймауті менший за холодне DNS + рукостискання, тест зрізає ще живий запит. Це не баг застосунку — це занижений таймаут.

Кейс 2. address already in use і 127.0.0.1 vs 0.0.0.0 у CI

Багато e2e-наборів піднімають локальний сервер під тест на фіксованому порту. Дві типові пастки живуть саме тут.

Перша — порт зайнятий попереднім прогоном, що не завершився:

Error: listen EADDRINUSE: address already in use 127.0.0.1:3000

Хто тримає порт — видно локально:

lsof -i :3000

Друга пастка тонша: 127.0.0.1:3000 слухає лише loopback — «сам до себе», тобто видно лише всередині тієї ж машини чи контейнера. А 0.0.0.0:3000 слухає всі інтерфейси й доступний ззовні контейнера. Плутанина між ними — типова причина «у мене працює, а в CI ні»: тест у сусідньому контейнері не достукається до сервера, прив'язаного до loopback.

У Playwright обидві проблеми лікуються конфігом webServer:

// playwright.config.ts (фрагмент)
export default defineConfig({
  use: { baseURL: 'http://localhost:3000' },
  webServer: {
    command: 'npm run start -- --host 0.0.0.0 --port 3000',
    url: 'http://localhost:3000/health',
    reuseExistingServer: !process.env.CI,
    timeout: 60_000,
  },
});

Що дивитися і чому:

• url, а не фіксована пауза. Playwright опитує http://localhost:3000/health, поки той не відповість, і лише тоді стартує тести. Це очікування за умовою — сервер може «прогріватися» довше на повільному CI, а тест не зривається завчасно.
• --host 0.0.0.0 у контейнері. Прив'язка до всіх інтерфейсів, щоб раннер достукався. Локально ж 127.0.0.1 цілком достатньо.
• reuseExistingServer: !process.env.CI. Локально перевикористовуєш уже піднятий сервер (не ловиш EADDRINUSE між прогонами), а в CI щоразу піднімаєш чистий — прямий вияв ізоляції стану між тестами.
• localhost резолвиться в loopback через файл hosts і працює навіть без DNS. Але не покладайся на це для доступу ЗЗОВНІ контейнера — там потрібна прив'язка до 0.0.0.0.

Кейс 3. Відтворюєш повільну мережу перехопленням і throttling

Flaky-поведінка на таймінгах часто не відтворюється на швидкій машині розробника. Щоб зловити її свідомо, мережу треба або сповільнити, або замокати. Обидва інструменти вбудовані у Playwright.

Перехоплення прибирає залежність від нестабільного зовнішнього сервісу — перехоплення відбувається всередині браузера через page.route:

test('UI не розсипається, коли API повільний і бекенд падає', async ({ page }) => {
  // штучна затримка перед фейковою відповіддю — імітуємо високий RTT
  await page.route('**/api/user', async (route) => {
    await new Promise((r) => setTimeout(r, 2000));
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ id: 1, name: 'Test User' }),
    });
  });

  // рідкісний стан — падіння бекенда 500
  await page.route('**/api/orders', (route) => route.fulfill({ status: 500 }));

  await page.goto('/dashboard');
  await expect(page.getByText('Test User')).toBeVisible();
  await expect(page.getByText('Не вдалося завантажити')).toBeVisible();
});

Що дивитися і чому:

• Затримка vs пропускна здатність. Штучний setTimeout перед fulfill імітує саме затримку (latency) — те, від чого страждають застосунки з купою дрібних API-викликів: кожен платить свій RTT, і вони складаються. Для важких файлів картина інша — там впираєшся в пропускну здатність, і мокати треба обсяг, а не паузу.
• Патерн маршруту. **/api/user має ловити саме той запит, що робить фронтенд. Звір із реальним шляхом у Network — інакше перехоплення мовчки не спрацює, а тест «зелений» через хибну причину.
• Очікування за умовою. toBeVisible() чекає появу елемента, а не фіксовані мілісекунди. Штучні 2000 мс на бекенді — контрольований подразник; фіксовані паузи в самому тесті — те, що першим зрізає перевірку на повільнішому CI.
• Емуляція мережі як інструмент. Той самий ефект дає throttling у DevTools: штучно піднімаєш затримку чи обрізаєш смугу й перевіряєш, чи не розсипаються тести й UI на повільному зв'язку — це спосіб відтворити флак, який на швидкій машині не виникає ніколи.

IP-адреси та адресація

• Знаю, що IP-адреса — числовий ідентифікатор вузла, за яким пакети знаходять дорогу; розумію різницю IPv4 (32 біти, октети 0–255) і IPv6 (128 біт, hex-групи, скорочення ::).
• Памʼятаю ключові адреси: loopback (127.0.0.1 / ::1), localhost, приватні діапазони (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), 0.0.0.0 як «усі інтерфейси».
• Розумію різницю 127.0.0.1:3000 (лише всередині машини/контейнера) vs 0.0.0.0:3000 (усі інтерфейси) — типова причина «у мене працює, а в CI ні».
• Можу прочитати CIDR (/16 — кількість фіксованих старших біт префікса) і пояснити, що приватні адреси не маршрутизуються в інтернеті, а назовні їх випускає NAT.

DNS та резолвінг

• Можу пояснити, що DNS перекладає імена в IP, і що непрямість «імʼя ↔ адреса» дає балансування, зміну IP без зміни імені та віртуальний хостинг.
• Знаю типи записів: A (IPv4), AAAA (IPv6), CNAME (alias), NS (авторитетні сервери), MX (пошта), TXT (довільний текст, верифікація).
• Можу описати рекурсивний резолвінг: stub → рекурсивний резолвер → кореневі → TLD .com → авторитетний сервер, і що root/TLD дають referral, а не адресу.
• Розумію кеш (браузер/ОС/резолвер) і TTL, і чому старий запис із довгим TTL чи «холодний» резолвінг першого запиту роблять тести flaky.
• Знаю, що файл hosts жорстко привʼязує домен до IP в обхід DNS — зручно спрямувати тести на стенд, але легко забути й отримати загадкову поведінку.

Порти, домен vs IP

• Можу пояснити, що порт — 16-бітне число (0–65535) для конкретного сервісу; знаю діапазони IANA й що фактичний ephemeral-діапазон залежить від ОС.
• Памʼятаю типові порти: 80 (HTTP), 443 (HTTPS), 22 (SSH), 53 (DNS), 25 (SMTP), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB), 8080.
• Розумію синтаксис host:порт і що для стандартних схем порт мається на увазі (80/443), а dev-порт 8080 треба вказувати явно; знаю причину address already in use у CI.
• Можу пояснити, що звʼязок «домен ↔ IP» не «один до одного» (балансування, віртуальний хостинг, CDN) і чому звертання за IP ламає віртуальний хост чи перевірку сертифіката; сервер розрізняє хости за Host / SNI.

TCP, UDP і транспорт

• Можу пояснити, що TCP дає надійний упорядкований потік байтів (перевідправка, порядок, контроль потоку), і знаю різницю TCP vs UDP (гарантії проти швидкості); HTTP/3 — це QUIC поверх UDP.
• Можу описати трикрокове рукостискання SYN → SYN-ACK → ACK і що для HTTPS зверху ще TLS-рукостискання — кілька round-trips до першого байта.
• Розумію, чому перший запит «холодний» і повільніший за наступні (keep-alive, мультиплексування HTTP/2), і чому тісні таймаути дають мигання тестів.

Затримка, проксі, VPN

• Можу розвести затримку (latency, RTT, мс) і пропускну здатність (bandwidth, Mbps): дрібні запити страждають від затримки, великі файли — від смуги; знаю, навіщо throttling у браузері.
• Можу розрізнити forward proxy (з боку клієнта) і reverse proxy (перед серверами: балансування, TLS, кеш; nginx, HAProxy) та пояснити принцип перехоплювального проксі й page.route у Playwright.
• Можу пояснити, що робить VPN (тунель, підміна видимої адреси, доступ до закритих мереж) і чого НЕ робить (не анонімізує, не шифрує весь шлях), і що він сам додає затримку й точку відмови.
• Можу простежити відкриття https://app.example.com/login (DNS → TCP на 443 → TLS із SNI → HTTP на /login) і розкласти час по шарах через curl -w (time_namelookup, time_connect, time_appconnect, time_starttransfer).