Interviewer: Tell me how Nginx handles requests? Why doesn't Nginx use a multi-threaded model? What are the Nginx load balancing algorithms? What are forward and reverse proxies?

Interviewer: Can you tell me how Nginx handles requests?

When a client initiates a request, the Nginx worker process listens to the network port and receives the client's connection request. The following is the specific process of Nginx processing the request:

(1) Receiving a connection request: After Nginx receives a connection request from a client, it allocates a connection object (ngx_connection_t) for the connection. The connection object contains connection status information, read and write event handlers, etc.

(2) Reading request header information: Nginx reads request header information from the client. The request header contains the HTTP method (such as GET, POST), URL, HTTP version, and various request header fields (such as Host, User-Agent, Content-Length, etc.).

(3) Parsing request header information: Nginx parses the request header information and extracts necessary parameters, such as request method, URI, Host, etc. The parsed request header information is stored in the ngx_http_request_t structure.

(4) Find matching virtual hosts and location blocks:

• Nginx looks for a matching virtual host (server block) based on the Host field in the request header. Each virtual host can be configured with a different domain name and listening port.
• After finding a matching virtual host, Nginx continues to look for a location block that matches the request URI. The location block defines how to handle requests for a specific path.

(5) Execution processing phase: Nginx's request processing is divided into multiple phases, each of which can be processed by multiple modules. These phases include:

• rewrite phase: Execute rewrite rules, such as URL rewriting.
• post rewrite phase: Processes the request after rewriting.
• preaccess phase: performs checks before access control, such as IP address filtering.
• Access phase: Perform access controls, such as authentication.
• postaccess phase: processing after access permission control.
• try-files: Try to access a file or directory.
• Content phase: Generate response content, such as static file service, reverse proxy, FastCGI, etc. In this phase, Nginx generates response content according to the configuration, which may involve reading static files, calling backend services (such as reverse proxy, FastCGI, uWSGI, etc.), generating dynamic content, etc.

(6) Generate and send a response:

• Nginx sends the generated response header back to the client. The response header contains the HTTP status code and response header fields (such as Content-Type, Content-Length, etc.).
• Nginx sends the generated response body back to the client. The response body can be static file content, data returned by the backend service, etc.

(7) Close the connection: Once the response is sent, Nginx closes the connection. If keep-alive connections are enabled, the connection can remain open for subsequent requests.

Interviewer: What is the process architecture of Nginx? Why doesn't Nginx use a multi-threaded model?

1. Process Model

Nginx uses a Master-Worker multi-process architecture, which is designed to ensure separation of responsibilities in order to better manage system resources, concurrent request processing, and fault recovery.

(1) Master-Worker architecture:

① Master Process:

• The core component of Nginx, responsible for initializing Nginx, loading configuration files, creating Worker processes, etc.
• Watch for changes to configuration files and reload the configuration without restarting.
• Manage the life cycle of the Worker process, including starting, stopping, and managing the Worker process.
• It does not directly process client requests, but is used to control and manage Worker processes.

② Worker Process

• Nginx's working process is responsible for processing client requests.
• Each Worker process is a complete Nginx server, and multiple Worker processes are peers.
• Each Worker process can handle tens of thousands of concurrent connections, and Nginx's event model can automatically select the appropriate event notification mechanism (such as epoll) based on the system load.

(2) Inter-process collaboration:

• The Master process and the Worker process communicate through signals and shared memory. The Master process sends signals to the Worker process to manage their life cycle (such as starting, stopping, restarting, etc.).
• Worker processes share and synchronize necessary data through shared memory and inter-process communication (IPC) mechanisms.

(3) Load balancing:

Nginx implements load balancing through a multi-process model. When new client connection requests arrive, these connections are evenly distributed to each Worker process to achieve load balancing. This design ensures that Nginx can efficiently handle a large number of concurrent connections and avoids a single process becoming a bottleneck.

(4) High availability:

Nginx's multi-process model also provides high availability. When a Worker process fails, the Master process will automatically restart a new Worker process to replace the original process, thereby ensuring high availability of the server. This design enables Nginx to run stably under high load and complex environments.

2. Why doesn’t Nginx use a multi-threaded model?

Nginx chooses not to use a multi-threaded model, but an event-driven model with multiple processes and asynchronous non-blocking I/O, mainly based on the following reasons:

