Как работает веб

01Общая картина: аналогия с рестораном

Представьте, что открыть сайт — это как сделать заказ в ресторане, где вы никогда не были. Сначала вы узнаёте адрес (DNS). Потом идёте туда и получаете столик (TCP-соединение). Договариваетесь с официантом о «секретном языке», чтобы никто не подслушал (TLS). Делаете заказ по меню (HTTP-запрос). Кухня готовит (сервер выполняет код и обращается к базе данных). Официант приносит блюдо (HTTP-ответ), а вы раскладываете его на столе и начинаете есть (браузер разбирает и отрисовывает страницу). CDN — это филиал ресторана рядом с вашим домом, где популярные блюда уже готовы. Держите эту картинку в голове: каждый шаг ниже — её часть.

• URL: https://example.com/products?page=2 = схема + хост + путь + query-параметры.
• Клиент — браузер или приложение; сервер — машина, которая отвечает.
• Для большинства страниц задержка (время кругового пути, RTT) важнее пропускной способности.

02Шаги 1–3: DNS, TCP и TLS

Браузеру нужен IP-адрес, а не имя. Он проверяет свой кэш, кэш операционной системы, а затем спрашивает рекурсивный резолвер (вашего провайдера, 1.1.1.1 или 8.8.8.8). Резолвер обходит корневые серверы, затем серверы зоны .com, затем авторитативные nameserver'ы домена и кэширует ответ на время его TTL. Получив IP, браузер открывает TCP-соединение на порт 443 через трёхстороннее рукопожатие (SYN, SYN-ACK, ACK). Затем запускается TLS 1.3: браузер и сервер договариваются о ключах, а сервер подтверждает свою личность сертификатом. TLS 1.3 требует одного дополнительного кругового пути; HTTP/3 объединяет транспорт и TLS в одно QUIC-рукопожатие поверх UDP. На мобильном канале с задержкой 100 мс эти круговые пути — это уже 200–300 мс до прихода первого байта HTML, поэтому повторное использование соединений и близкие серверы так важны.

1# See each phase of a real request with timings
2curl -o /dev/null -s -w "dns: %{time_namelookup}s
3tcp: %{time_connect}s
4tls: %{time_appconnect}s
5first byte: %{time_starttransfer}s
6total: %{time_total}s
7" https://example.com/

03Шаги 4–6: запрос, сервер, ответ

По защищённому соединению браузер отправляет HTTP-запрос: метод (GET), путь и заголовки — Host, Accept-Language, cookie и подсказки для кэширования. На стороне сервера его принимает веб-сервер вроде nginx. Он может сразу отдать статический файл или передать запрос приложению (Laravel через PHP-FPM, процесс Node.js), которое выполняет бизнес-логику, читает базу данных или кэш и собирает HTML или JSON. Ответ возвращается со статус-кодом (200, 301, 404, 500), заголовками (Content-Type, Cache-Control, Set-Cookie) и телом, обычно сжатым gzip или Brotli. Time to First Byte (TTFB) измеряет весь этот круг: сеть плюс работа сервера. Медленный TTFB обычно означает медленные запросы к базе, отсутствие кэша или сервер, расположенный далеко от пользователя.

1GET /products?page=2 HTTP/1.1
2Host: example.com
3Accept: text/html
4Accept-Encoding: br, gzip
5 
6HTTP/1.1 200 OK
7Content-Type: text/html; charset=utf-8
8Content-Encoding: br
9Cache-Control: public, max-age=60

04Шаг 7: браузер собирает страницу

Браузер читает HTML по мере поступления и строит DOM — дерево элементов. Встретив CSS, он скачивает и разбирает его в CSSOM; CSS блокирует рендеринг, потому что браузер не будет рисовать нестилизованный контент. Классические теги script тоже блокируют разбор, если у них нет defer или async. DOM и CSSOM объединяются в дерево рендеринга, после чего браузер рассчитывает layout (размеры и позиции), рисует пиксели и компонует слои на GPU. Изображения, шрифты и дополнительные скрипты грузятся параллельно. JavaScript может позже изменить DOM, что снова запускает layout. Результат измеряют Core Web Vitals: LCP (как быстро появляется основной контент), INP (как быстро страница реагирует на ввод) и CLS (насколько элементы «прыгают»).

• Подключайте CSS пораньше, скрипты — с defer, а изображениям задавайте width и height.
• Делайте preload для главного изображения и основного шрифта; всё, что ниже первого экрана, грузите лениво.
• Меньше JavaScript почти всегда означает более быструю и отзывчивую страницу.

05Где здесь CDN

CDN (Content Delivery Network) — Cloudflare, Fastly или CloudFront — держит серверы в сотнях городов. Когда ваш DNS указывает на CDN, TLS-рукопожатие посетителя завершается на ближайшем edge-сервере, часто в 10–30 мс вместо 150 мс. Edge сам отдаёт закэшированные файлы (изображения, CSS, JS, иногда целые HTML-страницы) и пересылает на ваш origin-сервер только промахи кэша — по «тёплому», переиспользуемому соединению. Многие CDN также добавляют защиту от DDoS, web application firewall и HTTP/3. Цена — ещё один слой, в котором нужно разбираться: правила кэширования, настройки SSL между edge и origin и то, что ваш сервер теперь видит IP CDN, если не восстановить реальный IP посетителя из заголовка.

