在PSH之后的FIN，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行）。服务器用FIN回复ACK，但客户端已经不复存在，其操作系统用RST响应。 （我希望客户端操作系统在臭名昭着的TIME-WAIT状态下默默地忽略并丢弃任何到达关闭连接的TCP段，但这不会因某种原因发生。）

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

某些主机TCP堆栈可能实现半双工关闭序列，如Linux或HP-UX。如果这样的主机主动关闭连接但仍未读取堆栈已从链路接收的所有传入数据，则该主机发送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