This is a static archive of our old Q&A Site. Please post any new questions and answers at

IE sends [RST,ACK] right after [ACK] from server


Some clients with IE are sending [RST, ACK] response right after receiving [ACK] from the server. Is there are reason why it could be happening? This seems to be not occurring in Firefox.

   1113 2013-09-23 09:49:48.514472000      HTTP     57963       http             653    GET /eclient/ctcCustom/JS/extJS/resources/images/default/tree/elbow.gif HTTP/1.1

1114 2013-09-23 09:49:48.515179000 TCP http 57963 60 http > 57963 [ACK] Seq=108815 Ack=16847 Win=12440 Len=0

1115 2013-09-23 09:49:48.516028000 TCP 57963 http 54 57963 > http [RST, ACK] Seq=16847 Ack=108815 Win=0 Len=0

asked 24 Sep ‘13, 11:47

torman's gravatar image

accept rate: 0%

One Answer:


IE uses RST to terminate TCP sessions, instead of being "nice" using FIN. This is a common thing to observe, since it is "unfriendly" but good for recovering resources quickly. Maybe a user just closed the browser, maybe he pressed the "stop" button.

answered 24 Sep '13, 13:41

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%

Thanks for looking into this Jasper. We did the capture on the user side and user didn't close or stopped loading the page.

For some reason the browser just kept resetting the connections and was requesting the same resource over and over again.

1313 2013-09-23 09:49:55.685872000 HTTP 57965 http 630 GET /eclient/ctcCustom/Images/Icons/marker_f.png HTTP/1.1 1314 2013-09-23 09:49:55.686558000 TCP http 57965 60 http > 57965 [ACK] Seq=102633 Ack=18777 Win=12484 Len=0 1315 2013-09-23 09:49:55.810773000 TCP 57965 http 54 57965 > http [RST, ACK] Seq=18777 Ack=102633 Win=0 Len=0 1316 2013-09-23 09:49:55.855863000 HTTP 57964 http 630 GET /eclient/ctcCustom/Images/Icons/marker_f.png HTTP/1.1 1317 2013-09-23 09:49:55.856564000 TCP http 57964 60 http > 57964 [ACK] Seq=133586 Ack=20029 Win=13044 Len=0 1318 2013-09-23 09:49:55.967640000 TCP 57964 http 54 57964 > http [RST, ACK] Seq=20029 Ack=133586 Win=0 Len=0 There were a few more GET requests with [RST, ACK] after [ACK] from the server...

At some point IE was kind enough to not reset it and wait for the response to be delivered: 1389 2013-09-23 09:50:01.202030000 HTTP 58005 http 630 GET /eclient/ctcCustom/Images/Icons/marker_f.png HTTP/1.1 1390 2013-09-23 09:50:01.202702000 TCP http 58005 60 http > 58005 [ACK] Seq=1 Ack=577 Win=6992 Len=0 1394 2013-09-23 09:50:01.523755000 HTTP http 58005 178 HTTP/1.1 304 Not Modified 1396 2013-09-23 09:50:01.717515000 TCP 58005 http 54 58005 > http [ACK] Seq=577 Ack=125 Win=65748 Len=0

(24 Sep '13, 14:55) torman

Can you put the trace on cloudshark so that we can take a better look - including the full connection from start to finish? The few packets you quoted are not enough to see if there are issues with the packet sequences, so maybe the RST is a result of something going wrong with the connection.

I noticed that the server never sent the actual content in the first block, it only acknowledges the GET request. In the second ("working") block there is a 304 not modified, so the behavior of the server is different. Maybe that has something to do with how IE behaves.

(24 Sep '13, 22:25) Jasper ♦♦

I will check if posting the full capture is possible..

As for the differences in the server replies: I believe the server didn't send the actual content in the first block as the client sent [RST, ACK] before that.

On the send block client didn't send [RST, ACK] and was just waiting for the server reply with the content (which he got shortly).

(25 Sep '13, 12:25) torman

Unfortunately I can't share full trace as it has some sensitive data inside.. Looking through the packages I don't see any problems with the TCP connections up until the point where client sends an [RST, ACK] to the server.

(30 Sep '13, 13:42) torman

Unfortunately I can't share full trace as it has some sensitive data inside..

Maybe tracewrangler can help.

(30 Sep '13, 14:53) Kurt Knochner ♦