Что происходит после DNS запроса и получения IP адреса?
Что проверяют
Знаете ли вы, что происходит между полученным адресом и первым байтом ответа, и понимаете ли, чем за это платит фронтенд. Вопрос не про сетевую теорию, а про то, откуда берётся долгий ответ и лишние задержки на странице.
Как отвечать
По шагам:
- открывается соединение TCP: обмен пакетами синхронизации и подтверждения, это один круг до сервера;
- для защищённого протокола поверх идёт рукопожатие TLS: согласование версии и шифров, имя хоста, цепочка сертификатов, ключи. Ещё один круг, при возобновлении сессии короче;
- уходит запрос с заголовками, сервер отвечает статусом, заголовками и телом;
- браузер начинает разбирать HTML, не дожидаясь конца загрузки, а предзагрузчик попутно вытаскивает из разметки ссылки на стили, скрипты и картинки;
- соединение не закрывается: следующие запросы к тому же источнику идут по нему же, а на HTTP/2 и HTTP/3 ещё и параллельно внутри одного соединения.
Для фронтенда отсюда следует практика: сокращать число источников, потому что каждый новый домен это снова разрешение имени, соединение и шифрование; ставить preconnect тем сторонним источникам, которые точно понадобятся; убирать цепочки редиректов, каждая добавляет круг, а смена схемы или домена ещё и новое соединение; не разносить статику по поддоменам ради параллельности, на современных протоколах это только вредит.
Где спотыкаются
Путают уровни и говорят, что браузер отправляет HTTP-запрос на DNS-сервер. Следом обычно выясняется, что TLS считают частью TCP, а не отдельным шагом поверх него.
Второе: думают, что на каждый запрос открывается новое соединение и закрывается после ответа. Отсюда растут советы дробить домены ради параллельных загрузок, которые при мультиплексировании дают обратный эффект.
Третье: не связывают всё это с производительностью своей страницы. Сторонний скрипт с чужого домена оплачивает цепочку заново и часто оказывается вверху списка блокирующих ресурсов, хотя в коде выглядит одной строчкой.