Linux Learning Path-nginx (1) Introduction "22"---20180206

First, Nginx Introduction

• Nginx:engine X, 2002, open Source, Commercial edition

• HTTP protocol: Web server (similar to httpd), HTTP reverse proxy (similar to httpd), IMAP/POP3 reverse proxy,tcp

• NGINX is a free, Open-source, high-performance an HTTP and reverse proxy server, a mail proxy server, and a generic tcp/ud P Proxy Server

• c10k (10K Connections)

• Two times development: Tengine, Openresty

• Official website: http://nginx.org

1. 1, nginx characteristics and basic functions

• Characteristics:

  Modular design, good extensibility

  High reliability

  Support Hot deployment: Non-Stop Update profile, upgrade version, change log file

  Low memory consumption: 10,000 inactive connections in keep-alive connection mode, requiring only 2.5M of memory

  Event-driven,aio,mmap,sendfile

• Basic Features:

  Web server for static resources

  HTTP protocol Reverse Proxy Server

  POP3/IMAP4 protocol Reverse Proxy Server

  FastCGI (LNMP), Uwsgi (Python) and other protocols

  Modular (non-DSO), e.g. ZIP,SSL modules

1. 2, the function of Nginx

• A static Web resource server

  Static resources such as HTML, pictures, Js,css,txt, etc.

• Reverse proxy dynamic resource request with fastcgi/uwsgi/scgi and other protocols

• Reverse Proxy for HTTP/HTTPS protocol

• Reverse Proxy for IMAP4/POP3 protocol

• Request forwarding of the TCP/UDP protocol (reverse proxy)

1. 3. Nginx Program Architecture

• web Service-related features:

         support for keep-alive and pipe connections

         access logs (supports improved performance based on log buffering)

        url rewirte

        path alias

        IP and user-based access control

        support rate limit and concurrency limit

         reconfiguration and online upgrades without interrupting customer's work process

      GET interface for   memcached

• nginx program Architecture:

         a master process:

             load load and analyze profiles, manage worker processes, smooth upgrade

             handles and responds to user requests

         Cache-related processes:

            cache Loader: Load Cache object

            cache Manager: Managing Cache objects

1. Ii. introduction of I/O
   

• / o:

  Network IO: Essentially a socket read

  Disk IO:

• Each IO is routed through two stages:

  First step: Load the data from the disk file into the kernel memory space (buffer), waiting for the data to be ready for a long time

  Step Two: Copy the data from the kernel buffer into the memory of the process of the user space for a short time

1. 1. Concrete implementation of I/O model

• There are several main ways to achieve this:

• Select:linux implementation of the corresponding, I/O multiplexing model, BSD4.2 the earliest implementation

• Poll:linux implementation, corresponding to the I/O multiplexing model, System V UNIX was first implemented

• Epoll:linux implementation, corresponding I/O multiplexing model with some characteristics of the signal-driven I/O model

• KQUEUE:FREEBSD implementation, corresponding I/O multiplexing model with some characteristics of the signal-driven I/O model

• /dev/poll:sun Solaris Implementation, corresponding I/O multiplexing model with some features of the signal-driven I/O model

• IOCP Windows implementation, corresponding to the 5th (asynchronous I/O) model

1. 2, Select/poll/epoll

• Select:posix is currently supported on almost all platforms, and its good cross-platform support is also an advantage, essentially by setting up or checking the data structure that holds the FD flag bit for the next step

• cons

         the number of FD that a single process can monitor is limited, that is, the number of ports that can be monitored

            cat/proc/sys/fs/file-max

• poll

         is essentially no different from Select, it copies the user's incoming array to the kernel space and then queries each FD for the device state

       poll feature is "horizontal trigger", if the FD is reported and is not processed, the FD

        Edge Trigger: Notify only once

• epoll: Enhanced version of Select and poll presented in the Linux 2.6 kernel

  Support for the level trigger LT and edge Trigger ET, the biggest feature is the Edge trigger, which only tells the process which FD has just become the desired state, and will only notify once

  Using the "event" ready notification method, the FD is registered via Epoll_ctl, and once the FD is ready, the kernel uses a callback mechanism similar to callback to activate the fd,epoll_wait to receive notification

• Advantages:

  There is no limit to the maximum number of concurrent connections: the upper limit of the FD that can be opened is greater than 1024x768 (1G of memory can monitor about 100,000 ports)

  Efficiency improvement: The non-polling method does not decrease in efficiency as the number of FD increases; only active FD calls the callback function, which means that Epoll's greatest advantage is that it manages only "active" connections, regardless of the total number of connections

  Memory copy, which uses the mmap () file to map memory to accelerate message delivery to kernel space, that is, Epoll uses mmap to reduce replication overhead

