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

Хто такий клієнт і хто сервер — і чому це питання не про залізо?

Клієнт — той бік, який починає обмін: складає запит і далі працює з тим, що прийшло назад. Сервер — програма, яка постійно тримає відкритим певний порт, приймає вхідні запити й формує відповіді. Перша плутанина ховається саме в слові «сервер»: ним називають і машину в дата-центрі, і процес на ній, а в розмові про HTTP мають на увазі процес. Клієнтом при цьому може бути будь-що, здатне надіслати мережевий запит: браузер, curl, Postman, мобільний застосунок, автотест. Головне тут не визначення, а асиметрія: ініціатива завжди на боці клієнта, і в класичній схемі сервер сам першим не озивається. Мотив такого поділу — розділення відповідальностей (separation of concerns): інтерфейс відокремлено від зберігання даних, тому його легше переносити між платформами, а серверну частину легше масштабувати.

Чому кажуть, що автотест — теж клієнт?

Бо в моделі обміну він займає те саме місце, що браузер чи curl, і успадковує ті самі залежності: адреси, зʼєднання, статуси, оточення. Це не метафора, а робочий висновок: усе, що ламає браузер на стенді — недоступний DNS-запис, зайнятий порт, протухлий сертифікат, проксі в корпоративній мережі, — так само ламає й тест. Практичний бонус із того самого факту: тест може бути клієнтом двома різними способами. Через page.goto() він працює як браузер і залежить від верстки, анімацій і локаторів; через прямий HTTP-запит до API — не залежить від них узагалі. Звідси звичка готувати передумову дешевим шляхом: створити замовлення одним POST, а вже потім перевіряти екран на готовому стані замість того, щоб проклацувати десять форм.

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

Форма обміну стала. У запиті — метод, шлях, заголовки й тіло, причому тіло є не завжди. У відповіді — статус-код, заголовки й тіло. Заголовки в обох випадках — це поля, які їдуть попереду тіла повідомлення; саме в них живе більшість того, що потім дивиться тестувальник: Content-Type, Cookie, Authorization, Location. Статус-код — тризначне число в межах від 100 до 599, і перша його цифра задає клас відповіді, тобто підказує стратегію реакції ще до читання тіла. Для QA це найдешевша діагностика: за методом і шляхом видно, чого хотіли, за статусом — чим це скінчилося, а тіло вже уточнює деталі.

Чи правда, що на один запит завжди приходить рівно одна відповідь?

Формула точна, але тільки щодо фінальної відповіді. Перед нею протокол дозволяє нуль або більше проміжних повідомлень класу 1xx — наприклад, 100 Continue або 103 Early Hints, — і вже після них приходить рівно одна фінальна. Це не аномалія й не баг сервера, а передбачений порядок. Практично це означає дві речі. По-перше, побачивши 1xx у трейсі, не варто заводити тікет: обмін ще не завершився. По-друге, асерт ставлять на статус саме фінальної відповіді — вона на запит одна, і решта класів кодів живе тільки в ній.

Що відбувається після того, як ти натиснув Enter в адресному рядку?

На співбесіді тут слухають не завчений список, а розуміння порядку й того, що на кожній ланці може зламатися. Спершу імʼя перетворюється на адресу — працює DNS. Далі піднімається зʼєднання: тристороннє рукостискання TCP, а для https ще й узгодження TLS. Тільки після цього їде сам запит із методом, шляхом і заголовками, а назад приходить статус, заголовки й тіло. Останній етап — браузер розбирає отримане й будує сторінку, дотягуючи дорогою стилі, скрипти й дані фоновими запитами. Сильна відповідь дописує до кожної ланки свій клас відмов: не резолвиться імʼя, не встановлюється зʼєднання, не сходиться сертифікат, відповів посередник замість застосунку, прийшла сторінка без даних. Повний ланцюг деталізує окрема глава — тут важливий сам скелет.

Навіщо в цьому ланцюгу DNS і чому після переїзду стенда тести ще довго стукають за старою адресою?

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

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

