TCP, it’s finally here!

[[394208]]

Previous articles have been talking about various network protocols, so starting from this article, I will talk to you about the various features of the TCP protocol, such as TCP connection management (which is also the main discussion of this article), TCP timeout and retransmission, TCP congestion control, TCP data flow and window management.

TCP is a connection-oriented unicast protocol. In TCP, there is no such behavior as multicast or broadcast, because the IP addresses of the sender and receiver can be clearly identified in the TCP segment.

Before sending data, the two communicating parties (i.e. the sender and the receiver) need to establish a connection. After sending the data, the two communicating parties need to disconnect. This is the establishment and termination of the TCP connection.

TCP connection establishment and termination

If you have read my previous article about the network layer, you should know that TCP has four basic elements: the sender's IP address, the sender's port number, the receiver's IP address, and the receiver's port number. Each party's IP + port number can be regarded as a socket, which can be uniquely identified. The socket is equivalent to a door, and data transmission will be carried out after leaving this door.

TCP connection establishment -> termination is divided into three stages

The focus of our discussion below is also on these three levels.

The following figure shows a very typical TCP connection establishment and closing process, which does not include the data transmission part.

TCP connection establishment - three-way handshake

The server process is ready to receive TCP connections from the outside, which is usually done by calling the bind, listen, and socket functions. This is considered a passive open. The server process is then in the LISTEN state, waiting for client connection requests.

The client initiates an active open through connect and sends a connection request to the server. The synchronization bit SYN = 1 in the request header and selects an initial sequence number sequence, abbreviated as seq = x. The SYN segment is not allowed to carry data and only consumes one sequence number. At this point, the client enters the SYN-SEND state.

After receiving the client connection, the server needs to confirm the client's message segment. In the confirmation message segment, both the SYN and ACK bits are set to 1. The confirmation number is ack = x + 1, and it also selects an initial sequence number seq = y for itself. This message segment cannot carry data, but it also consumes a sequence number. At this point, the TCP server enters the SYN-RECEIVED (synchronous received) state.

After receiving the response from the server, the client needs to confirm the connection. The ACK in the confirmation connection is set to 1, the sequence number is seq = x + 1, and the confirmation number is ack = y + 1. TCP stipulates that this segment can carry data or not. If it does not carry data, the sequence number of the next data segment is still seq = x + 1. At this time, the client enters the ESTABLISHED (connected) state

After receiving the client's confirmation, the server also enters the ESTABLISHED state.

This is a typical three-way handshake process. Through the above three segments, a TCP connection can be established. The purpose of the three-way handshake is not only to let the communicating parties know that a connection is being established, but also to use the option field in the data packet to exchange some special information and the initial sequence number.

Generally, the party that first sends a SYN message is considered to actively open a connection, and this party is usually called the client. The receiver of SYN is usually called the server, which is used to receive this SYN and send the next SYN, so this opening method is passive opening.

TCP requires three segments to establish a connection, but four segments to release a connection.

TCP disconnect - four wave data

After the transmission is completed, the communicating parties can release the connection. After the data transmission is completed, both the client host and the server host are in the ESTABLISHED state, and then enter the process of releasing the connection.

The process of TCP disconnection is as follows

The client application sends a message segment to release the connection, stops sending data, and actively closes the TCP connection. The client host sends a message segment to release the connection. The FIN bit in the header of the message segment is 1, it does not contain data, and the sequence number bit seq = u. At this time, the client host enters the FIN-WAIT-1 (termination wait 1) stage.

After the server host receives the message segment sent by the client, it sends a confirmation response message with ACK = 1 in the confirmation response message, generates its own sequence number seq = v, ack = u + 1, and then the server host enters the CLOSE-WAIT (close wait) state.

After receiving the confirmation response from the server host, the client host enters the FIN-WAIT-2 (Termination Wait 2) state, waiting for the client to send a connection release message segment.

At this time, the server host will send a disconnect message segment, in which ACK = 1, sequence number seq = v, ack = u + 1. After sending the disconnect request message, the server host enters the LAST-ACK (last confirmation) stage.

After the client receives the disconnect request from the server, it needs to respond and send a disconnect message segment. In the message segment, ACK = 1, sequence number seq = u + 1, because the client has not sent any data since the connection was disconnected, ack = v + 1, and then enters the TIME-WAIT state. Please note that the TCP connection has not been released at this time. The client must wait for a set time, that is, 2MSL, before it enters the CLOSED state. The time MSL is called the maximum segment lifespan.

After the server receives the disconnect confirmation from the client, it will enter the CLOSED state. Because the server ends the TCP connection earlier than the client, and the entire disconnection process requires sending four segments, the process of releasing the connection is also called four waves.

Any party in a TCP connection can initiate a close operation, but usually the client initiates the close operation. However, some servers, such as web servers, will also initiate a close operation after responding to a request. The TCP protocol stipulates that a close operation is initiated by sending a FIN message.

So in summary, establishing a TCP connection requires three segments, and closing a TCP connection requires four segments. The TCP protocol also supports a half-open state, although this is not common.

TCP Half-Open

