Кратко

  • Поле номера подтверждения постоянно присутствует в заголовке, но значимо только при установленном ACK.
  • Число обозначает следующий ожидаемый номер и накопительно подтверждает все предыдущие позиции.
  • Трёхстороннее рукопожатие показывает переход: начальный SYN не подтверждает, а SYN,ACK делает число значимым.

Наличие поля ещё не означает сообщения

RFC 793 и RFC 9293 сохраняют фиксированный заголовок TCP. Одни и те же 32 бита выделены в начальном SYN, сегменте данных и обмене при закрытии. Однако спецификации не требуют читать их безусловно. Если установлен ACK, поле содержит следующий номер последовательности, который отправитель ожидает получить. RFC 9293 прямо определяет ACK как признак значимости поля подтверждения.

Поэтому сторона, начинающая соединение, может объявить собственный начальный номер, не изображая, будто уже получила номер другой стороны. При сброшенном ACK поле остаётся в заголовке физически, но не является подтверждением. Формат один, а смысл зависит от состояния соединения.

Рукопожатие делает смену смысла наблюдаемой

В базовом примере RFC 9293 первый сегмент содержит SEQ=100 и SYN без ACK. Ответ содержит SEQ=300, ACK=101 и SYN,ACK. Завершающий сегмент содержит SEQ=101, ACK=301 и ACK. Поскольку SYN занимает одну позицию пространства последовательности, подтверждение 100 означает ожидание 101.

Так один и тот же заголовок пересекает смысловую границу. В первом сегменте номер незначим; в ответе ACK превращает его в свидетельство состояния другой стороны. После установления соединения подтверждение в этом состоянии посылается всегда.

Кумулятивная граница, а не подтверждение обработки приложением

Номер обозначает следующую ожидаемую позицию и тем самым накопительно подтверждает предыдущие непрерывные позиции. Это не перечень полученных сегментов, не аутентификация партнёра и не доказательство того, что приложение обработало данные. Поле Window сообщает, сколько октетов данных, начиная с указанной позиции, отправитель готов принять. Эти сведения связаны, но переключателем значимости остаётся ACK.

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

Преемственность от 1981 года

RFC 793 и действующий стандарт RFC 9293 сохраняют одну конструкцию: постоянное 32-битное поле, смысл которого зависит от ACK, накопительное подтверждение и отсутствие номера последовательности у ACK. Это вывод о структуре протокола, а не утверждение о современных реализациях.

Источники