IP-адреса доводить пакети до потрібної машини, але на машині одночасно живуть десятки програм — треба ще сказати, кому саме. Це й робить порт: 16-бітне число в діапазоні від 0 до 65535, що вказує на конкретний сервіс. Пара «адреса + порт» називається сокетом, а зʼєднання однозначно визначається парою сокетів — своїм на кожному боці. Для стандартних схем порт можна не писати, бо мається на увазі типовий: 80 для http і 443 для https; будь-який інший доводиться дописувати руками — звідси й звичний :3000 на локальному стенді. Звідси дві дуже приземлені речі в роботі: «сервіс не піднявся» і «сервіс піднявся на іншому порту» дають однакову помилку зʼєднання, а фіксований порт у тесті, зайнятий попереднім незавершеним прогоном, дає address already in use — тому порт або підбирають динамічно, або вимагають чистого стану між прогонами.

Чому localhost іноді підводить, хоча «це ж та сама машина»?

Бо localhost — це імʼя, а не адреса, і резолвиться воно у loopback-адреси обох сімейств: 127.0.0.1 для IPv4 і ::1 для IPv6. Loopback означає «ця сама машина», трафік на нього в мережу взагалі не виходить. Пастка виникає, коли застосунок слухає лише IPv4-адресу, а клієнт пішов на ::1: адреса начебто правильна, а зʼєднання не встановлюється, і повідомлення про помилку виглядає безглуздо. Найшвидша перевірка — підставити явну адресу замість імені й побачити, чи зміниться поведінка; альтернатива з боку сервера — слухати обидва сімейства адрес.

Про що домовляються сторони, перш ніж піде корисний трафік?

Це фаза рукостискань, і на звичайному HTTPS-запиті їх щонайменше два. Спершу транспортне: TCP домовляється в три кроки — SYN, у відповідь SYN-ACK, потім ACK; четвертого кроку не треба, бо сервер укладає підтвердження й власний SYN в одне повідомлення. Друге — криптографічне, TLS: сторони автентифікуються, узгоджують параметри шифрування й отримують спільні ключі, а починається все з ClientHello, на який прилітає ServerHello. Ця ціна нараховується раз на зʼєднання, тому звернення до незнайомого хоста коштує більше за всі подальші: keep-alive далі працює вже у відкритому каналі. Практичний наслідок для тестів — падіння на цій фазі виглядають інакше за помилки застосунку: немає ні статус-коду, ні тіла, є лише помилка зʼєднання чи сертифіката, і шукати причину в коді продукту марно.

Що саме дає HTTPS порівняно з HTTP?

HTTPS — це той самий HTTP, загорнутий у захищений шар: спершу піднімається канал, а вже всередині нього ходить звичний трафік із тими самими методами, заголовками й кодами. Гарантій рівно три: автентифікація сторін, конфіденційність і цілісність даних. Важлива деталь, за яку дають бали: сервер автентифікується завжди, а клієнт — опційно, тому «HTTPS означає, що сервер знає, хто я» — хибне твердження. Для тестувальника з цього випливає межа відповідальності: усе, що ламається на етапі узгодження захищеного каналу (несходження імені в сертифікаті, прострочений сертифікат, непідтримувана версія протоколу), — це проблема інфраструктури, а не логіки застосунку.

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

Це дві незалежні величини, і плутанина між ними дорого коштує. Затримка (latency) відповідає на питання «як довго дані добираються до місця призначення»; на практиці її міряють у два кінці, як round-trip. Пропускна здатність (bandwidth) — скільки інформації здатне пропустити зʼєднання за одиницю часу, і міряють її кратними бітам за секунду. Незалежність не теоретична: канал буває водночас «товстим» і «довгим» — у TCP є навіть добуток «пропускна здатність × затримка», а мережі з великим його значенням мають власний клас проблем продуктивності й окрему назву, long fat network. Діагноз від цього залежить прямо: довгий ланцюжок дрібних API-викликів гальмує саме затримка — кожен виклик оплачує власний round-trip, тож ширший канал тут нічого не змінить; натомість тягання великого файлу тримається на смузі, і рятує його зменшення обсягу даних. Саме тому оптимізації вебу здебільшого зменшують кількість походів у мережу: перевикористання зʼєднань, мультиплексування в HTTP/2, кешування, CDN, а HTTP/3 поверх QUIC ще й поєднує підняття транспорту з узгодженням TLS.

