Speed read the original -TCP / IP (TCP server design)

Establishment and termination Chapter 18 TCP connections

18.11 TCP server design

We in Section 1.8 said that most TCP servers are concurrent. When a new connection request arrives at the server, the server accepts the request, and invokes a new process to deal with this new customer requests. Different operating systems use different techniques to call the new server process. In the U nix systems, common technique is to create a new process using the fork function.

If your system supports, can also use lightweight processes, namely thread (thread). We are interested in the interaction with a number of concurrent TCP server. You need to answer the following questions: When a server process accepts a service request from the client, and how to deal with the port? If multiple connection requests arrive almost at the same time what happens?

18.11.1 TCP server port number

By observing any TCP server, we understand how to handle TCP port number. We use the netstat command to observe Te lnet server. The following is a connection in the absence of Te lnet (leaving only display lines Te lnet server).

• a marker for all hosts in the network side, rather than in the host ES TA BLISHED. - n flag will be displayed as dotted decimal IP address, rather than by the addresses into DNS host name, the port number is also required to display (for example 23) instead of the service name (such as Te lnet). -f inet option reports only use the host TCP or UDP.

Local Address shown is 23, often called the wildcard asterisk. This means that the incoming connection request (i.e. SYN) will be accepted on any local interface. If the host is multihomed, we could specify the IP address of a local IP address, and only receives the connection from the interface (in this section, we will see later in this example). Local port 23, which is well-known port number Te lnet.

Is displayed as the remote address *. * Indicates not know the remote IP address and port number, because the end of the LISTEN state, awaiting arrival connection request. Now (140. 252. 13. 65) to start a client Te lnet host slip Te lnet to connect the server. The following is the output line netstat program:

port row 123 in FIG ES TABLISHED connected state. It also shows the connection of the local IP address, local port, remote IP address and remote port number. Local interface to the IP address of the connection request (Ethernet interface, 140. 252. 13. 33) for.

The server process in the LISTEN state still exists. The server process is currently receiving Te lnet server for other connection requests. When the incoming connection request arrives and is received, the kernel creates a TCP module in the process of ES TA BLISHED state. Also, note that the port will not change in the status of ES TA BLISHED connection: is 23, and the same process is in LISTEN state.

Now we start another Te lnet client processes on the host slip, and still connect with the Te lnet server. The following is the output line netstat program:

Now we have two in connection ES TA BLISHED from the same host to the same server. Their local port numbers are 23. Because of their different remote port number, this will not cause conflict. Te lnet because each client process to use a peripheral port and the peripheral port will select the currently unused ports for the host (slip), so they are certainly different port numbers.

This example reiterates using TCP 4-tuple by the local address and a remote address consisting of: destination IP address, destination port number, source IP address and source port number to handle a plurality of incoming connection requests. TCP can not only determine the process receives a connection request by the destination port number. Further, in the process using three ports 23, only in the LISTEN state able to receive a new connection request. Process in ES TA BLISHED will not receive SYN segment, while in the LISTEN state into the
process will not be able to receive the data segment.

Let's start first three Te lnet client processes from the host solaris, the main across the SLIP link is connected to the host sun, rather than the Ethernet interface.

Now a first local IP address ES TA BLISHED SLIP link interface connected to a corresponding address (140 2 5 2.1. 29) in the multihomed host sun.

18.11.2 local IP address defined

When we take a look at their local server can not optional IP address must be the case when a specific IP address. If we specify an IP address (or host name), and it is a sock as a server program, then the IP address becomes the local IP address is LISTEN server. E.g

sun % sock -s 140.252.1.29 8888

This program makes connection to the server is limited to from SLIP interface (140 2 5 2.1. 29). netstat displays illustrates this point:

Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 140.252.1.29.8888 *.* LISTEN

If we are connected to the server via SLIP link from the host solaris, it will work properly.

Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 140.252.1.29.8888 140.252.1.32.34614 ESTABLISHED
tcp 0 0 140.252.1.29.8888 *.* LISTEN

But if we try to connect the host (140. 252. 13) with the Ethernet server, the connection request is rejected TCP module. If tcpdump to observe all, in response to the connection request SYN 18 as shown it is a - RST shown in FIG. 21.

This connection request will not reach the application server, because it specifies the application based on the local IP address rejected kernel TCP module.

18.11.3 remote IP address defined

At 11. 12, we know that UDP servers are typically specified local IP address and local port, but also can specify the remote IP address and remote port. Interface function shown in RFC 793 allows a server when performing a passive open socket unspecified (waiting for a particular customer active open), a unspecified socket (waiting for any customer).

Unfortunately, most do not support API. The distal end of the socket must not specify the server, waiting for the connection request, and then check the IP address and port number of the client.

FIG 18--22 summarizes the TCP server address binding when three types of connection. In the three cases, are well known lport server port, the local IP address must be a local IP interface. Order of rows in the table is the order that determines the local address of the TCP module when it receives a connection request. Binding (line 1, if supported) most frequently used will be the first attempt, the most unusual (the last line of IP addresses of the two are not developed) will be the last attempt.

18.11.4 incoming connection request queue

A concurrent server invokes a new process to handle each client, so the connection request in a passive connection request server should always be prepared to deal with an incoming call. That root cause is the use of concurrent server. But it may still occur when the server when you create a new process, or the operating system is busy with higher-priority process, multiple connection requests arrive. When the server is busy, TCP is how to deal with these incoming connection requests? TCP uses the following rules to achieve in Berkeley:

