TCP/IP RST 在不同浏览器中的发送方式不同答案

【问题标题】：TCP/IP RST being sent differently in different browsersTCP/IP RST 在不同浏览器中的发送方式不同
【发布时间】：2011-01-29 08:48:31
【问题描述】：

在 Mac OS X (10.6) 上，如果我开始下载 YouTube 视频并将以太网电缆拉 5 秒左右，然后重新插入，我会根据浏览器获得不同的结果。使用 Opera 和 Chrome，在我将电缆重新插入后，视频会继续加载。但是对于 Safari 和 Firefox，它永远不会。

使用 Wireshark 查看流量，我发现 Opera 和 Chrome 只是在重新插入电缆后 ACK 来自 YouTube 的第一个数据包，但是 Safari 和 Firefox 在 TCP 标头中设置了 RST 标志（0x4）并且没有更多流量随之而来。

我可以在机器和互联网连接之间放置一个集线器，问题消失了，当电缆重新插入集线器时，所有四个浏览器都继续加载视频。同样，查看 Wireshark 日志，很明显机器没有看到 Mulitcast 连接关闭，只是数据包流过时有延迟。

因此，如果 Safari 和 Firefox 看到多播连接关闭，然后在同一连接上看到数据，它们似乎会发送 RST。

我的问题是为什么？正确的做法是什么，为什么 2/4 的浏览器以一种方式这样做，而另外 2/4 的浏览器则以另一种方式进行？例如，在代码中的某个地方我可以看到在 Firefox 中发生这种情况的地方吗？

非常感谢。

【问题讨论】：

这很奇怪，我没想到浏览器会进入 ACK'ing 数据包的级别——这将是网络堆栈的工作，除非它是浏览器处理的方式来自网络堆栈的错误信号不同。
这很有趣。我之前没有接触过 Mac，你确定所有浏览器都使用同一个 Flash Player？

标签： macos networking tcp

【解决方案1】：

当 Firefox 和 Safari 看到多播连接关闭时，似乎从打开的连接列表中删除了 TCP 连接。

一旦 TCP 连接关闭，尝试向其发送数据包时的合理行为是发送 RST 数据包。

【讨论】：

【解决方案2】：

当您拔下电缆时，您的接口会关闭，随后的数据包应该会收到“ICMP NO ROUTE TO HOST”。然后由应用程序决定如何处理：您是立即放弃还是等待更长时间？看来 Firefox 和 Safari 已经等不及了。

当您将集线器留在原位时，您的计算机不知道它丢失了到主机的路由，因此不会出现消息。

HTH，

【讨论】：

【解决方案3】：

我知道这是一个老问题，但我相信有必要提供一些更全面的信息，因为我遇到过类似的问题，并且很难找到任何资源。

根据我的经验和Department of Computer Science at the University of Calgary 的研究，作者发现关于 TCP RST 数据包响应：

...应用程序级浏览器行为是导致 TCP异常行为的全球趋势。具体来说，持久HTTP的实施和管理中的违规行为连接是导致此问题的原因。更正 TCP 流行的 Web 浏览器的行为可能会消除大部分这些 TCP RST 异常。

本质上，这表明浏览器实现 TCP 重置行为的方式不同，因此您会看到不同的行为。此外，不同的操作系统似乎也实现了TCP RST headers differently，因此即使在不同的操作系统上使用相同的浏览器也可能导致略有不同的结果，这可能就是为什么在两者之间添加集线器可以解决问题的原因。

我相信 Chromium 错误跟踪器中的这个问题与 why Chrome works 有关。类似的东西被介绍给Firefox in 2010

当新套接字组的连接时间过长时，发出一个备份套接字请求以重试连接。这减少了延迟是否存在丢包。

某些浏览器会在单个 RST 数据包上主动终止连接（IE 11/Safari 9/10 至少根据我的测试）。基于 chrome://net-internals 中的数据的 Google Chrome（v56 测试）似乎在收到 ERR_CONNECTION_RESET -103 错误后重用相同的套接字重试。然后它会重试几次，直到成功。我相信这种智能重试行为可能是导致某些浏览器重新启动丢失的连接的原因。虽然它可能没有实现适当的 RFC 或规范（我找不到确切的，它可能适用于 HTTP/1.1 或只是 TCP Resets）

我今天的经历涉及在 Apache 中启用 Keep Alive，在 Big-IP F5 WAF/负载均衡器后面，它根据 URL 模式将流量路由到两个虚拟服务器组之一。在 Apache 中关闭 keep alive 解决了我们的 TCP RST 数据包被返回和连接被中止的问题。

【讨论】：