Клієнт-сервер і як працює веб

Поясни модель клієнт-сервер. Хто такий клієнт і хто такий сервер?

Клієнт — програма, яка ініціює запит і споживає відповідь; сервер — програма, яка слухає порт, обробляє запити й повертає відповіді. Клієнтом може бути не лише браузер: мобільний застосунок, curl, Postman чи автотест на Playwright — усе це клієнти. Слово «сервер» має два значення — фізична машина («залізо») і програма-процес на кшталт Nginx чи застосунку на Node.js, — і на співбесіді варто це розрізнення озвучити. Ключова властивість моделі — асиметрія: клієнт знає адресу сервера, а сервер не знає наперед, хто до нього прийде, і в класичній схемі сам обмін не ініціює. Для AQA це база: автотест — це ще один клієнт із тими самими залежностями від мережі, статусів і кукі.

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

Це ланцюг із кількох кроків: розбір URL → DNS-резолюція → TCP-рукостискання → TLS-рукостискання (для HTTPS) → HTTP-запит → обробка на сервері → HTTP-відповідь → побудова сторінки. Браузер спершу розкладає адресу на схему, хост, шлях і query string, потім перетворює доменне імʼя на IP (кеш браузера й ОС, файл hosts, далі DNS-резолвер), встановлює зʼєднання через SYN → SYN-ACK → ACK, узгоджує шифрування — і лише тоді надсилає сам запит. Отримавши HTML, браузер будує DOM і робить окремі запити на кожен підресурс (CSS, JS, зображення), а в SPA JavaScript після завантаження ще довантажує дані з API. Для автотестів критичні саме останні кроки: HTML уже прийшов, а даних на екрані ще немає, бо триває запит до API — тому «сторінка завантажилась» ≠ «дані готові», і надійні очікування чіпляються за конкретний елемент або завершення мережевого запиту.

З чого складається HTTP-запит і HTTP-відповідь?

Запит — це метод, шлях, заголовки й (не завжди) тіло; відповідь — код статусу, заголовки й тіло. Метод каже, що робимо, шлях — з чим, заголовки несуть метадані (наприклад, Host, Accept, Authorization), а тіло — дані, які надсилаємо, як-от JSON у POST. У відповіді статус повідомляє, чим усе скінчилось, а заголовки на кшталт Content-Type кажуть, як інтерпретувати тіло. Обмін завжди має форму «один запит → одна відповідь». Для AQA це щоденний інструмент: у вкладці Network у DevTools ти бачиш саме ці частини, і саме за ними локалізуєш баг.

Які HTTP-методи знаєш і чим вони відрізняються?

Основні: GET — отримати ресурс, POST — створити чи надіслати дані, PUT — замінити ресурс повністю, PATCH — частково оновити, DELETE — видалити, HEAD — як GET, але лише заголовки без тіла, OPTIONS — дізнатись доступні опції. Різняться семантикою і наявністю тіла запиту: POST, PUT і PATCH тіло мають, GET і DELETE — зазвичай ні. Важлива відмінність PUT від PATCH: перший заміняє ресурс цілком, другий оновлює лише частину полів. В API-тестах вибір методу — частина контракту: створення передумови для UI-тесту — це зазвичай один POST замість десяти кліків по екранах.

На які групи діляться коди статусів HTTP? Наведи приклади.

За першою цифрою: 1xx — інформаційні, 2xx — успіх, 3xx — перенаправлення, 4xx — помилка клієнта, 5xx — помилка сервера. З 2xx найчастіші 200 OK, 201 Created (після POST) і 204 No Content — успіх без тіла відповіді. З 4xx: 400 — некоректні дані від клієнта, 401 — не автентифікований, 403 — без прав, 404 — ресурсу немає, 422 — дані синтаксично коректні, але не проходять валідацію, 429 — спрацював rate limiting. З 5xx: 500 — помилка застосунку, а 502/503/504 часто приходять від проксі чи балансувальника, коли сервер за ним не відповів. У тестах перша цифра статусу — швидкий орієнтир, на чиєму боці проблема: 4xx — дивись на свій запит, 5xx — на сервер чи інфраструктуру.

Чим відрізняються 401 і 403?

