SeniorДизайнЧастоЕщё не отвечали
Приложение вызывает HTTP API по сети. Пройдите от начала до конца всё, что система делает, чтобы доставить этот запрос и вернуть ответ — от вызова приложения вниз через операционную систему и сетевой стек, через физическую сеть, до сервера и обратно. Затроньте, как разрешается адрес назначения, как устанавливаются соединение и шифрование, как данные оборачиваются при спуске по стеку и где в пути задействуются промежуточные узлы.
Запрос проходит: (1) API; (2) сокет ОС + TCP/IP; (3) DNS (кеш → stub → recursive → authoritative); (4) 3-way TCP handshake; (5) TLS при HTTPS; (6) HTTP; (7) ARP, маршрутизация, NAT, балансировщик; (8) сервер; (9) ответ обратно. Инкапсуляция: HTTP body → TCP → IP → Ethernet.
- ✗Пропускать задержку DNS в оценках — холодный DNS-запрос добавляет 20–200 мс; кэш ОС, кэш браузера и управление TTL EDNS0 критически важны для производительности
- ✗Не учитывать стоимость установки соединения — TCP + TLS добавляет 1.5–2 RTT; пул соединений и keep-alive устраняют эти накладные расходы для последующих запросов
- ✗Игнорировать буфер TCP ОС и алгоритм Нэгла — небольшие записи по умолчанию объединяются;
TCP_NODELAYотключает Нэгла для протоколов, чувствительных к задержке
- →На каком этапе задействуется ARP, и как это отличается для запроса через подсеть?
- →Как обратный прокси (nginx) изменяет жизненный цикл запроса по сравнению с прямым соединением?
Оглавление
Жизненный цикл сетевого запроса
Схема прохождения
Приложение
│ 1. HTTP-клиент вызывает connect() + write()
│
OS / Kernel
│ 2. Системный вызов → сокет создан
│ 3. DNS: gethostbyname() или getaddrinfo()
│ └─ /etc/hosts → кэш OS (nscd) → stub resolver → рекурсивный DNS (ISP)
│ └─ ROOT → TLD → авторитативный DNS → ответ A/AAAA
│ 4. TCP connect() → 3-way handshake (SYN / SYN-ACK / ACK)
│ 5. TLS handshake (ClientHello…Finished) — ~1 RTT в TLS 1.3
│ 6. HTTP/1.1: GET /path HTTP/1.1\r\nHost: …\r\n\r\n
│ или HTTP/2: HEADERS + DATA фреймы
│
Сетевой стек
│ 7. TCP-сегментация → IP-пакет (TTL=64, src/dst IP)
│ 8. IP → выбор маршрута → ARP для next-hop MAC
│ 9. NIC → Ethernet-фрейм (src MAC, dst MAC, EtherType)
│
Сеть (физический путь)
│ 10. Коммутатор L2 → маршрутизатор L3 → NAT (изменяет src IP:port)
│ 11. Балансировщик нагрузки / обратный прокси (nginx/HAProxy)
│ └─ TLS termination, добавление X-Forwarded-For
│
Серверное приложение
│ 12. accept() → обработка запроса → формирование ответа
│ 13. Ответ проходит весь путь в обратном направленииТаблица задержек на каждом этапе
| Этап | Типичная задержка |
|---|---|
| DNS (холодный) | 20–200 мс |
| DNS (кэш OS) | < 1 мс |
| TCP handshake | 1 RTT (10–100 мс) |
| TLS 1.3 handshake | 1 RTT |
| TLS 1.2 handshake | 2 RTT |
| HTTP запрос + ответ | зависит от сервера |
| С HTTP keep-alive | только RTT передачи |
Оглавление
