Kennt sich wer mit TCP aus?

3 Antworten

https://www.geeksforgeeks.org/why-tcp-connect-termination-need-4-way-handshake/?ref=rp

Hier ist das alles sehr gut erzählt. Ich hoffe, Englisch ist kein problem...

Why Does TCP Connect Termination Need 4-way-Handshake?

Now the question is, why termination can not send ACK and FIN packets at once? By which one step can be reduced. And why the four-way handshake is necessary here?

Well, by looking at it carefully, it can be seen that the four-way Handshake is actually a set of two-way handshakes. However, it is not completely false that in some cases, the 2 and 3 can be set at the same packet.

The four-way handshake works as a pair of two-way Handshakes. Where, the first phase is, when the client sends the FIN flag to the server, and in return, the server sends the ACK flag as acknowledgment. 

This can be understood by the statement below:

Client ------FIN-----> Server
Client <-----ACK------ Server

At this point, the client is in the waiting state, it is waiting for the FIN flag from the server. So, that the connection can be terminated. This state can be mentioned as FIN_WAIT_2. 

Now as we know that it works as the full-duplex mode, so if the one-side connection is broken down, then no more data can be sent from that side of the connection. But it can still receive the data from another side. 

Here, the server can send more data when the Client is in the FIN_WAIT_2 state. And once the server is done sending data, then the server will send the FIN flag to the client as the termination request, and then the client sends the ACK flag as the confirmation to terminate the connection. 

As you can see in the statement below:

Client <-----FIN------ Server
Client ------ACK-----> Server

So, as explained, in this case, steps 2 and 3 cannot be sent as one package, since they belong to two different states. 

Here four-way handshake is necessary in this case, as the first FIN flag, that is sent to the server by the client is a request for termination. And the first ACK, received by the client is just a response to FIN 1. Now here only the connection from the client is disconnected, but the server is still in a working position. This means it may still have some data to send. So, in this condition, the connection cannot be cut down suddenly. here, the other two steps are needed to be performed by the server. 

Now the other reason is that it can become difficult for both sides to define why the peer does not respond. Also, not only the offline state can cause a packet lost. Alongside, the other exceptions in the server’s processing can also lead to it. And there is another problem with this idea is that in this condition, the client will have to wait for a long time until the time is out. Here, the four-way handshake looks like a better and easier option to address these problems.

Das ist schon richtig, wie Du das angegeben hast.

Der Punkt ist: Die Verbindung ist aufgebaut. Deshalb ist in jedem Segment das ACK gesetzt. Ein FIN ohne ACK kann es also gar nicht geben.

Zudem ist ein verkürztes Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden.

oder auch anders gesagt

https://cs.stackexchange.com/questions/76393/tcp-connection-termination-fin-fin-ack-ack
A TCP implementation might send a standalone FIN in the first closing segment. However, it can  also send a FIN ACK, instead.
The latter is strictly better: the implementation can bundle a "free" ACK with the FIN segment without making it longer. This is because, if you don't ACK, there is still room in the segment for the ACK number, which will be ignored, and waste bandwidth. Hence the last-sent ACK is simply re-sent, just in case the receiver missed it.
https://www.cspsprotocol.com/tcp-connection-termination/
TCP FIN and TCP Fin Ack packets:
The sender sends TCP FIN to the receiver for an outgoing stream. The packet has a FIN flag set as another type of TCP message. The packet has a sequence number, the receiver sends the FIN Ack with one more  sequence number received in the FIN. Now the connection is closed in one direction. At this stage, the application is informed about the close of the connection.