在Mac OS X（10.6）上，如果我开始下载YouTube视频并拔下以太网线5秒钟，然后将其重新插入，我会根据浏览器获得不同的结果。有了Opera和Chrome，在我将视频插回视频后继续加载。但是使用Safari和Firefox，它永远不会。
使用Wireshark查看流量，我发现Opera和Chrome只是在重新插入电缆后确认来自YouTube的第一个数据包，但是Safari和Firefox在TCP标头中设置了RST标志（0x4）而没有随后会有更多的流量。
我可以在机器和互联网连接之间放置一个HUB，问题消失了，当电缆插回HUB时，所有四个浏览器继续加载视频。再看一下Wireshark日志，显然机器没有看到Mulitcast连接关闭，并且流量通过的数据包只有一个延迟。
因此，如果Safari和Firefox看到多播连接关闭，然后再看到同一连接上的数据，他们就会发送一个RST。
我的问题是为什么？什么是正确的行动方案，为什么2/4浏览器以单向方式进行，而另外2/4以另一种方式进行？代码中是否有某些地方我可以看到Firefox中发生这种情况，例如？
非常感谢。
答案 0 :(得分：1)
当Firefox和Safari看到多播连接关闭时，它们似乎从已打开的连接列表中删除了TCP连接。
TCP连接关闭后，尝试向其发送数据包时的合理行为是发送RST数据包。
答案 1 :(得分：1)
当您拉动电缆时，您的接口会关闭，后续数据包应该会出现“ICMP NO ROUTE TO HOST”。然后由应用程序决定如何处理：您是立即放弃还是等待更长时间？看起来Firefox和Safari不会再等待。
当您将集线器放置到位时，您的计算机不知道它丢失了通往主机的路由，因此消息不会出现。
HTH，
答案 2 :(得分：0)
我意识到这是一个老问题，但我相信一些更全面的信息是合理的，因为我遇到过类似的问题，并且在寻找任何资源方面都遇到了很多麻烦。
根据我的经验和Department of Computer Science at the University of Calgary的研究，作者发现了TCP RST数据包响应：
......应用程序级浏览器行为是主要的贡献者 TCP行为异常的全球趋势。具体来说 执行和管理持久性HTTP的不规范 连接是导致此问题的原因。纠正TCP 流行的Web浏览器的行为可能会消除大部分 这些TCP RST异常。
基本上，这表明浏览器以不同方式实现TCP重置行为，因此，您会看到不同的行为。此外，似乎不同的操作系统也实现TCP RST headers differently，因此即使在不同的操作系统上使用相同的浏览器也可能导致略有不同的结果，这可能是为什么在中间添加集线器解决问题的原因。
我相信Chromium bug跟踪器中的这个问题与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中关闭保持活动解决了我们的问题，即返回TCP RST数据包并且连接被中止。