Чим проксі відрізняється від reverse proxy — і де тут балансувальник?

Посередників розрізняють за роллю, а не за тим, «з якого боку вони стоять», і саме на цьому валиться більшість відповідей. Проксі — агент пересилання, якого обирає клієнт; типово його ставлять, щоб звести трафік організації через спільний вузол заради безпеки або спільного кешу. Шлюз (він же reverse proxy) грає протилежну роль: назовні він видає себе за origin-сервер, а всередину роздає запити іншим машинам; балансувальник навантаження — окремий випадок шлюзу, бо розподіл навантаження між машинами якраз і є типовим застосуванням цієї ролі. Третя форма — тунель: ретранслятор наосліп, який у зміст повідомлень не втручається, і повноцінним учасником обміну його не рахують. І окремий нюанс, який цінують на співбесіді: вузол, якого клієнт не обирав — корпоративний фаєрвол, публічний Wi-Fi, — протокольно не відрізнити від атаки на шляху, тому поведінка запиту може змінитися без жодної зміни в застосунку.

Прийшов 502. Де шукати причину і чим він відрізняється від 503?

502 і 504 за означенням віддає вузол, який діє як шлюз або проксі, тобто скарга йде на ланку за посередником: застосунок про такий запит міг узагалі не дізнатися. Шукати в його коді безглуздо — дивитися треба на балансувальник, шлюз і те, що стоїть за ними. 503 каже інше: сам сервіс тимчасово не здатен обробити запит — перевантаження або планові роботи. Практичний наслідок для команди: пачка однотипних 502 одразу після деплою частіше означає, що середовище ще не піднялося, ніж що в продукті зʼявився дефект. Тому перший крок — перевірити стан стенда, і лише другий — заводити тікет на розробників.

Що означає «HTTP — безстановий протокол»?

Що за замовчуванням сервер не тримає в памʼяті нічого з попереднього спілкування: кожне нове звернення він читає з нуля. Строгіше формулювання таке — семантику окремого запиту можна зрозуміти ізольовано, а те, що повідомлення приїхали одним зʼєднанням, їхнє тлумачення не змінює. Мотив — масштабованість і простота: якщо серверу не треба памʼятати клієнтів, будь-яка з десятка однакових машин обробить будь-який запит. І тут головне уточнення, на якому найчастіше валяться: безстановий саме протокол, а не застосунок. Свій стан застосунок має майже завжди — кошик, профіль, права; зберігається він у базі, а решту доносить клієнт кожним новим запитом. Для тестів звідси випливає правило: токен чи кукі мусять їхати з кожним зверненням, а не «один раз при логіні».

Що таке ідемпотентний метод і чому наївний ретрай POST небезпечний?

Ідемпотентність означає, що повторення того самого запиту не додає нічого понад результат єдиного виклику; під це підпадають PUT, DELETE і всі безпечні методи. POST до них не належить, і це не формальність: він просить сервер обробити передані дані, тож повторне надсилання цілком законно створює ще один обʼєкт. Класична історія в CI виглядає так — запит відпав по таймауту, обгортка мовчки повторила його, сервер обробив обидва, і в базі зʼявився дубль, який потім ламає наступний тест на унікальності. Тому автоматичний ретрай безпечно вішати на ідемпотентні методи, а для POST потрібен інший механізм — узгоджений із бекендом ключ ідемпотентності або перевірка перед повтором. Друга сторона тієї самої медалі: безстановий протокол сам собою не зберігає нічого між тестами, тож увесь спільний стан — записи в базі, кукі, глобальні фікстури — створюєш ти, і саме він потім тече між прогонами.

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

Памʼятає не протокол, а застосунок — за ключем, який клієнт сам приносить у кожному запиті. Класична схема: після входу серверна сторона лишає запис про сесію в себе — у памʼяті, Redis чи базі — і повертає браузеру самий лише ідентифікатор через Set-Cookie; далі рішення, чи причепити Cookie до чергового запиту, браузер ухвалює сам, спираючись на збережені метадані. Код сторінки в цьому не бере участі — саме тому кукі-сесія без жодних зусиль переживає перезавантаження вкладки. Альтернатива — токен: потрібні дані носить у собі він сам, тож серверу нема чого зберігати; лежати токен може або в кукі, або у сховищі браузера, і в другому разі жодної автоматики немає — заголовок Authorization формує код. Ця різниця дуже практична: зі сховища токен потрапляє в запит лише тоді, коли його туди поклав клієнтський код, тож «залогінився, а API каже 401» найчастіше означає саме це. Для тестів із цього народжується головна економія розділу: форму входу проходять один раз, а далі підставляють уже здобутий стан автентифікації.

