What can cause a Client to RST a connection from a Web Server?

Question

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

7562   13366.743126000   10.1.2.49   10.1.101.19   HTTP   265   HTTP/1.1 304 Not Modified 
7563   13366.744734000   10.1.2.49   10.1.101.19   HTTP   265   HTTP/1.1 304 Not Modified 
7564   13366.747540000   10.1.101.19   10.1.2.49   HTTP   781   GET /Scripts/SiteScripts/IDHUtility.js? HTTP/1.1 
7565   13366.749093000   10.1.101.19   10.1.2.49   HTTP   779   GET /Scripts/SiteScripts/TextInput.js     HTTP/1.1 
7566   13366.749247000   10.1.101.19   10.1.2.49   HTTP   783   GET /Scripts/SiteScripts/IDHWatermark.js? HTTP/1.1 
7567   13366.749294000   10.1.2.49   10.1.101.19   HTTP   265   HTTP/1.1 304 Not Modified 
7568   13366.750958000   10.1.2.49   10.1.101.19   HTTP   265   HTTP/1.1 304 Not Modified 
7569   13366.752475000   10.1.2.49   10.1.101.19   HTTP   265   HTTP/1.1 304 Not Modified 
7570   13366.942381000   10.1.101.19   10.1.2.49   TCP   54   62066 > http [ACK] Seq=1459 Ack=422 Win=63819 Len=0
7571   13366.942381000   10.1.101.19   10.1.2.49   TCP   54   62060 > http [ACK] Seq=2118 Ack=6860 Win=63819 Len=0
7572   13366.952376000   10.1.101.19   10.1.2.49   TCP   54   62065 > http [ACK] Seq=2172 Ack=633 Win=63608 Len=0
7573   13366.952384000   10.1.101.19   10.1.2.49   TCP   54   62072 > http [ACK] Seq=1461 Ack=423 Win=63818 Len=0
7574   13366.952389000   10.1.101.19   10.1.2.49   TCP   54   62069 > http [ACK] Seq=1446 Ack=423 Win=63818 Len=0
7575   13366.952395000   10.1.101.19   10.1.2.49   TCP   54   62075 > http [ACK] Seq=736 Ack=212 Win=64029 Len=0
7576   13369.299413000   10.1.2.49   10.1.101.19   TCP   62   [TCP Retransmission] http > 62057 [SYN, ACK] Seq=2463265357 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1
7577   13369.299438000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7578   13370.451189000   10.1.2.49   10.1.101.19   TCP   62   [TCP Retransmission] http > 62057 [SYN, ACK] Seq=128998961 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
7579   13370.451216000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7580   13376.453542000   10.1.2.49   10.1.101.19   TCP   62   [TCP Retransmission] http > 62057 [SYN, ACK] Seq=128998961 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1
7581   13376.453577000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7582   13396.450644000   10.1.101.17   10.1.2.49   TCP   66   52803 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
7583   13396.451265000   10.1.101.17   10.1.2.49   TCP   60   52803 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
7584   13396.453783000   10.1.101.17   10.1.2.49   HTTP   699   GET /DenPay/Performers HTTP/1.1 
7585   13427.206987000   10.1.2.49   10.1.101.19   TCP   60   [TCP Retransmission] http > 62057 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0
7586   13427.207325000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7587   13430.213996000   10.1.2.49   10.1.101.19   TCP   60   [TCP Retransmission] http > 62057 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0
7588   13430.214031000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7589   13436.224373000   10.1.2.49   10.1.101.19   TCP   60   [TCP Retransmission] http > 62057 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0
7590   13436.224400000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7591   13448.261050000   10.1.2.49   10.1.101.19   TCP   60   [TCP Retransmission] http > 62057 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0
7592   13448.261078000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7593   13472.334513000   10.1.2.49   10.1.101.19   TCP   60   [TCP Retransmission] http > 62057 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0
7594   13472.334545000   10.1.101.19   10.1.2.49   TCP   54   62057 > http [RST] Seq=1 Win=0 Len=0
7595   13492.949455000   10.1.2.49   10.1.101.19   TCP   60   http > 62072 [RST, ACK] Seq=423 Ack=1461 Win=0 Len=0
7596   13516.446650000   10.1.101.17   10.1.2.49   TCP   60   [TCP Previous segment not captured] 52803 > http [FIN, ACK] Seq=1286 Ack=5565 Win=65536 Len=0
7597   13516.447339000   10.1.101.17   10.1.2.49   TCP   60   52803 > http [ACK] Seq=1287 Ack=5566 Win=65536 Len=0

Answer 1

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.