TCP is a connection-oriented unicast protocol. In TCP, there is no multicast or broadcast because the IP address of the sender and receiver can be specified in the TCP packet segment.

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

Establishing and terminating a TCP connection

If you read my previous article on the network layer, you know that there are four basic elements of TCP: the IP address of the sender, the port number of the sender, the IP address of the receiver, and the port number of the receiver. The IP + port number of each party can be regarded as a socket, and the socket can be uniquely identified. The socket is like a door, out of which data is transferred.

TCP connection establishment -> termination is divided into three phases

The following discussion focuses on these three levels.

The following figure shows a typical TCP connection setup and closure process, excluding data transfer.

TCP establishes a connection – three-way handshake

  1. The server process is ready to receive TCP connections from the outside. Usually, it calls the bind, LISTEN, and socket functions to do this. This mode of opening is considered to bePassive open. Then the server process is inLISTENStatus waiting for a client connection request.
  2. Client passconnectinitiateActive openSends a connection request to the server with SYN = 1 at the beginning and an initial sequence number (seq = x). The SYN packet segment does not carry data and consumes only one sequence number. At this point, the client entersSYN-SENDState.
  3. After receiving the connection from the client, the server needs to confirm the packet segment of the client. Set both the SYN and ACK bits to 1 in the acknowledgment packet segment. The confirmation number is ACK = x + 1 and the initial number is seq = y. This message segment also cannot carry data, but again consumes a sequence number. At this point, the TCP server entersSyn-received (Synchronously RECEIVED)State.
  4. After receiving the response from the server, the client also needs to confirm the connection. Confirm that the ACK in the connection is set to 1, the sequence number is seq = X + 1, and the confirmation number is ACK = Y + 1. According to TCP, this packet segment may or may not carry data. If no data is carried, the sequence number of the next data packet segment is still seq = X + 1. At this point, the client entersESTABLISHEDstate
  5. After receiving the customer’s confirmation, the server also logs inESTABLISHEDState.

This is a typical three-way handshake. A TCP connection can be established through the preceding three packet segments. The purpose of the three-way handshake is not only to let the communication parties know that a connection is being established, but also to exchange special information using the option fields in the packet, exchanging initial serial numbers.

The first party to send a SYN packet is considered to open a connection, and this party is also called the client. The recipient of the SYN is usually called the server, and it is used to receive this SYN and send the SYN below, so it is opened passively.

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

TCP disconnects – Four waves

After the data transfer is complete, the communication parties can release the connection. After the data transfer is complete, both the client and server hosts are in the ESTABLISHED state, and the connection is released.

The procedure for TCP disconnection is as follows

  1. The client application sends a packet to release the connection, stops sending data, and actively closes the TCP connection. The client host sends a packet to release the connection. The FIN position in the header of the packet is 1, which does not contain data, and the sequence number bit is SEq = U. In this case, the client host enters the fin-WaI-1 phase.

  2. After receiving the packet segment from the client, the server host sends an acknowledgement packet, in which ACK = 1 is generated and its serial number seq = V, ACK = U + 1 is generated. Then the server host enters close-wait state.

  3. After receiving the acknowledgement from the server host, the client host enters the FIN-WaIT-2 state. Waiting for the client to send a packet to release the connection.

  4. In this case, the server host sends the disconnected packet segment, in which ACK = 1, sequence number SEq = V, ACK = U + 1 is sent. After sending the disconnected request packet, the server host enters the last-ACK phase.

  5. After receiving the disconnection request from the server, the client needs to respond. In the packet segment, ACK = 1 and sequence number SEq = U + 1 are sent, because the client has not sent any data since the disconnection, ACK = V + 1, Then it enters the time-wait state. Note that the TCP connection has not been released. The client can enter the CLOSED state only after the Maximum Segment Lifetime is set to 2MSL.

  6. The server enters the CLOSED state after receiving the disconnection confirmation from the client. The server terminates a TCP connection earlier than the client, and four packet segments are sent during the entire disconnection process. Therefore, the process of disconnection is also called four-fold waving.

Either side of a TCP connection can initiate the closing operation, although it is usually the client that initiates the closing operation. However, some servers, such as Web servers, may initiate a connection closure after responding to the request. TCP sends a FIN packet to initiate the closure.

To sum up, it takes three segments to establish a TCP connection and four segments to close a TCP connection. TCP also supports a half-open state, although this is rare.

TCP half open

