OSQA is unmaintained. Help us figure out where to go from here.

I found my connection got packet TCP Reset after I receive packet [FIN,ACK] in every time. I don't understand, why it send TCP Reset packet? This case is the normal or not? Cause my application didn't got error message when I found these packets.

P.S. Trace file is in this link.http://cloudshark.org/captures/fa18617b777d and http://cloudshark.org/captures/ee9c044e161d

asked 01 Sep '12, 21:09

horboyz's gravatar image

horboyz
1112
accept rate: 0%


TCP is a bi-directional protocol. This means that during a connection close sequence, both sides get to say "I'm done sending things now." The connection isn't "down" until both sides have done that, or one side sends a TCP RST packet.

It is quite possible — and indeed common — for the connection to be half-closed. For example, a simple HTTP 1.0 conversation is a request for information, followed by a response from the server. The client is free to close its sending half of the connection after the request; it won't affect whether the server sends the reply. HTTP 1.1 can be more complex than this, allowing multiple requests and responses on a single connection, but the old one request per connection style is still legal.

Looking at your capture, what I see is that the server sends its FIN and ACK bits, and the client responds with a RST. That means the client isn't coded to shut the connection down gracefully. There are many ways for this to happen:

  • The client can just exit without closing the connection. The stack is free to complete the graceful shutdown for the dead program, but it's likely to just send RST immediately.

  • The client can set the SO_LINGER option with setsockopt() to 0, then exit, leaving the stack no choice but send a RST because both TCP peers are gone and it has been told it isn't allowed to spend any time cleaning up the connection.

  • The client can use non-blocking sockets, call close() on the socket, then exit, thinking it has closed its sending half correctly, not realizing that it is forcing the stack to abort sending in-flight packets, substituting a RST.

  • If the client doesn't abortively exit like above, it may be doing something odd like shutdown(fd, SHUT_RDWR) or shutdown(SHUT_RD). The first is called "slamming the connection shut," and the second is basically the client telling the server "shut up, you!" Either way, a TCP RST goes out.

Bottom line, the client has a bug, and needs to be fixed.

permanent link

answered 02 Sep '12, 15:33

Warren%20Young's gravatar image

Warren Young
164
accept rate: 0%

edited 02 Sep '12, 15:37

RST in response to FIN is an old hack that's still common in http. The concept is basically that http sessions are short-lived, with a single Req/Resp pair (http 1.0). This special case therefore doesn't require TCP's ability to receive data after a FIN is sent, so after the server is done sending the requested content, the browser will send a RST. This bypasses the CLOSE-WAIT and LAST-ACK states on the browser, and triggers the server to bypass the FIN-WAIT-1/FIN-WAIT-2/CLOSING states.

Short answer: when dealing with web browsers, this is common behavior.

permanent link

answered 04 Dec '13, 16:34

shewfig's gravatar image

shewfig
262
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×77

question asked: 01 Sep '12, 21:09

question was seen: 90,632 times

last updated: 04 Dec '13, 16:34

p​o​w​e​r​e​d by O​S​Q​A