Почему я вижу пакет RST, ACK вместо пакета RST?

Заглядывая в Wireshark, я часто вижу, что потоки TCP заканчиваются пакетом RST, ACK вместо пакета RST. Кто-нибудь знает, почему это?

Пример того, что я вижу:

SYN SYN, ACK ... данные ... RST, ACK

Wireshark не принимает пакет RST до пакета RST, ACK.

wireshark

— packetwrassler
источник

Как вы думаете, почему перед RST / ACK должен быть сегмент RST? Может быть, вы могли бы привести пример такой трассировки пакетов?

— Гербен

ACK совмещал RST в том же пакете?

— generalnetworkerror

Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.

— Рон Мопин

Я ACK и отправил запрос \ данные об окончании соединения. Завершить соединение = RST

— motoko

Ответы:

RST / ACK не является подтверждением RST, так же как SYN / ACK не является точно подтверждением SYN. Установление TCP на самом деле является четырехсторонним процессом: инициирующий хост отправляет SYN принимающему хосту, который отправляет ACK для этого SYN. Принимающий хост отправляет SYN инициирующему хосту, который отправляет ACK обратно. Это устанавливает состояние связи.

SYN --> 
    <-- ACK
    <-- SYN
ACK -->

Чтобы сделать это более эффективным, принимающий хост может ACK SYN и отправить свой собственный SYN в том же пакете, создавая трехсторонний процесс, который мы привыкли видеть.

SYN -->
    <-- SYN/ACK
ACK -->

В случае RST / ACK устройство подтверждает, что все данные были отправлены в предыдущем пакете (ах) в последовательности с ACK, и затем уведомляет отправителя о том, что соединение закрыто с RST. Устройство просто объединяет два пакета в один, как SYN / ACK. RST / ACK обычно не является нормальным ответом при закрытии сеанса TCP, но он также не обязательно указывает на проблему.

— Сантино
источник

Примером сценария отправки RST / ACK является случай, когда принимающий хост не прослушивает TCP-порт назначения.

— Индика К

Да, в самом деле. Однажды я попытался смоделировать DDoS-атаку (для образовательных целей;)) с компьютера A на компьютер B на порту 80. Но порт 80 B не открыт. Итак, я вижу, как машина B посылает много RST ACKответов на фальшивый адрес источника.

— Smwikipedia

Может ли ответ RST / ACK зависеть от содержимого пакета? Т.е. сервер получает пакет, и поскольку содержимое пакета соответствует некоторому условию, сеанс был закрыт.

— skooog

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

после TCP рукопожатия

A ---> B Syn = x, Ack = y, len = z, ACK Flag

B ---> A Syn = y, Ack = x + z, len = o, ACK Flag

A ---> B Syn = x + z, Ack = y + o, len = p, ACK Flag

B ---> A Syn = y + o, ACK = x + z + p, len = q, RST, ACK Flag

B закрывает сокет после отправки последнего пакета, а A закрывает сокет после его получения.

(без учета окна TCP здесь, или может быть больше пакетов от одного конца до подтверждения)

Флаг ACK, номер подтверждения и процедура подтверждения связаны, но не одно и то же.

Согласно RFC793

RFC793

Номер подтверждения: 32 бита

If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive.  Once a connection is established this is always sent.

Сбросить Обработка

Во всех состояниях, кроме SYN-SENT, все сегменты сброса (RST) проверяются путем проверки их полей SEQ. Сброс действителен, если его порядковый номер находится в окне. В состоянии SYN-SENT (RST, полученный в ответ на начальный SYN), RST является приемлемым, если поле ACK подтверждает SYN.

Получатель RST сначала проверяет его, а затем изменяет состояние. Если получатель находился в состоянии LISTEN, он игнорирует его. Если получатель находился в состоянии SYN-RECEIVED и ранее находился в состоянии LISTEN, то получатель возвращается в состояние LISTEN, в противном случае получатель прерывает соединение и переходит в состояние ЗАКРЫТО. Если получатель находился в каком-либо другом состоянии, он прерывает соединение, сообщает пользователю и переходит в состояние ЗАКРЫТО.

— sdaffa23fdsf
источник