Рукопожатие TCP и жизнь соединения

Прежде чем ваш Mac отправит хоть один байт запроса веб-страницы, он уже обменивается тремя короткими сообщениями с сервером. Именно этот обмен, тройное рукопожатие TCP, превращает обещания надёжности TCP из предыдущего урока в реальное, отслеживаемое соединение между двумя машинами.

Три сообщения до первого слова

RFC 9293, действующая спецификация TCP, описывает этот процесс как синхронизированный обмен: «синхронизация требует, чтобы каждая сторона отправила свой собственный начальный номер последовательности и получила его подтверждение от удалённого узла TCP» (the synchronization requires each side to send its own initial sequence number and to receive a confirmation of it in acknowledgment from the remote TCP peer).

1. SYN. Устройство, открывающее соединение, отправляет сегмент с установленным флагом SYN, несущий начальный номер последовательности.
2. SYN-ACK. Другая сторона отвечает собственным SYN плюс подтверждением первого номера.
3. ACK. Первое устройство подтверждает этот ответ. RFC 9293 отмечает, что «поскольку шаги 2 и 3 можно объединить в одно сообщение, это называется тройным (или трёхсообщенческим) рукопожатием» (because steps 2 and 3 can be combined in a single message this is called the three-way (or three message) handshake). После его завершения обе стороны считают соединение установленным (ESTABLISHED) и начинают отправлять реальные данные.

Учебный центр Cloudflare даёт то же самое простыми словами, используя электронное письмо как пример: «сначала источник отправляет целевому серверу пакет SYN — „начальный запрос“, — чтобы начать диалог. Затем целевой сервер отправляет пакет SYN-ACK, соглашаясь на процесс. Наконец, источник отправляет целевому серверу пакет ACK, подтверждая процесс, после чего можно отправлять содержимое сообщения» (first, the source sends an SYN "initial request" packet to the target server in order to start the dialogue. Then the target server sends a SYN-ACK packet to agree to the process. Lastly, the source sends an ACK packet to the target to confirm the process, after which the message contents can be sent).

Аккуратное завершение соединения

Закрытие происходит более обдуманно, чем открытие. RFC 9293 объясняет, что «обычная последовательность закрытия TCP надёжно доставляет буферизованные данные в обоих направлениях» (the normal TCP close sequence delivers buffered data reliably in both directions), прежде чем соединение завершится: каждая сторона отправляет сегмент FIN, как только у неё больше нет данных для отправки, другая сторона его подтверждает, и только когда завершены оба направления, соединение полностью закрывается. Далее следует короткий период ожидания (TIME-WAIT), чтобы случайный запоздалый пакет из старого соединения нельзя было принять за часть нового.

Что видит файрвол посередине

Файрволу с отслеживанием состояния (stateful) — а таким оснащено большинство роутеров и сама macOS — не нужно проверять каждый пакет, чтобы принять решение. Объяснение Cloudflare описывает это так: он «сохраняет информацию об открытых соединениях и использует эту информацию для анализа входящего и исходящего трафика, вместо того чтобы проверять каждый пакет» (saves information regarding open connections and uses this information to analyze incoming and outgoing traffic, rather than inspecting each packet). На практике это означает, что он следит за SYN, открывающим соединение, запоминает, что это приложение ждёт ответа, а затем незаметно пропускает соответствующий SYN-ACK обратно; ответ, не соответствующий ни одному исходящему SYN, отбрасывается. Именно так файрвол отличает обычный ответ от незапрошенной попытки подключения, возникшей ниоткуда, — на этом строится блокировка нежелательного входящего трафика.

Ничего из этого обмена сам TCP не шифрует: SYN, SYN-ACK и ACK видны в открытом виде всему, что наблюдает за сетевым путём, включая ваш Wi-Fi роутер. То, что скрыто, а что нет, зависит от уровня над TCP, например TLS для HTTPS-сайта, — это отдельно рассматривается в курсе «Как устроен интернет».