Mercurial > hg > nginx-site

comparison xml/ru/docs/http/request_processing.xml @ 522:ef11546f75ee

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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&amp;page=1
224 /index.php?page=1&amp;user=john
225 </programlisting>
226 Кроме того, в строке запроса можно запросить что угодно:
227 <programlisting>
228 /index.php?page=1&amp;something+else&amp;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>”, а во-вторых&mdash;регулярное выражение
241 “<literal>\.(gif|jpg|png)$</literal>”,
242 поэтому он обрабатывается location’ом регулярного выражения.
243 Согласно директиве “<literal>root&nbsp;/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>”, а во-вторых&mdash;регулярное выражение
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>