The TCP connection is in a half-open state because one party of the connection closes or terminates the TCP connection without notifying the other party. In other words, two people are chatting on WeChat. You are offline but you didn't tell me. I am still gossiping with you. At this time, the connection is considered to be in a half-open state. This happens when one party in the communication is in a host crash. Damn it, my computer crashed. How can I tell you? As long as the party in the half-connected state does not transmit data, it is impossible to detect that the other party's host has been offline.

Another reason for the half-open state is that one of the communicating parties turns off the host power instead of shutting it down normally. In this case, there will be many half-open TCP connections on the server.

TCP Half Close

Since TCP supports half-open operation, we can assume that TCP also supports half-close operation. Similarly, TCP half-close is not common. TCP half-close operation means closing only one transmission direction of the data stream. Two half-close operations together can close the entire connection. Under normal circumstances, the communicating parties will send FIN segments to each other through the application to end the connection, but in the case of TCP half-close, the application will express its own idea: "I have completed the data transmission and sent a FIN segment to the other party, but I still want to receive data from the other party until it sends a FIN segment to me." The following is a schematic diagram of TCP half-close.

Let me explain the process:

First, the client host and the server host have been transmitting data. After a period of time, the client initiates a FIN message and requests to actively disconnect. After receiving the FIN, the server responds with ACK. Since the party initiating the half-close, that is, the client, still wants the server to send data, the server will continue to send data. After a period of time, the server sends another FIN message. After the client receives the FIN message and responds with ACK to the server, the connection is disconnected.

In TCP's half-close operation, one direction of the connection is closed, while the other direction is still transmitting data until it is closed. However, few applications use this feature.

Simultaneous opening and simultaneous closing

There is also a more unconventional operation, which is that two applications actively open a connection at the same time. Although this situation seems unlikely, it is possible under certain arrangements. We mainly describe this process.

Both communicating parties will first send a SYN before receiving a SYN from the other party. This scenario also requires that both communicating parties know the other party's IP address + port number.

For example, a man and a woman in love both say the sacred vow "I love you" at the same time, and then they respond to each other with a kiss, which is simultaneous opening.

The following is an example of opening at the same time

As shown in the figure above, both communicating parties actively sent a SYN message before receiving the other party's message, and both replied with an ACK message after receiving each other's message.

A simultaneous opening process requires the exchange of four segments, which is one more than the ordinary three-way handshake. Since there is no client and server in the simultaneous opening, I use the term "both communicating parties" here.

Like simultaneous opening, simultaneous closing also requires both communicating parties to make active closing requests at the same time and send FIN messages. The figure below shows a simultaneous closing process.

During the simultaneous closing process, the same number of segments need to be exchanged as in the normal closing process, but the simultaneous closing is not performed sequentially like the four waves, but is performed alternately.

Let’s talk about the initial serial number

Maybe my diagram or text description above is not professional. The initial sequence number is represented by professional terminology. The English name of the initial sequence number is Initial sequence numbers (ISN), so the seq = v we expressed above actually represents ISN.

Before sending SYN, both parties will select an initial sequence number. The initial sequence number is randomly generated, and each TCP connection will have a different initial sequence number. The RFC document states that the initial sequence number is a 32-bit counter, which increases by 1 every 4 us (microseconds). Because each TCP connection is a different instance, this arrangement is intended to prevent sequence number overlap.

When a TCP connection is established, only the correct TCP 4-tuple and the correct sequence number will be received by the other party. This also reflects the vulnerability of TCP segments being easily forged, because as long as I forge the same 4-tuple and initial sequence number, I can forge a TCP connection and interrupt the normal TCP connection. Therefore, one way to resist this attack is to use the initial sequence number, and another way is to encrypt the sequence number.

TCP State Transition

We talked about the three-way handshake and the four-way wave above, and mentioned some state transitions between TCP connections. Now I will start from the beginning and sort out the transitions between these states with you.

First, at the beginning, both the server and the client are in the CLOSED state. At this time, it is necessary to determine whether it is actively opened or passively opened. If it is actively opened, the client sends a SYN message to the server. At this time, the client is in the SYN-SEND state. SYN-SEND means waiting for a matching connection request after sending a connection request. The server is passively opened and will be in the LISTEN state to listen for SYN messages. If the client calls the close method or has no operation for a period of time, it will return to the CLOSED state. The conversion diagram of this step is as follows

Here is a question, why does the client in LISTEN state send SYN to change to SYN_SENT state?

I saw the answer from Che Xiaopang on Zhihu. This situation may occur in FTP. LISTEN -> SYN_SENT is because this connection may be triggered by the application on the server sending data to the client. The client passively accepts the connection. After the connection is established, it starts to transfer files. In other words, a server in the LISTEN state may also send a SYN message, but this situation is very rare.

The server in SYN_SEND state will receive SYN and send SYN and ACK to change to SYN_RCVD state. Similarly, the client in LISTEN state will receive SYN and send SYN and ACK to change to SYN_RCVD state. If the client in SYN_RCVD state receives RST, it will change to LISTEN state.

It would be better to look at these two pictures together.

Here we need to explain what RST is