06Отладка цепочки на практике

Когда что-то не так, проверяйте каждое звено по порядку, а не гадайте. Резолвится ли имя в правильный IP? Открывается ли TCP-соединение на порт 443? Действителен ли сертификат для этого хоста? Какой статус-код и какие заголовки возвращаются? Медленный ли сервер (высокий TTFB) или браузер (долгое выполнение скриптов или рендеринг в DevTools)? Вкладка Network в браузере показывает время DNS, соединения, TLS, ожидания и загрузки для каждого файла. Вкладка Performance и Lighthouse показывают разбор, layout и отрисовку. На сервере access- и error-логи подскажут, дошёл ли запрос вообще.

1dig +short example.com A           # 1. DNS
2nc -vz example.com 443             # 2. TCP port open?
3openssl s_client -connect example.com:443 -servername example.com </dev/null | head -n 20   # 3. TLS
4curl -sI https://example.com/      # 4. status + headers
5sudo tail -f /var/log/nginx/access.log   # 5. did it reach the server?

07Почему важны первые 14 KB: TCP slow start

Новое TCP- или QUIC-соединение не знает, насколько быстрый канал, поэтому начинает осторожно. Отправитель может держать «в полёте» всего около десяти пакетов (начальное окно перегрузки, примерно 14 KB), после чего должен ждать подтверждений, а затем удваивает этот объём на каждом round trip, пока ничего не теряется. Поэтому HTML-документ на 100 KB на свежем соединении требует нескольких round trip, а не одного, даже на быстром канале. Вот почему inline-критичный CSS и небольшой верх HTML ускоряют первую отрисовку и почему переиспользуемые, уже «прогретые» соединения ощущаются намного быстрее. Потеря пакетов заставляет отправителя снова уменьшить окно, поэтому мобильные сети с потерями вредят сильнее, чем подсказывают цифры пропускной способности. Современные алгоритмы управления перегрузкой, например BBR, лучше реагируют на потери, чем старые, но физика round trip никуда не девается.

• Небольшой HTML, отрендеренный на сервере, с критичным CSS отрисовывается раньше.
• Переиспользование соединений (keep-alive, мультиплексирование HTTP/2) позволяет следующим запросам пропустить slow start.
• Каждый дополнительный origin — это новый DNS-запрос, handshake и «холодное» окно.

08Как браузер решает, что загружать первым

Браузеры загружают ресурсы не в порядке их появления на странице. Пока основной парсер заблокирован скриптом, preload scanner читает сырой HTML наперёд и начинает загружать найденные изображения, стили и скрипты. Каждый запрос получает приоритет: CSS и блокирующие скрипты — высокий, изображения во viewport повышаются после layout, async-скрипты и изображения ниже первого экрана — низкий. Этим можно управлять. rel=preload загружает то, что сканер не видит, например шрифт, на который ссылается только CSS. fetchpriority=high помечает LCP-изображение как важное. 103 Early Hints позволяет серверу или CDN отправить preload-ссылки ещё до готовности HTML, используя время, пока сервер «думает». Ловушка — злоупотребление: если всё высокоприоритетное, значит, ничего, а preload неиспользуемых файлов тратит пропускную способность на критическом пути.

1<!-- In the <head>: help the browser find critical files early -->
2<link rel="preconnect" href="https://cdn.example.com" crossorigin>
3<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
4<img src="/img/hero.avif" width="1200" height="630" fetchpriority="high" alt="Product hero">
5<img src="/img/footer.webp" width="400" height="300" loading="lazy" alt="Team photo">
6<script src="/js/app.3f9a1c.js" defer></script>

09Слои кэша между пользователем и базой данных

На запрос можно ответить на многих уровнях, и каждый дешевле следующего. В браузере: back/forward cache держит целые страницы в памяти для мгновенного перехода назад; memory и HTTP disk cache хранят файлы согласно Cache-Control; service worker может отвечать из собственного кэша, даже офлайн. Дальше — edge CDN, иногда с региональным уровнем перед origin. На origin reverse proxy вроде nginx может кэшировать целые ответы (microcaching на несколько секунд гасит всплески трафика). Внутри приложения Redis или in-memory кэш хранят вычисленные данные, а у базы есть свой buffer pool. Инженерный вопрос всегда один: где этот ответ можно безопасно переиспользовать, для кого и как долго? Персонализированные данные могут жить только в кэшах с ключом, привязанным к конкретному пользователю.

10Доверие по всей цепочке: что можно подделать

Каждый шаг чему-то доверяет. Обычные DNS-ответы можно подделать во враждебной сети, поэтому существует DNSSEC, а зашифрованный DNS (DNS over HTTPS или TLS) скрывает запросы от локальной сети. Но настоящая защита — это TLS: даже если DNS отправит вас на чужой IP, атакующий не сможет предъявить валидный сертификат для example.com, и браузер остановится. HSTS убирает первый незащищённый запрос по http://, который атакующий мог бы перехватить. Внутри браузера same-origin policy не даёт одному сайту читать данные другого, cookie с SameSite ограничивают межсайтовые запросы, а Content-Security-Policy ограничивает, какие скрипты могут выполняться. На стороне сервера всё в запросе (заголовки, cookie, X-Forwarded-For) — это пользовательский ввод, пока за него не поручился доверенный прокси.