TCP服务器未收到客户端ACK就响应FIN,ACK是否符合协议规范？

你描述的服务器行为完全符合TCP协议规范，不存在合规性问题，是非常常见的实现方式，具体原因如下：

• TCP的FIN报文仅代表发送方不再向对端发送新的数据，不会中断接收方向本方传输数据的通道，也不会影响TCP栈对已发送数据的可靠传输保障。你担心的“未等数据确认就断开”的逻辑误解了FIN的作用：FIN只是关闭单方向的发送流，属于TCP半关闭设计的标准用法，此时客户端完全可以正常回传之前所有数据的ACK报文，服务器的TCP栈也会正常处理这些ACK。
• 这类实现大量存在于短连接文件传输场景中，比如HTTP/1.0的非keepalive连接，服务器返回完完整的响应数据后，上层应用会直接调用close关闭连接，触发内核发送FIN报文，不需要等待应用层的接收确认，也不需要等待传输层的所有ACK返回。
• 即使服务器已经发送了FIN报文，内核的TCP栈依然会负责保障已发送数据的可靠性：如果后续发现有数据丢包、未收到客户端的ACK，TCP栈会自动触发重传逻辑，直到所有已发送的数据都被客户端确认，或者达到超时阈值才会彻底清理连接资源，不会出现文件数据传输不完整的问题。

补充说明：只有当服务器开启了SO_LINGER套接字选项且将超时时间设置为0时，调用close才会直接发送RST报文强制断开连接，丢弃未发送或未确认的缓冲区数据，这种场景才属于不符合预期的行为，但你抓包看到的是FIN,ACK报文，因此不属于该异常场景。

内容的提问来源于stack exchange，提问作者Martí Coll Risco