The reason why the TCP connection is half-open is that one party of the connection closes or terminates the TCP connection without notifying the other party, that is to say, the two people are chatting on wechat. Cxuan You are offline and you didn’t tell me, I am still gossiping with you. The connection is considered to be half-open. This happens when one of the parties in the communication is in a mainframe crash, you f * * k, my computer crashed how do I tell you? As long as the half-connected party does not transmit data, it is impossible to detect that the other host is offline.

Another reason to be in the half-open state is when the communicating party turns off the host power instead of shutting it down properly. In this case, there are many half-open TCP connections on the server.

TCP half closed

Since TCP supports half-open operations, we can assume that TCP also supports half-closed operations. Similarly, IT is not common for TCP to be half-closed. TCP’s half-closed operation is to close only one direction of the data flow. The two half-close operations together close the entire connection. In normal cases, applications send FIN packets to each other to end the connection. However, when TCP is half-closed, applications indicate their views: “I have finished sending data and sent a FIN segment to the receiver, but I still want to receive data from the receiver until it sends a FIN segment to me.” The following is a schematic of TCP half-closed.

Explain the process:

First client host and server host at the start of the data transmission, after a period of time, the client has launched a FIN packet, actively ask disconnected, server, after receipt of the FIN response ACK, due to the side of a half closed is the client still want the server to send data, so the server will continue to send data, After a certain period of time, the server sends another FIN packet. After receiving the ACK packet, the client disconnects from the server.

In A TCP half-close operation, one direction of the connection is closed and the other direction continues to transmit data until it is closed. It’s just that very few applications use this feature.

Open and close at the same time

A more unconventional operation is when both applications actively open the connection at the same time. While this may seem unlikely, it is possible under certain arrangements. We’re going to focus on this process.

Each communication party sends a SYN before receiving a SYN from the other party. In this scenario, both parties must know the IP address and port number of the other party.

For example, a man and a woman in love, they both say “I love you” at the same time, and then they respond to each other, which is open at the same time.

Here is an example of simultaneous opening

As shown in the preceding figure, both sides send a SYN packet before receiving the packet from the other side and reply an ACK packet after receiving the packet from the other side.

A simultaneous opening process requires the exchange of four message segments, which is one more than the ordinary three-way handshake. Since there is no client and server to open at the same time, I use the two communication parties here.

Similar to simultaneous opening, simultaneous closing means that the communication parties send a FIN packet at the same time. The following figure shows the process of simultaneous closing.

The simultaneous closing process requires the same number of segments to be exchanged as normal closing, but the simultaneous closing is not sequential like the four waves, but is carried out across.

Talk about the initial serial number

Maybe it is because of my unprofessional drawings or text description. The Initial sequence number is represented by a technical term. The English name of the Initial sequence number is Initial Sequence numbers (ISN), so the seq = V represented above actually represents the ISN.

Before sending the SYN, the communication parties select an initial sequence number. The initial sequence number is randomly generated, and each TCP connection has a different initial sequence number. The RFC documentation states that the initial serial number is a 32-bit counter + 1 every 4 us (microseconds). Because each TCP connection is a different instance, the purpose of this arrangement is to prevent overlapping sequence numbers.

When a TCP connection is established, only the correct TCP quad and sequence number can be received by the peer. This also reflects the vulnerability of TCP packet segments to be forged. As long as I forge the same quad and initial sequence number, I can forge the TCP connection and break the NORMAL TCP connection. Therefore, one way to defend against this attack is to use the initial sequence number, and another way is to encrypt the sequence number.

TCP state transition

We talked about three handshakes and four waves, and talked a little bit about state transitions between TCP connections, so LET me start from the beginning and walk you through these state transitions.

At the beginning, both the server and the client are in the CLOSED state. In this case, you need to determine whether the server is opened actively or passively. If the server is opened actively, the client sends a SYN packet to the server, and the client is in syn-send state. Syn-send Sends a connection request and waits for a matching one. When the server is passively enabled, it listens for SYN packets. If the client calls the close method or does not operate for a period of time, it becomes CLOSED again

A client in LISTEN sends a SYN that changes to SYN_SENT.

LISTEN -> SYN_SENT because the connection may be triggered by the application on the server sending data to the client. The client passively accepts the connection and starts to transfer files after the connection is established. In other words, it is possible for a SERVER in LISTEN to send a SYN packet, but this is very rare.

A server in the SYN_SEND state receives a SYN and sends a SYN and an ACK to the SYN_RCVD state. Similarly, a client in LISTEN state receives a SYN and sends a SYN and an ACK to the SYN_RCVD state. If a client in the SYN_RCVD state receives an RST, it changes to LISTEN.

