Table of contents
TCP is basically the opposite of UDP. To establish a connection and disconnect a connection, a handshake is required first. In the process of data transmission, various algorithms are used to ensure the reliability of data. Of course, the problem is that it is less efficient than UDP.
head
From this figure, we can see that the TCP header is much more complicated than the UDP header.
For the TCP header, the following fields are important
Sequence number, this sequence number ensures that the packets transmitted by TCP are in order, and the opposite end can splicing packets through the sequence number sequence
Acknowledgement Number, this serial number indicates the number of the next byte that the data receiver expects to receive, and also indicates that the data of the previous serial number has been received
Window Size, the window size, indicates how many bytes of data can be received for flow control
- identifier
- URG=1: This field is one, indicating that the data part of this datagram contains emergency information, which is a high-priority datagram, and the emergency pointer is valid at this time. The urgent data must be located at the front of the data part of the current data packet, and the urgent pointer indicates the tail of the urgent data.
- ACK=1: If this field is one, it means the acknowledgment number field is valid. In addition, TCP also stipulates that all segments transmitted after the connection is established must have ACK set to one.
- PSH=1: If this field is one, it means that the receiver should push the data to the application layer immediately, instead of waiting until the buffer is full before submitting.
- RST=1: This field is one, indicating that the current TCP connection has a serious problem, and the TCP connection may need to be re-established. It can also be used to reject illegal message segments and reject connection requests.
- SYN=1: When SYN=1, ACK=0, it means that the current segment is a connection request message. When SYN=1 and ACK=1, it means that the current segment is a response message that agrees to establish a connection.
- FIN=1: If this field is one, it indicates that this segment is a request to release the connection.
state machine
The state machine of TCP is very complex and is closely related to the handshake when establishing a disconnection. Next, we will describe the next two handshakes in detail.
Before this, you need to understand an important performance indicator RTT. This metric indicates the round-trip time required by the sender from sending data to receiving data from the peer.
Establish connection three-way handshake
First, it is assumed that the end that actively initiates the request is called the client, and the end that is passively connected is called the server. Whether it is a client or a server, after the TCP connection is established, it can send and receive data, so TCP is a full-duplex protocol.
Initially, both ends are in CLOSED state. Before communication begins, both parties create a TCB. After the server creates the TCB, it enters the LISTEN state, and then starts to wait for the client to send data.
first handshake
The client sends a connection request segment to the server. This segment contains its own data communication initial sequence number. After the request is sent, the client enters the SYN-SENT state.
second handshake
After the server receives the connection request segment, if it agrees to the connection, it will send a response, and the response will also contain its own data communication initial sequence number. After the transmission is completed, it will enter the SYN-RECEIVED state.
third handshake
When the client receives the connection consent response, it also sends a confirmation message to the server. After the client sends this segment, it enters the ESTABLISHED state, and the server also enters the ESTABLISHED state after receiving the response. At this time, the connection is successfully established.
PS: Data can be included in the third handshake, which can be achieved through fast open (TFO) technology. In fact, as long as the handshake protocol is involved, a method similar to TFO can be used. The client and the server store the same cookie, and the cookie is issued during the next handshake to reduce RTT.
Because this is to prevent an invalid connection request segment from being received by the server, resulting in an error.
The following scenario can be imagined. The client sends a connection request A, but the timeout is caused by network reasons. At this time, TCP will start the timeout retransmission mechanism to send a connection request B again. At this point, the request arrives at the server successfully, the server establishes the request after responding, and then releases the connection after receiving the data.
Assuming that the connection request A finally arrives at the server after the two ends are closed at this time, then the server will think that the client needs to establish a TCP connection again, thus responding to the request and entering the ESTABLISHED state. But the client is actually in the CLOSED state, which will cause the server to wait all the time, resulting in a waste of resources.
PS: When establishing a connection, if either end is disconnected, TCP will retransmit the SYN packet, generally retries five times, and may encounter a SYN Flood attack during connection establishment. In this case you can choose to reduce the number of retries or simply reject the request if it cannot be processed.
Disconnect the four-way handshake
TCP is full-duplex, and both ends need to send FIN and ACK when disconnecting.
first handshake
If client A thinks the data transmission is complete, it needs to send a connection release request to server B.
second handshake
After B receives the connection release request, it will tell the application layer to release the TCP connection. Then it will send an ACK packet and enter the CLOSE_WAIT state, which indicates that the connection between A and B has been released, and the data sent by A is no longer received. But because the TCP connection is bidirectional, B can still send data to A.
third handshake
If B still has unfinished data at this time, it will continue to send, and after completion, it will send a connection release request to A, and then B will enter the LAST-ACK state.
PS: The second and third handshakes can be combined to delay the sending of the ACK packet by delaying the acknowledgment technique (usually with a time limit, otherwise the other party will mistakenly believe that retransmission is required).
fourth handshake
After receiving the release request, A sends a confirmation response to B, and A enters the TIME-WAIT state at this time. This state will last for 2MSL (maximum segment lifetime, which refers to the time that the message segment survives in the network, and the timeout will be discarded) time. If there is no retransmission request from B within this time period, it will enter the CLOSED state. When B receives the acknowledgment, it also enters the CLOSED state.
Why does A enter the TIME-WAIT state and wait 2MSL before entering the CLOSED state?
In order to ensure that B can receive the confirmation response from A. If A directly enters the CLOSED state after sending the confirmation response, if the confirmation response has not arrived due to network problems, it will cause B to not be shut down normally.
ARQ protocol
ARQ protocol is also a timeout retransmission mechanism. The correct delivery of data is ensured by the confirmation and timeout mechanism. The ARQ protocol includes two protocols: stop-waiting ARQ and continuous ARQ.
stop waiting for ARQ
normal transmission process
As long as A sends a message to B, it must stop sending and start a timer, wait for the response from the peer end, and cancel the timer and send the next message after receiving the response from the peer end within the timer time.
Message lost or error
Packet loss may occur during packet transmission. At this time, if the time set by the timer exceeds the time set by the timer, the lost data will be sent again until the peer responds, so it is necessary to back up the sent data every time.
Even if the packet is normally transmitted to the peer end, there may be an error in the packet during transmission. At this time, the peer end will discard the packet and wait for the A-end to retransmit.
The time set by the general timer will be greater than the average time of an RTT.
ACK timed out or lost
Replies transmitted by the peer may also be lost or timed out. Then, the A-side will still retransmit the packet after the timer expires. At this time, when the B end receives the message with the same sequence number, it will discard the message and retransmit the response until the A end sends the next sequence number message.
In the case of timeout, the response may arrive very late. At this time, the A side will determine whether the sequence number has been received. If it has been received, it only needs to discard the response.
From the above description, you can definitely find that this is definitely not an efficient way. Assuming that in a good network environment, it is definitely unacceptable to wait for a while every time data is sent. So since we can't accept this not-so-efficient protocol, let's move on to learning about a relatively efficient protocol.
Continuous ARQ
In continuous ARQ, the sender has a sending window and can continue to send the data in the window without receiving a response, which reduces the waiting time and improves the efficiency compared to stopping waiting for the ARQ protocol.
Accumulated confirmation
In continuous ARQ, the receiver will continue to receive packets. It would be a waste of resources to send an acknowledgment when it stops waiting for a packet to be received in ARQ. By accumulating acknowledgments, one reply message can be uniformly replied after receiving multiple messages. The ACK flag in the message can be used to tell the sender that all data before this sequence number has been received, and please send the data after this sequence number next time.
But cumulative confirmation also has a drawback. When receiving messages continuously, it may encounter that after receiving the message of sequence number 5, the message of sequence number 6 is not received, but the message of sequence number 7 and later has been received. In this case, the ACK can only reply 6, which will cause the sender to repeatedly send data.