FIN-ACK数据包是从服务器发送的，但客户端在客户端发送FIN-ACK数据包之前发送HTTP请求[关闭]

Posted 2023-03-23

【中文标题】FIN-ACK数据包是从服务器发送的，但客户端在客户端发送FIN-ACK数据包之前发送HTTP请求[关闭]

【英文标题】：FIN-ACK packet is sent from the server, but client sends HTTP request before client sends FIN-ACK packet [closed]

【发布时间】：2021-03-20 19:18:51

【问题描述】：

正如预期的行为，当服务器发送 FIN-ACK 数据包时，客户端也应该发送 FIN-ACK 数据包并终止连接。但是对于我的某些情况，当服务器发送 FIN-ACK 数据包时，客户端会立即发出新的 http 请求，然后再从客户端发回 FIN-ACK。这导致连接重置数据包。这背后的原因是什么以及如何解决这个问题。

【问题讨论】：

"正如预期的行为，当服务器发送 FIN-ACK 数据包时，客户端也应该发送 FIN-ACK 数据包并终止连接。" 这根本不是真的。 FIN只是意味着FIN的发送方将不再发送数据，但它有义务保持开放接收数据，直到对方也完成发送数据。

【参考方案1】：

...当服务器发送FIN-ACK包时，客户端也应该发送FIN-ACK包...

虽然这很常见，但实际上并不是必需的。来自服务器的 FIN 仅表示服务器将不再发送任何数据 - 但它仍可能接收数据。来自客户端的类似 FIN 信号表明客户端将不再发送任何数据 - 但它也可能仍会接收数据。只有当双方都发送了一个 FIN 并得到了匹配的 ACK 时，那么很明显不会再双向发送数据，从而关闭连接。

...当服务器发送 FIN-ACK 数据包时，在客户端发回 FIN-ACK 之前，立即有新的请求来自客户端。

在 TCP 级别没有“请求”。对于某些应用程序协议，请求和响应仅在应用程序级别具有意义。不清楚这里所说的是什么应用程序协议。

这是什么原因以及如何解决这个问题。

如上所述，来自服务器的 FIN 仅表示服务器不会再发送任何数据。但它可能仍会接收数据。这里没有禁止客户端发送更多数据。这里没有要解决的问题。

【讨论】：

实际上一个http请求是在服务器的FIN-ACK之后进行的，这导致连接重置。

@ElsonD'Sa：使用 HTTP 持久连接，这种竞争条件是可能的。服务器可以在响应发送后和收到新请求之前随时关闭连接。

连接重置标志在获取请求后从服务器发送。未获得给定请求的响应。先生如何处理这个问题

@ElsonD'Sa：见RFC 7230 section 6.31 "Retrying Requests"