Reputation: 1085

Why tcp termination need 4-way-handshake?

When connection sets up, there is:

Client ------SYN-----> Server

Client <---ACK/SYN---- Server ----①

Client ------ACK-----> Server

and when termination comes, there is:

Client ------FIN-----> Server

Client <-----ACK------ Server ----②

Client <-----FIN------ Server ----③

Client ------ACK-----> Server

my question is why ② and ③ can not set in the same package like ① which is ACK and SYN set in one package ???

Upvotes: 34

Answers (7)

XZX

Reputation: 41

it can be, look this

As in a three-way handshake, the FIN flag is similar to the SYN flag.

Why and When will this happend?

This can happen when one end receives the FIN flag and it doesn't need to send any data to the other end.

Upvotes: 1

Chris Bao

Reputation: 2868

Based on this document, we can see the detail process of the four way handshake as follows

The ACK (marked as ②) is send by TCP stack automatically. And the next FIN (marked as ③) is controlled in application level by calling close socket API. Application has the control to terminate the connection. So in common case, we didn't merge this two packets into one.

In contrast, the ACK/SYN (marked as ①) is send by TCP stack automatically. In the TCP connection establishment stage, the process is straightforward and easier, so TCP stack handles this by default.

Upvotes: 4

touchstone

Reputation: 1085

After googling a lot, I recognized that the four-way is actually two pairs of two-way handshakes.

If termination is a REAL four-way actions, the 2 and 3 indeed can be set 1 at the same packet.

But this a two-phase work: the first phase (i.e. the first two-way handshake) is :

Client ------FIN-----> Server

Client <-----ACK------ Server

At this moment the client has been in FIN_WAIT_2 state waiting for a FIN from Server. As a bidirectional and full-duplex protocol, at present one direction has break down, no more data would be sent, but receiving still work, client has to wait for the other "half-duplex" to be terminated.

While the FIN from the Server was sent to Client, then Client response a ACK to terminate the connection.

Concluding note: the 2 and 3 can not merge into one package, because they belong to different states. But, if server has no more data or no data at all to be sent when received the FIN from client, it's ok to merge 2 and 3 in one package.

References:

Upvotes: 35

Wason

Reputation: 1493

I think of course the 2 and 3 can merge technically, but not flexible enough as not atomic.
The first FIN1 C to S means and only means: I would close on my way of communication. The first ACK1 S to C means a response to FIN1. OK, I know your channel is disconnected but for my S(server) way connection, I'm not sure yet. Maybe my receiving buffer is not fully handled yet. The time I need is uncertain. Thus 2 and 3 are not appropriate to merge. Only the server would have right to decide when his way of connection can be disconnected.

Upvotes: 15

BrainAtom

Reputation: 29

If this is observed from the angle of coding, it is more reasonable to have 4 way than 3 way although both are possible ways for use.

When a connection is to be terminated by one side, there are multiple possibilities or states that the peer may have. At least one is normal, one is on transmitting or receiving, one is in disconnected state somehow all of a sudden before this initiation.

The way of termination should take at least above three into consideration for they all have high probabilities to happen in real life.

So it becomes more natural to find out why based on above. If the peer is in offline state, then things are quite easy for client to infer the peer state by delving into the packet content captured in the procedure since the first ack msg could not be received from peer. But if the two messages are combined together, then it becomes much difficult for the client to know why the peer does not respond because not only offline state could lead to the packet missing but also the various exceptions in the procedure of processing in server side could make this happen. Not to mention the client needs to wait large amount of time until timeout. With the additional 1 message, the two problems could become more easier to handle from client side.

The reason for it looks like coding because the information contained in the message is just like the log of code.

Upvotes: -1

Testing123

Reputation: 363

From Wikipedia - "It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.[14]"

Source:

Wikipedia - https://en.wikipedia.org/wiki/Transmission_Control_Protocol

[14] - Tanenbaum, Andrew S. (2003-03-17). Computer Networks (Fourth ed.). Prentice Hall. ISBN 0-13-066102-3.

Upvotes: 4

Dubois

Reputation: 124

In the Three-Way Handshake (connection setup) : The server must acknowledge (ACK) the client's SYN and the server must also send its own SYN containing the initial sequence number for the data that the server will send on the connection.
That why the server sends its SYN and the ACK of the client's SYN in a single segment.
In connection Termination : it takes four segments to terminate a connection since a FIN and an ACK are required in each direction.
(2) means that The received FIN (first segment) is acknowledged (ACK) by TCP
(3) means that sometime later the application that received the end-of-file will close its socket. This causes its TCP to send a FIN.
And then the last segment will mean that The TCP on the system that receives this final FIN acknowledges (ACK) the FIN.

Upvotes: -2

Why tcp termination need 4-way-handshake?

Answers (7)

Related Questions