насколько мне известно, seq и ack_seq обрабатываются стеком tcp независимо.
когда пакет приходит с несовместимым номером ack_seq
если: 1) число ack_seq устарело (меньше ожидаемого), например, дублированный ACK, этот пакет не проходит проверку достоверности, поэтому, если у него есть поле данных и номер seq верен, данные все еще принимаются из-за независимости обработки seq и ack_seq.
2) если номер ack_seq опережает (больше, чем ожидалось), то он не проходит проверку достоверности, этот пакет не будет доставлен в стек tcp. Таким образом, даже если обработка между seq и ack_seq независима, перед обработкой возникает проблема с недействительностью. И пакет не будет обрабатываться стеком TCP.
http://postimg.org/image/82cyf2cw9/
(Примечание: существует некоторое несоответствие порядкового номера в соединении tcp между 138.96.116.9 и 138.96.201.72, я не буду говорить о проблеме несовместимости, это другая тема)
Однако из приведенного выше графика в 1013-м пакете 138.96.201.72 отправляет пакет FIN/ACK, он имеет ack_seq 2086, который находится перед порядковым номером (1) 1011-го пакета. Теоретически, FIN/ACK не проходит проверку достоверности и не должен приниматься / обрабатываться стеком tcp. Но хост 138.96.116.9 отправляет обратно ACK tcp (1014-й пакет). Зачем?
И, кроме того, хотя 1014-й ACK-пакет имеет неправильный номер seq (который равен 2, но ожидается, что он будет 2086), он имеет правильный номер ack_seq и не проходит проверку достоверности. И в соответствии с принципом независимой обработки он правильно подтвердил 1013-й пакет FIN/ACK. Почему 138.96.201.72 все еще ретранслируют FIN/ACK?