据我所知，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/
（注：138.96.116.9和138.96.201.72之间的tcp连接存在一些序列号不一致的问题，这里就不讨论这个不一致的问题了，这是另外一个话题）
但是，从上图可以看出，在第 1013 个数据包中，138.96.201.72 发送了一个 FIN/ACK 数据包，其 ack_seq 为 2086，比第 1011 个数据包的序列号（1）要早。理论上，FIN/ACK 未通过有效性检查，因此不应被 tcp 堆栈接受/处理。但是主机 138.96.116.9 发回了一个 tcp ACK（第 1014 个数据包）。为什么？
另外，虽然第 1014 个 ACK 包的 seq 号是错误的（实际是 2，但应为 2086），但它的 ack_seq 号是正确的，没有通过有效性检查。而且根据独立处理原则，它正确确认了第 1013 个 FIN/ACK 包。为什么 138.96.201.72 还要重发 FIN/ACK？