One, Nginx features
Nginx uses scalable event-driven, not a traditional process-driven architecture.
In the traditional Web server architecture, each client connection is handled as a separate process or thread. As the popularity of the website increases and the number of concurrent connections increases, the Web server slows down and delays the response to the user.
From a technical point of view, spawning a single process/thread requires switching the CPU to a new task and creating a new runtime context, which consumes additional memory and CPU time, which has a negative impact on performance.
The goal of Nginx development is to achieve more than 10 times the performance, optimize the use of server resources, and at the same time be able to expand and support the dynamic growth of the website. Therefore, Nginx has become one of the most well-known modular, time-driven, asynchronous, single-threaded web servers and web proxies.
Nginx is a high-performance web and reverse proxy server. It has many very superior features:
1) As a web server,
compared to Apache, Nginx uses fewer resources, supports more concurrent connections, and reflects higher efficiency. This makes Nginx especially popular with virtual hosting providers. It can support up to 50,000 concurrent connections. Thank you Nginx for choosing epoll and kqueue as our development model.
2) As a load balancing server,
Nginx can directly support Rails and PHP internally, and can also support external services as an HTTP proxy server. Nginx is written in C, and it is much better than Perlbal in terms of system resource overhead and CPU usage efficiency.
3) As a mail proxy server,
Nginx is also a very good mail proxy server (one of the earliest purposes of developing this product is also as a mail
proxy server), Last.fm described successful and wonderful experience.
Nginx installation is very simple, the configuration file is very concise (also able to support perl syntax), a server with very few Bugs.
Nginx is particularly easy to start, and it can almost run 7*24 uninterrupted, even if it runs for several months, it does not need to be restarted.
You can also upgrade the software version with uninterrupted service.
Two, Nginx architecture
Nginx makes extensive use of multiplexing and event notifications, and is dedicated to specific tasks of separating processes. Connections are handled in an efficient running loop called a worker in a limited number of single-threaded processes. In each worker, nginx can handle thousands of concurrent connections and requests per second.
2.1 Code structure
Nginx work (worker) code includes core and functional modules. The core of nginx is responsible for maintaining a strict operating cycle and executing appropriate parts of the module code at each stage of request processing. Modules constitute most of the presentation and application layer functions. The module reads and writes to the network and storage, converts content, performs outbound filtering, contains operations on the application server, and passes requests to the upstream server when the agent starts.
The modular architecture of nginx usually allows developers to extend a set of web server functions without modifying the nginx kernel. The nginx module is slightly different, namely the core module, event module, stage handler, protocol, variable handler, filter, upstream and load balancer. nginx does not support dynamically loaded modules; that is, modules are compiled with the core during the build phase.
When dealing with various operations related to receiving, processing and managing network connections and content retrieval, nginx uses event notification mechanisms and some disk I/O performance enhancements in Linux, Solaris and BSD-based operating systems, such as: kqueue, epoll , And event port. The goal is to provide the operating system with as many prompts as possible in order to obtain timely asynchronous feedback such as inbound and outbound traffic, disk operations, read or write sockets, timeouts, etc. For each operating system running on Unix-based nginx, the use of different methods of multiplexing and advanced I/O operations has been optimized.
2.2 Working mode
Nginx does not generate a process or thread for each connection. Instead, the worker process accepts new requests from the shared "listen" socket and executes an efficient run loop within each worker to handle thousands of connections in each worker.
Worker is completed by the operating system kernel mechanism.
After startup, a set of initial listening sockets will be created, and then workers will continue to accept, read, and write sockets while processing HTTP requests and responses. The run loop is the most complicated part of nginx worker code. It includes comprehensive internal calls and relies heavily on the idea of asynchronous task processing. Asynchronous operations are achieved through modularization, event notification , extensive use of callback functions and fine-tuning timers . Overall, the key principle is to not block as much as possible.
The only situation where nginx can still block is when the worker process does not have enough disk storage .
Memory: In most cases, memory usage is very conservative and very effective, because nginx will not connect to a process or thread.
CPU: Save CPU cycles because there is no continuous "create-destroy" mode for processes or threads.
The role of nginx is to check the status of the network and storage, initialize a new connection, add it to the run loop, and process it asynchronously until completion, at which point the connection is reallocated and removed from the run loop. Combined with careful use of system calls (syscall) and precise implementation of supporting interfaces (such as pool and slab memory allocators), nginx can usually achieve moderate to low CPU usage under extreme workloads.
In some disk usage and CPU load patterns, the number of nginx workers should be adjusted. Suggestions:
1) If the load mode is CPU-intensive, if you need to process a large amount of TCP/IP, perform SSL or compression, the number of workers should match the number of CPU cores.
2) If the load mode is disk IO binding, such as different content collections from storage or heavy proxy services, the number of workers may be 1 to 2 times the number of cores.
Existing worker mode problems, the following two types of behavior will immediately cause the worker to hang, and affect thousands of connections at the same time.
- Problem 1: Most of the blocking on disk I/O. If there is not enough storage performance to provide disk operations generated by a particular work (worker), the work (worker) may still prevent reading/writing from the disk.
- Question 2: Related to the limited support of embedded scripts. One uses the standard nginx distribution and only supports embedding Perl scripts. A simple explanation: The key issue is the possibility of embedded scripts preventing any operation or unexpected exit.
2.3 Process role
nginx is running multiple processes in memory; a main course and a few work (worker) process . There are also some special-purpose processes, especially cache loaders and cache managers. All processes are single-threaded nginx version 1.x.
All processes mainly use shared memory mechanism for inter-process communication. The main process runs as the root user. The cache loader, cache manager and worker are not authorized to restrict users from running.
》》The main process is responsible for the following tasks:
- Read and verify configuration
- Create, bind and close sockets
- Number of worker processes to start, terminate and maintain the configuration
- Reconfiguration without service interruption
- Control uninterrupted binary upgrades (start new binary and roll back if necessary)
- Reopen the log file
- Compile embedded Perl script
》》The worker process accepts and processes connections from clients, provides reverse proxy and filtering functions, and performs almost all other nginx capabilities. Regarding monitoring the behavior of nginx instances, system administrators should pay attention to worker processes because they reflect the actual daily operations of web services.
》》The cache loader process is responsible for checking disk cache items and filling nginx's in-memory database with cache metadata. Essentially, the cache loader prepares the nginx instance to process files that have been stored on disk in a specific allocated directory structure. It traverses the directory, checks the cache content metadata, updates the related entries in the shared memory, and then exits when all the inner cylinders are clean and ready for use.
"" Cache Manager main responsible for cache expiration and ineffective. It remains in memory during normal nginx operations and is restarted by the main process in the event of a failure.
2.4 Cache
The cache in nginx is implemented in the form of hierarchical data storage on the file system.
The cache key is configurable, and different request-specific parameters can be used to control the inner cylinder that enters the cache. The cache key and cache metadata are stored in the shared memory segment, the cache is loaded, and the cache manager and workers can access them. The hierarchy (level and naming details) is controlled by nginx configuration directives. When the response is written into the cache directory structure, the path and name of the file will be derived from the MD5 hash of the proxy URL.
The process of putting content into the cache:
- When nginx reads the response from the upstream server, the content is first written to a temporary file outside the cache directory structure.
- When nginx finishes processing the request, it renames the temporary file and transfers it to the cache directory.
If the temporary file directory used for the agent is located on another file system, the file will be copied. Therefore, it is recommended to save the temporary file directory and the cache directory on the same file system. Therefore, it is recommended to store the temporary file directory and the cache directory on the same file system.
Three, Nginx application
3.1 Some instructions for Nginx installation and operation
1. When installing
Nginx, you need to install some dependent libraries.
- pcre: Responsible for making regular expressions.
- openssl: Used for MD5 authentication and NTPS encryption.
- zlib: used for compression.
2. Operation
- Start: sudo ./sbin/nginx -c ./conf/nginx.conf
- Shut down the service quickly: ./sbin/nginx -s stop
- Shut down the service normally: ./sbin/nginx -s quit
- Reload the configuration file: ./sbin/nginx -s reload
- Reopen the log file: ./sbin/nginx -s reopen
3.2 Layer 4 and Layer 7 load balancing
Hierarchical model
1) Four-layer load balancing
Definition:
Four-layer load balancing works at the transport layer of the OSI model. Because in the transport layer, there is only TCP/UDP protocol. In addition to the source IP and destination IP, the two protocols also contain the source port number. And the destination port number. After receiving the client request, the Layer 4 load balancing server forwards the traffic to the application server by modifying the address information ( IP+port number ) of the data packet .
2) Seven-layer load balancing
Definition:
Seven-layer load balancing works at the application layer of the OSI model. There are many application layer protocols, such as http, radius, dns and so on. The seven-layer load can be loaded based on these protocols. These application layer protocols will contain a lot of meaningful content. For example, in the load balancing of the same Web server, in addition to performing load based on IP and port, it can also be determined whether to perform load balancing based on the seven-layer URL, browser category, and language.
3) The difference between the fourth and seventh floors
- The fourth layer receives the request through the virtual IP+port, and then distributes it to the real server
- The seventh layer receives requests through virtual URLs or host names, and then distributes them to real servers
- The four-layer switch mainly analyzes the IP layer and the TCP/UCP layer to realize the four-layer traffic load balance
- In addition to supporting Layer 4 load balancing, Layer 7 switches also analyze application layer information, such as HTTP protocol, URI or Cookie information
- The essence of four-layer load balancing is forwarding, and the essence of seven-layer load balancing is content exchange and proxy
If it is http, choose nginx as the proxy, if it is tcp, use haproxy. Nginx can be used for seven-layer load balancing.
3.3 Application
3.3.1 Load balancing
Server topology:
Work flow: The
access machine first accesses the router, and then to Nginx, and Nginx then distributes the data to other services in the same LAN.
The router is also called the gateway, and nginx is the application gateway. The router to nginx is through port mapping (directly configured through the router or switch). When the external machine accesses the router port, it directly corresponds to the machine of the nginx subnet. Therefore, it feels like nginx is connected to the public network.
For example, the external access address provided by the router is 112.93.116.78.8080, which is mapped to the nginx service 192.168.1.123.80.
DNS does load balancing.
One domain name maps multiple IP addresses, such as www.xzq.com -> multiple IP addresses can be obtained when the domain name is resolved (it has nothing to do with the port), and the first IP address may be the first response , The second response may be the second IP address, what is done here is load balancing.
The load balancing has nothing to do with development, only the configuration number is needed, and the others don't care.
Features: The response is not so timely. Assuming that a machine is down, it may take up to 10 minutes to synchronize to other domain names.
》Conf file
The most commonly used core in development is the conf file.
The parsing principle of the conf file: parse the worker_processes parameter in the conf file, find the source code ngx_core_module function through source code search, and put all modules in the ngx_modules array.
conf file configuration instructions
#每个worker_processes进程对应的连接数--每一个连接，可读可写的时候就是事件
events {
worker_connections 1024;
}
#http协议模块，如果是自己封装的通信协议，也可以在配置文件中作为一个模块
http {
server {
#80为http默认端口，自定义端口最好大于1024
listen 8080;
server_name localhost;
#客户端请求body最大数量 网页设置小些，视频文件设置大些
client_max_body_size 100m;
#要访问的网页或者文件
location / {
root /usr/local/nginx/html/www;
}
location /images/ {
root /usr/local/nginx/html;
}
}
}
》Http request
http request a relatively large file, there is a header range: 0-1024, there is a corresponding request location, if the file size in the server is 500M, each time you can take 25M, determine the start and end positions (position Defined by the requesting client), you can use 20 threads to download at the same time. For example, the first thread requests 0-25, the second thread requests 26-50M...
Question: Does writing to the same file with 20 threads return to single-threaded processing?
The file size has been allocated in advance, and each thread can write to a certain location.
Question: There is only one head, is it single-threaded to write to the disk?
Disk SSD writing can reach 1G/s, and software writing is generally faster at 100M/s. The bottleneck here is not a disk problem.
Q: Is it possible to split a resumable transfer? If so, how to ensure the order?
Breakpoint resumable transmission also requires fragmentation, but it is not possible to resumable one byte by one byte:
1) When multiple threads download a file at the same time, it is necessary to determine the start and end positions of each thread.
2) Resuming the transfer at a breakpoint, remembering the end position of the previous time as the beginning of the next time.
3.3.2 Acting as an agent
1. Agent
A requests 123, and 123 will actually send the data to 168 for processing. 123 is an agent.
Example: The
IP address of the 123 server is 192.168.139.132, and the address of the 168 server is 192.168.139.133.
1) The nginx.conf configuration file of 123 service is:
events {
worker_connections 1024;
}
http {
server {
listen 8080;
server_name localhost;
location / {
proxy_pass http://192.168.139.133;
}
}
}
2) The nginx.conf configuration file of 168 service is:
events {
worker_connections 1024;
}
http {
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
}
}
3) Start 123 server Nginx, 168 server Nginx
./sbin/nginx -c ./conf/nginx.conf
4) Use the webpage to access 123 service.
You can see that the displayed webpage data is the data of 168 service.
2. The
nginx.conf configuration file of multiple agents can be modified as follows:
events {
worker_connections 1024;
}
http {
upstream backend{
server 192.168.139.133 weight=2;
server 192.168.139.134 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http:// backend;
}
}
}
When you request the Nginx service on the web page, you can see that the displayed web page is constantly switching between 192.168.139.133 and 192.168.139.134 services.
Specify the polling probability, the weight is proportional to the access ratio, which is used when the back-end server performance is uneven.
Then, usually only 1 time will visit 192.168.139.134, and 2 times will visit 192.168.139.133.
3.3.3 Access pictures
1) Create a new images folder in Nginx, the folder stores three pictures 1.jpg 2.jpg 3.jpg.
2) Modify the nginx.conf configuration file
events {
worker_connections 1024;
}
http {
upstream backend{
server 192.168.139.133 weight=2;
server 192.168.139.134 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http:// backend;
}
location /images/ {
root ./;
}
}
}
3) Webpage access pictures:
3.3.4 Access video
1) Create a media folder in Nginx, and the folder will store the video file RB.mp4.
2) Modify the nginx.conf configuration file
events {
worker_connections 1024;
}
http {
upstream backend{
server 192.168.139.133 weight=2;
server 192.168.139.134 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http:// backend;
}
location /images/ {
root ./;
}
location ~ \.(mp3|mp4) {
root media;
}
}
}
Static resources can be configured using the above two methods, such as css, js, png.
3.3.5 CGI public gateway interface
CGI is a process. When a client requests a Web server, the server converts some response data to CGI, and the calculated result is returned to the Web server.
Q: What is the difference between CGI and the back-end Server?
CGI provides external input and output streams, such as std cout, printf, and prints directly to web pages. Server's protocol is http protocol.
Q: Where exactly is CGI used? In which scenarios must CGI be used?
Online compilation tool, when you submit the code, the compilation tool can give you real-time output results, which is implemented using CGI.
Q: What is the difference between CGI and fastcgi?
CGI is a request-to-process mode, fastcgi: start the process pool to wait.
Q: How does Nginx do CGI?
Need to use two tools fcgi and spawn-fcgi. Among them:
fcgi: CGI library file, we can develop CGI through the interface here.
spawn-fcgi: A tool to start CGI.
CGI programming
1) spawn-fcgi compilation: After decompression, go to the folder and execute ./configure, then execute make, and then copy spawn-fcgi in the src file to the sbin folder of Nginx.
2) fcgi compilation: After decompression, go to the folder and execute ./configure, and then execute make.
At this time, the following compilation error message may appear:
We can solve it by adding #include <stdio.h> in the include/fcgio.h header file.
Finally, execute sudo make install.
3) Source code example
- coding
#include <stdio.h>
#include <fcgi_stdio.h>
int main()
{
while(0 <= FCGI_Accept())
{
printf("Content-type:text/html\r\n");
printf("\r\n");
printf("<title> Fast CGI Hello!</title>");
printf("<h1>ZVoice cgi</h1>");
printf("Thank you cgi\n");
}
}
-
Compile
Compile CGI program:gcc –o zvoice_cgi zvoice_cgi.c -lfcgi -
run
./zvoice_cgi
It was found that the program failed to run and the corresponding library file could not be found error:
So I checked the installation of the cgi library file from the beginning, from ./configure to make to sudo make install, there was no problem, but the error was still reported.
At this time, we think about it. The library file has been installed but the call failed. It should be the system did not recognize it. At this time, we set the dynamic library to be shared by the system, execute the command:, sudo ldconfigand then run the program to find that the program runs successfully.
ldconfig: dynamic library management, so that the dynamic library is shared by the system, and the newly installed so is shared by the system.
-
Start the CGI program:
./spawn-fcgi -a 127.0.0.1 -p 9002 -f /home/ubuntu/nginx/zvoice_cgi -
Configure Nginx conf file
events {
worker_connections 1024;
}
http {
upstream backend{
server 192.168.139.133 weight=2;
server 192.168.139.134 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http:// backend;
}
location /images/ {
root ./;
}
location ~ \.(mp3|mp4) {
root media;
}
}
server{
listen 9000;
location ~ \.cgi{
fastcgi_pass 127.0.0.1:9002;
fastcgi_index index.cgi;
fastcgi_param SCRIPT_FILENAME cgi$fastcgi_script_name;
include ../conf/fastcgi_params;
}
}
}
-
Restart Nginx
-
Visit the webpage: http://192.168.139.132:9000/zvoice_cgi.cgi
