Компьютерные сети
What happens when you type google.com
Это самый популярный вопрос на networking интервью в FAANG. Один вопрос покрывает DNS, TCP, TLS, HTTP, CDN и позволяет интервьюеру оценить глубину понимания на любом уровне.
- **Google SRE**: понимание flow критично для диагностики latency проблем и оптимизации TTFB (Time To First Byte)
- **Frontend Performance**: знание, где тратится время, помогает применять правильные оптимизации (preconnect, dns-prefetch)
- **System Design**: этот flow - основа для проектирования любого web-сервиса с требованиями к latency
Предварительные знания
DNS Lookup
Первый шаг - **преобразование доменного имени в IP-адрес**. Браузер не знает, куда отправлять запрос, пока не получит IP сервера Google.
**Иерархия DNS lookup**: Browser cache → OS cache → Router cache → ISP DNS → Recursive resolution (Root → TLD → Authoritative)
На практике большинство запросов попадают в кеш браузера или ISP. TTL записи определяет время жизни в кеше - Google использует короткий TTL (~300 сек) для гибкости распределения нагрузки.
Почему Google использует короткий DNS TTL (~5 минут)?
TCP Handshake
Получив IP-адрес, браузер устанавливает **TCP соединение** на порт 443 (HTTPS). TCP требует предварительного handshake - это добавляет один RTT к задержке.
**RTT** (Round Trip Time) - время туда и обратно. Москва → Калифорния ≈ 150-200ms. При высоком RTT каждый handshake ощутимо замедляет загрузку.
TCP Handshake также согласует **Window Size** (сколько данных отправлять без подтверждения) и **MSS** (Maximum Segment Size). Это влияет на пропускную способность соединения.
Сколько RTT требуется для установки TCP соединения?
TLS Handshake
После TCP соединения браузер инициирует **TLS handshake** для шифрования. Это ещё 1-2 RTT, но TLS 1.3 и техники вроде 0-RTT могут сократить задержку.
**SNI** (Server Name Indication) - клиент указывает домен в ClientHello. Это позволяет одному IP обслуживать множество HTTPS сайтов, но SNI передаётся в открытом виде (ECH решает это).
Браузер проверяет сертификат: срок действия, подпись CA, цепочку до root CA. При ошибке - показывает предупреждение. Google использует собственный CA через Chrome для certificate pinning.
Что передаётся в открытом виде даже при HTTPS?
HTTP Request & Response
Наконец браузер отправляет **HTTP запрос**. Google использует HTTP/2 или HTTP/3, что позволяет мультиплексировать запросы и передавать заголовки в сжатом виде.
**alt-svc** header предлагает браузеру перейти на HTTP/3 (QUIC) для последующих запросов. QUIC объединяет TCP+TLS в один протокол и работает поверх UDP.
Google использует агрессивное сжатие (gzip/brotli), HTTP/2 Server Push, preload hints. Ответ включает HTML, который ссылается на CSS, JS, изображения - каждый ресурс это отдельный запрос (но в HTTP/2 все идут по одному соединению).
Какое преимущество HTTP/2 критично для страницы с множеством ресурсов?
Full Flow Timeline
Соберём полную картину от нажатия Enter до отображения страницы. Понимание каждого этапа критично для оптимизации производительности и ответа на system design интервью.
**На интервью** разбивайте ответ на слои: Application (HTTP), Transport (TCP/QUIC), Security (TLS), Network (IP routing), Link (Ethernet/WiFi). Показывайте, как каждый слой добавляет к latency.
Оптимизации Google: CDN (сервер рядом с пользователем), TCP Fast Open, TLS 1.3 0-RTT, HTTP/3 (QUIC без handshake при reconnect), preconnect hints в HTML, Service Workers для кеширования.
HTTPS добавляет значительный overhead и замедляет сайт
TLS 1.3 добавляет всего 1 RTT, а HTTP/3 (QUIC) объединяет transport и security в один handshake. Преимущества кеширования и HTTP/2 часто компенсируют overhead
Современные протоколы оптимизированы для минимального latency. 0-RTT resumption, QUIC, certificate caching делают HTTPS почти бесплатным. Не-HTTPS сайты даже медленнее из-за отсутствия HTTP/2.
Что больше всего влияет на latency при первом визите на сайт из другого континента?
Итоги
- **DNS → TCP → TLS → HTTP** - базовая последовательность для любого HTTPS запроса
- **RTT доминирует** - на больших расстояниях handshakes важнее размера данных
- **CDN критичен** - приближение сервера к пользователю уменьшает RTT в разы
- **HTTP/3 (QUIC)** - следующее поколение, объединяет TCP+TLS и работает поверх UDP
Связанные темы
Этот вопрос объединяет множество networking концепций:
- DNS Resolution — Первый шаг - преобразование домена в IP
- TLS и HTTPS — Шифрование соединения после TCP handshake
- HTTP/2 и HTTP/3 — Мультиплексирование и оптимизации протокола
Вопросы для размышления
- Как бы вы оптимизировали загрузку страницы для пользователей из Австралии при серверах в США?
- Почему Google использует собственные DNS серверы (8.8.8.8) и CDN?
- Как изменится flow при использовании HTTP/3 вместо HTTP/2?