(1) Resource isolation and stability

• In the multi-process model, each worker process is independent and does not share memory space between them (except for communication through specific mechanisms such as shared memory). This isolation ensures that the crash of one worker process will not affect other processes, thereby improving the stability of the entire system.
• In a multi-threaded model, threads share the memory space of the process, which may lead to data competition, deadlock and other problems between threads, increasing the complexity of the system and the difficulty of debugging.

(2) Utilizing multi-core CPUs

• Nginx's multi-process model can make good use of the process scheduling mechanism provided by modern operating systems to assign working processes to different CPU cores to run, thereby achieving parallel processing.
• Although the multi-threaded model can also take advantage of multi-core CPUs, the creation, switching, and synchronization overhead of threads is usually higher than that of processes, especially in high-concurrency scenarios.

(3) Avoid thread competition and deadlock

• In a multi-threaded model, multiple threads may access shared resources (such as memory, files, etc.) at the same time, which requires the use of lock mechanisms to ensure data consistency and security. However, the use of locks often leads to thread contention and deadlock problems, reducing system performance.
• Nginx avoids the use of locks by adopting asynchronous non-blocking I/O and an event-driven model, thereby reducing the risk of thread contention and deadlock.

(4) Simplify the programming model

• Nginx's multi-process plus asynchronous non-blocking I/O model is relatively simple and clear, making it easier for developers to understand and maintain the code.
• Multithreaded programming often involves complex thread synchronization and communication mechanisms, which increases the complexity of programming and the possibility of errors.

(5) Design intention

• Nginx was originally designed to provide a high-performance, low-resource Web server and reverse proxy server. At the beginning of the design, the developers of Nginx chose a multi-process plus asynchronous non-blocking I/O model, which has been used ever since.
• The Nginx community and developer groups also tend to maintain this design philosophy to ensure the stability and performance advantages of Nginx.

Interviewer: What are forward proxy and reverse proxy? How does Nginx implement forward proxy and reverse proxy functions?

The reverse proxy function means that the proxy server accepts connection requests from the Internet, then forwards these requests to the server on the internal network, and returns the response obtained from the internal server to the client requesting the connection on the Internet. In this process, the proxy server appears as a server to the outside world.

Generally speaking, the proxy server and the backend service in a reverse proxy are in the same group and are bound together. The client does not know who it is actually requesting.

Real-world examples of reverse proxies include load balancing servers, network security protection (anti-DDoS attacks), and content distribution networks (CDNs).

Nginx implements reverse proxy function mainly by configuring the Nginx server to make it an intermediary between the client and the target server. The following are the specific steps and key points for Nginx to implement reverse proxy function:

(1) Configure Nginx:

Nginx's reverse proxy configuration is mainly performed in the nginx.conf file, or in the included sub-configuration files.

• Listening port: Set the port that Nginx listens on. The default port is 80, which is used to receive HTTP requests.
• Server Name: Defines the domain name that the Nginx server responds to.
• Location block: matches the requested URI and defines corresponding operations, such as reverse proxy.
• Reverse proxy directive (proxy_pass): Specifies the URL of the backend server to which requests should be forwarded.

(2) Configuration example:

