How nginx processes a request; Nginx处理一条请求的过程
来源:互联网 发布:动漫 惊艳 音乐 知乎 编辑:程序博客网 时间:2024/04/30 10:11
Name-based virtual servers
FROM: http://nginx.org/en/docs/http/request_processing.html
nginx first decides which server should process the request. Let’s start with a simple configuration where all three virtual servers listen on port *:80:
server { listen 80; server_name nginx.org www.nginx.org; ...}server { listen 80; server_name nginx.net www.nginx.net; ...}server { listen 80; server_name nginx.com www.nginx.com; ...}
In this configuration nginx tests only the request’s header line “Host” to determine which server the request should be routed to. If the “Host” header line does not match any server name, or the request does not contain this line at all, then nginx will route the request to the default server. In the configuration above, the default server is the first one — which is nginx’s standard default behaviour. If you do not want the first server listed to be the default server, you may set it explicitly with the “default_server” parameter in the “listen” directive:
server { listen 80 default_server; server_name nginx.net www.nginx.net; ...}
The “default_server” parameter has been available since version 0.8.21. In earlier versions the “default” parameter should be used instead.
Note that the default server is a property of the listen port and not of the server name. More about this later.
How to prevent processing requests with undefined server names
If you do not want to process requests with undefined “Host” header lines, you may define a default server that just drops the requests:
server { listen 80 default_server; server_name _; return 444;}
We have chosen the non-existent domain name “_” as the server name and returned nginx’s special non-standard code 444 that closes the connection. Note that you should set a name for this server, otherwise nginx will use the hostname.
Mixed name-based and IP-based virtual servers
Let’s look at a more complex configuration where some virtual servers listen on different addresses:
server { listen 192.168.1.1:80; server_name nginx.org www.nginx.org; ...}server { listen 192.168.1.1:80; server_name nginx.net www.nginx.net; ...}server { listen 192.168.1.2:80; server_name nginx.com www.nginx.com; ...}
In this configuration, nginx first tests the IP address and port of the request against the “listen” directives of the “server” blocks. It then tests the “Host” header line of the request against the “server_name” entries of the “server” blocks that matched the IP address and port. If the server name is not found, the request will be processed by the default server. For example, a request for www.nginx.com received on the 192.168.1.1:80 port will be handled by the default server of the 192.168.1.1:80 port, i.e., by the first server, since there is nowww.nginx.com defined for this port.
As already stated, a default server is a property of the listen port and different default servers may be defined for different listen ports:
server { listen 192.168.1.1:80; server_name nginx.org www.nginx.org; ...}server { listen 192.168.1.1:80 default_server; server_name nginx.net www.nginx.net; ...}server { listen 192.168.1.2:80 default_server; server_name nginx.com www.nginx.com; ...}
A simple PHP site configuration
Now let’s look at how nginx chooses a location to process a request for a typical, simple PHP site:
server { listen 80; server_name nginx.org www.nginx.org; root /data/www; location / { index index.html index.php; } location ~* /.(gif|jpg|png)$ { expires 30d; } location ~ /.php$ { fastcgi_pass localhost:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }}
nginx first searches for the most specific location given by literal strings regardless of the listed order. In the configuration above the only literal location is “/
” and since it matches any request it will be used as a last resort. Then nginx checks locations given by regular expression in the order listed in the configuration file. The first matching expression stops the search and nginx will use this location. If no regular expression matches a request, then nginx uses the most specific literal location found earlier.
Note that locations of all types test only a request URI part without a query string. This is done because arguments in the query string may be given in several ways, for example:
/index.php?user=john&page=1/index.php?page=1&user=john
Besides, anyone may request anything in the query string:
/index.php?page=1&something+else&user=john
Now let’s look at how requests would be processed in the configuration above:
A request “
/logo.gif
” is matched by the literal location “/” first and then by the regular expression “/.(gif|jpg|png)$”, therefore, it is handled by the latter location. Using the directive “root /data/www” the request is mapped to a file “/data/www/logo.gif
”, and the file is sent to the client.A request “
/index.php
” is also matched by the literal location “/” first and then by the regular expression “/.(php)$”. Therefore, it is handled by the latter location and the request is passed to a FastCGI server listening on localhost:9000. The “fastcgi_param”directive sets the FastCGI parameter SCRIPT_FILENAME to “/data/www/index.php
”, and the FastCGI server executes the file. The variable $document_root is equal to the value of the “root” directive and the variable $fastcgi_script_name is equal to the request URI, i.e. “/index.php
”.A request “
/about.html
” is matched by the literal location “/” only, therefore, it is handled in this location. Using the directive“root /data/www” the request is mapped to the file “/data/www/about.html
”, and the file is sent to the client.Handling a request “
/
” is more complex. It is matched by the literal location “/” only, therefore, it is handled by this location. Then the “index” directive tests for the existence of an index file according to its parameters and the “root /data/www” directive. If a file “/data/www/index.php
” exists, then the directive does an internal redirect to “/index.php
”, and nginx searches the locations again as if the request had been sent by a client. As we saw before, the redirected request will eventually be handled by the FastCGI server.
written by Igor Sysoev
edited by Brian Mercer
- How nginx processes a request; Nginx处理一条请求的过程
- how nginx processes a request
- nginx.org的How nginx processes a request页面翻译
- Nginx--官网中文翻译(中英文对比)--9-nginx怎样处理一个请求How nginx processes a request
- Nginx--官网中文翻译(中英文对比)--13-nginx如何处理会话How nginx processes a TCPUDP session
- nginx.org的How nginx processes a TCP/UDP session页面翻译
- How Django processes a request
- Nginx中http请求的处理过程
- Nginx处理HTTP请求的路由过程
- nginx的请求处理
- nginx的请求处理
- 文章18 :Nginx中http请求的处理过程
- nginx做反向代理处理http请求的过程
- Nginx的HTTP请求处理
- nginx的请求处理机制
- nginx对request header的处理
- nginx 处理请求
- Nginx 如何处理请求
- C/C++中static关键字详解
- getWindow()
- VS2005 VC6.0 用VC++制作有滚动字幕效果的软件封面
- 对话框编程2
- crontab2
- How nginx processes a request; Nginx处理一条请求的过程
- 《企业应用架构模式》之模式列表
- 讲讲volatile的作用
- 修改应用程序外观
- 4.27笔记
- SQL自定义函数
- MPEG-2音频解码
- myeclipse自我整理版
- ubutnu命令行软件