当服务器发送 PSH、FIN、ACK 时 HTTP 客户端不启动 TCP FIN/ACK答案

【问题标题】：HTTP Client not initiate TCP FIN/ACK when Server sends PSH,FIN,ACK当服务器发送 PSH、FIN、ACK 时 HTTP 客户端不启动 TCP FIN/ACK
【发布时间】：2019-06-09 02:19:50
【问题描述】：

我在 UBoot 上实现了自己的 TCP 协议栈和一个非常简单的 HTTP 服务器，我遇到了客户端在发送 FIN/ACK/PSH 后不发送 FIN/ACK 的问题。关于 TCP 序列和 Ack 以及内容长度，HTTP 和 TCP 内容似乎都是正确的，但客户端仅在第一次尝试任何 URL 时以 FIN 响应。对访问 URL 的任何后续尝试都不会以 FIN 响应。谁能告诉我我的 TCP 或 HTTP 内容中缺少什么导致客户端无法关闭连接？

我提供了一个截图，以防有人对此问题感兴趣 Link to packet capture

预期的结果应该是客户端显示 HTTP 404 Not found 的内容。但是，我所看到的只是浏览器是否一直在不停地加载，直到客户端发送 TCP RST，并且无法找到浏览器显示页面。

【问题讨论】：

您的 pcap 充满了不相关的数据包，并且不清楚 pcap 的哪个部分与您的问题相关。请将您的 pcap 减少到基本部分，并在您的问题中清楚地描述 pcap 的哪些部分（即基于tcp.stream 的数量或所涉及的端口号的 TCP 流）与您看到的行为的哪一部分相关。跨度>
对不起，我的错。对于过滤器，只需过滤 IP 地址 192.168.99.9 和 TCP。主要是对 /ncsi.txt 的请求。请让我再上传一张，很抱歉造成混乱。
请让我评论另一件事。我使用 chrome 的 Developer Analyzer，发现浏览器本身实际上并没有收到响应。所以很可能问题仍然在于 TCP 会话。 tcp.stream 0 是第一个也是唯一一个从客户端成功接收 FIN/ACK 的。后面的就不行了。此行为也可以应用于其他 URI。

标签： http tcp

【解决方案1】：

在问题的流中（如 pcap 中的tcp.stream eq 1）来自服务器的 404 没有得到客户端的确认，这可能意味着它被丢弃在某个地方。在没有问题的流 (tcp.stream eq 0) 中，404 得到确认。仔细观察这两个 404 会发现，好的那一个具有有效的 TCP 校验和，而丢弃的那一个则没有。因此，很可能您的 TCP 校验和计算是错误的，并且客户端系统正在丢弃这些错误的数据包，因此它们永远不会到达客户端应用程序。

【讨论】：

感谢您的评论。请问您是否使用 Wireshark TCP 验证器验证 TCP 校验和？
@TommyLin：正确，我在 Wireshark 中启用了 TCP 校验和验证。来自客户端的数据都具有错误的校验和，这可能是因为您已在客户端捕获并且您正在进行 TCP 校验和卸载，即捕获完成后在网卡上计算 TCP 校验和。但是来自服务器的 TCP 校验和应该都是正确的，但有些是正确的，有些不是 - 那些没有在客户端被丢弃的。
谢谢，这个问题是由关于 malloc() 的一个非常奇怪的问题引起的。当我调用 malloc() 时，缓冲区包含来自前一个 malloc() 的前一个数据包（包括校验和），这将导致计算不正确。但是，在手动设置 TCP 标头的内容后，该操作可以正常工作。非常感谢。
@TommyLin：这是 malloc 的预期（并且有据可查）行为，即它不初始化内存，这意味着内存可能包含以前的数据。如果您想初始化内存，请改用 calloc。