UNP client/server program design paradigm note

1. TCP/IP protocol Overview

First, let's review the TCP/IP model and know the operating system layer of each layer;

The bottom two layers of the OSI model are the device drivers and network hardware provided by the system. In general, except for the characteristics of data links,

We don't need to worry about these two layers. The network layer is processed by IPv4 and IPv6 protocols. You can select TCP or UDP as the transport layer. Top three layers of OSI model

It is merged into one layer, called the application layer, which is the layer where all web clients (browsers), Telnet clients, and web servers are located.
It can be seen that the OSI model uses the transport layer as the dividing line; the socket programming interface is the interface for the application layer to enter the transport layer; it also conforms to the abstract purpose: to hide the network on the Application Layer

The application layer only processes specific network applications, while the bottom layer (from the transport layer to the physical layer) does not know much about specific network applications, but does

All communication details: send data, wait for confirmation, sort unordered arrival data, calculate and verify the checksum, and so on. Second, the top three layers are usually composed

The bottom layer is usually provided as part of the operating system kernel. Fully compliant with Unix and other modern operating systems, which provide separate user processes

And kernel mechanism.

2. Basic TCP socket programming

TCP: Transmission Control Protocol. TCP is a connection-oriented protocol that provides a reliable full-duplex byte stream for user processes.

TCP socket is a stream socket ).
TCP cares about details such as validation, timeout, and retransmission. Most network applications use TCP;

The basic client/server model of TCP is as follows:

Take nginx as an example. It works at the application layer, listens to a specified port, and accepts client connections through the process pool or thread pool,

Here is a concept of "surprise group". Let's first look at what is "surprise group "? To put it simply, multithreading/multi-process (there is not much difference between thread processes in Linux)

When the same socket event occurs, these threads/processes are awakened at the same time. It can be imagined that the efficiency is very low and many

The process is awakened by the kernel rescheduling and responds to this event. Of course, only one process can successfully process the event. Other processes are processing the event.

Failed to sleep (there are other options ). This kind of performance waste is a shocking group. The shocking group usually occurs on the server. When the parent process is bound to

Port listening socket, and then fork out of multiple sub-processes, the sub-processes began to process the socket loop (such as accept. Each time a user initiates

When a TCP connection is established, multiple sub-processes are awakened at the same time. Then, the new accept connection of one of the sub-processes is successful, and all the other processes fail and sleep again.

The nginx solution is to allow only one nginx worker to process the listening handle in its epoll at the same time (Here we use

Obtain the accept lock. Only one worker can obtain the lock .)

3. Explore the modern popular network server design architecture for coping with high-concurrency requests;

What is the Client/Server programming paradigm? Simply put, some specific design methods are used to write client/server-related programs. These design methods are summarized to form several fixed

The customer/server program design paradigm is called the customer/server program design paradigm. In fact, most of it is about the server program design paradigm, while the client program is usually compared with the service

Program is easier, because the process control in the customer is much less. However, we will still mention various methods of writing the customer program.

In general, the server design paradigm is divided into two types: cyclic design and concurrent design."Iteration server" and "Concurrent Server".
Iterative server programs are the simplest and easiest to write. However, this type of application is extremely limited, this is because such a server cannot process new customers waiting for the service before it completes the service to the current customer.
There are many ways to implement concurrent servers:

1. 1. Call fork to derive a sub-process for each customer (it is said that apache1.0 does this );
2. Pre-dispatch of the child process (this method is used by the prework module in Apache );
3. Creates a thread for each customer request;
4. Method of creating a thread in advance;
5. Of course, there are also multi-process and multi-thread hybrid models (this method is used by the worker module in Apache );
6. Another special method is to use select in a single process to process any number of customer requests...
   

In most cases, the customer program design can meet the requirements through iteration, although it operates in a stop-and other way. In some special cases, there must be some flexibility.

Method. for example, the client program is blocked during user input, and the network connection events are invisible. in this case, select can be used to notify the process of network events while waiting for user input, or non-blocking I/O can be used. Of course, the customer program can also use fork to dispatch the child process, or use multiple threads to achieve concurrency.

Below we will test various Server Design paradigms and discuss the differences between these paradigms. (Unpv1) mainly includes the following paradigms:

1. Iterative server program customer/server program design paradigm-iterative server program
2. Concurrent Server program. Each customer has one sub-process: customer/server program design paradigm-concurrent server program, and each customer has one sub-process.
3. Pre-dispatch of child process server programs, accept Supreme lock protection "customer/Server programming paradigm-concurrent server programs, accept Supreme lock protection"
4. Pre-Dispatch child process server program, accept uses file lock to protect client/server program design paradigm-concurrent server program, accept uses file lock Protection
5. Pre-Dispatch child process server program, accept uses thread lock to protect client/server program design paradigm-concurrent server program, accept uses thread lock Protection
6. Pre-dispatch of the child process server program, transfer the description word "customer/server program design paradigm-concurrent server program, transfer descriptor"
7. Concurrent Server program, one thread per customer
8. Create a thread server program in advance, and each thread has its own accept
9. Creates a thread server program in advance, and the master thread uses the accept
   

We will run multiple instances of the same client program for each server to measure the CPU time required for a fixed number of requests. Note that the time here refers to the CPU time required for process control, while the iteration server is our benchmark because the iteration server has no process control overhead. Therefore, deduct the actual CPU time of the iteration server from the actual CPU time of other servers to obtain the time required by the corresponding server for process control. (For the comparison results, see the UNP chapter 30th illustration)

After comparison, we can draw the following summative opinions:

1. When the system load is low, it is enough to derive a traditional concurrent server program model for sub-processes to serve each customer request.

2. Compared with the traditional one-time design paradigm of each customer fork, the design paradigm of creating a sub-process pool or sub-thread pool can control the process first.

CPU time is reduced by 10 times or more.

3. Some implementations allow multiple sub-processes or threads to be blocked in the same accept call, while others require the encapsulation of an Accept call

Type locks are protected. File locks or pthread mutex locks are supported.

4. Make all sub-processes or threads call the accept by themselves. Generally, the accept is called by the parent process or the main thread and the descriptor is passed to the sub-process or

The thread is simple and fast.

5. All Sub-processes or threads are blocked in the same accept call than in the same select call due to potential select conflicts.

Is more desirable.

6. The use of the thread is much faster than the use of the process. However, selecting one sub-process for each customer or one thread for each customer depends on the support provided by the operating system,

It may also depend on the call of fork and exec to the server connected to each customer of the service, so the process of fork one single thread may be faster than that of fork one Multithreading

.

Reference: http://blog.chinaunix.net/uid-20788107-id-485103.html