Кратко

  • При одновременном открытии оба узла выполняют активный OPEN для одной пары сокетов. Чистые SYN пересекаются, обе стороны переходят в SYN-RECEIVED, а встречные SYN-ACK создают одно соединение, а не два.
  • Сначала назначать клиента не требуется. Каждый узел локально проверяет актуальный начальный номер партнёра и получает подтверждение собственного номера.
  • NAT часто знали только шаблон «исходящий SYN — входящий SYN-ACK». RFC 5382 пришлось потребовать, чтобы разрешённое соединение сохраняло и допустимый входящий SYN одновременного пути.

Три стрелки незаметно превратились в иерархию

SYN, SYN-ACK, ACK — верная схема обычного случая. Но RFC 793 прямо говорил: если два процесса одновременно выполняют активные открытия друг к другу, они будут правильно соединены. Такая гибкость была важна для распределённых компонентов, действующих асинхронно.

Клиент и сервер — полезные роли приложений, но не источники действительности TCP. Соединение определяют пара сокетов и синхронизация двух пространств последовательности.

Одновременное открытие не было поздней защитой от редкой коллизии. Оно входило в исходную машину состояний. Популярная картинка показывала один маршрут, а будущие посредники приняли его за всю грамматику.

Два SYN сошлись в одном состоянии

A выбирает начальный номер 100, B — 300. Оба отправляют SYN и входят в SYN-SENT. Получив чистый SYN B, узел A не отбрасывает его из-за собственной попытки. Он запоминает 300, переходит в SYN-RECEIVED и отправляет SYN-ACK с подтверждением 301. B зеркально подтверждает 101.

После прихода встречных SYN-ACK каждая сторона знает начало удалённой последовательности и знает, что её собственное начало принято. RFC 9293 сохраняет исправленную трассу: у обоих CLOSED → SYN-SENT → SYN-RECEIVED → ESTABLISHED.

Внешний порядок пакетов иной, но логическое доказательство то же. Оба начала должны быть объявлены, получены и подтверждены.

Прибавление единицы было доказательством

SYN занимает одну позицию пространства последовательности. Поэтому SYN с номером 300 подтверждается числом 301. ACK говорит не просто «пакет замечен», а удостоверяет, что приёмник перешёл за конкретный нумерованный управляющий элемент. Пустой ACK сам позиции не занимает, иначе пришлось бы бесконечно подтверждать подтверждения.

Пространства отправки не сливаются. Симметрия инициативы не означает общую нумерацию. RFC 6528 позднее усилил выбор ISN секретной псевдослучайной функцией от четырёхкомпонентного идентификатора соединения.

Таким образом, центральный арбитр не нужен. Идентичность пары, удалённый номер и подтверждение собственного номера проверяются каждым концом самостоятельно.

Два локальных вызова не создавали два соединения

Два активных вызова естественно принять за два сетевых объекта. RFC 1122 специально предупреждал об этой ошибке: одновременные попытки дают одно соединение, и это намеренное решение не следует «исправлять».

Для A локальный сокет A связан с удалённым сокетом B; B видит ту же пару в обратном порядке. Дублирование не добавило бы реальности, а создало бы лишний спор о том, какой двойник переносит данные.

Количество локальных процедур не равно количеству общих фактов. Два запроса сходятся в одной синхронизированной ассоциации.

Одинаковому состоянию требовалась память о пути

В SYN-RECEIVED можно попасть после пассивного OPEN или после получения SYN вслед за собственным активным OPEN. RFC 1122 и RFC 9293 требуют хранить происхождение состояния: обработка RST и возможный возврат в LISTEN зависят от него.

RFC 793 также предупреждал, что старый дубликат SYN способен выглядеть как новое одновременное открытие. TCP не запрещает законный путь ради простоты. Текущие ожидания последовательности, подтверждения и проверка RST отделяют новое воплощение соединения от старого мусора.

Название состояния — ещё не всё состояние. Если стереть причинную историю, восстанавливаться придётся без необходимого доказательства.

NAT выучил только самый частый сюжет

При обычном клиент-серверном соединении исходящий SYN создаёт отображение, после чего приходит SYN-ACK. При одновременном открытии приходит ещё один SYN. RFC 5382 описал NAT, блокировавшие его как незапрошенный, и устройства, неверно переводившие последующий исходящий SYN-ACK.

Конечные узлы соблюдали TCP, а посредник превращал частый шаблон в закон. Это не то же самое, что явная политика запрета соединения.

Если политика разрешила связь, отслеживание должно понимать все допустимые переходы. Поэтому RFC 5382 требует обрабатывать для разрешённых соединений все корректные последовательности TCP, включая одновременное открытие. Право отказать остаётся; скрыто сужать протокол нельзя.

Шесть секунд оценили стоимость незнания

Удалённый SYN может прийти в NAT раньше локального SYN, который создаст отображение. В этот момент пакет действительно выглядит незапрошенным. Немедленный RST или ICMP быстро сообщает ошибку, но завершает и законную встречу, если локальный SYN просто задержался.

RFC 5382 устанавливает паузу не менее шести секунд. Если появляется соответствующий исходящий SYN, ранний пакет молча отбрасывается, а повторная передача проходит через готовое отображение. Если соответствия нет, ошибка возможна согласно политике безопасности.

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

Одноранговые приложения вернули старой симметрии пользу

Когда оба узла находятся за трансляторами, ни один не всегда доступен как пассивный сервер. Зато оба могут создать исходящее состояние к заранее обменянным адресу и порту. При подходящих отображениях и времени SYN встречаются на подготовленных путях.

RFC 6544 определил S-O-кандидаты ICE TCP наряду с активными и пассивными. Он же рекомендует несколько типов кандидатов и реле: ОС, NAT и сети поддерживают возможности неодинаково.

Допустимость в TCP не означает доступность повсюду. Одновременное открытие даёт механизм конечным узлам; вся трасса решает, останется ли он практически применимым.

Выжила симметрия, основанная на доказательствах

Общий слой мал: определить пару сокетов, обменяться двумя свежими началами, подтвердить оба и сохранить нужную историю. Выше приложения выбирают активный, пассивный, одновременный или релейный путь.

Проблемой NAT была не чрезмерная свобода краёв, а превращение большинства в скрытую обязанность. RFC 5382 снова разделил решения: посредник вправе выбирать, что разрешить, но обязан верно читать разрешённый TCP.

Когда оба конца позвонили, TCP не назначил победителя. Он заставил каждого доказать отправку и приём. Одно соединение возникло из проверяемого общего состояния, а не из заранее выданных ролей.

Источники и границы доказательств

Основа: RFC 793, RFC 1122, RFC 5382, RFC 6528, RFC 6544 и RFC 9293. Они не дают сегодняшней доли использования, полного обзора API или всех NAT. Потери и повторные передачи меняют наблюдаемую трассу без изменения логики.