Чим SPA відрізняється від MPA з погляду очікувань у тесті?

SPA завантажує один документ і далі перемальовує його вміст засобами JavaScript, підтягуючи дані фоновими запитами; адресою при цьому займається History API: history.pushState() і history.replaceState() переписують URL без походу на сервер. У MPA кожен екран є окремим документом, тож перехід означає, що браузер іде по новий документ і будує сторінку заново. Для тесту вся різниця зводиться до одного питання: чи існує тут момент «сторінка завантажилась». У MPA є чіткі навігаційні події, і дочекатися завершення переходу відносно просто. У SPA ці сигнали спрацьовують один раз на старті й потім більше нічого не означають, тому чекати доводиться на появу самого контенту — конкретного елемента чи стану. Звідси й типова помилка: «документ завантажився, отже дані на екрані» — у SPA хибний висновок, бо документ приїхав раніше за дані.

Коли потрібен WebSocket, а коли вистачить звичайного запиту?

Межа проходить по тому, хто має заговорити першим. Якщо ініціатива лишається за клієнтом, схема «запит — відповідь» покриває все. Якщо ж першим має озватися сервер — чат, нотифікації, живі оновлення статусу, — базового HTTP не вистачає, і до появи WebSocket це імітували постійним опитуванням сервера, полінгом (polling), який специфікація прямо називає зловживанням протоколом. WebSocket — двобічний обмін поверх одного TCP-зʼєднання; відкривають його звичайним GET, до якого додають Upgrade: websocket і Connection: Upgrade, а підтвердженням служить єдиний можливий статус 101 Switching Protocols. Після переходу перед нами вже окремий протокол зі схемами ws і wss, де ні заголовків, ні повторної автентифікації на кожне повідомлення не потрібно. Поруч живе простіший інструмент — Server-Sent Events: дані там рухаються лише в один бік, від сервера до клієнта, через інтерфейс EventSource і відповідь text/event-stream, а перепідключення вбудоване в сам механізм. Для тестів головне те, що кореляції «запит — відповідь» тут немає: чекати треба на подію-наслідок, а не на фіксовану паузу.

REST — це протокол?

Ні. REST — архітектурний стиль, тобто перелік обмежень, які Рой Філдінг наклав на взаємодію компонентів системи. Частину цих обмежень видно вже в базовій моделі вебу: client-server (розділення відповідальностей), stateless (запит несе все потрібне сам) і layered system — компонент не бачить далі сусіднього шару, тому на шляху й можуть стояти посередники. Решта — кешованість, необовʼязковий code on demand і, найголовніше, єдиний інтерфейс із чотирьох складників: ресурси ідентифікуються, змінюють їх через представлення, повідомлення самоописові, а рушієм стану служить гіпермедіа. Практично стиль дає простий поділ ролей: що — визначає адреса ресурсу, а що з ним робимо — метод. За GET закріплено отримання представлення, POST віддає надіслані дані серверові на обробку, PUT або створює ресурс, або повністю переписує його стан, а DELETE просить розірвати звʼязок між ресурсом і його функціональністю. Тому питання «чи RESTful цей API» коректно розбирати як питання про дотримання обмежень, а не про наявність JSON у відповіді.

Інфраструктура переїхала на HTTP/2 або HTTP/3. Що з цього побачать тести?