There is a situation where the IP and port number do not match when the host receives a TCP segment. Suppose the client host sends a request, and the server host finds that it is not for this server after judging the IP and port number, then the server will send a RST special segment to the client.

Therefore, when the server sends a RST special segment to the client, it tells the client that there is no matching socket connection and please stop sending.

RST: (Reset the connection) is used to reset an error connection caused by some reason, and is also used to reject illegal data and requests. If the RST bit is received, some error usually occurs.

Failure to identify the correct IP port above is one of the situations that causes RST. In addition, RST may also occur due to request timeout, cancellation of an existing connection, etc.

The server at SYN_RCVD will receive the ACK message, and the client at SYN_SEND will receive the SYN and ACK messages and send an ACK message, thus establishing a connection between the client and the server.

One thing to note here is that I did not deliberately indicate the state of simultaneous opening above. In fact, when it is opened at the same time, its state changes are like this.

Why is this so? Because you think, when both ends are opened at the same time, the hosts at both ends initiate SYN messages, and the host that actively initiates SYN will be in the SYN-SEND state. After the sending is completed, it will wait to receive SYN and ACK. After both hosts have sent SYN + ACK, both parties are in the SYN-RECEIVED (SYN-RCVD) state, and then wait for the SYN + ACK message to arrive. Then, both parties will be in the ESTABLISHED state and start transmitting data.

Well, so far, I have described to you the state transitions during the TCP connection establishment process. Now you can make a pot of tea and drink some water, waiting for data transmission.

OK, now you have had enough water and the data transmission is complete. After the data transmission is completed, the TCP connection can be disconnected.

Now let's turn the clock forward to the moment when the server is in the SYN_RCVD state. Because it has just received a SYN packet and sent a SYN + ACK packet, the server is very happy at this time. However, at this time, the server application process is closed, and then the application process sends a FIN packet, which will cause the server to go from the SYN_RCVD -> FIN_WAIT_1 state.

Then adjust the clock to the present. The client and server have now completed data transmission. At this time, the client sends a FIN message hoping to disconnect. At this time, the client will also change to FIN_WAIT_1 state. For the server, it receives the FIN message segment and replies with an ACK message, and it will change from ESTABLISHED -> CLOSE_WAIT state.

The server in the CLOSE_WAIT state will send a FIN message and then put itself into the LAST_ACK state. The client in FIN_WAIT_1 will change to the FIN_WAIT_2 state after receiving the ACK message.

Here we need to explain the CLOSING state. The transition from FIN_WAIT_1 to CLOSING is quite special.

The CLOSING state is quite special and should be rarely seen in actual situations. It is a rare exception state. Under normal circumstances, after you send a FIN message, you should receive (or receive at the same time) the other party's ACK message first, and then receive the other party's FIN message. However, the CLOSING state means that after you send a FIN message, you did not receive the other party's ACK message, but instead received the other party's FIN message.

Under what circumstances will this happen? In fact, if you think about it carefully, it is not difficult to draw the conclusion: if both parties close a link at the same time, then FIN messages will be sent at the same time, that is, the CLOSING state will appear, indicating that both parties are closing the connection.

After a client in FIN_WAIT_2 state receives a FIN + ACK message from the server host and sends an ACK response, it will change to TIME_WAIT state. A client in CLOSE_WAIT state will be in LAST_ACK state after sending a FIN.

Although many diagrams and blogs here show that the LAST_ACK state will be reached only after the FIN + ACK message is drawn in the diagram, when describing it, usually only the FIN is described. In other words, the LAST_ACK state will be reached only after the CLOSE_WAIT sends the FIN.

So the state of FIN_WAIT_1 -> TIME_WAIT here is the state that the client is in after receiving FIN and ACK and sending ACK.

If the client in the CLOSINIG state still receives ACK at this time, it will continue to be in the TIME_WAIT state. It can be seen that the TIME_WAIT state is equivalent to the last state of the client before closing, which is an active closing state; and LAST_ACK is the last state of the server before closing, which is a passive opening state.

There are several special states above, which we will explain here.

TIME_WAIT state

After the two communicating parties establish a TCP connection, the party that actively closes the connection will enter the TIME_WAIT state. The TIME_WAIT state is also called the 2MSL waiting state. In this state, TCP will wait for twice the Maximum Segment Lifetime (MSL) time.

Here we need to explain MSL

MSL is the maximum expected lifetime of a TCP segment, that is, the longest time it exists in the network. This time is limited, because we know that TCP relies on IP data segments for transmission. There are TTL and hop count fields in IP datagrams. These two fields determine the lifetime of IP. Generally, the maximum lifetime of TCP is 2 minutes, but this value can be modified according to different operating systems.

Based on this, let's explore the TIME_WAIT state.

When TCP performs an active close and sends the final ACK, TIME_WAIT should exist for 2 * maximum lifetime, so that TCP can resend the final ACK to avoid loss. The final ACK is resent not because TCP retransmits the ACK, but because the other party retransmits the FIN. The client often sends back FIN because it needs an ACK response to close the connection. If the lifetime exceeds 2MSL, the client will send RST, causing the server to fail.