como a pilha tcp lida com o número ack_seq e o número seq do pacote tcp FIN / ACK?

Question

pelo meu conhecimento, seq e ack_seq são processados pela pilha tcp independentemente.

quando um pacote chega com um número inconsistente de ack_seq

se: 1) o número ack_seq for obsoleto (menor que o esperado), por exemplo, um ACK dup, este pacote não falhará na verificação de validade, então se ele tiver campo de dados e o número seq estiver correto, os dados ainda é aceito devido à independência do processamento seq e ack_seq.

2) se o número ack_seq estiver adiantado (maior que o esperado), então ele falhará na verificação de validade, este pacote não será entregue na pilha tcp. Portanto, mesmo que o processamento entre seq e ack_seq seja independente, há um problema de invalidade antes do processamento. E o pacote não será processado pela pilha TCP.

link

(Nota: existem algumas inconsistências no número de seqüência na conexão tcp entre 138.96.116.9 e 138.96.201.72, não vou falar sobre o problema de inconsistência, é outro tópico)

No entanto, do gráfico acima, no pacote 1013-th, 138.96.201.72 envia um pacote FIN / ACK, ele tem um ack_seq 2086 que está à frente do número de seqüência (1) do pacote 1011-th. Em teoria, o FIN / ACK falha na verificação de validade e não deve ser aceito / processado pela pilha tcp. Mas o host 138.96.116.9 envia de volta um tcp ACK (o pacote 1014-th). Por quê?

E, além disso, embora o pacote ACK 1014-th possua um número de seq errado (que é 2, mas espera-se que seja 2086), ele tem um número ack_seq correto e não falha na verificação de validade. E de acordo com o princípio do processamento independente, ele reconheceu o pacote FIN / ACK 1013-th corretamente. Por que 138.96.201.72 ainda retransmite o FIN / ACK?