FIN,ACK 在 PSH,ACK 之后答案

【问题标题】：FIN,ACK after PSH,ACKFIN,ACK 在 PSH,ACK 之后
【发布时间】：2012-11-07 13:33:35
【问题描述】：

我正在尝试实现旧系统和 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 不是很熟悉

【问题讨论】：

您需要查看您的客户端代码。
FIN 可以搭载在数据上。

标签： sockets networking tcp tcpdump tcp-ip

【解决方案1】：

当服务器发送数据后，客户端应该回复数据，但我却得到一个“FIN, ACK” 为什么会这样？我该如何解释？

可能是一旦服务器发送了数据（第 4 行），客户端关闭套接字或提前终止，操作系统关闭其套接字并发送FIN（第 5 行）。服务器以ACK 回复FIN，但客户端已不复存在，其操作系统以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。两者都会导致远程堆栈丢弃它收到的所有数据，但应用程序仍然没有读取

【讨论】：

【解决方案2】：

经过FIN、PSH、ACK --> 一笔交易完成第二个请求接收但发送 [RST] seq=140 win=0 len=0

【讨论】：