It’s better to look at these two pictures together.

So I need to explain what is RST

In this case, when the host receives a TCP packet segment, the IP address and port number do not match. If the client host sends a request and the server host finds that the request is not for the server after checking the IP address and port number, the server sends a special RST message segment to the client.

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

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

Failure to identify the correct IP port above is one condition that causes an RST to occur. In addition, an RST may occur due to a request timeout, cancellation of an existing connection, and so on.

The SYN_RCVD server receives ACK packets, and the SYN_SEND client receives SYN and ACK packets and sends ACK packets. Thus, a connection is established between the client and the server.

Now, the other thing to notice here is that I didn’t specify the simultaneous state up here, but in fact, in the simultaneous state, it looks something like this.

Why is this so? If both hosts SEND SYN packets, the host that initiates the SYN packet is in syn-send state. After the packet is sent, the host waits for SYN and ACK packets to be received. After both hosts SEND SYN + ACK packets, the host that initiates the SYN packet is in SYN-send state. Both parties are in the SYN-received (SYN-RCVD) state. After a SYN + ACK packet arrives, the two parties enter the ESTABLISHED state and start data transmission.

Well, so far, I’ve given you an overview of state transitions during TCP connection setup, and now you can make a pot of tea and wait for the data to transfer.

Ok, now that you’ve had enough water, the data transfer is complete, and when the data transfer is complete, the TCP connection can be disconnected.

Now let’s move the clock forward to the time when the server is in the SYN_RCVD state. The server is happy because it just received a SYN packet and sent a SYN + ACK packet. But then the server application shuts down and sends a FIN packet. The server goes from SYN_RCVD -> FIN_WAIT_1 state.

Then set the clock to now, and the client and server have finished transmitting data. The client sends a FIN packet to disconnect, and the client becomes FIN_WAIT_1. In the case of the server, it receives a FIN packet and replies with an ACK packet. It goes from ESTABLISHED -> CLOSE_WAIT.

The server in CLOSE_WAIT state sends a FIN packet and places itself in the LAST_ACK state. A client in FIN_WAIT_1 state becomes FIN_WAIT_2 when it receives an ACK message.

So I need to explain the CLOSING state, so FIN_WAIT_1 -> CLOSING is a very special transition

CLOSING is a special state, which should be very rare in the actual situation and belongs to a rare exceptional state. Normally, after you send a FIN packet, you should receive the ACK packet first or at the same time and then the FIN packet. However, in a CLOSING state, you receive a FIN packet instead of an ACK packet from the peer party after sending a FIN packet.

When does this happen? If both parties close a link at the same time, FIN packets are sent at the same time. In other words, the two parties are CLOSING the connection.

The FIN_WAIT_2 client changes to the TIME_WAIT state after receiving the FIN + ACK message sent by the server host and sending an ACK response. The FIN sent by the CLOSE_WAIT client is in the LAST_ACK state.

In many images and blogs, the LAST_ACK state is displayed only after the FIN + ACK packet is displayed. However, only the FIN is described. That is, the FIN is in the LAST_ACK state only when CLOSE_WAIT is sent.

The FIN_WAIT_1 -> TIME_WAIT state is the state of the client after receiving the FIN and ACK and sending the ACK.

The client in CLOSINIG state will continue to be in TIME_WAIT state if ACK is received. As you can see, the TIME_WAIT state is the last state of the client before closing. LAST_ACK is the last state of the server before closing. It is a passive open state.

There are a couple of states up here that are special, so let’s go west.

TIME_WAIT state

After a TCP connection is established, the party that actively closes the connection enters the TIME_WAIT state. The TIME_WAIT state is also called the 2MSL wait state. In this state, TCP waits twice the Maximum Segment Lifetime (MSL).

MSL needs to be explained here

MSL is the maximum expected lifetime of a TCP segment, that is, the maximum time it can exist on the network. The TTL and hop count fields in the IP packet determine the lifetime of the IP address. Generally, the maximum lifetime of TCP is 2 minutes, but this value can be changed. You can change this value based on the operating system.

Based on this, let’s explore the state of TIME_WAIT.

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

I have uploaded six PDFS by myself, and the spread has exceeded 10W + on the Internet. After searching the public account of “Programmer Cxuan” on wechat, I reply to CXuan on the background and get all PDFS. These PDFS are as follows

Six PDF links