Семантика від версії не залежить: метод, шлях, заголовки й статус лишаються ті самі, бо специфікація навмисно вимагає, щоб повідомлення можна було ретранслювати іншою версією без зміни змісту. Тому в панелі мережі ти бачиш звичні поля незалежно від того, що на дроті, і переписувати асерти не доводиться. Змінюється кодування: HTTP/1.1 текстовий і читається очима, а в HTTP/2 ті самі повідомлення вкладені у двійкові кадри — MDN перелічує три відмінності: двійкова форма, мультиплексування (кілька запитів паралельно в одному зʼєднанні) і стиснення заголовків. HTTP/3 живе поверх QUIC, а кадрування на кожному його потоці зроблено схожим на те, що є в HTTP/2. Щодо поширення: за даними, на які посилається MDN, пік вживання HTTP/2 припав на січень 2022 і склав 46,9 % усіх сайтів, а частка сайтів на HTTP/3 у жовтні 2022 становила 26 %. Найважливіший для QA наслідок інший: перехід не потребує змін у коді застосунку, тому команда може про нього навіть не оголосити — а поведінка мережі під тестами зміниться сама, і плаваючі падіння звідти виглядатимуть як регресія продукту.

Три кейси, які тримаються на одній думці глави: тест — такий самий клієнт, як браузер. Спершу карта ланок, за якою «незрозуміле» падіння на CI розкладається на конкретного підозрюваного; далі — як користуватися роллю клієнта свідомо й дешево готувати стан; наостанок — де модель «запит — відповідь» перестає працювати і на що тоді чекати.

Кейс 1. «Локально зелено, на CI червоно»: карта ланок

Між твоїм expect і кодом застосунку стоїть довгий ланцюг, якого в тесті не видно: імʼя, адреса, порт, зʼєднання, рукостискання, посередники. Більшість «містичних» падінь живе саме там, і впізнаються вони за симптомом ще до читання логів застосунку. Порядок перегляду — вздовж ланцюга, від імені до застосунку.

Три висновки, які економлять години.

• Клас симптому вже називає винного. Відсутність статус-коду означає, що до застосунку не дійшло — ламалося зʼєднання, імʼя або сертифікат. Наявність статусу означає, що хтось відповів; лишається зʼясувати хто — застосунок чи посередник перед ним.
• 502 і 504 — не тікет на розробників за замовчуванням. Обидва коди за означенням віддає вузол у ролі шлюзу чи проксі, тобто скарга йде на ланку за ним, і застосунок про такий запит міг узагалі не дізнатися. 503 — інша історія: тут озвався сам сервіс і сказав, що зараз не може.
• «У мене працює» майже завжди означає іншу ланку, а не інший код. Локальна машина й агент CI відрізняються резолвом імен, доступом крізь проксі, набором сертифікатів і тим, які порти вже зайняті. Тому перше питання до червоного пайплайна — не «що змінили в застосунку», а «чим відрізняється шлях запиту».

Кейс 2. Тест як клієнт: дешева передумова й один логін

Якщо тест — клієнт, то він може ходити двома дорогами, і вибір дороги вирішує, наскільки він крихкий. Клацання формою залежить від верстки, анімацій і локаторів; той самий результат через API від них не залежить взагалі. Звідси робочий поділ: стан готуємо запитом, перевіряємо — інтерфейсом.

import { test, expect } from '@playwright/test';

test('щойно створене замовлення видно на його сторінці', async ({ page, request }) => {
  // передумова одним запитом замість проходу по формах
  const created = await request.post('/api/orders', {
    data: { sku: 'SOME-SKU-1', qty: 2 },
  });

  // передумова мусить падати голосно й окремо від самої перевірки
  expect(created.status(), 'замовлення не створилося — це не баг UI').toBe(201);
  const { id } = await created.json();

  await page.goto(`/orders/${id}`);
  await expect(page.getByTestId('order-status')).toHaveText('Нове');
});

Логін — окремий випадок тієї самої ідеї. Протокол не памʼятає нічого між запитами, тож стан автентифікації тримає клієнт: кукі або те, що лежить у сховищі браузера. Значить, його достатньо здобути один раз і покласти у файл.

// auth.setup.ts — відпрацьовує один раз перед сюїтою
import { test as setup, expect } from '@playwright/test';

const authFile = 'playwright/.auth/user.json';

setup('здобути стан автентифікації', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.USER_EMAIL!);
  await page.getByLabel('Пароль').fill(process.env.USER_PASSWORD!);
  await page.getByRole('button', { name: 'Увійти' }).click();

  // чекаємо наслідок входу, а не факт навігації
  await expect(page.getByTestId('user-menu')).toBeVisible();

  // у файл їдуть і кукі, і сховище браузера
  await page.context().storageState({ path: authFile });
});

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