A basic reverse proxy configuration example is as follows:

 http { server { listen 80; # 监听80端口server_name example.com; # 服务器名称location / { proxy_pass http://backend-server:8080; # 后端服务器地址与端口proxy_set_header Host $host; # 保留原始Host头proxy_set_header X-Real-IP $remote_addr; # 传递真实客户端IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 传递请求协议(http/https) # 其他可选配置，如缓存、超时、重试等} } }

A forward proxy is used to forward the client's request to the target server and return the server's response to the client. In this way, the client sends the request to the proxy server, which sends the request to the target server on behalf of the client and returns the target server's response to the client. Through a forward proxy, the client can directly access the external network without establishing a direct connection with the target server.

Real-world examples of forward proxies include: VPN.

As a high-performance Web server and reverse proxy server, Nginx can also implement forward proxy function. The following are the specific steps and configuration methods for Nginx to implement forward proxy:

How to configure Nginx forward proxy

Since the default Nginx release does not support the forward proxy function, you need to use the third-party plug-in ngx_http_proxy_connect_module to complete it. Add the forward proxy configuration in the configuration file, for example:

 server { listen 3128; # 监听端口resolver 114.114.114.114; # DNS解析器proxy_connect; # 允许CONNECT请求proxy_connect_allow 443 563; # 允许连接的端口proxy_connect_connect_timeout 10s; # 连接超时时间proxy_connect_data_timeout 10s; # 数据传输超时时间location / { proxy_pass http://$host; # 转发请求到目标服务器proxy_set_header Host $host; # 设置请求头} }

In the above configuration, the listen directive specifies the port that Nginx listens on, the resolver directive specifies the address of the DNS resolver, the proxy_connect directive and other directives are used to configure the processing of CONNECT requests, and the location directive and proxy_pass directive are used to specify which target server to forward the request to.

Interviewer: What is the separation of dynamic resources and static resources? Why do we need to separate dynamic and static resources? How does Nginx separate dynamic and static resources?

Separation of dynamic resources from static resources (referred to as dynamic and static separation) is a common Web application architecture pattern.

1. Dynamic resources and static resources

(1) Static resources

When a user accesses a resource multiple times, if the source code of the resource does not change, then the resource is called a static resource. Common static resources include images (img), style sheets (css), script files (js), videos (mp4), etc. These resources can usually be cached by browsers and CDN (content delivery network) to reduce repeated requests to the server.

(2) Dynamic resources

If the source code of a resource may change when a user accesses it multiple times, then the resource is called a dynamic resource. Common dynamic resources include server-side scripts or template files such as JSP and FTL. These resources usually need to dynamically generate response content based on user requests.

2. Reasons for separation of movement and stillness

(1) Performance optimization

There are differences in the processing and distribution of dynamic content and static content. Separating them allows them to be optimized separately, thereby improving overall performance. For example, static resources can be directly processed and served by a dedicated static resource server (such as Nginx), while dynamic resources are processed by the application server. This can significantly reduce the number of requests to the dynamic resource server and reduce its load.

(2) Cache Management

Static resources are easy to cache, while dynamic resources are usually not suitable for caching or require more sophisticated cache control. By separating dynamic and static resources, you can better manage cache strategies, improve cache hit rates, and reduce server response time and bandwidth consumption.

(3) Load Balancing

After separation, resources can be optimally allocated according to content type to achieve more effective load balancing. For example, the number and scale of dynamic resource servers can be increased in a targeted manner according to the access volume and characteristics of dynamic resources to cope with high concurrent access requirements.

(4) Security enhancement

Static content servers usually do not need to execute complex program code, so the attack surface is smaller and security risks can be reduced. Separating them from servers that execute dynamic code can reduce potential security threats.

The following is the specific implementation of Nginx dynamic and static separation:

3. Configuration method

In Nginx, you can use the location directive to achieve dynamic and static separation. The location directive is used to match the request URI and distribute the request to different processing modules according to different paths.

(1) Static resource processing

In the above configuration, location /static/ and location /images/ match requests starting with /static/ and /images/ respectively, and Nginx will search for the corresponding files in the specified root directory. If the file exists, Nginx will directly return the file to the client. location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ uses regular expressions to match all requests ending with these extensions and sets the cache expiration time and Cache-Control header.

Static resources are usually processed directly by Nginx, so the directory of static resources can be specified in the location block.

Use regular expressions to match file extensions of static resources, such as .jpg, .jpeg, .png, .gif, .ico, .css, .js, etc.

Configuration example:

 server { listen 80; server_name www.example.com; # 静态资源处理 location /static/ { root /var/www/example; } location /images/ { root /var/www/example; } location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { root /var/www/example; expires 30d; # 设置静态资源的缓存过期时间 add_header Cache-Control "public"; # 添加Cache-Control头部，强化浏览器缓存行为 } }

(2) Dynamic request processing

For dynamic requests, the requests can be forwarded to the backend application server (such as PHP-FPM, Django, Node.js, etc.) for processing.

Configuration example:

 server { listen 80; server_name www.example.com; # 动态请求处理 location ~ \.php$ { root /var/www/example; fastcgi_pass 127.0.0.1:9000; # 指定将这些请求转发给PHP-FPM服务器处理 fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

In the above configuration, location ~ \.php$ uses a regular expression to match all requests ending with .php and treats them as dynamic requests. fastcgi_pass specifies that these requests are forwarded to the PHP-FPM server for processing, and 127.0.0.1:9000 is the listening address of PHP-FPM. Other parameters are used to set FastCGI parameters and the file path of the request.

4. Notes

(1) Nginx location matching priority

Nginx's location matching follows specific priority rules, including exact matching (using the = symbol), regular expression matching (using ~ or ~*), and prefix matching (ordinary location). When configuring multiple location blocks, you need to carefully consider the priority relationship between them to ensure correct request routing.

(2) Cache strategy

By properly configuring the cache, you can significantly improve website performance. Nginx provides a powerful and flexible cache function, which can be implemented through the proxy_cache_path and proxy_cache directives. For static resources, you can set a longer cache expiration time to reduce repeated requests to the server.

(3) Security

By separating static and dynamic content, you can separate static content servers from servers that execute dynamic code, thereby reducing security risks. Static content servers usually do not need to execute complex program codes, so the attack surface is smaller.

Interviewer: What are the algorithm strategies for Nginx load balancing?

1. Round Robin

Principle: The polling algorithm distributes requests in the order of the server list. When a new request arrives, Nginx will assign it to the next server in the list. If it reaches the end of the list, the cycle will start again.

Features:

• Easy to use, no additional configuration required.
• This is suitable for situations where the performance of the backend servers is similar, because each server will receive requests in turn.

 http { upstream backend { server backend1.example.com; server backend2.example.com; server backend3.example.com; } server { location / { proxy_pass http://backend; } } }

2. Weighted Round Robin

Principle: Based on round-robin, a weight value is assigned to each server. The higher the weight value of the server, the more requests it receives. Nginx will calculate the proportion of requests received by each server based on the weight value.

Features:

• Requests can be flexibly allocated, taking into account differences in server performance.
• The weight value needs to be manually configured to reflect the actual performance of the server.
• It is suitable for situations where the backend server performance is uneven, and can better utilize server resources.

 http { upstream backend { server backend1.example.com weight=3; server backend2.example.com weight=2; server backend3.example.com weight=1; } server { location / { proxy_pass http://backend; } } }

3. IP Hash

Principle: Requests are assigned based on the hash value of the client IP address. Nginx calculates the hash value of each client IP address and uses the hash value to select a backend server. Since the hash value of the same IP address is the same, requests from the same IP address are always assigned to the same backend server.

Features:

• Session persistence is implemented, that is, requests from the same client are always assigned to the same backend server.
• Applicable to scenarios where session consistency needs to be maintained, such as shopping carts, user sessions, etc.
• However, this may result in uneven load distribution because clients in certain IP address ranges may frequently access the same server.

 http { upstream backend { ip_hash; server backend1.example.com; server backend2.example.com; server backend3.example.com; } server { location / { proxy_pass http://backend; } } }

4. Least Connections

Principle: Distribute requests to the server with the least number of current connections. Nginx monitors the current number of connections of each backend server and distributes new requests to the server with the least number of connections.

Features:

• The current load situation of the server is taken into account, which can balance the load more effectively.
• Applicable to long connection scenarios, such as WebSocket, database connection, etc.
• However, Nginx is required to maintain the connection status, which may increase some overhead.
• Nginx itself does not directly support this strategy and usually requires the use of third-party modules or custom scripts to implement it.

 http { upstream backend { least_conn; server backend1.example.com; server backend2.example.com; server backend3.example.com; } server { location / { proxy_pass http://backend; } } }

5. Fair (third party)

Principle: Allocate requests based on the response time of the backend server. Nginx monitors the response time of each backend server and allocates new requests to the server with the shortest response time.

Features:

• A smarter load balancing is implemented, which can distribute requests according to the actual performance of the server.
• Applicable to scenarios with high response time requirements.
• However, you need to install a third-party module (such as nginx-module-vts) to achieve this.

6. URL Hash (third party)

Principle: Requests are assigned based on the hash value of the request URL. Nginx calculates the hash value of each request URL and uses the hash value to select a backend server. Since the hash value of the same URL is the same, requests for the same URL are always assigned to the same backend server.

Features:

• Improves cache hit rate because requests for the same URL are always assigned to the same backend server.
• Applicable to cache server clusters.
• But it may also lead to uneven load distribution.
• Nginx itself does not support this strategy, you need to install the Nginx hash package to implement it.