3

I am attempting to understand the three way handshake however have difficuly understanding how this applies to a real-world scenario. For example if I am using a web browser such as Mozilla Firefox and browse to the website www.superuser.com, I take it the following occur

  1. I launch Firefox and as an application is assigned a random process identifier. Assuming I launch with a blank page, this is all that happens.

  2. Now if I browse to www.superuser.com, my PC initiates contact with the server by sending a SYN packet.

  3. The server responds to by request by sending an ACK packet along with its own SYN packet

  4. My computer responds with an ACK packet and the connection is established.

Now the confusion,

  1. What does established exactly mean? If I were to for example to then browse to another page on www.superuser.com, does the three way handshake repeat itself?

  2. When does my PC send the FIN flag and when does the server respond with its own FIN packet?

  3. I understand that an application can have multiple threads when making a request from a server, does this mean each thread has its own three way handshake? Are these independent from one another?

  4. What does the various states of FIN_WAIT mean?

  5. Can a server end the connection without being initiated by the client or does it always have to be initiated from the client?

2

2 Answers 2

3

What does established exactly mean? If I were to for example to then browse to another page on www.superuser.com, does the three way handshake repeat itself?

"Established" means that the three-way handshake has been completed, and the connection is available for transferring data (until it is closed).

The number of requests is protocol-dependent. In HTTP 1.0, only one request per connection is made – TCP handshake, HTTP request, HTTP reply, TCP close handshake. To retrieve the stylesheets or the images, more connections had to be made (possibly multiple at the same time).

In HTTP 1.1, persistent connections are allowed, in which the connection is held open (idle) after the initial request, and if the browser needs to load more resources (images, other pages) it sends more requests down the same connection.

Other protocols often carry out long conversations over a single connection. FTP, on the other hand, uses multiple short-lived "data" connections in addition to the primary "control" conn.

When does my PC send the FIN flag and when does the server respond with its own FIN packet?

When your browser decides to close the connection or to "hang up", your computer sends a FIN packet, the server replies to it with a FIN ACK, and your computer replies with an ACK.

I understand that an application can have multiple threads when making a request from a server, does this mean each thread has its own three way handshake? Are these independent from one another?

Threads are irrelevant. The only concept is TCP connections. Each separate connection has a separate handshake.

Each thread can establish multiple connections; several threads can potentially share a connection; even several processes can share a connection in some situations.

What does the various states of FIN_WAIT mean?

  1. client is in ESTABLISHED → server sends FIN → client is in FIN_WAIT1
  2. server is in ESTABLISHED → server recvs FIN → server is in CLOSE_WAIT
  3. ...I'll admit, I don't know. (Someone feel free to edit. I found this diagram.)

Can a server end the connection without being initiated by the client or does it always have to be initiated from the client?

The connection can be closed by either end. If the HTTP daemon closed it, it would work the same way but in opposite direction – the server would send FIN and your computer would reply with FIN ACK...


TCP is specified in RFC 793. The Wikipedia article on TCP explains how the protocol handshake is done.

13
  • Thanks for the awesome answer althought it has raised more questions. When you say it is protocol dependent I take it that it is the protocol supported by the server e.g. If the server only supports HTTP 1.0 the browser would have to make a HTTP 1.0 connection. Is that right? Now you mean that HTTP 1.1 is persistent, how long is the connection kept open and does the server define this value? If so how? When would the server or client decide to close the connection? Sep 18, 2011 at 21:49
  • You mean each connection has a separate handshake. What is deemed as a separate connection using the example of the web browser? Sep 18, 2011 at 21:49
  • @PeanutsMonkey: If a browser is relatively recent, it will send a HTTP/1.1 request indicating that it accepts "keep-alive" connections. If the server supports and allows persistence, it returns the same header in the response and the browser can reuse the connection. (How and when it does, depends strictly on the browser, and is not related to TCP.) If the server does not indicate persistence support, the browser will make additional connections, as many as it needs until all page assets are retrieved. Sep 18, 2011 at 21:53
  • 1
    @PeanutsMonkey: The FIN packet is sent when either end decides that the connection will not be necessary and tells the OS to close the connection (to hang up). In HTTP/1.0, the server closes the connection immediately after sending a response, since the protocol only supports one request/response pair. In HTTP/1.1, the server can close the connection in case of problems, and the client (browser) when it knows it downloaded everything needed. In addition, if you click the "Stop" button, the browser will close the connection in the middle of receiving a response. Sep 19, 2011 at 7:25
  • 1
    @PeanutsMonkey: RST is another TCP flag, indicating a "reset". Generally, it is used for these purposes: a) refusal to open a connection, in reply to SYN; b) immediate termination of a connection, for example, when a process is killed by the OS; c) as the original purpose, indication that the RST-sender received a TCP packet belonging to a connection it doesn't know about (for example, hosts A and B connect, A loses power and reboots, B keeps sending data, A replies with RST indicating it doesn't know that connection anymore). Sep 19, 2011 at 7:30
0
  1. it means that a TCP connection is set up (a duplex connection)

  2. when the connection is not needed anymore (some browsers and servers keep a connection alive for a while see the http connection headers)

  3. each TCP connection is independent and has done it's own handshake when the connection is setup

  4. FIN_WAIT_1 means that FIN is send but not acked FIN_WAIT_2 means it is acked but the other side hasn't FINed yet

  5. either end can terminate the connection when it doesn't have anything to send anymore

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .