0

我正在尝试实现遗留系统和 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 不太熟悉

4

2 回答 2

1

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

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

于 2012-11-07T13:43:49.370 回答
0

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

于 2017-12-19T04:38:06.543 回答