当 FIN 为 recv 而套接字发送缓冲区中仍有数据时，系统会做什么？答案

【问题标题】：What would the system do when FIN is recv while there's still data in socket send buffer?当 FIN 为 recv 而套接字发送缓冲区中仍有数据时，系统会做什么？
【发布时间】：2016-08-22 22:27:37
【问题描述】：

目前我遇到了一个奇怪的问题。

所以我想知道会发生什么。

假设有一个 TCP 连接，socket 发送缓冲区有 10 个字节的数据，那么一个 FIN 是 recv，哪个数据包会被回复？

A.一个 10 字节数据的 ACK

B.一个没有字节的 ACK 和一个 10 字节的 ACK

C.以上任一

【问题讨论】：

找出问题的一个好方法是在有问题的确切系统上运行tcpdump 并观察它的作用。您可以通过积极发送并让对方缓慢接收然后关闭连接来强制出现这种情况。
不要对非代码文本使用代码格式。

标签： linux sockets tcp

【解决方案1】：

FIN 仅表示对方不再发送数据。这并不意味着它不会接受更多数据，因此本地系统不会关闭连接。这意味着对 FIN 的 ACK 将反映连接的当前状态：如果可以发送数据（取决于窗口），本地系统通常会（*）发送一个包含数据的数据包和 FIN 的 ACK。如果数据不能立即发送，它只会 ACK FIN 并可能稍后发送数据。

(*) 请注意，理论上它可以分两个数据包发送，但 TCP 堆栈通常会尽可能将数据和 ACK 结合起来，以便发送更少的数据包。

【讨论】：

【解决方案2】：

目前我遇到了一个奇怪的问题。

我建议你应该发布实际的奇怪问题，而不是你的猜测。

A.一个 10 字节数据的 ACK

什么 10 字节的数据？为什么 ACK 会回显 10 个字节的接收数据？

B.一个没有字节的 ACK 和一个 10 字节的 ACK

这也没有意义。

C.以上任一

这个也不行。

当收到一个 FIN 时，它应该通过一个 ACK 数据包来确认。由于 FIN 终止该方向的连接，因此套接字接收缓冲区中当前的数据量无关紧要。

【讨论】：

10字节数据在recv FIN的机器的socket的发送缓冲区中。