TCP/IP RST being sent differently in different browsers

On Mac OS X (10.6), if I start a YouTube video download and pull the Ethernet cable for 5 or so seconds, then plug it back in, I get varying results depending on the browser. With Opera and Chrome, after I plug the cable back in the video c开发者_开发技巧ontinues to load. But with Safari and Firefox, it never does.

Using Wireshark to look at the traffic, I found that Opera and Chrome simply ACK the first packet from YouTube after the cable has been plugged back in, but Safari and Firefox set the RST flag (0x4) in the TCP header and no more traffic follows.

I can put a HUB in between the machine and the internet connection, the problem goes away and all four browsers continue loading the video when the cable is plugged back into the HUB. Again, looking at the Wireshark logs, it's evident that the machine doesn't see the Mulitcast connection close and there is simply a delay in the packets flowing through.

So it seems that if Safari and Firefox sees a Multicast connection close, and then later see data on that same connection, they will send a RST.

My question is why? What is the correct course of action, and why are 2/4 browsers doing it one way, while the other 2/4 are doing it another way? Is there somewhere in the code that I can see where this is happening in Firefox, for instance?

Thank you very much.

It seems that Firefox and Safari delete the TCP connection from their list of opened connections when they see the Multicast connection close.

Once a TCP connection is closed, a reasonable behavior when trying to send packets to it is to send a RST packet.

When you pull the cable, your interface goes down, and subsequent packets should get an "ICMP NO ROUTE TO HOST". It's then up to the application as to what to do with that: do you give up immediately or wait longer? Looks like Firefox and Safari don't wait longer.

When you leave the hub in place, your computer doesn't know it's lost the route to the host, so the message doesn't come up.

HTH,

I realise this is an old question, but I believe some more thorough information is warranted as I've experienced similar issues, and had much trouble finding any resources.

Based on my experiences, and a study by the Department of Computer Science at the University of Calgary, the authors found with regards to TCP RST packet responses:

...that application-level browser behaviour is the primary contributor to the global trend of abnormal TCP behaviours. Specifically , irregularities in the implementation and management of persistent HTTP connections are the cause of this problem. Correcting the TCP behaviour of a popular Web browser would likely eliminate most of these TCP RST anomalies.

Essentially, this indicates that browsers implement TCP reset behaviour differently and as a result, you see different behaviours. Furthermore, it appears that different Operating Systems also implement TCP RST headers differently, so even using the same browser on a different OS may lead to slightly different results, which could be why adding a hub in between is resolving the issue.

I believe this issue in the Chromium bug tracker is related to why Chrome works. A similar thing was introduced to Firefox in 2010

When connect takes too long for a new socket group, issue a single backup socket request to retry the connect. This reduces latency in the presence of packet loss.

Some browsers will aggressively terminate a connection on a single RST packet (IE 11/Safari 9/10 at least from my tests). Google Chrome (v56 tested), based on data in chrome://net-internals, appears to reuse the same socket to retry after receiving an ERR_CONNECTION_RESET -103 error. It then retries a few times until it succeeds. I believe this intelligent retry behaviour may be what is causing certain browsers to restart connections that were lost. While it may not implement the appropriate RFC or Spec (I can't find an exact one, it may be for HTTP/1.1 or just TCP Resets)

My experience today involved Keep Alive being on in Apache, behind a Big-IP F5 WAF/Load Balancer which routed traffic based on a URL pattern to one of two Virtual server groups. Turning keep alive off in Apache resolved our issue with TCP RST packets being returned and connections being aborted.