1. 3. I/O model

•       Synchronization: Synchronous, the caller has voluntarily waited for the callee to return a message in order to continue execution of

         Async: Asynchronous, the callee actively notifies the caller of the running state of the callee by state, notification, or callback mechanism

• blocking/non-blocking: focus on the status of the caller before waiting for the result to return

        Block: Blocking, the IO operation needs to be completely completed before returning to the user space, the caller is suspended until the call results are returned

• I/O model:

       -blocking, nonblocking, multiplexed, signal-driven, asynchronous

1. 4. Synchronous Blocking IO Model

• The synchronous blocking IO model is the simplest IO model, and user threads are blocked when the kernel is IO-operated

• The user thread initiates an IO read operation through the system call read, which is transferred from the user space to the kernel space. The kernel waits until the packet arrives, then copies the received data to the user space, completing the read operation

• The user waits until read reads the data into buffer before continuing to process the received data. During the entire IO request, the user thread is blocked, which causes the user to not do anything when initiating the IO request, and the CPU resource utilization is insufficient.

1. 5. Synchronous non-blocking IO model

• Returned immediately when the user thread initiates an IO request. However, no data is read, and the user thread needs to constantly initiate an IO request until the data arrives and the data is actually read to continue execution. That is, "polling" mechanism

• Throughout the IO request process, although the user thread can return immediately after each IO request, but in order to wait until the data, still need to continuously poll, repeated requests, consumes a lot of CPU resources

• is a waste of CPU, generally very few direct use of this model, but in other IO models using the non-blocking IO feature

1. 6, IO multiplexing model

• The user will first add the IO operation to the Select and proceed to do other work (async) while waiting for the select system call to return. When the data arrives, IO is activated and the Select function returns. The user thread formally initiates a read request, reads the data, and continues execution.

• Although the above approach allows multiple IO requests to be processed in a single thread, However, the process of each IO request is still blocked (blocking on the Select function), and the average time is even longer than the synchronous blocking IO model. If the user thread simply registers the IO request that it needs, and then does its own thing and waits until the data arrives, it can increase the CPU utilization

• io multiplexing is the most commonly used IO model, but it is not asynchronous enough to be "thorough" because it uses a select system call that blocks threads. So IO multiplexing can only be called an asynchronous blocking IO model, not a true asynchronous IO

1. 7. Multi-channel I/O multiplexing

• Io multiplexing refers to a kernel that notifies a process when it is ready to read one or more of the IO conditions specified by the process

• IO multiplexing is suitable for the following applications:

  When a client handles multiple descriptors (typically interactive input and network socket interfaces), I/O multiplexing must be used

  This situation may but rarely occur when a client processes multiple sockets at the same time

  When a TCP server handles both the listening socket interface and the connected socket interface, I/O multiplexing is usually used

  When a server is dealing with TCP and UDP, it is generally used I/O multiplexing

  When a server is dealing with multiple services or multiple protocols, I/O multiplexing is generally used

1. 8. Signal-driven IO model

• Signal-driven io:signal-driven I/O

• The user process can register a signal handler through the sigaction system call, and then the main program can continue execution down, when an IO operation is ready, a Sigio signal handler is triggered by the kernel notification, and then the data required by the user process is copied from the kernel space to the user space

• The advantage of this model is that the process is not blocked while waiting for the datagram to arrive. The user main program can continue to execute as long as the notification from the signal processing function waits

• The model is not commonly used

1. 9. Asynchronous IO Model

• The main difference between asynchronous IO and signal-driven IO is that the signal-driven IO is the kernel notifies when IO operations can be performed, while asynchronous IO is the kernel that tells us when the IO operation is complete. Specifically, signal-driven IO when the kernel notifies the triggering signal handler, the signal handler also needs to block the process of copying data from the kernel space buffer to the user space buffer, and the asynchronous IO is directly notified by the kernel directly after the second phase is complete.

• Compared to the IO Multiplexing model, asynchronous IO is not very common, and many high performance concurrent service programs use the IO multiplexing model + multi-threaded task processing architecture to meet the requirements. In addition, the current operating system support for asynchronous IO is not particularly perfect, more is the use of IO multiplexing model to simulate the asynchronous IO mode (IO Event trigger does not directly notify the user thread, but the data is read and written into the user-specified buffer)

1. 10. Comparison of five I/O models

Linux Learning Path-nginx (1) Introduction "22"---20180206