TCP connection establishment and Termination

Three-way handshake

The following situations occur when a TCP connection is established.

(1) The server must be prepared to accept external connections. This is usually done by calling the socket, bind, and listen functions.Passive open.

(2) The customer calls connect to initiateEnable. This causes the customer TCP to send a SYN (synchronous) subnode, which tells the server the initial serial number of the data that will be sent in the (to be established) connection. Generally, Syn nodes do not carry data. The IP datagram contains only one IP header, one TCP header, and Possible TCP options.

(3) The server must confirm (ACK) the customer's SYN and send a SYN Shard, which contains the initial serial number of the data that the server will send in the same connection. The server sends SYN and ACK (OK) to the customer SYN in a single shard ).

(4) The customer must confirm the server syn.

In this way, the Exchange requires at least three groups, so it is called the three-way handshake of TCP. Figure 2-2 shows the three segments exchanged.

Figure 2-2 shows the initial serial number of the customer as J and the initial serial number of the server as K. The confirmation number in Ack is the expected next serial number at the end of the Ack. Because SYN occupies the space of a byte serial number, the confirmation number in each syn ack is the initial serial number of the SYN plus 1. Similarly, the confirmation in the ACK of each fin (indicating the end) is the serial number of the fin plus 1.

 

TCP options

Each SYN can contain multiple TCP options. Below are common TCP options.

• MSS options. The TCP End that sends SYN uses this option to notify the peer of its maximum shard size (MSS), that is, the maximum amount of data that it is willing to accept in each TCP shard of this connection. The sending end uses the MSS value of the receiving end as the maximum size of the sent shard.
• Window Size Option. The maximum window size of the Peer end can be advertised at any end of the TCP connection is 65535, because the corresponding fields in the TCP Header occupy 16 bits.
• TIMESTAMP options. This option is required for high-speed network connections. It can prevent data corruption caused by lost and reproduced groups.

TCP connection termination

To establish a connection over TCP, three sub-sections are required. To terminate a connection, four sub-sections are required.

(1) An application process first calls close. We call this end to take the initiative to close it. The TCP End sends a fin Shard, indicating that the data has been sent.

(2) The Peer of the received fin is passively disabled. This fin is confirmed by TCP. Its receipt is also transmitted as a file terminator to the receiving end application process, because the receiving of fin means that the receiving end application process can receive no additional data on the corresponding connection.

(3) after a period of time, the application process that receives the file Terminator will call close to close its socket. As a result, TCP also sends a fin.

(4) The original sending end TCP that receives the final fin confirms the fin.

Since one Fin and one ack are required in each direction, four subsections are usually required. We use the qualifier "normally" because, in some cases, the fin of step 1 is sent along with the data; in addition, the sub-sections sent by Step 2 and Step 3 are executed passively to close the end, it may be merged into a shard. Figure 2-3 shows these groups.

Like SYN, a fin occupies 1 byte serial number space. Therefore, the ACK validation number for each fin is the serial number of the fin plus 1.

Between steps 2 and 3, it is possible to passively close one end of execution to actively close one end of flow data. This is called semi-close.

When the socket is closed, the tcp client sends a fin. We point out in the figure that this occurs when the application process calls close, but we need to realize that,When a Unix process ends voluntarily (calling exit or returning from the main function) or involuntarily (receiving a signal to terminate the process), the opened descriptor is disabled., Which also causes a fin to be sent on any TCP connection that is still open.

Figure 2-3 shows the customer's active shutdown. However, we point out that the active shutdown can be performed on either client or server. Generally, the client executes active shutdown, but some protocols are disabled by the server.

 

TCP status transition diagram

TCP operations involving connection establishment and connection termination can be illustrated in the state transition diagram, as shown in Figure 2-4.

TCP defines 11 States for a connection, and the TCP rules specify how to switch from one State to another based on the current state and the segments received in this state. For example, when an application is actively opened in the closed state, a SYN occurs in TCP and the new State is syn_sent. If this TCP receives an SYN with Ack, it sends an ACK and the new status is established. This final state is the status of most data transfers.

