【问题标题】:Linux application doesn't ACK the FIN packet and retransmission occursLinux 应用程序不确认 FIN 数据包并发生重传
【发布时间】:2013-12-05 16:49:24
【问题描述】:

我有一个在 linux(内核 3.0.35)上运行的服务器和一个在 Windows 7 上运行的客户端。每次客户端连接到服务器时,都会发生 TCP 重新传输: 这是来自wireshark的流量: http://oi39.tinypic.com/ngsnyb.jpg

我认为发生的事情是这样的:

客户端(192.168.1.100)连接到服务器(192.168.1.103),连接成功。在某些时候,客户端决定关闭连接(FIN,ACK),服务器不确认 FIN。 然后客户端开始一个新的连接,这个连接是ACK,并且是成功的。同时Windows内核继续重传FIN,ACK包,最终决定进行reset。

在建立第二个连接的那一刻,我没有收到客户端在服务器端发送的数据(长度为 16 字节的数据包),我仅在 RST 数据包之后收到这些字节。

在服务器端,我使用 poll() 函数检查 POLLIN 事件,在 RST 数据包到达之前,我不会收到任何数据通知。

那么有谁知道为什么会出现这种情况?

【问题讨论】:

  • 所以...结果是服务器堆栈没有以符合 TCP 的方式处理来自客户端的关闭请求?
  • 问题是在我的服务器应用程序中,直到收到RST数据包,我才收到客户端发送的16个字节,这是一个很长的时间。

标签: linux windows sockets networking tcp


【解决方案1】:

您的数据字节不是在那个 52687 连接上发送的,而是在下面的 52690 连接上发送的。我猜服务器应用程序一次只接受一个连接(内核会提前接受它们并只保存数据),因此在第一个连接断开之前看不到来自第二个连接的数据并且它继续下一个。

这并不能解释为什么您的 FIN 没有被确认。这应该。也许内核中有一些东西不喜欢打开然后关闭无数据连接?也许某种攻击缓解?防火墙规则?

【讨论】:

  • 感谢您引导我走上正确的道路,实际上是防火墙导致 FIN 未被确认。我禁用了防火墙,连接没有问题。
猜你喜欢
  • 2015-09-24
  • 2019-07-23
  • 2016-01-08
  • 2023-04-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-04-19
  • 2013-01-04
相关资源
最近更新 更多