TCP protocol-Establish a connection, disconnect, state transition diagram

Source: Unix Network Programming Volume 1: Socket Networking API (3rd edition) Chapter 2nd Transport Layer: TCP, UDP, and SCTP

establishment and termination of 2.6 TCP connections

To help you understand the 3 functions of Connect, accept, and close, and to debug TCP applications using the Netstat program, we must understand how TCP connections are established and terminated, and master TCP's state transition diagrams.

2.6.13-Way Handshake

The following scenario occurs when a TCP connection is established.

(1) The server must be ready to accept incoming connections. This is usually done by calling the 3 functions of the socket, bind, and listen, which we call a passive open (passive open).

(2) The client initiates an active open (active open) by calling Connect. This causes client TCP to send a SYN (sync) section that tells the server the initial serial number of the data that the client will send in the connection (to be established). Usually the SYN section does not carry data, and its IP datagram contains only one IP header, one TCP header, and possibly TCP options (we'll explain later).

(3) The server must acknowledge (ACK) The Syn of the customer and also send a SYN section that contains the initial serial number of the data that the server will send in the same connection. The server sends SYN and ACK (acknowledgements) to the customer's SYN in a single section.

(4) The customer must confirm the Syn of the server.

This exchange requires at least 3 groupings, so it is called a TCP three-way handshake (three-way handshake). Figure 2-2 shows the 3 sections that are exchanged.

Figure 2-2 the customer's initial serial number is J, and the server's initial serial number is K. The acknowledgment number in the ACK is the next sequence number expected for the end of the ACK to be sent. Because Syn occupies a byte of serial number space, the confirmation number in each SYN ACK is the SYN's initial serial number plus 1. Similarly, the confirmation number in each of the fin (indicating end) ACK numbers is the fin number plus 1.

Establishing a TCP connection is like a telephone system [Nemeth 1997]. The socket function is equivalent to having a phone available. The bind function is to tell someone your phone number so they can call you. The listen function is to turn on the phone ringing so that when a foreign call arrives, you can hear it. The Connect function requires that we know each other's phone number and dial it. The Accept function occurs when the person being called answers the phone. The return of the customer's identity (that is, the client's IP address and port number) by accept is similar to having the phone's caller ID feature display the caller's telephone number. The difference, however, is that accept only returns the customer's identity after the connection is established, while the caller ID feature displays the caller's phone number before we choose to answer or not answer the phone. If you use domain Name System DNS (see chap. 11th), it provides a service similar to the phone book. Getaddrinfo is similar to finding a person's phone number in a phone book, Getnameinfo is similar to having a phone book sorted by phone number rather than by user name.

2.6.2 TCP Options

Each SYN can contain multiple TCP options. The following are the commonly used TCP options.

MSS option. The TCP end of the Send SYN uses this option to advertise its maximum section size (maximum segment size), the MSS, which is the maximum amount of data it is willing to accept in each TCP section of this connection. The sender side TCP uses the MSS value of the receiver as the maximum size of the sent section. We'll see how to use the TCP_MAXSEG socket option to extract and set this TCP option in section 7.9.

Window sizing options. The maximum window size that can be advertised on either end of the TCP connection is 65535, because the corresponding field in the TCP header occupies 16 digits. However, the high speed network connections that are already popular on the internet today (mbit/s or faster, as described in RFC 1323[jacobson, Braden, and Borman 1992]) or long delay paths (satellite links) require larger windows to achieve the greatest possible throughput. This new option specifies the number of digits (0~14) that the notification window in the TCP header must be enlarged (that is, left), so the maximum window provided is approximately 1 GB (65535x214). The window size is used on a TCP connection if its two-port system must support this option. We'll see in section 7.5 How to use the SO_RCVBUF socket option to affect this TCP option.

To provide interoperability between earlier implementations that do not support this option, the following rules need to be applied. TCP can send this option as part of an active opening with its SYN, but only if the option is sent to the right end along with its SYN, it expands the size of its own window. Similarly, a server's TCP can send this option only if it receives this option when it arrives with a client's syn. This logic assumes that the implementation ignores options that they do not understand, so ignoring is a required requirement and is generally satisfied, but it is not guaranteed that all implementations meet this requirement.

Time stamp option. This option is necessary for high-speed network connectivity to prevent data corruption that may result from missing and reproduced groupings. It is a newer option and is also negotiated in a manner similar to the window sizing option. As a network programmer, we do not need to consider this option.

Most implementations of TCP support these common options. The latter two options are sometimes referred to as "RFC 1323 options" because they are described in RFC 1323[jacobson, Braden, and Borman 1992]. Since high-bandwidth or long latency networks are called "long fat Pipes," The two options are also known as "long fat pipe Options" (pipe). The 24th chapter of TCPV1 gives a detailed account of these options.

2.6.3 TCP connection termination

TCP requires 3 sections to establish a connection, and 4 sections to terminate a connection.

(1) An application process calls close first, and we say that the end performs active shutdown (active closing). TCP At that end sends a FIN section indicating that the data is sent.

(2) A passive shutdown (passive close) is received for the end of this fin. This fin is confirmed by TCP. Its reception is also passed as a file terminator (End-of-file) to the receiving application process (after any other data that has been queued for receipt by the application process), because the receipt of the fin means that the receiving application process has no additional data to receive on the corresponding connection.

(3) After a period of time, the application process that receives the end of this file calls close to turn off its socket. This causes its TCP to also send a fin.

(4) To receive this final fin from the original sender TCP (that is, the end of the active shutdown) confirms the fin.

Since each direction requires a fin and an ACK, 4 sections are usually required. We use qualifiers "usually" because: in some cases the fin of step 1 is sent along with the data, and the sections that are sent in steps 2 and 3 come from the end of the passive shutdown and may be merged into a section. Figure 2-3 shows these groupings.

Like Syn, a fin also occupies 1 bytes of serial number space. Therefore, the ACK confirmation number for each fin is the number of this fin plus 1.

Between step 2 and step 3, it is possible to move data from a passive shutdown end to an active shutdown. This is called a half-close, and we'll detail it in section 6.6 with the shutdown function.

When the socket is closed, its host TCP sends a fin of its own. We point out in the diagram that this occurs when the application process calls close, but recognizes that when a UNIX process terminates either voluntarily (calling exit or returning from the main function) or involuntarily (receiving a signal to terminate this process), all open descriptors are closed. This also causes a fin to be emitted on any TCP connections that are still open.

Figure 2-3 shows the customer performing an active shutdown, but we point out that both the customer and the server can perform active shutdown on either end. Typically, a customer performs an active shutdown, but some protocols, such as noteworthy http/1.0, are actively shut down by the server.

2.6.4 TCP state transition diagram

TCP operations that involve connection establishment and termination of connections can be explained by state transition diagram, as shown in Figure 2-4.

TCP defines 11 states for a connection, and the TCP rule prescribes how to transition from one state to another based on the current state and the section received in that state. For example, when an application process is actively opened in the closed state, TCP sends a SYN, and the new state is syn_sent. If this TCP then receives a SYN with an ACK, it sends an ACK, and the new state is established. This final state is the state in which most data transmissions occur.

The two arrows drawn from the established state handle the termination of the connection. If an application process calls close (active shutdown) before receiving a fin, it is converted to the fin_wait_1 state. However, if an application process receives a fin (passive shutdown) during the established State, it is converted to the close_wait state.

We use the thick solid line to represent the usual client state transitions, with bold dashes representing the usual server state transitions. The diagram also notes the existence of two transformations we have not discussed: one to open at the same time (simultaneous open), where both ends send syn almost simultaneously and the two SYN is interleaved across the network, while the other is closed at the same time (simultaneous close), Occurs when the fin is sent almost simultaneously at both ends. TCPV1 's 18th chapter contains examples and discussions of these two situations, which are likely to occur, but are very rare.

One of the reasons for showing the state transition diagram is to give the names of 11 TCP states. These states can be displayed using Netstat, which is a useful tool for debugging client/server applications. We will use Netstat to monitor state changes in the 5th chapter.

2.6.5 Observation Group

Figure 2-5 shows the actual packet exchange occurring for a complete TCP connection, including connection establishment, data transfer, and connection termination in 3 phases. The diagram also shows the TCP status experienced by each endpoint.

In this example, the customer notices an MSS with a value of 536 (indicating that the customer only implements the minimum size of the reassembly buffer), and the server advertises an MSS with a value of 1460 (a typical value for IPV4 on Ethernet). The MSS value is not the same in different directions (see Exercise 2.5).

Once a connection is established, the client constructs a request and sends it to the server. Here we assume that the request is appropriate for a single TCP section (that is, the request size is less than MSS with a value of 1460 bytes for the server advertisement). The server processes the request and sends an answer, and we assume that the answer is also appropriate for a single section (less than 536 bytes in this case). The bold arrows are used in the diagram to denote the two data sections. Note that the server's acknowledgement of the customer request is accompanied by its reply sent. This is referred to as a piggybacking, which usually occurs when the server processes the request and produces a response less than Ms. If the server consumes more time, say 1 s, then we will see that the answer is first confirmed. (The mechanism of TCP data flow is described in detail in chapters 19th and 20th of TCPV1.) ）

The figure then shows the 4 sections that terminate the connection. Note that the one end of the active shutdown (for the customer in this example) enters the time_wait state that we will discuss in the next section.

It is noteworthy in figure 2-5 that if the entire purpose of the connection is simply to send a single section of the request and receive a single section reply, then TCP has 8 section overhead. If you use UDP instead, you only need to swap two groups: a hosting request, and a hosting response. Switching from TCP to UDP, however, loses all the reliability that TCP provides to the application process, forcing a lot of detail from the Transport layer (TCP) to the UDP application process. Another important feature that TCP provides is that congestion control must also be handled by the UDP application process. Nevertheless, we still need to know that many network applications are built using UDP because they require less data to exchange, while UDP avoids the overhead required to establish and terminate TCP connections.

2.7 Time_wait State

There is no doubt that the most difficult to understand about network programming in TCP is its time_wait state. In Figure 2-4 We see the end of the active shutdown experiencing this state. The endpoint stays in this state for a duration of twice times the longest section life period (maximum segment LIFETIME,MSL), sometimes called 2MSL.

Any TCP implementation must select a value for the MSL. The recommended value for RFC 1122[braden 1989] is 2 minutes, but the implementation from Berkeley has traditionally been converted to 30-second value. This means that the duration of the TIME_WAIT state is between 1 minutes and 4 minutes. The MSL is the longest time any IP datagram can survive on the Internet. We know that this time is limited because each datagram contains a 8-bit field called a hop limit (see the TTL field in Figure A-1 and the IPv6 field in the figure A-2), and its maximum value is 255. Although this is a jump limit rather than a real time limit, we still assume that a packet with the maximum hop limit (255) cannot be in the network longer than the MSL second.

Grouping in the network "stray" is usually the result of routing exceptions. When a router crashes or a link between two routers is disconnected, the routing protocol takes several seconds to a few minutes to stabilize and find another path. There is a possibility that the routing loop (router A sends packets to Router B and B to send them back to a) may be in this loop for the group we care about. Suppose that the stray packet is a TCP section, and that the sending-side TCP timeout and the grouping are passed through the sender's path, while the retransmission group reaches the final destination through a candidate route. However soon after (since the stray group starts its journey up to the maximum of MSL seconds) The routing loop fixes, and the packets that were previously lost in the loop are eventually sent to the destination. This original grouping is called a stray repeating group (lost duplicate) or a roaming repeating grouping (wandering duplicate). TCP must handle these duplicate groupings correctly.

The TIME_WAIT state has two reasons for existence:

(1) reliably realize the termination of TCP Full-duplex connection;

(2) Allow the old repeating section to fade through the network.

The first reason can be explained by looking at figure 2-5 and assuming that the final ACK is missing. The server will resend its final fin, so the customer must maintain state information to allow it to resend the final ack. If the customer does not maintain state information, it responds with a RST (another type of TCP section), which is interpreted by the server as an error. If TCP intends to perform all the necessary work to completely terminate the two-directional data flow (that is, Full-duplex shutdown) on a connection, it must correctly handle the loss of any of the sections in the 4 sections of the connection termination sequence. This example also explains why the end of the active shutdown is at the end of the TIME_WAIT state: It may have to retransmit the end of the ACK.

To understand the second reason for the existence of a time_wait state, we assume that there is a TCP connection between the 12.106.32.254 1500 port and the 206.168.112.219 21 port. We close this connection and establish another connection between the same IP address and port over a period of time. The latter connection is called the incarnation of the previous connection (incarnation) because they have the same IP address and port number. TCP must prevent old repeating groupings from a connection from being reproduced after the connection has terminated, thereby being misunderstood as a new incarnation belonging to the same connection. To do this, TCP will not initiate a new incarnation of the connection in the TIME_WAIT state. Since the duration of the time_wait state is twice times that of the MSL, this is enough to allow the group in one Direction to survive up to a maximum of MSL seconds to be discarded, and the answer to the other in the direction of the maximum surviving MSL seconds is discarded. By enforcing this rule, we can ensure that every time a TCP connection is successfully established, the old repetitive groupings from the previous incarnation of the connection are already disappearing on the network.

An exception to this rule is that if the serial number of the SYN that arrives is greater than the end sequence number of the previous incarnation, the implementation originating from Berkeley will start a new avatar for the connection currently in the TIME_WAIT state. This situation is described in detail on page No. 958 to No. 959 of TCPv2. It requires the server to perform an active shutdown because the end of the receiving next SYN must be in a time_wait state. Rsh commands have this ability. RFC 1185[jacobson, Braden, and Zhang 1990] describe some of the pitfalls of this situation.