CODEWITHSUNDEEP
tcphandshake
frankguthrie
frankguthrie

Reputation: 149

TCP 4-way close

I was under the impression that in order to close a TCP session a 4-way close/handshake need to happen. Looking at a TCP dump (from an F5 loadbalancer)

21:44:39.149332 IP 1.1.1.1.54934 > 2.2.2.2.https: Flags [S], seq 2406625584, win 29200, options [mss 1460,sackOK,TS val 1897921772 ecr 0,nop,wscale 7], length 0 out slot1/tmm1 lis=

21:44:39.163133 IP 2.2.2.2.https > 1.1.1.1.54934: Flags [S.], seq 4293133240, ack 2406625585, win 28960, options [mss 1418,sackOK,TS val 220337697 ecr 1897921772,nop,wscale 7], length 0 in slot1/tmm1 lis=

21:44:39.163277 IP 1.1.1.1.54934 > 2.2.2.2.https: Flags [.], ack 1, win 229, options [nop,nop,TS val 1897921786 ecr 220337697], length 0 out slot1/tmm1 lis=

The TCP 3 way handshake to set up the connection look exactly as expected, with a SYN, SYN ACK and SYN. However the tear-down uses 3 message: FIN ACK, FIN ACK and ACK... I don't understand why this is different from what literature say. Is this the TCP implementation F5 uses? Do vendors use a different implementation of TCP?

21:44:39.163282 IP 1.1.1.1.54934 > 2.2.2.2.https: Flags [F.], seq 1, ack 1, win 229, options [nop,nop,TS val 1897921786 ecr 220337697], length 0 out slot1/tmm1 lis=

21:44:39.176912 IP 2.2.2.2.https > 1.1.1.1.54934: Flags [F.], seq 1, ack 2, win 227, options [nop,nop,TS val 220337700 ecr 1897921786], length 0 in slot1/tmm1 lis=

21:44:39.177067 IP 1.1.1.1.54934 > 2.2.2.2.https: Flags [.], ack 2, win 229, options [nop,nop,TS val 1897921800 ecr 220337700], length 0 out slot1/tmm1 lis=

What am I missing?

Upvotes: 2

Views: 3137

Answers (2)

frankguthrie
frankguthrie

Reputation: 149

Ok,

I have looked over this with a colleague of mine and he had a possible answer as to why we see a double ACK.

We see the same ACK in the 3rd packet of the TCP 3-way SYN and in the first packet of the TCP 4-way close. According to my college, because there is no actual data send after the 3-way handshake, it will send another ACK to make sure the other host knows the session is terminated, because no data is flowing and so the other side doesn't see a stop of dataflow. So it sends another ACK to make sure.

So the actual TCP close is:
-> FIN
<- FIN, ACK
-> ACK

Upvotes: 0

Some programmer dude
Some programmer dude

Reputation: 409176

Notice how the other peers stack combines FIN with ACK.

The four-way hand-shake is really:

  1. Local host sends FIN to remote host
  2. Remote host sends ACK for the previous message
  3. Remote host sends FIN to local host
  4. Local host sends ACK to remote host

The remote peer combines the two middle steps into a single step as an optimization (to limit the number of packets sent).

Upvotes: 2

Related Questions