• Статус передумови асертять окремо. Без цього невдале створення замовлення виявиться аж на перевірці інтерфейсу й прочитається як дефект UI. Асерт на 201 перетворює туманне падіння на точне: не створилося — і далі йти немає сенсу.
• POST не ідемпотентний, тому передумову не можна наївно ретраїти. Повторення того самого створення законно дає другий обʼєкт, а не той самий; на нестабільній мережі це тихо породжує дублі, які потім валять перевірку унікальності в сусідньому тесті. Якщо ретрай потрібен — потрібен і узгоджений з бекендом ключ, за яким сервер розпізнає повтор.
• Збережений стан покриває обидва механізми памʼяті про логін, і це не дрібниця. Кукі-сесія їде автоматично, бо її додає браузер; токен, покладений у сховище, летить лише тоді, коли клієнтський код сам поставив його в Authorization. Якщо застосунок тримає токен у сховищі, а тест дивує 401 при живих кукі — дивитись треба саме сюди.
• Дані для передумови роблять унікальними на прогін. Спільний стан між тестами створює не протокол, а ти: фіксований email чи артикул на другому прогоні законно впреться в конфлікт із тим, що вже лежить у базі.

Кейс 3. Коли «запит — відповідь» перестає працювати

Модель «клацнув — приїхала сторінка» описує MPA. У SPA документ приходить один раз, а далі вміст приносять фонові запити, і старий сигнал завантаження більше нічого не означає. У реалтаймі ще складніше: сервер озивається сам, і корелювати відповідь із запитом просто нема з чим.

// крихко: документ у SPA не перезавантажується, тож чекати завершення навігації нема чого
await page.getByRole('link', { name: 'Замовлення' }).click();
await page.waitForLoadState('load'); // спрацює миттєво й нічого не гарантує
await expect(page.getByTestId('order-row').first()).toBeVisible();

// надійно: чекаємо наслідок дії — потрібну відповідь і потрібний стан екрана
await Promise.all([
  page.waitForResponse((r) => r.url().includes('/api/orders') && r.ok()),
  page.getByRole('link', { name: 'Замовлення' }).click(),
]);

await expect(page.getByTestId('order-row').first()).toBeVisible();

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

test('статус замовлення оновлюється пушем із сервера', async ({ page }) => {
  const wsPromise = page.waitForEvent('websocket');
  await page.goto('/orders/42');
  const ws = await wsPromise;

  // чекаємо конкретну подію, а не фіксовану паузу
  await ws.waitForEvent('framereceived', (frame) =>
    String(frame.payload).includes('order.paid'),
  );

  await expect(page.getByTestId('order-status')).toHaveText('Оплачено');
});

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

• «Сторінка завантажилась» у SPA не означає «дані на екрані». Документ приїхав раніше за них, тому чекати треба контент — конкретний елемент або конкретну відповідь, — а не подію завантаження, яка вже давно відбулася.
• Навігація в SPA може взагалі не породити запиту на сервер. Адресу міняє History API, тож URL у рядку оновився, а мережею не пішло нічого; асерт на URL тут доводить менше, ніж здається.
• У реалтаймі фіксована пауза — це ставка, а не очікування. Подія приходить тоді, коли її надіслав сервер; waitForTimeout або дає flaky-тест, або дарма подовжує прогін. Чекають саме подію-наслідок.
• Кадр із сокета доводить менше, ніж стан екрана. Він каже, що сервер повідомив, а не що застосунок це показав. Тому кадр — проміжна синхронізація, а фінальний асерт лишається на інтерфейсі.

Ролі й форма обміну

• Можу пояснити асиметрію моделі — ініціативу тримає клієнт, сервер у класичній схемі першим не озивається — і назвати мотив поділу: інтерфейс окремо від зберігання даних заради переносності й масштабування.
• Розумію, чому автотест стоїть у моделі там само, де браузер чи curl, і вмію назвати наслідок: усе, що ламає браузер на стенді, ламає й тест.
• Памʼятаю склад запиту (метод, шлях, заголовки, тіло) і відповіді (статус у межах 100–599, заголовки, тіло) і знаю точне формулювання «один запит — одна відповідь»: рівно одна фінальна, якій можуть передувати проміжні 1xx на кшталт 100 Continue чи 103 Early Hints.

