Client RST connection of a Web Server
We have a web application, hosted in IIS and we appear to be getting an intermittent '0 bytes returned from server' in the web application. As part of our tests we had users access the web application direct on the box and the issue goes away so we think that issue is on the network layer. Using Wireshark we noticed we seem to get a bunch of http [RST] that we believe are happening just before the browser is rendering the white page/0 bytes received from server.
We have to admit we're learning as we go with this one but believe that while RST packets can be normal behavior our thinking is it's not in this case. We're able to see many instances of RSTs from the server to the client but not the other way around and when it is the other way around we seem to get this problem with the web application.
This is local traffic so doesn't go through our firewall, the server a VM using Windows 2008 R2 Server. We've not seen this issue manifest in other systems but can't be sure it's not happening elsewhere. If I've missed anything off let me know.
The questions I have are; what could cause a RST from a client? Are we premature identifying this as network issue rather than an application problem?
We found the a related link but have checked that ECN is not set. http://serverfault.com/questions/641794/random-tcp-rsts-on-certain-websites-whats-going-on
asked 16 Jan '15, 06:26
Resets are almost never a network issue, no matter if they happen as part of a normal conversation or a critical abort. Critical aborts are usually caused by application problems, not network problems. The only exception to the rule is when packets get so badly damaged in transit that client or server decide to terminate the connection, but that is very very rare. Especially since this only happens when the damaged packet makes it through to the other end, which is unlikely - packets like that get killed in routers and switches on the way because their FCS will be bad, too. This turns the bad packet into simple packet loss, which is not a reason for a connection abort (unless it can't be recovered from).
A client can perfectly use a RST to terminate a connection if it is certain that the server is not sending any more content. This is the case when a request is sent, the answer came in completely fine, and the client doesn't need anything else.
BTW, if you can, post a capture file instead of ASCII exports; nobody likes to read those. Use TraceWrangler if you need to sanitize your files first. Post files to Cloudshark and paste the link here.
answered 16 Jan '15, 06:43
edited 16 Jan '15, 06:44