RST TCP: разрыв соединения не сообщает результат бизнес-операции
Фотография конкретного исполнения не приложена.
Клиент может получить разрыв после отправки команды и остаться без ответа. Из этого нельзя однозначно заключить, что команда не выполнилась. Сервер мог изменить состояние до потери возможности вернуть результат, поэтому автоматический повтор иногда создаёт вторую операцию.
RFC 9293 требует различать нормальное закрытие и abort. FIN и reset имеют разный смысл для жизненного цикла транспорта. При этом даже транспортный ACK подтверждает получение диапазона TCP, а не сохранение документа, выдачу устройства или фиксацию транзакции приложением.
Сам факт RST также не определяет виновную программу или участок сети. Для такого вывода нужны контекст соединения, место наблюдения и журналы сторон. Отметка reset в одном захвате не является достаточным доказательством, что именно удалённое бизнес-приложение сознательно отклонило запрос.
В приёмке отдельно обрабатывают штатный конец ответа, аварийный разрыв и неизвестный результат операции. Для изменяющих запросов предусматривают идентификатор, проверку состояния или другую согласованную защиту повторов. Отчёт должен связывать ошибку транспорта с доступными прикладными доказательствами. Это позволяет восстанавливать работу без необоснованного предположения, что отсутствие ответа равно отсутствию выполненного действия.
Основание — Numbered IETF TCP references with RFC7413 explicitly Experimental; selected mechanisms and algorithms only, разделы RFC9293 3.6 Closing a Connection; Reset Processing; application close distinction. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC TCP. Дополнения и алгоритмы не считаются включёнными автоматически; RFC 7413 о Fast Open имеет статус Experimental. Реальный TCP stack, socket options, трасса и настройки системы не проверялись; соединения и сетевые испытания не выполнялись.