TCP is a connection-oriented, reliable, byte stream based transport layer communication protocol. Before sending data, communication parties must establish a connection with each other. The so-called “connection” is actually a piece of information about each other, such as IP address and port number, saved by the client and the server.

A TCP connection is usually divided into three phases: connection, data transfer, and exit (close). Establish a link with three handshakes and close a link with four waves.

1. The header structure of the TCP packet

Before learning about TCP connections, learn about the structure of TCP header packets.

1.1 Port Number (16 bits)

The source port number indicates where the packet is from. Destination port number Indicates where the packet is to be sent. During TCP communication, the client uses a temporary port number automatically selected by the system, and the server uses a specified port number.

1.2 Serial number SEQ (32 bits)

TCP uses IP to transmit packet segments, and IP cannot filter out repeated packets or ensure the sequence of packets. For example, the client sends a 5 KB data to the server. If TCP can only send 1 KB data at a time, the client divides the data into five segments and sends them five times. The five segments are numbered as 1, 2, 3, 4, and 5 respectively. That is, the order in which the server receives the data may be different from the order in which the server sends it, or even the server may receive multiple data with the same number due to certain factors (for example, the client may resend the data after receiving the ACK packet from the server).

So how does the server receive all the data and then concatenate it into the correct data? That’s where the serial number comes in. First, the sequence number is initialized to a random ISN. The sequence number of a packet is the ISN+ the offset of the first byte of the data carried in the packet. For example, five packets are sent. The offset of the first byte of the first packet is 0 and the sequence number is ISA+0. Since the data size of the first packet is 1kb(1024), the offset of the first byte of the second packet is 1024, and the sequence number is ISA+1024, and so on. (Note that the triple handshake actually occupies a sequence number, so actually the serial number of the first packet is ISA+1+0 when the data is officially sent. The serial number occupied by the triple handshake is not considered here for the convenience of understanding.)

1.3 Confirmation NUMBER ACK (32 bits)

The ack number of the ack packet is equal to the sequence number of the packet received by the server +1. For example, the sequence number of the packet received by the server is ISN+2048. In this case, the ISN+2048+1 is the confirmation number of the reply packet to the client, which tells the client that all data before the ISN+2048+1 is received.

There are a few things to note about ack replies (the following client is the sender and the server is the receiver) :

A. After sending a packet, the client can send the next packet without waiting for the ACK reply from the server.

B. When sending an ACK reply, ensure that all data before the ACK ack number is received. For example, if the ACK with the ISN+2048 is received, but the ISN+1024 is not received, the ACK with the ISN+2048+1 cannot be received.

C. The server does not immediately send ack packets to the client after receiving data. The delay is 200ms. (the system has a timer to check whether ack packets need to be sent every 200ms.) This is because the order of TCP packets arriving is not guaranteed. For example, the ACK for the ISN+2048+1 ISN+1024+1 ISN+1024+1 ISN+1024+1 ISN+1024+1 ISN+1024+1 is not needed. An ACK that replies to ISN+2048+1 tells the client that all the data before ISN+2048+1 has been received. This also reduces network traffic. If the server does not receive any ACK response from the ISN+1024 because of packet loss, the client will resend data from the last ACK response, including the ISN+2048 received by the server. In addition, if the server happens to have data to send to the client, the ACK message will be included in the TCP packet that sends the data.

1.4 Head length (4 positions)

The length of the TCP header is 32 bits (4 bytes). The length of the header indicates the total number of 32 bits in the TCP header. The maximum length of the 4-bit header is 1111 in binary system (15 in decimal system). The first 20 bytes of the TCP header are fixed. The minimum TCP header is 20 bytes.

1.5 Six flag bits (each flag has 1 bit, and each flag has only 0 and 1 states)

URG: 1 indicates that the emergency pointer is valid.

ACK: 1 indicates that the acknowledgement number is valid. The packet segment carrying the ACK flag is also called the acknowledgement packet segment.

PSH: 1 indicates that the receiving application should immediately read data from the TCP receive buffer to make room for subsequent received data.

RST: 1 notifies the peer party to close the connection or re-establish the connection. TCP packet segments with RST flags are also called reset packet segments. TCP connections cannot be established or terminated abnormally in many cases. For example, when a client requests a non-existent port, the server can send an RST packet to reject the request. Another example is the TCP connection has not transmitted data for a long time, you can send the RST packet segment to terminate the connection. For example, if a TCP connection occurs once and the server wishes to terminate the abnormal connection, it can send an RST message segment to terminate the connection. Notice Once the reset packet segment is sent, all the queued data on the sender is discarded, and the TCP connection is closed after the RST packet is sent. Therefore, the receiver does not need to send an ACK packet after receiving the RST packet.

SYN: 1 indicates that a connection is established. The packet segment carrying the SYN flag is the synchronization packet segment. The SYN flag is set to 1 only when TCP establishes a connection (that is, the three-way handshake). The packet sent by the client for establishing a connection (the first handshake) carries the SYN flag and the initial sequence number (that is, the start sequence number). The SYN flag reminds the server of the start sequence number of the client. The server then initializes its own start sequence number and replies to the client with a packet (second handshake) containing the start sequence number of the server, the SYN flag bit, and the ACK flag bit. The SYN flag bit is used to remind the client of the start sequence number of the server.

FIN: Indicates that the local end will close the connection when the value is 1.

1.6 Window Size (16 bits)

The window size can be interpreted as the size of the cache for receiving data, which is used to tell the other party how much data it can receive. If the data sent by the other party exceeds the window size, the data will be discarded. When the window size is 0, the peer party stops sending data and resumes sending data until the window size is greater than 0.

1.7 Checksum (16 bits)