Коротко: 401 — «я не знаю, хто ти», 403 — «я знаю, хто ти, але тобі сюди не можна». 401 Unauthorized означає, що клієнт не автентифікований: креденшелів немає або вони невалідні — наприклад, протухла сесія чи відсутній токен. 403 Forbidden означає, що автентифікація пройшла, але прав на ресурс бракує. Це класичне питання співбесіди й часте джерело плутанини в баг-репортах. Практично: 401 у тесті найчастіше сигналізує про проблему з сесією чи токеном (переотримай і підклади заново), а 403 — про тест-дані з неправильною роллю користувача.

Що означає, що HTTP — stateless-протокол?

Stateless означає, що сервер за замовчуванням не памʼятає нічого про попередні запити — кожен запит обробляється так, ніби клієнт прийшов уперше. Так зробили заради масштабованості: якщо сервер не мусить памʼятати клієнтів, будь-який із десятка однакових серверів може обробити будь-який запит. Наслідок: кожен запит має нести все потрібне сам — токен чи кукі прикладаються до кожного звернення, а не «один раз залогінився». Важливий нюанс, який відрізняє сильного кандидата: stateless — це про протокол, а не про застосунок; кошик і профіль існують, просто цей стан живе в базі даних і в тому, що клієнт приносить із кожним запитом. Для тестів це подарунок: протокол не тримає стану між запитами, тож тести легко робити ізольованими — а будь-який «спільний стан», що тече між тестами й дає флак, ти створив сам через базу, кукі чи глобальні фікстури.

Якщо HTTP нічого не памʼятає, як сайт памʼятає, що я залогінений?

Клієнт сам нагадує про себе в кожному запиті. Найпоширеніший механізм — кукі: після успішного логіну сервер у відповіді ставить кукі через заголовок Set-Cookie (наприклад, session_id), браузер її зберігає й автоматично додає до кожного наступного запиту на цей домен у заголовку Cookie. Сервер знаходить цей ідентифікатор у своєму сховищі сесій і «впізнає» користувача. Альтернатива — токени (найчастіше JWT), які клієнт зберігає сам, наприклад у localStorage, і додає в заголовок Authorization: Bearer .... Для автотестів звідси головний практичний прийом: не проклацувати форму логіну щоразу, а один раз отримати сесію через API й підкласти її в контекст браузера — у Playwright для цього є storage state; це прибирає флак на сторінці логіну й економить час прогону.

Чим кукі відрізняються від токенів?

