FIN、PSH之后的ACK、ACK

Question

我正在尝试实现遗留系统和Linux系统之间的通信，但我经常遇到以下情况之一：

(遗留系统是服务器，Linux是客户端)

Function recv(2) returns 0 (the peer has performed an orderly shutdown.)
> SYN
< SYN, ACK
> ACK
< PSH, ACK  (the data)
> FIN, ACK
< ACK
> RST
< FIN, ACK
> RST
> RST

Function connect(2) returns -1 (error)
> SYN
< RST, ACK

当服务器发送数据后，客户端应该用数据应答，但我得到的却是"FIN，ACK“为什么会这样？我该如何解释这个呢？在这个级别上，我对TCP不是很熟悉

Answer 1

当服务器发送数据时，客户端应该用数据应答，但我得到的却是"FIN，ACK“为什么会这样？我该如何解释这个呢？

可能的情况是，一旦服务器发送了数据(第4行)，客户端就会关闭套接字或提前终止，并且操作系统会关闭其套接字并发送FIN (第5行)。服务器使用ACK响应FIN，但是客户端已经不复存在，其操作系统使用RST响应。(我希望客户端操作系统在臭名昭著的TIME-WAIT状态期间会默默地忽略并丢弃任何到达关闭连接的TCP段，但由于某种原因，这种情况不会发生。)

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination

与Linux或HP-UX一样，

某些主机TCP堆栈可能实现半双工关闭序列。如果此类主机主动关闭连接，但仍未读取堆栈已从链路接收到的所有传入数据，则此主机将发送RST而不是FIN ( RFC 1122中的第4.2.2.13节)。这允许TCP应用程序在主动关闭连接时确保远程应用程序已经读取了前面发送的所有数据-等待来自远程端的FIN。但是，远程TCP堆栈无法区分中止RST的连接和此数据丢失RST。两者都会导致远程堆栈丢弃它接收到的所有数据，但应用程序仍然不读取

Answer 2

在FIN、PSH、ACK之后-->一个事务完成了第二个请求接收但发送了RST seq=140 win=0 len=0