1. One end of the connection request awaiting connection queue has a fixed length, connected to the TCP queue has been accepted (i.e., three-way handshake has been completed), but has not been accepted by the application layer. Note that distinguish a TCP connection is to be accepted into the queue, and the application to the accepted connection is removed from the queue.
2. The application specifies the maximum size of the queue, commonly called the backlog value (backlog). It is an integer in the range 0 to 5, comprising 0 and 5 (most applications will be described this value is 5).
3. When a connection request (i.e. SYN) arrives, TCP uses an algorithm to determine whether to accept the connection according to the current number of connections in the connection queue. We expect the backlog value specified by the application of this endpoint can accept the maximum number of connections allowed, but the situation is not so simple. FIG 18--23 backlog value shows a conventional system and Berkeley S olaris

The relationship between the maximum number of connections allowed for the acceptance 2.2. Note that the value of the backlog noted that TCP listening TCP endpoint has been accepted and the maximum number of connections waiting to accept the application layer. The maximum number of clients that backlog value for the number of connections allowed by the system, or concurrently concurrent processing server can not affect. In this figure, a predetermined value S olaris system as we expected. The traditional BSD system, this

value (for some reason) the backlog value set by 3 divided by 2, plus 1.

4. If a request for a new connection, the endpoint TCP listening space also the connection queue (based on FIG. 18 - 2 3) confirmation, and TCP SYN completed module will establish a connection. However, the application layer only the third segment in the three-way handshake is received after will know when this new connection. In addition, when customers take the initiative to open the process was successful but the application layer server did not know this new connection, it may think that the server process is ready to receive the data (if this happens, the server's TCP will only receive data into the buffer queue).

5. If the request for a new connection, the connection queue has no space, TCP will ignore the received SYN. Not returning any segment (ie, not sent back RST). If the server does not get accepted to have been accepted TCP connections, these connections may occupy the entire connection queue, the client's active open will eventually time out. We can see this scenario sock program. We call it, and use the new option (- O). After you create a new server process without pause before accepting any connection requests. If, during the pause it then invoke multiple client processes that will lead to accept the connection queue is full, tcpdump can see through it all.

bsdi % sock -s -v -q1 -O30 5555

• Q 1 backlog server option value set. In this case, conventional systems BSD queue allowed to accept a connection request two (FIG. 18--23). - O 3 0 option to make the program pause 30 seconds before accepting any client connections. In these 30 seconds, we can start the process to fill the other customers queue. Start four client processes on the host sun.

FIG 18--24 tcpdump shows the output of a first of the first SYN from the first client process (not the window size and MSS announcements when TCP connection is established, the port number of the client process indicated in bold.) .

A first client port 1090 TCP connection request is accepted (segments 1 ~ 3). The second port of the client 1091 is also accepted by TCP connection request (segment 4 to 6). The application server is still dormant, has not yet accepted any connection. TCP module to complete all the work is done by the current kernel. In addition, two client processes have successfully completed their active open, because they establish a three-way handshake connection has been completed.

We then start the third and four in the customer segment 7 (port 1092) and segment 8 (port 1093) process. Since the connection queue is full server, TCP will ignore two SYN. Two client processes in segments 9, 10, 11, 12, 15 retransmit their SYN. Third SYN retransmission fourth client process is accepted, because 30-second pause after the server program, the connection will have received two removed from the queue, the connection queue becomes empty (server program receives a connection the time is 28. 19, the reason is that less than 30 after starting the server program it takes a few seconds to start the process of a customer (segment 1, shown is the start time)). 3rd 4th client process SYN retransmission time is accepted (segment 15 ~ 17).

Causes the server program to accept client connections 4 (port 1093) is the timing of interactions between the server program 30-second pause and client retransmission.

We expect to receive transmission connection queue in FIFO order to the application layer. TCP accepts a connection on port 1090 and 109 1, we expect the application to the connection on port 1090, and then the connection on port 109 1. But many Berkeley TCP implementations deliver the order LIFO appear, the error has existed for many years. Recently manufacturers have begun to correct this mistake, but the problem still exists in other systems such as SunOS 4.13. When the queue is full, TCP will ignore incoming SYN, RST is not sent back as a response, because it is a soft error, rather than a hard error. Usually queue is full due to the application or operating system caused by busy, which prevents the application of the incoming connection service. This condition can be changed within a very short period of time. But if the system is reset to a TCP server response, the client's active open will be discarded (if the server does not start we will encounter).

Because they do not answer SYN, TCP server program then forcing customers to retransmit SYN, to wait for a connection queue has room to accept new connections.

This example has a clever place, which could be seen in most of the specific implementation of TCP / IP, the connection is, if the queue is not full server, TCP will accept incoming connection requests (ie SYN), but not let the application layer to know who it's from (ie not inform the source IP address and source port). This is not required by TCP, but rather a common implementation techniques (such as Berkeley source code usually do). If an API such as the TLI (see Section. 15) to provide an understanding of the connection request to the application
method and allows applications to choose whether to accept the connection. When the application is supposed to be informed when the connection request has come, TCP three-way handshake is over! Implement other transport layer may be connected to separate between arrival and acceptance (e.g., the OSI transport layer), but not TCP.

Solaris 2.2 provides an option to enable TCP only if the application is acceptable to say (tcp _ eager _l isteners see E. 4), is allowed to accept incoming connection requests.

This behavior also means that the server can not make TCP client's active open failure. When a new client connection to the application server, TCP three-way handshake is over, the client's active open has completed successfully. If the application server at this time to see the client's IP address and port number, and decide whether the service for the client, the server can do is close the connection (send FIN), or reset the connection (send RST). In either case, the client thought everything is normal, because it's open initiative has been completed, and has sent a request to the server program.