Analysis & Answers
TCP(Transmission Control Protocol)
TCP is a host-to-host layer transmission control protocol that provides reliable connection services.
There are 6 types of tcp flags (bit codes):
- SYN (synchronous establishment of connection)
- ACK(acknowledgement confirmation)
- PSH (push transmission)
- FIN(finish)
- RST (reset reset)
- URG (urgent emergency)
HTTP three-way handshake:
The first time: the client sends a SYN message to the server (SYN is generally used for synchronization). At this time, the client enters the SYN_SEND state, and the server enters the SYN_RECE waiting for confirmation state.
Host A sends a bit code of syn=1 and randomly generates a data packet with seq number=x to the server. Host B knows that SYN=1, and A requests to establish a connection;
The second time: After receiving the SYN message, the server simultaneously sends a reception confirmation message to the client, along with an ACK message (for response).
Host B needs to confirm the connection information after receiving the request, and sends ack number=(x+1 of host A), syn=1, ack=1 to A, and randomly generates a packet with seq=y
The third time: The client receives the ACK message and checks whether the ACK message is correct. If it is correct, the client sends the ACK again, and the server confirms that the verification is passed after receiving it, indicating that the connection has been successfully established and the data packet can be sent.
Host A checks whether the ack number is correct after receiving it, that is, the seq number+1 sent for the first time, and whether the bit code ack is 1, if correct, host A will send ack number=(y+1 of host B), ack=1, host B confirms the seq value and ack=1 after receiving it, and the connection is successfully established.
The four disconnected waves:
Since TCP is full-duplex, each direction must be closed separately. This principle is that when one party completes the data transmission task, it can send a FIN flag to end the transmission channel. After receiving FIN, it only means There is no data flow in this direction (no data is needed to be sent), and a TCP can still send data after receiving a FIN.
The first wave: the client sends FIN to the server to tell the server that I have received what you sent and I want to close the channel. Therefore, when the active party sends a disconnection request (that is, a FIN message) to the passive party, it only means that the active party will no longer send data packets, but the active party can still receive data packets.
The second wave: the server receives the FIN from the client and sends back an ACK message (for response) to confirm receipt of the client's message. The passive party may still have corresponding data packets to send at this time, so it needs to send an ACK message first, telling the active party "I know your request to disconnect". In this way, the initiative will not continue to send disconnection requests (that is, FIN messages) because no response is received.
The third wave: the server closes the connection with the client and sends a FIN to the client. After the passive party has processed the data message, it sends the FIN message to the active party; this can ensure that the data communication is completed normally and reliably. After sending the FIN message, the passive party enters the LAST_ACK stage (timeout waiting).
The fourth time the connection is closed: the client sends back an ACK message to confirm after receiving it. If the active party sends an ACK message in time to confirm the connection interruption, then the passive party directly releases the connection and enters the available state.
Why does the TCP client have to send a confirmation at the end?
In other words, why does a tcp connection need to be carried out with three handshakes, but not two?
The establishment of the three-way handshake is mainly because A sent another confirmation, so why does A confirm again, mainly to prevent the invalid connection request segment from being suddenly transmitted to B , resulting in an error.
The so-called "invalid connection request message" is generated in this way. Under normal circumstances, A sends a connection request, but does not receive the confirmation because the connection message request is lost, so A retransmits the connection request again, and then receives the request , and received the confirmation, the connection was established, and after the data transmission was completed, the connection was released. A sent a total of two connection request segments, the first one was lost, and the second one arrived at B. There is no "expired connection However, under abnormal circumstances, the connection segment of the request message sent by A is not lost, but stays in a certain network node for a long time, so that it is delayed to reach B at a certain time after the request is released. It was originally an invalid segment, but after B received the invalid connection request segment, it mistakenly thought that A had resent the connection request segment, and sent a confirmation segment to A, agreeing to establish a connection, If there is no three-way handshake, then after B sends a confirmation, the connection is established, but at this time A does not send a request segment to establish a connection, so it ignores B's confirmation and does not send data to B, but B has been waiting A sends data, so many resources of B are wasted. Using the three-way handshake method can prevent this from happening. For example, just now, A ignores B, so it will not send confirmation to B, and B cannot receive confirmation from A. Just know that A does not require the establishment of a connection, so resources will not be wasted.
Reflect & Expand
1. Why does the client have to wait for 2MSL at the end?
MSL (Maximum Segment Lifetime), maximum segment life, TCP allows different implementations to set different MSL values.
First, ensure that the last ACK message sent by the client can reach the server, because this ACK message may be lost. From the perspective of the server, I have sent a FIN+ACK message to request disconnection, and the client is still No response was given to me. It should be that the request to disconnect the message I sent was not received, so the server will resend it again, and the client can receive the retransmitted message within this 2MSL time period, and then give A response message is sent out and the 2MSL timer is restarted.
Second, prevent "invalid connection request segments" similar to those mentioned in the "three-way handshake" from appearing in this connection. After the client sends the last confirmation message, within this 2MSL time, all message segments generated during the duration of the connection can be disappeared from the network. In this way, the request message of the old connection will not appear in the new connection. Let’s have a deep understanding of the so-called old and new connection problems here: if there is no waiting time of 2msl, then, after the active closing party enters the close state at this time, it will immediately make a tcp connection with the other party (same ip, same port). , the new connection may regard the invalid message segments of the previous old connection as its own message segments, causing confusion.
2. Why is it a three-way handshake to establish a connection and a four-way wave to close a connection?
When the connection is established, the server is in the LISTEN state, and after receiving the SYN message of the connection establishment request, it puts the ACK and SYN in one message and sends it to the client.
When the connection is closed, when the server receives the other party's FIN message, it only means that the other party no longer sends data but can still receive data, and it may not have sent all the data to the other party, so the server can close it immediately or send it. After sending some data to the other party, send a FIN message to the other party to express agreement to close the connection now. Therefore, your own ACK and FIN are generally sent separately, resulting in one more time.
3. What if the connection has been established but the client suddenly fails?
TCP also has a keep-alive timer. Obviously, if the client fails, the server cannot wait forever and waste resources. The server will reset the timer every time it receives a request from the client. The time is usually set to 2 hours. If it has not received any data from the client within two hours, the server will send a probe segment, and then every 75s Send once. If there is still no response after sending 10 probe messages in a row, the server will think that the client is faulty, and then close the connection.
Meow Interview Assistant: A one-stop solution to interview questions. You can search the WeChat applet [Meow Interview Assistant] or follow [Meow Interview Assistant] -> Interview Assistant to answer questions for free. If you have any good interview knowledge or skills, I look forward to sharing them with you!