服务器发送FIN、ACK的时间过长

Question

我有一个移动应用程序（捕获为 186.18.33.118）从 php api (200.80.41.246) 的一些简单 http 服务器请求数据。

当我从我的应用程序发送请求时，我一分钟内无法从发送请求的同一局域网访问 Web 服务器。

服务器是 Centos 7 apache 和所有更新。

我使用 tcpdump 分析服务器和我的应用程序之间的数据包（下面显示了当我从应用程序请求服务器以及从我的浏览器请求服务器以使用 wireshark 打开之后的捕获）。

我能看到的奇怪的是服务器发送FIN数据包ACK的时间太长了

有什么问题？

编辑/添加

Capture with tcpdump

（我如何进行捕获的步骤）

1. 我在手机里打开了这个应用（这个应用会咨询安装在服务器200.80.41.246上的wordpress）

2. 几秒钟后，我尝试从浏览器（从与手机连接的同一个局域网）进入 wordpress

3. 服务器给我一条消息说：错误超时（靠近数据包45）

4. 所以我尝试了很多次，大约一分钟后连接正常（靠近数据包 110）

编辑 2

我对比了浏览器和app对api的查询，因为当我从浏览器发出请求的时候并没有带来问题，我发现不同的是浏览器发送了一个RST包应用程序不发送。 下面我留个图，上面是浏览器的查询，下面是app的查询。

analyzed capture by wireshark

有什么建议吗？

Answer 1

在分析 Linux 中的连接配置时，我发现了两个允许重用以前关闭的连接的参数，它们是启用的。当我想从具有相同公共 IP 的另一台设备访问时，该设备在打开的连接发生冲突并且会有新的连接之前，禁用并现在可以正常工作。

参数为：
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_reuse
他们是 1（启用）

禁用执行命令
sysctl net.ipv4.tcp_tw_recycle = 0
sysctl net.ipv4.tcp_tw_reuse = 0

Answer 2

这里你需要知道两件事： 1. TCP 状态机用于连接关闭。 2. 与连接关闭相关的 TCP 定时器。

总共有 7 个 TCP 计时器，其中“最大段生命周期”和“重传”计时器将在连接关闭的上下文中发挥作用。

现在关于 TCP 状态：客户端可以发起连接关闭，或者服务器也可以这样做。

"服务器向客户端发送一个设置了"FIN"位的数据包，此时服务器处于FIN_WAIT_1状态。客户端得到FIN数据包并进入CLOSE_WAIT状态，并向客户端发送一个确认包服务端，当服务端收到这个包后，进入FIN_WAIT_2状态。从服务端的角度来看，连接已经关闭，服务端不能再发送数据了。但是，在TCP协议下，客户端需要关闭也可以通过发送一个 FIN 数据包，服务器 TCP 实现应该 ACK。服务器应该在最大段生命周期 (MSL) 定义的一段时间后关闭。"

在任何时候，如果发送者没有收到确认，它将触发重传。

你应该在你的具体情况下寻找：

1 是 MSL 在您提到的延迟中发挥作用。 2 有重传吗？是否有任何虚假的重传？

Answer 3

如果您共享 tcpdump，将会很有帮助。通常一个 FIN 数据包会在特定的超时值之后发送，这取决于操作系统。

在 Linux I 上，默认值为 60 秒。 看这里：TCP parameters, Linux kernel

编辑：

我查看了捕获，有几件事：

1. 当服务器没有使用 [SYN,ACK] 数据包响应 SYN 请求时，会发生 TCP 重新传输。它尝试向服务器打开许多会话，但服务器没有响应（约 20 个会话）。 TCP 重传是 TCP 协议的一部分，它在 3、6、12、24 等（取决于 TCP 堆栈实现）之后发送重传，当它没有收到答案时，这是正常行为。

2. 下一次服务器应答是在约 48 秒后（从第一个没有应答的 SYN 开始）。我的猜测是服务器不会关闭会话并且在此期间不接受其他会话。