Ключова відмінність — хто їх додає до запиту: кукі браузер підкладає автоматично до кожного запиту на відповідний домен, а токен із localStorage мусить вручну додати код фронтенду в заголовок Authorization. Тому кукі-сесія «переживає» перезавантаження сторінки без зусиль, а токен потрібно спершу дістати зі сховища. У кукі є атрибути, які прямо впливають на тести: HttpOnly забороняє доступ із JavaScript (не витягнеш через document.cookie — керуй на рівні контексту браузера), Secure вимагає HTTPS (на локальному http:// кукі може не встановитись), SameSite обмежує крос-сайтові запити й ламає сценарії з редіректами між доменами, а Expires/Max-Age задають час життя — протухла сесія дає плаваючі падіння в довгих прогонах. Окремий нюанс із SameSite: браузери на Chromium за відсутності атрибута трактують кукі як SameSite=Lax, а Firefox і Safari такого дефолту не мають — тож у крос-доменних сценаріях дивись у DevTools, що реально прийшло в Set-Cookie.

Чим фронтенд відрізняється від бекенду і як зрозуміти, де баг?

Фронтенд — усе, що виконується в браузері (HTML, CSS, JavaScript); бекенд — усе на боці сервера: бізнес-логіка, база даних, автентифікація. Для локалізації бага алгоритм простий: відкрий вкладку Network і подивись на мережеву відповідь. Якщо на екрані не той текст, а у відповіді дані правильні — баг фронтендовий, він неправильно відрендерив; якщо відповідь уже містить неправильні дані — баг бекендовий. Це вміння розводить «клієнт неправильно показав» і «сервер неправильно віддав» і часто економить години. Нюанс для повноти: при серверному рендерингу (SSR) HTML готує сервер, тож межа буває розмитою, але поділ ролей лишається тим самим.

Що таке API і навіщо тестувати його окремо від UI?

API — контракт, за яким одна програма звертається до іншої; у вебі це найчастіше HTTP API — набір ендпоінтів зі своїм шляхом, методом і форматом запиту-відповіді, зазвичай у JSON. Домінантний стиль — REST, де ресурси адресуються шляхами, а дії — HTTP-методами (є ще GraphQL і gRPC). Тестувати API окремо варто з трьох причин. Перша — швидкість і стабільність: API-тести не залежать від верстки, анімацій і локаторів, тому рідше флакають. Друга — підготовка стану: один POST-запит замінює прокликування десяти екранів для створення передумови UI-тесту. Третя — перехоплення мережі: у UI-тестах можна перехопити запит фронтенду до API й підмінити відповідь (mock), щоб перевірити рідкісний стан — наприклад, як UI поводиться при коді 500 чи порожньому списку.

Що таке ідемпотентність HTTP-методів і чому вона важлива?

Ідемпотентність означає, що повторення запиту дає той самий результат, що й одноразове виконання. GET, PUT і DELETE можна безпечно повторити, а повторний POST може створити дубль ресурсу. Це прямий наслідок семантики: PUT заміняє ресурс на конкретний стан (скільки не повторюй — стан той самий), а POST щоразу створює щось нове. Для автотестів це критично при ретраях: наївний автоматичний ретрай POST-запиту здатен створити два записи — і далі тест або наступні тести падають через несподівані дублікати в даних. Тому перш ніж вмикати ретраї на рівні HTTP-клієнта чи тест-ранера, варто розуміти, які запити в сценарії неідемпотентні.

Чим відрізняються редіректи 301/302 від 307/308?

Дві осі відмінності: постійність і збереження методу. 301 і 308 — постійні перенаправлення, 302 і 307 — тимчасові. Головний нюанс: 307 і 308 гарантують, що метод і тіло запиту збережуться при редіректі, тоді як при 301/302 деякі клієнти історично перетворюють POST на GET. Практично це означає, що POST на ендпоінт, який відповідає 302, може «загубити» тіло й доїхати до фінальної адреси вже як GET — і тест отримає зовсім не ту поведінку, яку очікував. Тому при дивних результатах після редіректів перший крок — подивитись у Network, який саме код повернувся і яким методом пішов наступний запит.

Що таке localhost і 127.0.0.1? Це одне й те саме?

localhost — імʼя, що вказує на «цю саму машину», і воно резолвиться в loopback-адресу: 127.0.0.1 (загалом діапазон 127.0.0.0/8) для IPv4 або ::1 для IPv6. Loopback означає, що трафік не виходить у мережу — він розвертається всередині твоєї машини, тому ззовні до localhost:3000 ніхто не достукається. Але строго кажучи, це не завжди одне й те саме: імʼя localhost резолвиться через систему (зазвичай файл hosts) і може вказувати то на IPv4, то на IPv6. Класична пастка: застосунок слухає лише на IPv4, а localhost резолвиться в ::1 — і зʼєднання «незрозуміло чому» не встановлюється; явне 127.0.0.1 у конфігу тесту це лікує. Порт після двокрапки вказує, до якого саме процесу на машині звертатись — одна машина може тримати багато сервісів на різних портах.

Навіщо потрібні оточення dev, staging і prod?

Щоб експерименти й помилки не зачіпали реальних користувачів: dev — для розробки з синтетичними «брудними» даними, staging — репетиція перед релізом, максимально схожа на prod, prod — бойове середовище з реальними даними. Зміна проходить шлях: перевірка в dev → автотести на staging → викочування в prod. Для AQA звідси три наслідки. Тести мають знати, проти якого оточення біжать: той самий сценарій може дати різний результат через різні дані чи ввімкнені feature flags. Дані мають бути ізольовані: синтетика не потрапляє в prod, реальні дані користувачів — у фікстури. І конфігурації різняться: на staging можуть бути інші ліміти, детальніше логування, тестові платіжні системи — тому баг, що відтворюється на staging, іноді не відтворюється на prod, і навпаки.

Чи може сервер сам надіслати дані клієнту без запиту? А браузер — бути сервером?

У класичній моделі HTTP — ні: сервер лише відповідає на те, що прийшло, а браузер не слухає порт і не приймає вхідні зʼєднання ззовні, тож повноцінним вебсервером не є. Але є технології, які цю картину розширюють. WebSocket і Server-Sent Events (SSE) дозволяють серверу надсилати дані у вже відкрите клієнтом зʼєднання — ініціатором зʼєднання лишається браузер, але далі сервер може «говорити» сам. WebRTC дозволяє браузерам обмінюватись даними майже напряму (peer-to-peer), хоча встановлення зʼєднання все одно координує сигнальний сервер. Практичний висновок для тестів: якщо застосунок оновлює дані «сам» — нотифікації, чат, живі оновлення, — не шукай там звичайний запит/відповідь; це, найімовірніше, WebSocket або SSE, і перехоплювати й чекати їх треба інакше, ніж HTTP-запити.

Що таке latency і bandwidth? Чому сторінка вантажиться повільно навіть на швидкому каналі?

Затримка (latency) — час одного round-trip «запит пішов → відповідь повернулась» (RTT); пропускна здатність (bandwidth) — скільки даних пролізе за одиницю часу. Ключова різниця: bandwidth можна нарощувати, а latency диктується фізичною відстанню й маршрутом пакетів — її товстим каналом не прискориш. Повільне завантаження на швидкому каналі пояснюється тим, що сторінка — це не один round-trip, а багато: DNS, TCP-рукостискання, TLS — це кілька повних циклів ще до першого байта корисних даних, а потім кожен підресурс і API-запит додають свої. При RTT 100 мс навіть 5 послідовних round-trips — уже пів секунди чистих «подорожей». Тому оптимізації вебу борються з кількістю циклів: keep-alive, мультиплексування в HTTP/2, кешування, CDN, а HTTP/3 поверх QUIC поєднує встановлення транспортного зʼєднання з узгодженням TLS. Для AQA це прямо про таймаути: локально RTT до localhost близький до нуля, а на CI тест бʼється в реальний staging — і жорсткі короткі таймаути, які «завжди встигали» локально, починають зрізати тести.

Що робить load balancer і які проблеми він може створювати в тестах?

Балансувальник навантаження приймає всі вхідні запити й розподіляє їх між кількома однаковими серверами — по черзі, за найменшою завантаженістю тощо. Це працює гладко, поки сервери stateless: тоді байдуже, куди потрапить наступний запит того самого користувача. Але якщо стан зберігається локально на конкретному сервері (сесія в памʼяті), без «липких сесій» (sticky sessions) користувач може «втратити логін», коли наступний запит прийде на інший сервер. У тестах балансувальник дає два характерні симптоми. Перший — плаваючі падіння: тест іноді бачить старі дані, іноді нові, бо різні запити потрапили на різні сервери, які ще не синхронізувались. Другий — коди 502/503/504, які часто приходять саме від балансувальника, коли сервер за ним перевантажений або не відповів, — тобто це не обовʼязково помилка в коді застосунку, і в баг-репорті це варто розрізняти.

Чому той самий тест зелений локально, але червоний на CI?

Тому що тест — програма, чутлива до середовища, а локальна машина й CI різняться майже за всіма осями: RTT (localhost проти реальної мережі до staging), потужність CPU (на CI слабший спільний ресурс — UI рендериться повільніше), режим браузера (headed проти headless з іншим viewport і шрифтами), паралелізм (конкуренція воркерів за спільні дані), дані оточення, часовий пояс і локаль (на CI часто UTC — падають перевірки дат), чистота машини між прогонами. Головний механізм флаку — гонки станів (race conditions): те, що локально «встигало» за 10 мс, на повільнішому CI займає 300 мс, і тест, який мовчки покладався на «дані вже завантажились», ламається. Що робить досвідчений AQA: жодних фіксованих пауз — лише очікування конкретної умови (елемент видимий, запит завершився); ізоляція стану — кожен тест сам готує свої дані через API; максимально однакове з CI локальне оточення (headless, той самий браузер і таргет-URL); і читання мережі при падінні — статус і тривалість запиту часто одразу показують причину: 401 через протухлу сесію, 500 від перевантаженого сервера або timeout через RTT.

Три кейси, які показують модель клієнт-сервер у роботі AQA: читання реального обміну в мережі, підготовка стану через API замість кліків по формі логіну та відтворення серверної помилки перехопленням запиту. Скрізь — що дивитися і чому.

Кейс 1. Читаєш Network, коли тест «не бачить» дані

Класична ситуація: HTML прийшов, сторінка «завантажилась», а на екрані порожньо. Причина — крок динамічного довантаження: фронтенд SPA після завантаження документа сам ходить в API за даними, і саме ця відповідь ще в дорозі.

Найшвидший спосіб розвести «клієнт неправильно показав» і «сервер неправильно віддав» — глянути в реальний обмін. Той самий запит, який робить браузер, можна повторити з терміналу:

curl -i 'https://api.example.com/api/orders?id=1001' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1Ni...'

HTTP/1.1 200 OK
Content-Type: application/json

{"orderId": 1001, "status": "pending"}

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

• Статус. 200 — сервер віддав дані, отже баг фронтендовий (не відрендерив). 401 — протухла чи відсутня сесія. 500 — впав бекенд. 429 — спрацював ліміт запитів. Статус одразу вказує, на чиєму боці шукати.
• Тіло відповіді vs екран. Якщо в JSON дані правильні, а на екрані ні — баг у рендері. Якщо вже в JSON сміття — баг на бекенді.
• Час запиту. Довгий round-trip на CI при короткому таймауті = тест зрізає ще живий запит. Це не баг застосунку.

У DevTools дивись ту саму вкладку Network: колонки Status, Time, вкладку Response. Прапорець -i у curl друкує заголовки — саме там видно Set-Cookie, Content-Type і реальний код.

Кейс 2. Логін через API замість форми (Playwright storage state)

HTTP stateless — сервер не памʼятає тебе між запитами, тому кожен запит мусить нести сесію сам (кукі або токен). Проклацувати форму логіну в кожному тесті — повільно й флакітно: сторінка логіну сама по собі джерело гонок. Надійніше один раз отримати сесію й підкласти її в контекст браузера.

Глобальний setup логіниться один раз і зберігає стан автентифікації:

// auth.setup.ts
import { test as setup } from '@playwright/test';

setup('authenticate', async ({ request }) => {
  // один POST замість кліків по формі
  const res = await request.post('https://api.example.com/api/login', {
    data: { email: 'qa@example.com', password: process.env.PASSWORD },
  });
  // сервер поставив Set-Cookie / повернув токен — зберігаємо весь стан
  await request.storageState({ path: 'storage/auth.json' });
});

// playwright.config.ts (фрагмент)
use: { storageState: 'storage/auth.json' }

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

• Чому це стабільніше. Прибираємо крок динамічного довантаження форми логіну — а це один із головних джерел флаку. Тест стартує вже автентифікованим.
• Кукі vs токен. Кукі-сесію браузер підкладає в кожен запит автоматично, тому вона «переживає» перезавантаження без зусиль. Токен із localStorage мусить додавати сам код фронтенду. storageState контексту сторінки зберігає і кукі, і localStorage; але зверни увагу: у цьому кейсі логін іде через request (API-контекст), а він зберігає лише кукі — токен у localStorage так не зʼявиться. Для токен-авторизації логінься через сторінку або поклади токен у localStorage вручну перед збереженням стану.
• HttpOnly. Сесійну кукі з HttpOnly не витягнеш через document.cookie — керуй нею на рівні контексту браузера, а не через JS на сторінці.
• Secure на локалхості. Кукі з атрибутом Secure шлеться лише через HTTPS. На локальному http:// вона може не встановитись — і логін «незрозуміло чому» не тримається.

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

Рідкісні стани — порожній список, помилка сервера — важко зловити на живому бекенді. Але фронтенд і бекенд спілкуються контрактом (API), тож відповідь можна підмінити (mock), не чекаючи, поки сервер справді впаде. Так перевіряєш, як UI поводиться при коді 500.

test('показує банер помилки, коли API віддає 500', async ({ page }) => {
  await page.route('**/api/orders**', (route) => {
    route.fulfill({
      status: 500,
      contentType: 'application/json',
      body: JSON.stringify({ error: 'Internal Server Error' }),
    });
  });

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

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

• Патерн маршруту. **/api/orders** має ловити саме той запит, який робить фронтенд. Звір його з реальним шляхом у Network — інакше перехоплення мовчки не спрацює, а тест «зелений» через хибну причину.
• Очікування за умовою, не за паузою. toBeVisible() чекає появу елемента, а не фіксовані «500 мс». Фіксовані паузи — перше, що зрізає тести на повільнішому CI.
• WebSocket/SSE так не перехопиш. Якщо застосунок оновлює дані «сам» (нотифікації, живі оновлення), це не звичайний запит/відповідь, а WebSocket або Server-Sent Events — їх треба чекати й мокати інакше, ніж HTTP-запити.

Клієнт, сервер і модель запит/відповідь

• Можу пояснити асиметрію ролей: клієнт ініціює запит, сервер лише відповідає й сам першим не заговорить у базовій моделі HTTP.
• Розумію, чому «сервер» — це двозначне слово (залізо vs процес-програма) і за замовчуванням маю на увазі саме програму.
• Знаю, що автотест (Playwright, curl, Postman) — це такий самий клієнт, що й браузер, з тими самими залежностями від DNS, round-trips і статусів.
• Можу пояснити, що обмін завжди має форму «один запит → одна відповідь», а запит складається з методу, шляху, заголовків і (не завжди) тіла.
• Розумію, чому семантика HTTP (метод, шлях, заголовки, статус) однакова в HTTP/1.1, HTTP/2 і HTTP/3 — у DevTools я бачу ті самі поля незалежно від версії.

Шлях від URL до сторінки, статуси й флак

• Можу перелічити ланцюг від Enter до сторінки: розбір URL → DNS → TCP-рукостискання → TLS → HTTP-запит → обробка на сервері → відповідь → побудова DOM і підресурси → динамічне довантаження.
• Розумію, чому «сторінка завантажилась» ≠ «дані готові»: HTML прийшов (крок 7), а дані ще їдуть окремими API-запитами (крок 9) — головне джерело флаку.
• Знаю, чому надійне очікування чіпляється за конкретний елемент або завершення запиту, а не за фіксовану паузу чи подію завантаження документа.
• Знаю ключові коди статусів (200, 201, 204, 301/302, 304, 400, 401, 403, 404, 422, 429, 500, 502/503/504) і типову причину кожного.
• Можу пояснити різницю 401 vs 403: «я не знаю, хто ти» проти «знаю, хто ти, але тобі сюди не можна».
• Розумію, що 422 замість 400 на валідацію — рішення конкретного API, а не універсальне правило: звіряюсь із контрактом бекенду.

Stateless і памʼять про логін

• Можу пояснити, що HTTP stateless: сервер за замовчуванням не памʼятає попередніх запитів, тому кожен запит мусить нести все потрібне сам (токен чи кукі).
• Розумію, що stateless — про протокол, а не про застосунок: стан живе в базі даних і в тому, що клієнт приносить із кожним запитом.
• Знаю ідемпотентність: GET, PUT, DELETE безпечно повторити, а наївний ретрай POST здатен створити дубль.
• Можу пояснити механізм кукі-сесії: Set-Cookie у відповіді → браузер автоматично додає Cookie до кожного запиту на домен → сервер «впізнає» за session_id.
• Знаю атрибути кукі, важливі для тестів (HttpOnly, Secure, SameSite, Expires/Max-Age), і чому Secure-кукі може не встановитись на локальному http://.
• Розумію різницю кукі vs токен: кукі браузер підкладає сам, а токен із localStorage мусить додати код фронтенду вручну в Authorization: Bearer.
• Можу пояснити, чому в тесті найстабільніше отримати сесію через API й підкласти в контекст (storage state), а не проклацувати форму логіну.

Фронтенд, бекенд і API

• Можу розвести фронтенд (виконується в браузері) і бекенд (виконується на сервері) і сказати, що на кожному боці тестую.
• Розумію, як за вкладкою Network локалізувати баг: правильні дані у відповіді + не той текст на екрані = баг фронтенду; неправильні дані у відповіді = баг бекенду.
• Можу пояснити, що API — це контракт із набором ендпоінтів (шлях + метод + формат), найчастіше REST з JSON.
• Знаю, навіщо тестувати API окремо від UI: швидкість і стабільність, підготовка стану одним запитом, перехоплення мережі (mock рідкісних станів на кшталт 500).

Мережа, оточення та інфраструктура

• Можу розвести затримку (latency, диктує швидкість світла й маршрут) і пропускну здатність (bandwidth) і пояснити, чому завантаження сторінки — це багато round-trips.
• Розумію, чому оптимізації (keep-alive, мультиплексування HTTP/2, кеш, CDN, HTTP/3 поверх QUIC) борються саме з кількістю round-trips.
• Можу пояснити, чому «локально зелено, на CI червоно»: різні RTT, CPU, headless-режим, паралелізм, дані, часовий пояс — а корінь флаку зазвичай гонки станів.
• Розумію, чому браузер у класичній моделі не сервер (не слухає порт ззовні), і що живі оновлення — це WebSocket або SSE, а не звичайний запит/відповідь.
• Знаю різницю dev / staging / prod і чому баг зі staging може не відтворитись на prod через інші дані, фіча-флаги чи конфіг.
• Можу пояснити роль load balancer і чому 502/503/504 часто приходять від нього, а не від застосунку; знаю проблему «липких сесій» при локальному стані.
• Розумію localhost та loopback (127.0.0.1 / ::1) і чому явне 127.0.0.1 рятує, коли застосунок слухає лише IPv4, а localhost резолвиться в ::1.