The Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream based transport layer communication protocol, which operates in the transport layer of the OSI seven-layer model. It is a specialized transport protocol designed to provide a reliable end-to-end byte stream over unreliable interconnected networks.
client server
Active Open → SYN=1,seq=x → Passive Open, Received
(SYN Sent) (SYN Received)
Received ← SYN=1,ACK=1,seq=y,ack=x+1 ← Sent
(Link Established) (SYN Received)
Sent → ACK=1,seq=x+1,ack=y+1 → Received
(Link Established) (Link Established)
- First Handshake: The client actively initiates the connection to the server, sends the initial sequence number
seq=xwith theSYN=1synchronization request flag, and enters the SYN_SENT state, waiting for server confirmation. - Second Handshake: After receiving the message, the server sends the acknowledgment flag
ACK=1and the synchronization request flagSYN=1, along with its own sequence numberseq=yand the client's acknowledgment numberack=x+1. At this point, the server enters the SYN_RECEIVED state. - Third Handshake: After receiving the message, the client sends the acknowledgment flag
ACK=1, its own sequence numberseq=x+1, and the server acknowledgment numberack=y+1. Upon sending, the connection is confirmed to be in the ESTABLISHED state. The server, upon receiving the confirmation information, enters the ESTABLISHED state.
- First Handshake: Client: "Hey, buddy, do you want to hang out later? Can you see my message? If so, give me a sign and let me know that I have the ability to send messages."
- Second Handshake: Server: "Got it, where do you want to go? I received your message, you have the ability to send messages. How about sending me a message back so that I can also confirm that I have the ability to send messages?"
- Third Handshake: Client: "Let's go fishing in the river and then pick some fruits on the mountain. I also got your message. Your ability to send messages is fine. Both of us have the ability to send messages, so we can have a great time."
Both sides need to wait for the other party to agree and return the confirmation. Once one party requests and receives the acknowledgment packet, it means that the network is reachable and the other party agrees to establish the connection. The final model is
A --Request--> B
A <--Acknowledgment-- B
A <--Request-- B
A --Acknowledgment--> B
The middle two steps can be returned together, hence the three-way handshake.
Taken from Zhihu@Manistein
client server
active close → FIN=1,seq=u → passive close, receive
(termination wait 1) (close wait)
receive ← ACK=1,seq=v,ack=u+1 ← send
(termination wait 2) (close wait)
receive ← FIN=1,ACK=1,seq=w,ack=u+1 ← send
(time wait) (last confirmation)
send → ACK=1,seq=u+1,ack=w+1 → receive
(time wait 2MSL close) (close)
- First Handshake: The client sends the release identification
FIN=1, its own sequence numberseq=u, and enters the termination waitFIN-WAIT-1state. - Second Handshake: After receiving the message, the server sends the
ACK=1confirmation flag and the client's acknowledgment numberack=u+1, its own sequence numberseq=v, and then enters a close waitCLOSE-WAITstate. After receiving this message, the client enters the termination waitFIN-WAIT-2state. - Third Handshake: The server sends the release identification
FIN=1signal, confirmation flagACK=1, acknowledgment numberack=u+1, its own sequence numberseq=w, and enters the last confirmationLAST-ACKstate. - Fourth Handshake: After receiving the reply, the client sends the confirmation flag
ACK=1, acknowledgment numberack=w+1, its own sequence numberseq=u+1, and enters the time waitTIME-WAITstate. After the expiration of2maximum segment lifetimes, the clientCLOSES. The server immediately enters theCLOSEstate upon receiving the acknowledgment.
The TCP connection handshake is performed using sequence numbers, which are seq. TCP requires the seq sequence number for reliable retransmission or reception and to avoid the inability to distinguish whether seq is delayed or from an old connection when reusing a connection. Therefore, a three-way handshake is necessary to agree and determine the initial seq sequence numbers of both parties, thus ensuring the completion of synchronized confirmation of sequence numbers.
If a two-way handshake were to occur, as follows, the client sends the initial sequence number seq=x to the server. The server, upon receiving the message, sends the acknowledgment flag ACK=1, acknowledgment number ack=x+1, and its own sequence number req=y. At this point, the server believes the connection is established, and upon receiving the message, the client also believes the request is established.
Considering the scenario of network data delay, if the client initiates a connection, and the packet becomes blocked in the network, and the client re-initiates the request. At this point, the packet changes the routing path and reaches the server. The server then believes the connection is established and sends the packet back to the client. After completing data communication, the connection is closed. Subsequently, the delayed packet from the client finally reaches the server. Because of the two-way handshake, the server believes the connection is established and sends an acknowledgment flag to the client. However, the client deems the sequence number invalid and does not establish the connection, leading to wastage of server resources as a connection that should not have been established is.
Back in class, the teacher gave the example of the red and blue army problem, also known as the two-army problem. From the perspective of communication reliability, there's no absolutely reliable protocol.
On the two ends of the mountain are Red Army 1 and Red Army 2, and the Blue Army is on the mountain. Red Army 1 and 2 are not opponents of the Blue Army. The only way to defeat the Blue Army is to attack together. So Red Army 1 and 2 need to communicate with each other to determine when to attack.
Red Army 1's messenger successfully sneaks across the mountain and tells Red Army 2 that they should attack at twelve noon the next morning.
Red Army 2 agrees, but Red Army 1 is not sure if Red Army 2 received the message. Recklessly attacking will surely fail, so Red Army 2's messenger needs to cross the mountain and tell Red Army 1 that the message has been received.
Red Army 1 receives the confirmation from Red Army 2, but now Red Army 2 doesn't know if Red Army 1 received their confirmation. So Red Army 1's messenger needs to cross the mountain and tell Red Army 2 that the confirmation has been received.
Red Army 2 receives the confirmation from Red Army 1, but now Red Army 1 doesn't know if Red Army 2 received their confirmation. So Red Army 2's messenger needs to cross the mountain and tell Red Army 1 that the confirmation has been received.
......
The two-army problem ultimately falls into a deadlock, indicating that an agreement can never be reached perfectly, and there's no completely reliable communication protocol. As a reliable transmission control protocol, TCP needs to ensure the reliable transmission of data while improving transmission efficiency. When the three-way handshake is completed, a very considerable level of reliability and transmission efficiency is already achieved. Continuing the handshake can indeed further improve the connection's reliability, but just like the curve of a logarithmic function, as the number of handshakes increases, the increase in reliability is not significant. In fact, in relation to the consumption of efficiency, multiple handshakes are detrimental to data transmission.
Establishing a connection requires three-way handshake, but closing a connection requires a four-way handshake
When establishing a connection, when the server is in the LISTEN state and receives a connection request in the form of a SYN packet, it sends an ACK and SYN together in one packet to the client. However, when closing a connection, when the server receives a FIN packet from the other party, it means that the other party will no longer send data but can still receive it. At this point, the server may not have sent all of its data to the other party, so the server can either immediately close the connection or send some data to the other party first and then send a FIN packet to indicate agreement to close the connection. Therefore, the server's ACK and FIN are generally sent separately, resulting in an additional step.
MSL stands for Maximum Segment Lifetime, and TCP allows different implementations to set different MSL values.
First, to ensure that the last ACK packet sent by the client can reach the server. Because this ACK packet may be lost, from the server's perspective, it has sent the FIN+ACK packet to request the disconnection, but the client has not responded, indicating that it may not have received the disconnection request packet sent by the server. As a result, the server will resend the disconnection request, and the client can receive this retransmitted packet within the 2MSL time frame, then respond and restart the 2MSL timer.
Second, to prevent the occurrence of invalid connection request packets in the current connection. After sending the last acknowledgment packet, the client can allow all segments generated in the time of this 2MSL to disappear from the network. Thus, in the new connection, there won't be any request packets from the old connection.
https://github.com/WindrunnerMax/EveryDay
https://www.zhihu.com/question/24853633
https://www.cnblogs.com/jainszhang/p/10641728.html
https://blog.csdn.net/jun2016425/article/details/81506353
https://blog.csdn.net/qq_38950316/article/details/81087809