The sender of TCP packets (including TCP header and data section) get the checksum CRC algorithm, the receiver algorithm to perform the same message after receipt of the message, check and compare the results with both agree that TCP segment was not damaged during transmission, if don’t agree it TCP packet will be discarded directly.

1.8 Emergency Pointer (16 bits)

The emergency pointer is meaningful only if the URG flag bit is 1, and the emergency pointer points to the last byte of the emergency data. The value of the emergency pointer is actually an offset relative to the sequence number. For example, the value of the emergency pointer is 5. If the sequence number of the packet segment seq=10, it means that the emergency pointer points to the byte at position 15, which means that the data between 10 and 14 are emergency data. Emergency data is not in the cache. (Note: There are different opinions online about the direction of the emergency pointer and the length of the emergency data, and I’m not sure which one is correct).

1.9 TCP header Options

TCP header options Optional information of variable length, containing a maximum of 40 bytes. Typical TCP header options include kind, Length, and INFO. Kind indicates the type of the option, Length indicates the length of the option, and INFO indicates the specific content of the option.

2. Three handshakes

  • First handshake: To initiate a connection request to the server, the client generates an ISN(for example, 100) randomly. The packet segment sent from the client to the server contains the SYN flag (SYN=1) and the SEQUENCE number is seq=100.

  • Second handshake: After receiving the packet from the client, the server finds SYN=1 and realizes that this is a connection request. The server stores the client’s start sequence number 100 and randomly generates a server’s start sequence number (for example, 300). Then, a reply packet is sent to the client containing the SYN and ACK flags (SYN=1,ACK=1), sequence number seQ =300, and ACK number 101(sequence number +1 from the client).

  • Third handshake: After receiving the reply from the server, the client finds ACK=1 and ACK= 101, and knows that the server has received the packet with serial number 100. SYN=1 (SYN=1); SYN=1 (SYN=1); The client then replies a packet to the server containing the ACK flag bit (ACK=1), ACK= 301(serial number +1 of the server), and SEQ =101(the sequence number used to send the packet during the first handshake is the same, so the SEQ starts from 101. Note that the ACK packet without data does not occupy the sequence number, so the seQ is still 101 when the data is formally sent for the first time. When the server receives the packet and finds ACK=1 and ACK= 301, it knows that the client has received the packet with serial number 300. In this way, the client and the server establish a connection through TCP.

3. Wave four times

  • First wave: After all data is transmitted, the client sends a connection release packet to the server. The connection release packet contains the FIN flag bit (FIN=1) and serial number (SEQ =1101) (100+1+1000, Where 1 is the serial number used to establish the connection. Note that after sending FIN packets, the client cannot send data, but can receive data normally. In addition, a FIN packet segment occupies a sequence number even if it does not carry data.
  • Second wave: After receiving the FIN packet from the client, the server replies with an ACK flag bit (ACK=1), ACK number (ACK= 1102), and SEQUENCE number (SEQ =2300(300+2000). In this case, instead of sending FIN packets to the client immediately, the server is in the closed waiting state. This state lasts for a period of time because the server may not finish sending data.
  • Third wave: After sending the last data (for example, 50 bytes), the server sends a connection release packet to the client. The packet contains the FIN and ACK flag bits (FIN=1,ACK=1),ACK= 1102, and serial number seQ =2350(2300+50).
  • Fourth wave: After receiving the FIN packet from the server, the client sends an ACK packet containing the ACK flag bit (ACK=1), ACK id (ACK= 2351), and SEQUENCE number (SEQ =1102) to the server. Note The client does not release the TCP connection immediately after sending the confirmation packet, but releases the TCP connection after 2MSL(twice the lifetime of the longest packet segment). The server releases the TCP connection as soon as it receives the confirmation packet from the client. Therefore, the server terminates the TCP connection earlier than the client.

4. Meet often

4.1 Why Are TCP Connections Made three Times? Can’t you do it twice?

The problem of packet loss during connection needs to be considered. If the handshake is done twice, if the segment of the confirmation packet sent by the server to the client is lost during the second handshake, the server has prepared the data (it can be understood that the server has been successfully connected), but the client has not received the confirmation packet from the server. Therefore, the client does not know whether the server is ready or not. In this case, the client does not send data to the server and ignores the data sent by the server.

For example, if the ack packet sent by the client for the third handshake is lost and the server does not receive the ACK packet for a period of time, the server resends the SYN packet segment. After receiving the retransmitted packet segment, the client sends an ACK packet to the server.

4.2 Why are TCP Connections Attempted three times but closed four times?

This is because TCP can only be disconnected when neither the client nor the server has data to send. When the client sends FIN packets, the client can only ensure that no data is sent. It is unknown whether the server sends data to the client. While the service side only after receipt of the client a FIN message to reply a confirmation message to the client first told me the client service side FIN of your message has been received, but I still have some data server didn’t send out, such as the data is sent over the server to send the client FIN packet (so cannot one-time to send confirmation message and FIN a message to the client, This is the extra one).

4.3 why does it take 2MSL for the client to release the TCP connection after sending the fourth wave acknowledgement packet?

Packet loss is also considered here. If the fourth wave packet is lost, the server will resend the third wave packet without receiving the ack packet. In this way, the longest time for the packet to go back is 2MSL, so it takes such a long time to confirm that the server has received the packet.

4.4 What Can I Do if the Client Suddenly Fails after a Connection has been established?

TCP has a keepalive timer, so if the client fails, the server can’t wait forever, wasting resources. The server resets this timer every time it receives a request from the client, usually for two hours. If it does not receive any data from the client within two hours, the server sends a probe segment, which is then sent every 75 seconds. If there is no response after 10 probe packets are sent, the server assumes that the client is faulty and closes the connection.