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?

PeanutsMonkey
  • 9,100
  • This isn't really a practical computer or hardware problem for SU as per the FAQ - maybe it's within the scope of SO or Webapps. – Linker3000 Sep 18 '11 at 21:39
  • @Linker3000 - Think it is a computer or hardware problem especially reading about long TIME_WAITS at http://antmeetspenguin.blogspot.com/2008/10/timewait-in-netstat.html – PeanutsMonkey Sep 18 '11 at 21:50

2 Answers2

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.

Community
  • 1
u1686_grawity
  • 452,512
  • 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? – PeanutsMonkey Sep 18 '11 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? – PeanutsMonkey Sep 18 '11 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. – u1686_grawity Sep 18 '11 at 21:53
  • @PeanutsMonkey: I used "connection" as a TCP term, and the concept is not specific to web browsers. I'm really bad at explaining it, but you can think of connections as similar to phone calls: dial, talk, hangup. (In HTTP 1.0 - dial, ask, answer, hangup. In HTTP 1.1 - dial, ask, answer, ask, answer, ask ask ask, answer answer answer, hangup.) – u1686_grawity Sep 18 '11 at 21:57
  • When you say how and when depends on the browser are you referring to the browser reusing the connection? If so, how does the server know long long to keep the connection idle and open? Also does the state remain established? Now if I am looking at the server's netstat output would it display the connection as established as well with the local address being the server's and the foreign address being the client's? – PeanutsMonkey Sep 18 '11 at 21:59
  • @Peanuts: Yes, the same browser opens a connection and decides how it should be reused. (Although it is probably the same in all browsers: if a connection can be reused, then it should be reused. But this is an implementation detail.) As for the server, it depends on the HTTP daemon's configuration. For example, Apache 2.0 drops such connections after 15 seconds of idle time, and in version 2.2 this has been lowered to 5 idle seconds. But this too is not a TCP question, and varies between protocols. (For example, in SMTP, the timeouts range in several minutes.) – u1686_grawity Sep 18 '11 at 22:04
  • @PeanutsMonkey: In the olden days, the server would close the connection after every single request. These days it closes after a task (e.g. loading a web page) is complete or it times out, assuming both the client and server support that. As far as state, no, once a connection is closed, the state related to the connection goes away (not including state at a higher level, like the cookie). Finally, yes, the netstat output should match what you describe, but you might have to be quick to catch it before the connection closes. – Slartibartfast Sep 18 '11 at 22:06
  • @Peanuts: Even though the connection is idle, it remains as "ESTABLISHED". (You can have a silent phone call, too.) The state changes only on explicit close (when a packet with FIN or RST is sent). – u1686_grawity Sep 18 '11 at 22:06
  • @Slartibartfast - When you say 'assuming both the client and server support that' what are you referring to exactly? – PeanutsMonkey Sep 19 '11 at 03:25
  • @grawity - Assuming the browser has downloaded all the content from a web page, when is the FIN packet sent? Also what is RST and what purpose does it serve? – PeanutsMonkey Sep 19 '11 at 03:26
  • 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. – u1686_grawity Sep 19 '11 at 07: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). – u1686_grawity Sep 19 '11 at 07:30
  • @grawity - Thanks. Is there any material for noobs you can suggest I can read further to learn about TCP/IP? – PeanutsMonkey Sep 19 '11 at 20:13
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

ratchet freak
  • 2,854