Зміст
Сьогодні відкриття будь-якої веб-сторінки запускає ланцюжок із десятків технологій, сервісів і протоколів. Користувач натискає посилання — і за частки секунди бачить готовий інтерфейс, хоча за кліком ховаються браузер, DNS, мережа доставки контенту, балансувальники, веб-сервери, застосунки, кеші, черги та бази даних. У цій статті пройдемо весь шлях запиту: від введення https://example.com до запису в PostgreSQL і повернення відповіді в браузер.
Ключові висновки
Веб — це розподілена система, а не «сайт на сервері». Навіть проста сторінка проходить через DNS, TCP/TLS, можливо CDN і reverse proxy, перш ніж код застосунку побачить запит. Розуміння кожної ланки допомагає відрізнити мережеву проблему від SQL.
Межі відповідальності розділені навмисно. Веб-сервер приймає з'єднання й віддає статику; застосунок містить бізнес-логіку; БД зберігає стан. Змішувати ролі зручно на старті й дорого при зростанні.
Кеш і асинхронність — не оптимізація «на потім». Browser cache, CDN, Redis і черги визначають, чи витримає продукт пік навантаження без деградації латентності.
Фронтенд 2020-х — продовження backend. React, SSR, SSG і гідратація не скасовують API та авторизацію на сервері. Історія змін — у огляді еволюції веб-архітектур.
Без спостережуваності систему не супроводжувати. Логи, метрики й трейсинг (OpenTelemetry, Prometheus, Grafana) — частина архітектури, коли сервісів більше одного.
Вступ: навіщо розбирати шлях запиту цілком
Розробник, який бачить лише свій шар — React-компонент або SQL-запит — часто лікує симптоми. «Сторінка гальмує» може означати відсутність індекса в PostgreSQL, промах CDN або важкий JS-бандл. Карта повного шляху перетворює здогадки на чеклист.
Уявіть інцидент: користувачі скаржаться на повільне оформлення замовлення. Фронтенд бачить у DevTools POST /orders — 4 секунди. APM показує 3,8 с на одному SQL без індекса. DevOps помічає інстанс з 98% CPU через витік пам'яті у воркері. Без спільної карти кожен лагодить «свій» шар, а корінна причина лишається.
Далі рухаємося в тому ж порядку, як пакети йдуть мережею: від URL у адресному рядку до JSON у DevTools і назад. Приклади — типовий стек (Nginx, Node/NestJS, PostgreSQL, Redis), але принципи переносяться на PHP, Go й Java.
Що відбувається після введення адреси сайту
Користувач вводить https://example.com/products. Браузеру потрібно дізнатися IP-адресу хоста, встановити захищене з'єднання і який ресурс запросити. Поки DNS не поверне адресу, TCP не почнеться; поки не завершиться TLS, HTTP не піде відкритим текстом.
DNS — інтернетний «телефонний довідник»
Браузер підключається до IP, а не до імені — наприклад 192.0.2.1 для example.com. DNS перетворює домен через кеш, resolver, кореневі та TLD-сервери, авторитетні DNS домену.
Кешування прискорює повторні візити, але затримує поширення змін (TTL). Перед міграцією хостингу TTL знижують заздалегідь — інакше частина користувачів ще добу ходить на старий IP. Окрім A/AAAA, важливі CNAME на CDN, MX, TXT. Помилка DNS — «сайт лежить» при живому сервері. Допомагають dig, nslookup, панелі Cloudflare.
Встановлення з'єднання
TCP Handshake
Після отримання IP браузер відкриває TCP на порт 443: SYN, SYN-ACK, ACK. Кожен round-trip додає латентність; на мобільних мережах TCP+TLS можуть коштувати чверть секунди до першого байта HTTP. HTTP/2 мультиплексує потоки; HTTP/3 на QUIC краще переживає зміну мережі. Keep-alive критичний — без нього кожен asset платить повний handshake знову.
TLS і HTTPS
TLS узгоджує версію, обмінюється сертифікатами, перевіряє сайт і встановлює ключі. Let's Encrypt зробив HTTPS масовим. HSTS змушує браузер завжди використовувати HTTPS — захист від downgrade-атак.
HTTP-запит
Коли канал готовий, браузер надсилає HTTP-запит. Приклад:
GET /products HTTP/1.1
Host: example.com
Accept: text/html,application/json
Cookie: session_id=abc123
Authorization: Bearer eyJhbG...
Метод визначає семантику: GET — читання, POST — створення, PUT/PATCH — оновлення, DELETE — видалення. Від методу залежать кешування та ідемпотентність — це впливає на проєктування API.
Заголовки несуть метадані: тип контенту (Content-Type), мова, аутентифікація (Authorization, Cookie), директиви кешу (Cache-Control), CORS при cross-origin запитах.
Тіло запиту використовується в POST/PUT/PATCH — JSON замовлення, завантаження файлу. Для GET параметри зазвичай у query string (?page=2).
Відповідь сервера: статус-коди (200, 404, 500), заголовки (Set-Cookie) і тіло. HTTP/2 — кілька потоків у одному з'єднанні; великі cookie все одно б'ють по мережі.
CDN — чому сайт відкривається швидко
CDN (Content Delivery Network) — мережа edge-серверів у десятках міст. Статика (зображення, CSS, JS) і іноді HTML віддаються з найближчої точки, а не з єдиного датацентру.
Користувач з Києва може отримати app.js з європейського PoP, а не чекати трансатлантичний канал. Cloudflare, Fastly, Akamai кешують відповіді за Cache-Control і власними політиками.
Origin лишається джерелом істини; CDN — прискорювач і щит від DDoS. Динамічні API (POST /orders) частіше йдуть на origin.
Директиви: max-age, s-maxage, stale-while-revalidate. Після деплою — purge кешу, інакше користувачі бачать старий app.js. Статику з fingerprint (app.a1b2c3.js) кешують довго, HTML — коротко.
Балансувальник навантаження
Продакшен-сайт рідко живе на одній віртуальній машині. Перед пулом застосунків стоїть балансувальник — Nginx, HAProxy, AWS ALB.
Завдання: розподілити трафік між здоровими інстансами, зняти SSL (termination), перевіряти health checks, маршрутизувати за шляхом (/api → backend).
Алгоритми: Round Robin, Least Connections, Weighted. При падінні одного сервера трафік йде на інші.
Sticky sessions потрібні, якщо сесія в пам'яті процесу — краще Redis. Health check б'є в GET /health кожні 5–10 с. L7-балансувальник маршрутизує за path і host.
Веб-сервер
За балансувальником — Nginx, Apache або Caddy. Приймають TCP, завершують TLS, віддають статичні файли, проксують динамічні запити на upstream, стискають gzip/brotli, обмежують rate limit.
Веб-сервер ≠ застосунок. Nginx рухає байти й захищає upstream. Event-driven модель: мало воркерів — тисячі з'єднань. location /api/ → upstream на порт 3000, location / → статика або SSR.
Сервер застосунку
Тут бізнес-логіка: Laravel/Symfony (PHP), NestJS/Fastify (Node), Spring Boot (Java), ASP.NET, Gin/Fiber (Go). Застосунок слухає внутрішній порт (3000, 8080), недоступний з інтернету — лише через Nginx. Запускають через systemd, PM2 або Kubernetes; горизонтальне масштабування — більше однакових інстансів за балансувальником.
Що відбувається всередині застосунку
Розглянемо POST /orders — створення замовлення.
Роутинг зіставляє URL і метод з обробником. Middleware — ланцюжок до контролера: парсинг JSON, CORS, логування, аутентифікація, валідація схеми (Zod, class-validator).
Контролер витягує тіло запиту, викликає сервіс, формує HTTP-відповідь. Сервісний шар — правила: чи можна замовити при нульовому залишку, розрахунок знижки, виклик платіжного шлюзу. Репозиторій (ORM) — OrderRepository.save(), SQL через Prisma, TypeORM, Eloquent.
Таке розділення спрощує тести: сервіс мокає репозиторій, контролер мокає сервіс.
Для POST /orders: middleware auth читає JWT; validate перевіряє схему; сервіс у транзакції перевіряє склад, списує оплату, зберігає замовлення, ставить email у чергу; повертає 201. Помилка оплати — rollback, користувач не бачить «створене» замовлення без списання.
Аутентифікація та авторизація
Сервер має зрозуміти хто викликає API і що йому дозволено.
Сесії: після логіну сервер створює запис у Redis/БД, клієнт зберігає session_id у cookie. Плюси — відклик сесії на сервері; мінуси — sticky sessions.
JWT: самодостатній токен із підписом; сервер не зберігає сесію. Зручно для мікросервісів і SPA; складніше відкликати до закінчення терміну. Ризики — у матеріалі про JWT у Node.
OAuth 2.0: вхід через Google, GitHub, Microsoft — делегування ідентифікації провайдеру.
Cookie: HttpOnly, Secure, SameSite. JWT у localStorage вразливий до XSS. Деталі — безпека Node.js.
Кешування
Без кешу сучасний веб не масштабується. Рівні: browser cache за Cache-Control/ETag; CDN; reverse proxy (Nginx); Redis у застосунку — гарячі профілі, каталоги, важкі агрегації.
Інвалідація — найскладніша частина. Cache stampede лікується jitter TTL і single-flight. Патерни — у статті про кешування.
Черги повідомлень
Не кожну операцію треба робити в HTTP-запиті. Email, PDF, ресайз зображень, синхронізація з CRM — задачі для RabbitMQ, Kafka, Redis (Bull/BullMQ), Amazon SQS.
Патерн: API кладе повідомлення в чергу й одразу відповідає 202 Accepted з job_id; воркери обробляють у фоні. Користувач не чекає 30 секунд SMTP.
Асинхронність критична при зростанні; компроміс — eventual consistency. Воркери мають бути ідемпотентними. Kafka — для потоків подій; BullMQ на Redis — зручно в Node-стеку.
Робота з базою даних
Більшість бізнес-систем зберігають стан у БД.
Реляційні (SQL): PostgreSQL, MySQL — таблиці, зв'язки (FK), транзакції (ACID), індекси. Підходять для замовлень, фінансів, звітності.
NoSQL: MongoDB, Cassandra, Redis — коли гнучка схема або масштаб запису виправдовує вибір, а не «бо модно».
Пул з'єднань (PgBouncer) обмежує коннекти до PostgreSQL. Read replicas знімають навантаження читання з primary.
Що відбувається всередині бази даних
Запит SELECT * FROM orders WHERE id = 100 проходить: парсер SQL → оптимізатор (index seek vs full scan) → виконавець (читання сторінок з диска або з пам'яті) → повернення рядків застосунку.
Один і той самий запит — мілісекунди з індексом по id і хвилини при full table scan на мільярді рядків. EXPLAIN ANALYZE — перший інструмент DBA й backend-розробника.
Транзакції групують операції: або commit усього, або rollback. VACUUM прибирає мертві рядки; shared buffers тримають гарячі сторінки в RAM. Складний індекс (user_id, created_at) прискорює «замовлення користувача за період».
Звідки беруться проблеми продуктивності
Повільний SQL без індексів; N+1 у ORM; довгі транзакції під час очікування платіжного шлюзу; великий JSON замість пагінації; зайві HTTP-запити; важкий JS-бандл. Діагностика: Network tab (TTFB), APM, slow query log, Redis hit rate. Оптимізуйте найповільніший шар у ланцюжку.
Як відповідь повертається назад
Застосунок формує відповідь зі статусом, заголовками та тілом (JSON, HTML). Шлях: БД → застосунок → веб-сервер → (CDN) → браузер. Стиснення, HTTP/2, keep-alive зменшують overhead. Помилки структуровані: 4xx — клієнт, 5xx — сервер.
Сучасний фронтенд
Після HTML і JSON працює JavaScript. React будує UI з компонентів; Virtual DOM мінімізує дорогі операції з реальним DOM.
SPA, SSR, SSG, гідратація — компроміс інтерактивності та SEO. Astro мінімізує JS; Core Web Vitals (LCP, INP) залежать і від TTFB сервера. Див. нативний CSS.
Спостережуваність та експлуатація
Розподілену систему не полагодити з одного лог-файлу.
Логи — структурований JSON у ELK, OpenSearch, Loki; correlation id крізь сервіси. Метрики — Prometheus + Grafana: RPS, latency p95/p99, error rate, CPU/RAM. Трейсинг — OpenTelemetry, Jaeger: один trace на запит через Nginx → API → Redis → PostgreSQL.
Три стовпи доповнюють одне одного: логи відповідають «що сталося з цим request id», метрики — «скільки помилок за хвилину», трейси — «який span з'їв 90% часу». Алерти за SLO («p99 < 500 ms») випереджають скарги користувачів. Без цього мікросервіси стають чорною скринькою.
На практиці починають з метрик і структурованих логів; трейсинг додають, коли сервісів більше трьох і причину інциденту інакше шукають годинами.
Як виглядає архітектура сучасного веб-застосунку
Користувач
↓
Браузер (HTML, JS, cache)
↓
DNS → CDN (статика)
↓
Балансувальник
↓
Nginx / Caddy (TLS, proxy)
↓
Backend API (Node / Go / Java / PHP)
↓
Redis (cache, sessions)
↓
Черга (RabbitMQ / Kafka / SQS)
↓
PostgreSQL (+ read replicas)
↓
Об'єктне сховище (S3, MinIO)
Не кожен проєкт потребує всіх блоків одразу. Стартап живе на monolith + managed PostgreSQL; маркетплейс з піками — CDN, Redis, черги й горизонтальне масштабування API.
Еволюція типова: один VPS → CDN для статики → Redis для сесій → read replica для звітів → черга для фонових задач → Kubernetes, коли деплоїв більше десяти на тиждень. Файли (аватари, вкладення) — у S3/MinIO з підписаними URL, не BYTEA в Postgres на масштабі.
Як змінився веб за 20 років
2005: PHP + MySQL на одному сервері, повні перезавантаження сторінки. 2015: SPA, REST, Docker, хмари. 2025: Next.js, Astro, Kubernetes, Kafka, edge CDN. Детальніше — еволюція веб-архітектур. Веб швидший для користувача й складніший для команди.
Часті питання
Чому сайт довго відкривається вперше?
Часто винні холодний DNS, повний TLS-handshake, відсутність CDN і важкий перший JS-бандл. Повторний візит швидший завдяки кешу браузера та keep-alive.
Чим веб-сервер відрізняється від застосунку?
Веб-сервер приймає TLS, віддає файли, проксує. Застосунок виконує бізнес-логіку й ходить у БД. Розділення дозволяє масштабувати шари незалежно.
Чи потрібен Redis, якщо є PostgreSQL?
Redis не замінює Postgres. Він прискорює сесії, кеш, rate limiting, блокування, прості черги. Дані в Redis мають бути відновлюваними або допустимо ефемерними.
Коли черга замість синхронного API?
Коли операція довша за 200–500 ms, не критична для негайної відповіді або має пережити піки (email, звіти, інтеграції).
Чому один SQL-запит раптом сповільнився?
Зростання таблиці без індекса, застаріла статистика планувальника, блокування, конкуренція за диск. Дивіться EXPLAIN ANALYZE і slow query log.
SPA чи SSR у 2026?
Залежить від продукту: кабінет і дашборди — SPA/SSR; контентний маркетинг — SSG/SSR; максимальна простота — серверні шаблони + HTMX.
Чи обов'язковий Kubernetes?
Ні. PaaS, Docker Compose або serverless вистачає багатьом командам. Kubernetes виправданий при десятках сервісів.
Що таке TTFB?
Час до першого байта відповіді — включає DNS, TLS і роботу сервера. Високий TTFB при малому тілі вказує на backend або БД.
Чи потрібен BFF?
Коли мобільному й веб-клієнту потрібні різні агрегації даних, тонкий BFF зменшує round-trip. Для одного SPA часто вистачає версіонованого API (/v1/).
Далі для читання
Якщо ви будуєте або супроводжуєте веб-продукт, варто поглибитися в суміжні теми: еволюція веб-архітектур, приховані ризики безпеки Node.js, кешування на рівні застосунку, помилки з JWT та нативні можливості CSS.
Висновок
Клік за посиланням запускає розподілену систему: DNS знаходить хост, TCP і TLS будують канал, HTTP несе намір клієнта через CDN і балансувальники до коду, який читає кеш, ставить задачі в чергу й записує дані в БД. Відповідь іде зворотним шляхом, а браузер перетворює байти на інтерфейс.
Розуміння повного маршруту запиту — не академічна вправа. Воно допомагає обирати, де кешувати, де асинхронити, де індексувати — і не копіювати архітектуру Netflix у команді з п'яти людей. Збережіть цю статтю як карту: при наступному інциденті проходьте шар за шаром — від Network tab до EXPLAIN у базі.