table of Contents
●TCP three-way handshake and four waved hands
● TCP segment format
The 6 reserved bits have emergency flag URG, push flag PSH, confirmation flag ACK, reset flag RST, link synchronization flag SYN and end flag FIN.
○ Emergency sign URG(U):
Occupies 1 bit. When URG=1, it means that the urgent pointer field is valid. Notify the sender that this data segment contains urgent data and needs to be transmitted immediately. At this time, the sender will not wait until the buffer is full before sending, but will directly send the segment first.
○ Push flag PSH(P):
It occupies 1 bit. When PSH=1, it means that the current segment needs to request a push operation, that is, when the receiver TCP receives a message with the push flag bit 1, it will immediately submit it to the receiving application process without waiting. Submit after the entire cache is filled.
○ The difference between URG and PSH:
①Urgent URG inserts the urgent message field in front of the ordinary message field, while pushing PSH is to directly recreate a message with urgent data and send it out immediately;
②URG=1, which means urgent data (data starts from the serial number to the urgent Pointer to byte) directly delivered to the application process without passing through the buffer. PSH=1 means to push as soon as possible, and the data will be delivered to the buffer first, without waiting for the buffer to be filled (the default TCP/IP buffers the data to a certain upper limit before delivery From the upper layer), it will be handed over to the upper layer program;
③ URG=1 is handed over to the upper layer process only urgent data, PSH=1 is handed over to the upper layer program is the urgent data and the data in the order of the previous receiver buffer.
● TCP timer
For each connection, TCP manages four different timers: retransmission timer, persistence timer, keep-alive timer and 2MSL timer:
○ Retransmission timer
In order to prevent the loss of data segment or confirmation segment, when TCP sends the segment, it starts the retransmission timer of the specific segment. If the confirmation of the segment is received before the timer expires, it will be cancelled. Timer. If the timer has expired before the confirmation of a specific message segment is received, the message is retransmitted and the timer is reset. The most important thing here is the calculation of the timeout time. Please refer to the specific algorithm for the time. It will not be recorded here.
○ Persistent timer
Sticking to the timer is mainly to solve the deadlock problem that may be caused by the zero window size notification. At the beginning, the receiving end sent a zero window segment to the sending end. In the near future, if the buffer area of the receiving end has a certain amount of space to receive data, the receiving end will send a message segment with a non-zero window size (ie, window update) to the sending end, but this non-zero window size is The message segment is lost in the transmission process, causing the sender to be unable to receive the message segment with the non-zero window size. Therefore, the sender will always be waiting for the notification of a message with a non-zero window size. Since the receiver has sent a message segment with a non-zero window size and does not know that the message segment was lost during transmission, the receiver The end will always be in a state of waiting to receive data. If there is no measure, this deadlock situation will continue.
In order to solve the above problem, TCP has a persistence timer (also called persistence counter) for each connection. When the sender receives the zero-window confirmation, it starts the persistence timer. When the persistence timer expires, the sender sends a special segment called the probe segment. This segment has only one word. Section data. The probe segment has a serial number, but the serial number never needs to be confirmed, and even the serial number is ignored when calculating the confirmation of other parts of the data. The probe message segment reminds the receiving end that the confirmation has been lost and must be retransmitted.
The deadline of the persistence timer is set to the value of the retransmission time, but if no response from the receiver is received, another probe segment is sent, and the value of the persistence timer is doubled and reset, and the sender continues to send probes In the message segment, the value of the persistence timer is doubled and reset until the value increases to the threshold (usually 60 seconds). After that, the sender will send a segment every 60s until the window is reopened.
Adhere to the principle of the timer: When the TCP server receives a 0 sliding window message from the client, it starts a timer to count, and when the timer overflows, it queries the client whether the window has increased, and if it gets a non-zero window It restarts sending data, and if it gets a zero window, it starts a new timer to prepare for the next query.
○ Keep-alive timer
The keep-alive timer is to cope with the situation where there is no data transmission for a long time on both sides of the TCP connection. If after the client establishes a TCP connection with the server, the client causes a host failure for some reason, the server cannot receive data from the client, and the server cannot always be in a waiting state. The keep-alive timer is used to solve this questionable. Each time the server receives data from the client, it resets the keep-alive timer, which is usually 2 hours. If it does not receive the data from the client for 2 hours, the server sends a probe packet, which will be sent every 75 seconds thereafter. After sending the probe segment 10 times in a row and still not receiving a response from the client, the server considers the client to be faulty and can terminate the connection.
○ 2MSL timer
The 2MSL timer mainly solves the following two situations:
TIME_WAIT ensures that there is enough time for the opposite end to receive the ACK. If the passively closed party does not receive the ACK, it will trigger the passive end to resend the FIN. Because the last acknowledgement ACK segment is likely to be lost, the passive closing party is in the LIST_ACK state. At this time, the passive closing party will retransmit the FIN+ACK segment and actively shut down within the waiting 2MSL time The party re-receives the FIN+ACK segment retransmitted by the passive closing party. Therefore, the actively closing party will re-send the confirmation response message, thereby restarting the 2MSL timer until both parties in the communication enter the CLOSED state. If the active closing party directly releases the connection and enters the CLOSED state without waiting for a period of time in the TIME_WAIT state, then the active closing party cannot receive the retransmitted FIN+ACK segment from the passive closing party and will not send another confirmation ACK message Therefore, the passively closed party cannot enter the CLOSED state normally.
There is enough time for this connection to not be mixed with the following connections. Prevent invalid request connections from appearing in this connection. When the connection is waiting for 2MSL, any late message segment will be discarded, because the connection defined by the socket (socket is the meaning of IP and port pair, socket) waiting for 2MSL will not be able to be re-opened during this time. In this way, the delayed message segment before the old connection will not appear in the next new connection.
● TCP three-way handshake and four waved hands
○ 1~3 are the process of establishing a connection, also called the "three-way handshake". The reasons for the "three-way handshake" are:
The "failed connection request message segment" is generated in such a situation: the first connection request message segment sent by the client is not lost, but stays at a network node for a long time, resulting in delay It will not reach the server until some time after the connection is released. Originally, this is a segment that has long since expired. However, after the server receives this invalid connection request segment, it mistakes it for a new connection request sent by the client again. So it sends a confirmation segment to the client, agreeing to establish a connection. Assuming that the "three-way handshake" is not used, then as long as the server sends an acknowledgment, a new connection is established. Since the client does not send a request to establish a connection, it ignores the server's confirmation and does not send data to the server. But the server thinks that the new transport connection has been established, and has been waiting for the client to send data. In this way, a lot of server resources are wasted in vain . Using the "three-way handshake" approach can prevent the above phenomenon from happening.
○ 7~10 is the process of disconnection, also called "wave four times". The reason for waving hands "four times" is:
Waves four times because TCP is in full-duplex mode. When FIN is received, it means that no data will be sent again, but data can still be sent.
The party that first calls close() to initiate an active shutdown will enter the TIME_WAIT state. The TCP connection that enters the TIME_WAIT state requires 2MSL to return to the initial state, which means that the typical duration of TIME_WAIT is 1-4 minutes. The reason for the existence of TIME_WAIT is:
①In order to realize the reliable release of full-duplex connection like
TCP, when TCP releases the connection and waved 4 times, the ACK sent by the hypothetical initiator to connect one party (client in the figure) is lost in the network, then due to TCP's retransmission mechanism , The other party (the server in the figure) needs to resend its FIN. Before the FIN reaches the client, the client must maintain the state of this connection. In other words, the local_ip and local_port resources corresponding to this TCP connection cannot be released or reallocated immediately. The TCP connection cannot be disconnected until the retransmitted FIN is reached and the client also retransmits the ACK. If the client does not enter TIME_WAIT to maintain its connection status, when the FIN retransmitted by the server is reached, the client's TCP transport layer will respond to the other party with a RST packet, which will be considered by the other party as an error.
②In order to make the old data packets disappear due to the expiration of the network,
suppose there is no limitation of the TIME_WAIT state in the TCP protocol, and then suppose there is a TCP connection: local_ip, local_port, remote_ip, remote_port. We close it first, and then quickly establish a new connection with the same quadruple. Because the TCP protocol stack cannot distinguish the difference between the two TCP connections before and after, it may happen that the previous TCP connection was sent by the local peer. After the data arrives at the remote peer, it will be received by the TCP transport layer of the remote peer as the normal data of the current TCP connection and passed up to the application layer (in fact, in our hypothetical scenario, before these old data reach the remote peer, the old The connection has been disconnected and a new TCP connection composed of the same four-tuple has been established. Therefore, these old data should not be passed up to the application layer), causing data confusion and leading to various unpredictable strange phenomena. As a reliable transmission protocol, TCP must consider and avoid this situation at the protocol level.
In other words, after the local peer actively calls close, the TCP connection at this time enters the TIME_WAIT state. The TCP connection in this state cannot immediately establish a new connection with the same four-tuple, that is, the local port occupied by the party that initiated the active close. Cannot be reassigned during TIME_WAIT. Since the duration of the TIME_WAIT state is 2MSL, this ensures that the old data packets in the duplex link of the old TCP connection will all disappear due to expiration (over MSL). After that, a new connection can be established with the same quadruple instead of The connection data was disordered twice before and after.