Адреси, порти й зʼєднання

• Розумію, чому після переїзду стенда тести ще стукають за старою адресою: винен TTL запису в кеші DNS, а орієнтир для типового вузла — порядок днів.
• Знаю різницю IP vs порт (машина vs сервіс на ній), памʼятаю діапазон 0–65535 і типові порти 80/443, які можна не писати.
• Розумію пастку localhost: імʼя веде і на 127.0.0.1, і на ::1, тож сервіс, який слухає лише IPv4, для клієнта, який пішов на IPv6, просто не існує — рятує явна адреса замість імені.
• Можу описати, що відбувається до першого байта корисного трафіку: рукостискання TCP (SYN → SYN-ACK → ACK) і TLS із ClientHello/ServerHello, а також три гарантії TLS — автентифікація (сервер завжди, клієнт опційно), конфіденційність, цілісність.

Затримка, смуга й посередники

• Знаю різницю затримки vs пропускної здатності, вмію показати їхню незалежність (добуток «смуга × затримка», long fat network) і поставити діагноз: десятки дрібних викликів упираються в затримку, велике завантаження — у смугу; окремо памʼятаю, чому перший запит до хоста дорожчий за наступні і що саме економить keep-alive.
• Можу пояснити, чому оптимізації вебу зменшують саме кількість round-trips: перевикористання зʼєднань, мультиплексування HTTP/2, кешування, CDN, обʼєднання підняття транспорту з узгодженням TLS у QUIC.
• Знаю різницю проксі vs шлюз за роллю, а не за місцем: проксі призначає клієнт, шлюз для зовнішнього світу виглядає як сам origin-сервер, балансувальник — окремий випадок шлюзу, а тунель лише сліпо ретранслює.
• Не плутаю 502/504 з 503: перші два віддає вузол у ролі шлюзу чи проксі (зламалася ланка за ним), 503 каже про сам сервіс — і памʼятаю, що вузол, якого клієнт не обирав, протокольно не відрізнити від атаки на шляху, тож поведінка запиту може змінитися без жодної зміни в застосунку.

Безстановість і стан застосунку

• Можу сформулювати stateless точно: семантика запиту зрозуміла ізольовано, а факт спільного зʼєднання на тлумачення повідомлень не впливає — і додати ключове уточнення, що безстановий тут протокол, а не застосунок.
• Знаю означення ідемпотентного методу, памʼятаю, що PUT, DELETE і безпечні методи такими є, і можу пояснити, чому наївний ретрай POST створює дубль, який потім ламає сусідній тест.
• Памʼятаю зворотний бік ізоляції: спільний стан — записи в базі, кукі, глобальні фікстури — створюю я сам, і протікає між прогонами саме він.
• Можу описати механізм памʼяті про логін: сервер тримає запис сесії у себе, віддає ключ через Set-Cookie, браузер сам повертає його заголовком Cookie.
• Знаю різницю кукі-сесії vs токена у сховищі (перша їде автоматично й переживає перезавантаження, другий летить лише тоді, коли код сам поклав його в Authorization) і логінюся один раз із перевикористанням збереженого стану.

SPA, реалтайм і версії протоколу

• Знаю різницю SPA vs MPA і наслідок для очікувань: у MPA є навігаційні події, у SPA документ приїхав раніше за дані, тому чекають появу контенту, а history.pushState() міняє URL без запиту на сервер.
• Можу назвати межу застосування WebSocket — потрібен, коли першим має заговорити сервер; відкривається GET-запитом з Upgrade і підтверджується статусом 101 — і відрізнити його від SSE (однобічний канал через EventSource і text/event-stream).
• Можу пояснити, що REST — архітектурний стиль, а не протокол, назвати його обмеження й поділ ролей: адреса каже, що за ресурс, метод — що з ним робимо.
• Знаю, що семантика повідомлення не залежить від версії HTTP (змінюється кодування: текст у 1.1, двійкові кадри й мультиплексування у 2, QUIC у 3) і що перехід не потребує змін у коді застосунку — тому про нього можуть не попередити.