Shulou(Shulou.com)06/02 Report--

This article mainly explains "the request processing flow of Nginx". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "the request processing flow of Nginx".

Why are we talking about the architectural foundation of Nginx?

Because Nginx runs on the outermost layer of the intranet, that is, the edge node, the traffic it handles is several times or even orders of magnitude that other application servers handle. We know that his solution to any kind of problem is completely different under different orders of magnitude, so in the application scenarios that Nginx deals with, all the problems are magnified, so we have to understand. Why does Nginx adopt an architectural model like master-worker, and why does the number of worker processes match the number of cores in CPU? When we need to share data among multiple worker processes, why do they share data differently in scenarios such as TLS or current and speed limits? then all these require us to have a clear understanding of the architecture of Nginx.

Let's first take a look at the request processing flow of Nginx.

Why look at the request processing flow in Nginx? Because in fact, we learned earlier that Nginx can record access logs and error logs, and can also handle static resources, so it can also do reverse proxies, so let's take a look at these things from within Nginx to see how it handles these requests and what components it contains.

Request processing flow of Nginx

From the far left of this graph, we can see that the leftmost are WEB, EMAIL and TCP, that is to say, after there are roughly three kinds of traffic entering Nginx from here, we have three large state machines in Nginx, one is the transport layer state machine of TCP/UDP layer 4 and the HTTP state machine of application layer and the MAIL state machine of email.

So why do we call it a state machine? Because of the big green box in the Nginx core, it uses the non-blocking event-driven processing engine, which is known as epoll, so once we use this asynchronous processing engine, we usually need to use a state machine to identify and process the request correctly.

Based on such an event state processor, when we parse out that the request needs to access static resources, we see the arrow at the bottom left, then it finds the static resources. If we go to reverse proxy, then I can do disk cache and cache the contents of the reverse proxy to disk, which is also on the lower left line below, but when we are dealing with static resources, There will be a problem when the entire memory is not enough to fully cache all files and information, then calls like send File or AIO will degenerate into blocked disk calls, so here we need to have a thread pool to deal with, for each completed request, we will enter the access log or error log.

Well, here we also enter the disk, of course, we can access it to the remote machine through the syslog protocol, then more often our Nginx is used as a load balancer or reverse proxy, that is, we can transfer the request to the later server through the protocol level (HTTP,Mail and stream (TCP)). You can also proxy to the corresponding application server through some protocols (FastCGI, uWSGI, SCGI, memcached) of the application layer, for example. The above is the request processing flow of Nginx.

At this point, I believe you have a deeper understanding of "Nginx request processing flow", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.