The http encapsulation request data packet is then passed to the transport layer, and the tcp protocol part starts to operate. Here, the data packet and the TCP header are generated into a TCP message and packaged into a new data packet.
TCP message structure
Three handshake:
Before communication, a three-way handshake mechanism is used to confirm whether the connection between the two ports is available. And UDP does not need to be confirmed, directly transmitted
At the very beginning, both the client and the server are in the CLOSED state. The client actively opens the connection, and the server passively opens the connection.
At a certain moment, the client and the server need to communicate. At this time, both parties have prepared ports, and the server's port will be in the listening state, waiting for the client to connect.
How do you know the server port number?
http has been obtained in the visit url!
How do I know that the client needs to connect before the server enters the listen state?
TCP has long created the transmission control block TCB, and is always ready to accept the client's connection request. At this time, the server passively enters the listen state.
The first handshake:
The client wants to connect, creates a transmission control block TCB, and the status becomes active open. A connection request message that does not contain data content is sent to the server. The synchronization bit SYN=1 in the header of the request message, and an initial sequence number seq=x (carrying x bytes) is selected at the same time. Then the client enters the SYN-SENT (synchronization sent) state and tells the server that I want to synchronize with you. TCP stipulates that the SYN segment (the segment with SYN=1) cannot carry data, but it needs to consume a sequence number.
The second handshake:
The TCP server receives the connection request message and sends a confirmation message if it agrees to connect. In order to ensure that the seq sequence number is correct the next time the client sends a message, the confirmation number ack=x+1 needs to be sent, and the confirmation number ack must be sent ACK=1 for the confirmation number to take effect, plus the synchronization bit SYN=1, the sequence number seq=y (carrying Y bytes), and then the server also enters the SYN-RCVD (synchronization received) state to complete the synchronization connection. This message is also a SYN message and cannot carry data, but it also consumes a serial number.
The third handshake :
After receiving the confirmation, the client must send a confirmation message to the server. The confirmation message is no longer a request message SYN, and no longer contains the SYN synchronization bit. The content sent has the sequence number seq=x+1 (corresponding to the ACK of the second handshake), the confirmation number ack=y+1, and ACK=1. The client enters the ESTABLISHED (established) state after sending the confirmation message, and the server also enters the ESTABLISHED state after receiving the confirmation message. At this time, the TCP connection is established.
Then you can send the new data packet generated after TCP receives the Http data packet!
But it seems that two handshake requests can accomplish things. Why do you have to shake hands three times?
<The
main purpose is to prevent the invalid connection request message from being transmitted to the server suddenly, causing errors.
<
If it is a two handshake, assume a scenario: the client sends the first connection request message and it is not lost, but it is stuck in the network node for too long because of network problems. Since the client has not received the confirmation message for a long time, it is assumed that the server has not received it. Then send another request to connect message, at this time, the two handshake is completed smoothly all the way to establish a connection, transmit data, and close the connection. Then the request message of the previous turtle speed finally reached the server, and the connection with the server was established again, which caused unnecessary waste of resources.
<
If it is a three-way handshake, even if the turtle-speed request message finally arrives at the server, then the server also sends a connection confirmation message, but at this time the client will no longer send a confirmation message, and the server will not accept it. Confirm the message, so the connection cannot be established.
Wave four times:
After the data transmission is complete, both parties can release the connection. At the very beginning, both the client and the server are in the ESTABLISHED state, and then the client actively shuts down and the server passively shuts down.
First wave:
The client changes from the ESTABLISHED state to the actively closed state, and the client sends a request to release the connection message to the server, FIN=1, seq=u (equal to the sequence number of the last byte of the previously transmitted data plus 1), at this time The client enters the FIN-WAIT-1 (termination waiting 1) state. TCP stipulates that even if the FIN segment does not carry data, it will consume a sequence number.
Waving for the second time:
After the server receives the request release message from the client, it sends a confirmation message to tell the client that I have received your request. The content is almost seq=v, ack=u+1, ACK=1, and the server enters CLOSE at this time. -WAIT (waiting for closing) state.
Why is it CLOSE-WAIT state? Maybe there is still data on the server side that has not been sent, so at this time the entire TCP connection becomes a half-closed state. The server can still send data, and the client can also receive data, but the client can no longer send data and can only send confirmation messages.
After the client receives the confirmation message from the server, it enters the FIN-WAIT-1 (termination waiting 2) state, and waits for the server to send the connection release message (before this, it needs to accept the last data that the server has not sent. ).
Waved for the third time:
The server has sent all the data and thinks that the connection can be closed, so it sends a connection release message to the client with the content FIN=1, seq=w, ack=u+1 (the client did not send a message, so remind the client to download Once the sequence is sent from u+1), ACK=1. At this time, the server enters the LAST-ACK (last acknowledgement) state, waiting for the client to send an acknowledgement message.
Fourth wave:
The client receives the connection release message sent by the server and must send an acknowledgement. Acknowledge message seq=u+1, ack=w+1, ACK=1. At this time, the client enters the TIME-WAIT state, but it is not immediately closed. At this time, the TCP connection has not been released, and the time of 2∗∗MSL (the longest message segment life) must pass, and the client can enter the CLOSED state after withdrawing the corresponding TCB.
Because this confirmation message may be lost. The server couldn't receive the confirmation message. I thought it might be because I didn't transmit it or it was lost, so the server sent another FIN, and then the client sent another confirmation message. Then refresh the 2∗∗MSL time. Until the FIN connection release message is not received within this time, the client cancels the TCB and enters the CLOSE state.
The server immediately changes to the CLOSE state when it receives the confirmation message. So the server ends the TCP connection slightly earlier than the client.
What if the client fails after confirming the connection?
TCP has a keep-alive timer. Obviously, when the client fails, the server will not wait as if mentally retarded, and waste resources in vain. The server will refresh this keep-alive timer every time it receives a request from the client, and the time is usually set to 2 hours. If no data is received from the client for 2 hours, the server will send a probe segment every 75 minutes. If there is no data response for ten consecutive transmissions, then the server knows that the client is down and closes the connection. .
knock off
Repost the original text: cccrush_