Mercurial > hg > nginx-site
comparison xml/ru/docs/http/request_processing.xml @ 522:ef11546f75ee
Translated "request_processing" into Russian, removed "virtual_hosts"
(which was a partly obsolete subset of "request_processing"), added
Russian introduction.
author | Ruslan Ermilov <ru@nginx.com> |
---|---|
date | Thu, 24 May 2012 12:39:04 +0000 |
parents | |
children | be54c443235a |
comparison
equal
deleted
inserted
replaced
521:3481a91d46ab | 522:ef11546f75ee |
---|---|
1 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> | |
2 | |
3 <article name="Как nginx обрабатывает запросы" | |
4 link="/ru/docs/http/request_processing.html" | |
5 lang="ru" | |
6 author="Игорь Сысоев" | |
7 editor="Brian Mercer"> | |
8 | |
9 <section name="Определение виртуального сервера по имени"> | |
10 | |
11 <para> | |
12 nginx вначале решает, какой из серверов должен обработать запрос. | |
13 Рассмотрим простую конфигурацию, | |
14 где все три виртуальных сервера слушают на порту *:80: | |
15 <programlisting> | |
16 server { | |
17 listen 80; | |
18 server_name example.org www.example.org; | |
19 ... | |
20 } | |
21 | |
22 server { | |
23 listen 80; | |
24 server_name example.net www.example.net; | |
25 ... | |
26 } | |
27 | |
28 server { | |
29 listen 80; | |
30 server_name example.com www.example.com; | |
31 ... | |
32 } | |
33 </programlisting> | |
34 | |
35 </para> | |
36 | |
37 <para> | |
38 В этой конфигурации, чтобы определить, какому серверу следует направить | |
39 запрос, nginx проверяет только поле <header>Host</header> заголовка запроса. | |
40 Если его значение не соответствует ни одному из имён серверов | |
41 или в заголовке запроса нет этого поля вовсе, | |
42 nginx направит запрос в сервер по умолчанию для этого порта. | |
43 В вышеприведённой конфигурации сервером по умолчанию будет первый сервер, | |
44 что соответствует стандартному поведению nginx по умолчанию. | |
45 Сервер по умолчанию можно задать явно с помощью параметра | |
46 <literal>default_server</literal> в директиве | |
47 <link doc="ngx_http_core_module.xml" id="listen"/>: | |
48 <programlisting> | |
49 server { | |
50 listen 80 <b>default_server</b>; | |
51 server_name example.net www.example.net; | |
52 ... | |
53 } | |
54 </programlisting> | |
55 | |
56 <note> | |
57 Параметр <literal>default_server</literal> появился в | |
58 версии 0.8.21. | |
59 В более ранних версиях вместо него следует использовать параметр | |
60 <literal>default</literal>. | |
61 </note> | |
62 Следует иметь в виду, что сервер по умолчанию является свойством | |
63 слушающего порта, а не имени сервера. | |
64 Подробнее это обсуждается ниже. | |
65 </para> | |
66 | |
67 </section> | |
68 | |
69 | |
70 <section id="how_to_prevent_undefined_server_names" | |
71 name="Как предотвратить обработку запросов без имени сервера"> | |
72 | |
73 <para> | |
74 Если запросы без поля <header>Host</header> в заголовке не должны | |
75 обрабатываться, можно определить сервер, который будет их отклонять: | |
76 <programlisting> | |
77 server { | |
78 listen 80; | |
79 server_name ""; | |
80 return 444; | |
81 } | |
82 </programlisting> | |
83 Здесь в качестве имени сервера указана пустая строка, которая | |
84 соответствует запросам без поля <header>Host</header> в заголовке, | |
85 и возвращается специальный для nginx код 444, который закрывает | |
86 соединение. | |
87 <note> | |
88 Начиная с версии 0.8.48 настройка <literal>server_name ""</literal> | |
89 является стандартной и может явно не указываться. | |
90 В более ранних версиях в качестве стандартного имени сервера | |
91 выступало имя машины (hostname). | |
92 </note> | |
93 </para> | |
94 | |
95 </section> | |
96 | |
97 | |
98 <section id="mixed_name_ip_based_servers" | |
99 name="Определение виртуального сервера по имени и IP-адресу"> | |
100 | |
101 <para> | |
102 Рассмотрим более сложную конфигурацию, | |
103 в которой некоторые виртуальные серверы слушают на разных адресах: | |
104 <programlisting> | |
105 server { | |
106 listen 192.168.1.1:80; | |
107 server_name example.org www.example.org; | |
108 ... | |
109 } | |
110 | |
111 server { | |
112 listen 192.168.1.1:80; | |
113 server_name example.net www.example.net; | |
114 ... | |
115 } | |
116 | |
117 server { | |
118 listen 192.168.1.2:80; | |
119 server_name example.com www.example.com; | |
120 ... | |
121 } | |
122 </programlisting> | |
123 В этой конфигурации nginx вначале сопоставляет IP-адрес и порт | |
124 запроса с директивами | |
125 <link doc="ngx_http_core_module.xml" id="listen"/> | |
126 в блоках | |
127 <link doc="ngx_http_core_module.xml" id="server"/>. | |
128 Затем он сопоставляет значение поля <header>Host</header> | |
129 заголовка запроса с директивами | |
130 <link doc="ngx_http_core_module.xml" id="server_name"/> | |
131 в блоках | |
132 <link doc="ngx_http_core_module.xml" id="server"/>, | |
133 которые соответствуют IP-адресу и порту. | |
134 Если имя сервера не найдено, запрос будет обработан в | |
135 сервере по умолчанию. | |
136 Например, запрос <url>www.example.com</url>, пришедший на порт | |
137 192.168.1.1:80, будет обработан сервером по умолчанию для порта | |
138 192.168.1.1:80, т.е. первым сервером, т.к. для этого порта | |
139 <url>www.example.com</url> не указан в списке имён серверов. | |
140 </para> | |
141 | |
142 <para> | |
143 Как уже говорилось, сервер по умолчанию является свойством слушающего порта, | |
144 поэтому у разных портов могут быть определены свои серверы по умолчанию: | |
145 <programlisting> | |
146 server { | |
147 listen 192.168.1.1:80; | |
148 server_name example.org www.example.org; | |
149 ... | |
150 } | |
151 | |
152 server { | |
153 listen 192.168.1.1:80 <b>default_server</b>; | |
154 server_name example.net www.example.net; | |
155 ... | |
156 } | |
157 | |
158 server { | |
159 listen 192.168.1.2:80 <b>default_server</b>; | |
160 server_name example.com www.example.com; | |
161 ... | |
162 } | |
163 </programlisting> | |
164 | |
165 </para> | |
166 | |
167 </section> | |
168 | |
169 | |
170 <section id="simple_php_site_configuration" | |
171 name="Конфигурация простого сайта PHP"> | |
172 | |
173 <para> | |
174 Теперь посмотрим на то, как nginx выбирает <i>location</i> | |
175 для обработки запроса на примере обычного простого PHP-сайта: | |
176 <programlisting> | |
177 server { | |
178 listen 80; | |
179 server_name example.org www.example.org; | |
180 root /data/www; | |
181 | |
182 location / { | |
183 index index.html index.php; | |
184 } | |
185 | |
186 location ~* \.(gif|jpg|png)$ { | |
187 expires 30d; | |
188 } | |
189 | |
190 location ~ \.php$ { | |
191 fastcgi_pass localhost:9000; | |
192 fastcgi_param SCRIPT_FILENAME | |
193 $document_root$fastcgi_script_name; | |
194 include fastcgi_params; | |
195 } | |
196 } | |
197 </programlisting> | |
198 | |
199 </para> | |
200 | |
201 <para> | |
202 nginx вначале ищет среди всех префиксных location’ов, заданных строками, | |
203 максимально совпадающий. | |
204 В вышеприведённой конфигурации | |
205 указан только один префиксный location “<literal>/</literal>”, и поскольку | |
206 он подходит под любой запрос, он и будет использован, если других | |
207 совпадений не будет найдено. | |
208 Затем nginx проверяет location’ы, заданные регулярными выражениями, в | |
209 порядке их следования в конфигурационном файле. | |
210 При первом же совпадении поиск прекращается и nginx использует | |
211 совпавший location. | |
212 Если запросу не соответствует ни одно из регулярных выражений, | |
213 nginx использует максимально совпавший префиксный location, | |
214 найденный ранее. | |
215 </para> | |
216 | |
217 <para> | |
218 Следует иметь в виду, что location’ы всех типов сопоставляются только с | |
219 URI-частью строки запроса без аргументов. | |
220 Так делается потому, что аргументы в строке запроса могут быть | |
221 заданы различными способами, например: | |
222 <programlisting> | |
223 /index.php?user=john&page=1 | |
224 /index.php?page=1&user=john | |
225 </programlisting> | |
226 Кроме того, в строке запроса можно запросить что угодно: | |
227 <programlisting> | |
228 /index.php?page=1&something+else&user=john | |
229 </programlisting> | |
230 | |
231 </para> | |
232 | |
233 <para> | |
234 Теперь посмотрим, как бы обрабатывались запросы | |
235 в вышеприведённой конфигурации: | |
236 <list type="bullet" compact="no"> | |
237 | |
238 <listitem> | |
239 Запросу “<literal>/logo.gif</literal>” во-первых соответствует префиксный | |
240 location “<literal>/</literal>”, а во-вторых—регулярное выражение | |
241 “<literal>\.(gif|jpg|png)$</literal>”, | |
242 поэтому он обрабатывается location’ом регулярного выражения. | |
243 Согласно директиве “<literal>root /data/www</literal>” запрос | |
244 отображается в файл <path>/data/www/logo.gif</path>, который | |
245 и посылается клиенту. | |
246 </listitem> | |
247 | |
248 <listitem> | |
249 Запросу “<literal>/index.php</literal>” также во-первых соответствует префиксный | |
250 location “<literal>/</literal>”, а во-вторых—регулярное выражение | |
251 “<literal>\.(php)$</literal>”. | |
252 Следовательно, он обрабатывается location’ом регулярного выражения | |
253 и запрос передаётся FastCGI-серверу, слушающему на localhost:9000. | |
254 Директива | |
255 <link doc="ngx_http_fastcgi_module.xml" id="fastcgi_param"/> | |
256 устанавливает FastCGI-параметр | |
257 <literal>SCRIPT_FILENAME</literal> в “<literal>/data/www/index.php</literal>”, | |
258 и сервер FastCGI выполняет указанный файл. | |
259 Переменная <var>$document_root</var> равна | |
260 значению директивы | |
261 <link doc="ngx_http_core_module.xml" id="root"/>, | |
262 а переменная <var>$fastcgi_script_name</var> равна | |
263 URI запроса, т.е. “<literal>/index.php</literal>”. | |
264 </listitem> | |
265 | |
266 <listitem> | |
267 Запросу “<literal>/about.html</literal>” соответствует только префиксный | |
268 location “<literal>/</literal>”, поэтому запрос обрабатывается в нём. | |
269 Согласно директиве “<literal>root /data/www</literal>” запрос | |
270 отображается в файл <path>/data/www/about.html</path>, который | |
271 и посылается клиенту. | |
272 </listitem> | |
273 | |
274 <listitem> | |
275 Обработка запроса “<literal>/</literal>” более сложная. | |
276 Ему соответствует только префиксный location “<literal>/</literal>”, | |
277 поэтому запрос обрабатывается в нём. | |
278 Затем директива | |
279 <link doc="ngx_http_index_module.xml" id="index"/> | |
280 проверяет существование индексных файлов согласно своих параметров | |
281 и директиве “<literal>root /data/www</literal>”. | |
282 Если файл <path>/data/www/index.html</path> не существует, | |
283 а файл <path>/data/www/index.php</path> существует, то | |
284 директива делает внутреннее перенаправление на “<literal>/index.php</literal>” | |
285 и nginx снова сопоставляет его с location’ами, | |
286 как если бы такой запрос был послан клиентом. | |
287 Как мы видели ранее, перенаправленный запрос будет в конечном итоге | |
288 обработан сервером FastCGI. | |
289 </listitem> | |
290 | |
291 </list> | |
292 | |
293 </para> | |
294 | |
295 </section> | |
296 | |
297 </article> |