TCP works at the transport layer of the network protocol stack. The data transmitted on this layer is called Segment.
The data of our application will first be packaged into the transport layer, which will then be handed over to the lower Internet layer, and then to the lower data link layer
There are four things in the above picture is very important:
Serial number: used to solve the problem of data packets not being out of order during network transmission
Confirmation number: Solve the problem of no packet loss
TCP flag (URG, ACK, PSH, RST, SYN, FIN): It is the type of packet and is used to control the TCP state machine
Window: used to solve flow control (i.e. sliding window)
Note:
TCP FLAG flags
TCP flags and their meanings are listed below:
F: FIN - end; end session
S: SYN - synchronization; indicates a request to start a session
R: RST - reset; interrupt a connection
P: PUSH - push; packet sent immediately
A: ACK - response
U: URG - urgent W: CWR - Congestion Window Reduction
E: ECE - Explicit Congestion Alert Response
TCP connection:
For the 3-way handshake to establish the link,
1. To enable each party to know the existence of the other party
2. Allow both parties to negotiate some parameters
(1) Mainly to initialize the initial value of the serial number. Both parties in the communication must inform each other of their initialization sequence numbers (Sequence Number) - so it is called SYN, the full name is Synchronize Sequence Numbers. That’s x and y in the picture above. This number should be used as the sequence number for future data communications to ensure that the data received by the application layer will not be out of order due to transmission problems on the network (TCP will use this sequence number to splice the data
(2) Maximum window value
(3) Whether to use the window expansion option (occupies 3 bytes, 1 byte of which represents the shift value S, the new window value is equal to the 16-bit window number in the TCP header plus S, That is (16+S), the maximum allowed value of the shift value is 14, which is equivalent to increasing the maximum value of the window to 2(16+14)-1=230-1)
是否使用时间戳选项(计算往返时间RRT；处理TCP序号超过2^32的情况，会在报文中加上这种时间戳)
3. Able to allocate transportation entity resources (such as cache size)
A TCP connection requires four tuples to represent the same connection, that is, TCP connection::={socket1,socket2}={(IP1:port1),(IP2:port2)}
Where socket socket=(IP address: port number)
Each TCP connection is uniquely identified by the two endpoints (i.e. sockets) at both ends of the communication.
The end that sends the first SYN will perform an active open, and the other end that receives this SYN and sends back the next SYN will perform a passive open. In addition, TCP's handshake protocol is carefully designed to handle simultaneous opens, for which it only establishes one connection instead of two. Therefore, a connection can be initiated by either or both parties, and once the connection is established, data can flow peer-to-peer in both directions without a so-called master-slave relationship. (After the connection is established, TCP will no longer ignore another connection request.) After the TCP connection is established, data streams can be transmitted in both directions.
A question that needs attention is why is there a third handshake?
The TCP connection adopts the client-server mode. The application process that actively initiates the connection is the client, and the application process that passively waits for the connection request is the server.
Assume that host A is the client and host B is the server. When A sends a connection establishment request to B, B does not receive the request due to some reasons (such as a node staying in the network for a long time). However, the message is not lost. After the timeout, A will resend the request to establish a connection. B receives it and establishes a connection with A. After the data transmission is completed, the connection will be closed. After that, B receives the first message sent before. To establish a connection request (we call it an expired connection request segment), B will think that A has initiated a connection request again, so it will send a confirmation segment to A. If there is no third handshake at this time, B will think that the connection is established, and will wait for A to send data, but A will not send data, so B will waste resources. But if there is a third handshake, when B sends a confirmation message segment to A, A will not pay attention to B's confirmation message. At this time, B will not think that the connection has been established and wait for A to send data.
Something else to note is:
When the client sends a connection establishment request to the server, SYN=1, and selects a sequence number seq=x. TCP stipulates that the SYN segment (that is, the segment with SYN=1) cannot carry data, but it also consumes a Serial number. After B receives the connection request message, if it agrees to the connection, it sends a confirmation to A. In the confirmation message, both SYN and ACK are set to 1. The confirmation number is ack=x+1, and it also chooses one for itself. Sequence number seq=y, this message cannot carry data, and also consumes a sequence number. At this time, after the client receives the confirmation from the server, when it performs the third handshake, the ACK is also set to 1, and the confirmation number ack=y +1, sequence number seq=x+1, TCP stipulates that ACK messages can carry data. If it does not carry data, the sequence number will not be consumed. The sequence number of the next data segment is still seq=x+1.
TCP disconnection:
When the TCP application process no longer has data to send, it sends a shutdown command. TCP closes its own data flow by sending a data piece with the control bit FIN=1 (TCP stipulates that the FIN segment also consumes a sequence number), but it can continue to receive data until the other party closes the data flow in that direction and connects Just close.
It takes 4 waves to terminate a connection, which is caused by TCP's half-close. Because a TCP connection is full-duplex (that is, data can be transferred in both directions simultaneously), each direction must be closed independently. The principle of closing is that when one party completes its data sending task, it can send a FIN to terminate the connection in this direction. When one end receives a FIN, it must notify the application layer that the other end has terminated data transfer in that direction. Sending a FIN is usually the result of a shutdown performed by the application layer.
If both sides disconnect at the same time, it will enter the CLOSING state and then reach the TIME_WAIT state.
The party that actively initiates the release of the connection will enter the TIME_WAIT (time waiting) state. The TCP connection has not yet been released, and 2MSL (maximum message life) must pass before A enters the CLOSED state.
Reasons for setting TIME_WAIT:
In order to ensure that the last confirmation message sent by the client is received by B, this confirmation message may be lost. If the server cannot receive the message, it will time out and retransmit the FIN+ACK message. At this time, the client The 2MSL timer will be restarted, and the client will re-send the confirmation message to the server. When the server receives the final confirmation message, both the client and the server will enter the CLOSED state normally. Otherwise, if there is no TIME_WAIT, the server will May not enter CLOSED state normally
TCP also has a keep-alive timer. If the host fails after the client connects to the server, the server will no longer be able to receive the data sent by the client. But the server can't wait forever, right? This will waste a lot of resources
Every time the server receives data from the client, it will update the keep-alive timer. The time setting is usually two hours. If no data from the client is received after two hours, a detection segment will be sent. Every time Sent once every 75 minutes. If the client does not respond after 10 consecutive attempts, the client is considered to have exited and the server releases the connection.
From the perspective of one party's TCP, there are three situations when the connection is closed:
- The other party starts and shuts down
When TCP receives the FIN message from the other party, it sends an ACK to confirm the FIN message and notify the application process that the connection is being closed. The application process will respond with a shutdown command. After TCP sends the unprocessed message segment, it sends a FIN message to the other party TCP, then waits for the other party's confirmation of the FIN, and closes the connection after receiving the confirmation. If the other party's confirmation does not arrive in time, the connection will be closed after waiting for a period of time.
2. Start and shut down on our own side
After receiving the shutdown command of its own application process, TCP sends the message segment with FIN = 1 to the other party after sending the unprocessed message segments, and TCP no longer accepts data transmission from its own application process. Data bytes sent before FIN, including FIN, require confirmation from the other party, otherwise they will be retransmitted. Note that FIN also occupies a sequence number. Once it receives the other party's confirmation of the FIN and the other party's FIN message segment, the local TCP will confirm the FIN, wait for a period of time, and then close the connection. The purpose of waiting is to prevent the loss of the confirmation message from the other party and to prevent the other party's retransmission message from interfering with the new connection.
- Both sides start and shut down at the same time
If the application processes on both sides of the connection send shutdown commands at the same time, the TCPs of both parties will send FIN messages after sending the unprocessed message segments. After all TCP messages sent before the FIN are confirmed, it sends an ACK to confirm the FIN it received. After receiving the other party's confirmation of FIN, each party also waits for a period of time before closing the connection. This is called simultaneous close.
TCP state machine:
In fact, transmission on the network is not connected, including TCP. The so-called "connection" of TCP is actually just maintaining a "connection state" on both sides of the communication, making it look like there is a connection. Therefore, TCP state transition is very important. Both ends of TCP maintain a state machine respectively. The state machine transitions of active initiation/passive initiation and active closing/passive closing of TCP connections are different.
The operation of the TCP protocol can be represented by a finite state machine (Finite State Machine) with 11 states.
Every connection starts in the CLOSED state. When a party executes the passive connection primitive (LISTEN) or the active connection primitive (CONNECT), it will leave the CLOSED state. Either party can first request to release the connection. When the connection is released, the status returns to CLOSED.
The above picture can be compared with the second picture in this article for analysis
- normal state transition
The server first executes the LISTEN primitive to enter the passive open state (LISTEN) and waits for the client to connect;
When an application on the client issues a CONNECT command, the local TCP entity creates a connection record for it and marks it in the SYN SENT state, and then sends a SYN segment to the server;
The server receives a SYN segment, and its TCP entity sends an acknowledgment ACK segment to the client and a SYN signal at the same time, entering the SYN RCVD state;
When the client receives the SYN + ACK segment, its TCP entity sends the last ACK segment of the three-way handshake to the server and transitions to the ESTABLISHED state;
The server receives the confirmed ACK segment, completes the three-way handshake, and enters the ESTABLISHED state.
In this state, both parties can freely transmit data. When an application completes its data transfer task, it needs to close the TCP connection. It is assumed that the client still initiates the active closing of the connection.
The client executes the CLOSE primitive, and the local TCP entity sends a FIN segment and waits for response confirmation (enters state FIN WAIT 1);
The server receives a FIN segment, confirms the client's request, sends back an ACK segment, and enters the CLOSE WAIT state;
When the client receives the confirmation ACK segment, it moves to the FIN WAIT 2 state. At this time, the connection is disconnected in one direction;
After the server-side application is notified, it also executes the CLOSE primitive to close the connection in the other direction. Its local TCP entity sends a FIN segment to the client and enters the LAST ACK state, waiting for the last ACK confirmation segment;
The client receives the FIN segment and confirms it, and enters the TIMED WAIT state. At this time, the connections between both parties have been disconnected, but TCP has to wait for a maximum Segment Lifetime of 2 times MSL (Maximum Segment Lifetime) to ensure that all connections on the connection All groups disappear to prevent acknowledgment loss. When the timer times out, TCP deletes the connection record and returns to the initial state (CLOSED).
When the server receives the last confirmation ACK segment, its TCP entity releases the connection, deletes the connection record, and returns to the initial state (CLOSED).
2. Open at the same time:
Although extremely unlikely, it is possible for two applications to perform active openings on each other at the same time. Each party must send a SYN, and these SYNs must be passed to the other party. This requires each party to use a port that is well known to the other party as the local port. For example, an application in Host A uses local port 7777 and performs an active open with Host B's port 8888. The application in Host B uses local port 8888 and performs an active open with Host A's port 7777. TCP is specifically designed to handle simultaneous opens, for which it establishes only one connection instead of two (other protocol families, most notably the OSI transport layer, will establish two connections instead of one in this case connect).
When simultaneous opening occurs, both ends send SYN almost at the same time and enter the SYN_SENT state. When each end receives a SYN, the status changes to SYN_RCVD, and they both send SYN again and acknowledge the received SYN. When both parties receive SYN and corresponding ACK, the status changes to ESTABLISHED. The following figure shows these state transition processes.
A simultaneously opened connection requires the exchange of 4 segments, one more than the normal three-way handshake. Also, note that we do not refer to either end as client or server, as each end is both a client and a server.
- Also close:
Under normal circumstances, one party (usually but not always the client) sends the first FIN to perform active closing, but it is also possible for both parties to perform active closing, and the TCP protocol also allows such simultaneous closing.
When the application layers at both ends issue shutdown commands at the same time, both ends change from ESTABLISHED to FIN_WAIT_1. This will cause each party to send a FIN, and the two FINs will arrive at the other end after being transmitted through the network. After receiving FIN, the status changes from FIN_WAIT_1 to CLOSING, and the final ACK is sent. When the final ACK is received, the status changes to TIME_WAIT. The following figure summarizes these status changes. It can be seen from the figure that simultaneous shutdown and normal shutdown use the same number of segment exchanges.
About SYN timeout when establishing a connection
If the server receives the SYN sent by the client and replies with SYN-ACK, then the client is disconnected, and the server does not receive the ACK from the client, then the connection is in an intermediate state, that is, it is neither successful nor failed. Therefore, if the server does not receive TCP within a certain period of time, it will resend SYN-ACK. Under Linux, the default number of retries is 5, and the retry interval starts from 1s. The retry interval of 5 times is 1s, 2s, 4s, 8s, 16s, a total of 31s, and the fifth time After sending it, you still have to wait 32 seconds to know that the fifth time has also timed out. Therefore, it takes a total of 1s + 2s + 4s + 8s + 16s + 32s = 2^6 -1 = 63s before TCP will disconnect the connection.
About the initialization of ISN
ISN cannot be hard coded, otherwise problems will occur - for example: if the ISN is always used as 1 after the connection is established, if the client sends 30 segments, but the network is disconnected, then the client reconnects and uses the ISN again. 1 does ISN, but the previously connected packets arrive, so they are regarded as newly connected packets. At this time, the client's Sequence Number may be 3, and the server thinks that the client's Sequence Number is 30. All chaos. RFC793 says that the ISN will be tied to a fake clock. This clock will add one to the ISN every 4 microseconds until it exceeds 2^32 and starts from 0 again. In this way, the period of an ISN is approximately 4.55 hours. Because we assume that the survival time of our TCP Segment on the network will not exceed the Maximum Segment Lifetime (abbreviated as MSL), so as long as the value of MSL is less than 4.55 hours, then we will not reuse the ISN.
About MSL and TIME_WAIT
We noticed that in the TCP state diagram, there is a timeout setting from the TIME_WAIT state to the CLOSED state. This timeout setting is 2*MSL (RFC793 defines MSL as 2 minutes, and Linux sets it to 30s). Why is there TIME_WAIT? ? Why not just transfer it to CLOSED state? There are two main reasons: 1) TIME_WAIT ensures that there is enough time for the peer to receive the ACK. If the passively closed party does not receive the Ack, it will trigger the passive end to resend Fin, with exactly 2 MSLs coming and going. 2) There is enough time so that this connection will not be mixed with subsequent connections (you have to know that some self-initiated routers will cache IP data packets. If the connection is reused, then these delayed packets may be received. will be mixed with new connections)
Too many TIME_WAIT numbers
TIME_WAIT is a very important state, but if there are large concurrent short links, there will be too many TIME_WAITs, which will also consume a lot of system resources.