The two arrows in the established status process the termination of the connection. If an application process calls close (Active close) before receiving a fin, it is switched to fin_wait_1. However, if an application process receives a fin (passively closed) during the established State, it is switched to the close_wait state.

We use the bold line to convert the normal customer status. The figure also shows two conversions we have not discussed: one is opened at the same time, when both ends send SYN almost simultaneously and the two SYN are staggered in the network, the other is closed at the same time, when both ends send fin at almost the same time.

 

Observation Group

Figure 2-5 shows the actual group exchange situation of a complete TCP connection, including three phases: Connection establishment, data transmission, and connection termination. The figure also shows the TCP status of each endpoint.

In this example, the customer advertises an MSS value of 536 (indicating that the customer only implements the minimum size of the restructured buffer), and the server advertises a value of 1460 (a typical value of IPv4 over Ethernet ). The MSS value varies in different directions.

Once a connection is established, the customer constructs a request and sends it to the server. Here we assume that the request is suitable for a single TCP shard (that is, the request size is smaller than the value advertised by the server is 1460 bytes of MSs ). The server processes the request and sends a response. We assume that the response is also suitable for a shard (less than 536 bytes in this example ). In the figure, the bold arrows are used to represent the two data segments. Note that the server's confirmation of the customer's request is sent along with its response. This method is called the response band, which is usually sent when the server processes the request and generates a response for less than Ms. If the server takes a longer time, for example, 1 s, we will see that the response is confirmed first.

The following figure shows the four sub-sections for terminating the connection. Note that the end that is proactively disabled (in this example, the customer) enters the time_wait status.

In Figure 2-5, it is worth noting that if the whole purpose of the connection is to send a single-node request and receive a single-node response, TCP has eight sub-nodes. If you use UDP, you only need to exchange two groups: one carrying the request and the other carrying the response. However, switching from TCP to UDP will lose all the reliability TCP provides to the application process, forcing a lot of details of the reliable service to be transferred from the transport layer to the application process. Another important feature and congestion control provided by TCP must also be handled by UDP application processes. Even so, we still need to know that many network applications are built using UDP, because they need to exchange less data, and UDP avoids the overhead required to establish and terminate TCP connections.

 

Time_wait status

In Figure 2-4, we can see that the end of the active shutdown has gone through this state. The duration of the endpoint staying in this state is twice the maximum lifecycle of the subnode, which is sometimes called 2msl.

The time_wait status has two reasons:

(1) Reliable termination of TCP full-duplex connections;

(2) allow the old duplicate segments to disappear in the network.

The first reason can be explained by looking at Figure 2-5 and assuming that the final Ack is lost. The server will resend its final fin, so the customer must maintain the status information to allow it to resend that ack. If the customer does not maintain the status information, it will respond to an RST (another type of TCP segmentation), which will be interpreted as an error by the server. If TCP intends to perform all necessary work to completely terminate the data streams in the two directions of a connection (that is, full duplex shutdown ), therefore, it must correctly handle the loss of any of the four segments in the connection termination sequence. This example also explains why the end of the active shutdown operation is in the time_wait state: Because the end Of the ACK may have to be re-transmitted.

To understand the second reason for the existence of the time_wait status, we assume that there is a TCP connection between port 1500 of 12.106.32.154 and port 21 of 206.168.112.219. We closed this connection. After a while, we established another connection directly on the same IP address and port. The next connection is called the embodiment of the previous connection because their IP addresses and port numbers are the same. TCP must prevent old repeat groups from a connection from appearing after the connection is terminated, and thus be misunderstood as a new embodiment of the same connection. To achieve this, TCP will not initiate a new embodiment for connections in the time_wait status. Since the duration of the time_wait status is twice that of MSL, this is enough to make the group in a certain direction alive up to MSL seconds and is discarded, in the other direction, the response is discarded after a maximum of MSL seconds. By implementing this rule, we can ensure that every time a TCP connection is established successfully, the old repeat groups from the previous embodiment of the connection have disappeared in the network.

TCP connection establishment and Termination