Какое соединение устанавливается между клиентом и сервером

Что проверяют

Понимаете ли вы, что HTTP сам по себе не соединение, а протокол поверх транспорта, и что транспорт бывает разным. Для фронтенда вопрос прикладной: от числа и типа соединений зависит скорость загрузки. Следом часто спрашивают, чем HTTP/2 отличается от HTTP/3 или как устроен WebSocket.

Как отвечать

Идите снизу вверх и называйте цену каждого шага:

• DNS: браузер узнаёт IP-адрес по имени, ответ кешируется;
• TCP: тройное рукопожатие SYN, SYN-ACK, ACK, это один круг до сервера (RTT). TCP даёт надёжную доставку в правильном порядке;
• TLS: для HTTPS поверх TCP договариваются о шифровании. В TLS 1.3 это ещё один RTT, при повторном заходе возможен 0-RTT;
• HTTP/1.1: соединение по умолчанию постоянное (keep-alive), но запросы в нём идут по очереди, поэтому браузер открывает до шести соединений на хост;
• HTTP/2: одно TCP-соединение и много параллельных потоков. Слабое место: потеря пакета тормозит все потоки сразу;
• HTTP/3: работает поверх QUIC, то есть UDP. Транспорт и TLS 1.3 объединены, рукопожатие короче, потеря пакета задерживает только свой поток. Поддержку сервер объявляет заголовком Alt-Svc.

Отдельно назовите долгоживущие варианты. WebSocket начинается с HTTP-запроса с Upgrade: websocket и ответа 101 Switching Protocols, дальше идёт двусторонний канал. Server-Sent Events это обычный HTTP-ответ, который не закрывается. WebRTC связывает браузеры напрямую, в основном по UDP.

Практика фронтенда: <link rel="preconnect"> к сторонним доменам, а в DevTools вкладка Network показывает протокол (h2, h3) и разбивку Timing на DNS, Initial connection и SSL.

Где спотыкаются

Говорят «устанавливается HTTP-соединение» и на этом останавливаются. Без TCP, TLS и QUIC ответ выглядит заученным.

Считают, что соединение закрывается после каждого запроса. Так было в HTTP/1.0, сейчас соединения переиспользуются.

Уверены, что HTTPS скрывает всё, включая домен. Имя сервера обычно видно в SNI при рукопожатии, шифруются путь, заголовки и тело.