Введение
Nginx — это высокопроизводительный веб-сервер, который также используется в качестве обратного прокси-сервера, почтового прокси, балансировщика нагрузки и HTTP-кэша. Nginx является бесплатным и открытым исходным кодом, что позволяет любому желающему скачать и использовать его в своей серверной среде.
Возможно, вы уже использовали Nginx для обслуживания веб-сайтов. В этом руководстве мы обсудим другие возможности Nginx. HTTP-проксирование в Nginx позволяет передавать запросы на бэкенд-серверы HTTP для обработки. С помощью этой функции вы можете настроить несколько бэкенд-серверов. Это позволяет масштабировать инфраструктуру по мере необходимости для обработки всплесков клиентских запросов.
По мере прохождения руководства вы узнаете о масштабировании вашей инфраструктуры с использованием функций Nginx для балансировки нагрузки, буферизации и кэширования ответов для повышения производительности вашего сервера, а также для обеспечения лучшего взаимодействия с клиентами. Давайте начнем!
Прежде всего, чтобы начать работу с Nginx, ознакомьтесь с нашим руководством по установке Nginx на сервер Ubuntu.
Общая информация о проксировании
Если ваши знания о веб-серверах ограничиваются лишь обработкой запросов к сайту и обслуживанием веб-страниц, вы можете задаться вопросом, зачем нам нужно проксировать запросы. Ниже мы объясним причины этого.
Одна из причин проксирования запросов к другим серверам из Nginx — поддержка масштабируемости вашей инфраструктуры. Nginx по умолчанию обрабатывает множество одновременных соединений. Это делает его идеальной первой точкой контакта для клиентов. Затем он может передавать запросы на различные бэкенд-серверы для фактической обработки клиентских запросов. Именно это распределяет нагрузку. Таким образом, это гарантирует, что вы сможете максимально масштабировать свою инфраструктуру. Это также позволяет вам отключать другие серверы на техническое обслуживание, пока остальные продолжают обслуживать запросы.
Вторая причина, по которой вы можете захотеть проксировать запросы к другим серверам, заключается в использовании серверов приложений, которые не подходят для прямой обработки запросов от клиентов в реальных рабочих средах. Некоторые фреймворки, включая веб-серверы, не подходят для обеспечения высокой производительности, как Nginx. Использование Nginx в качестве точки входа и проксирование запросов к этим низкопроизводительным серверам может обеспечить лучший опыт для ваших пользователей. Кроме того, это может гарантировать повышенную безопасность вашего приложения.
Процесс проксирования запросов в Nginx включает в себя изменение запроса от сервера Nginx и его передачу на другие бэкенд-серверы для фактической обработки. Как только другие бэкенд-серверы обработают запрос, они передают результат обратно в Nginx. Затем он отправляет результат в качестве ответа клиенту. Клиентом в данном случае является веб-браузер или даже мобильное веб-приложение. Другими бэкенд-серверами могут быть локальные серверы, недоступные публично в Интернете, удаленные серверы или даже другие виртуальные серверы в конфигурациях блоков серверов Nginx. Эти другие серверы, на которые Nginx проксирует запросы, называются апстрим-серверами.
Nginx может проксировать запросы к серверам, которые взаимодействуют по нескольким протоколам, включая HTTP(S), Memcached, SCGI, FastCGI и uWSGI. Для каждого типа протокола существуют наборы директив. В этом руководстве мы сосредоточимся на протоколе HTTP. Nginx анализирует запросы и компоненты сообщений, преобразуя их в формат, который может интерпретировать и обработать апстрим-сервер.
Анализ базового проксирования HTTP (Proxy Pass)
Простейший тип проксирования включает передачу запроса на один сервер, взаимодействующий по протоколу HTTP. Этот тип проксирования обычно называют «proxy pass», и он обрабатывается соответствующей директивой proxy_pass в конфигурационных файлах Nginx.
Директива proxy_pass указывается внутри блоков location. Она также может находиться внутри блоков контекста location и в контекстах limit_except. Когда запрос соответствует location с директивой proxy_pass внутри, запрос направляется на URL-адрес, указанный в директиве. Ниже приведен пример фрагмента конфигурации:
|
1 2 3 4 |
listen 80; location / { proxy_pass http://127.0.0.1:3000; } |
В приведенном выше примере запросы к порту 80 будут направляться на localhost:3000:
На скриншоте выше показана страница Nginx по умолчанию при попытке перейти на localhost. После перезапуска сервера Nginx с действующей директивой proxy_pass все запросы будут идти на порт 3000. Демо-приложение запущено на порту 3000, что видно на изображении ниже, и вы можете перейти на него напрямую с localhost без указания порта:
В следующем примере в конце адреса сервера в определении proxy_pass не был указан URI. Для определений, соответствующих этому шаблону, URI, запрашиваемый клиентом, будет передан на вышестоящий сервер в исходном виде.
|
1 2 3 |
location /match/url/here { proxy_pass http://example.com; } |
Например, когда этот блок обрабатывает запрос для /match/url/here, URI запроса будет передан на сервер example.com как http://example.com/match/url/here.
Ниже приведен пример альтернативного фрагмента конфигурации:
|
1 2 3 |
location /match/url/here { proxy_pass http://example.com/new/url/prefix; } |
Как видно из приведенного выше фрагмента, мы определили сегмент URI в конце прокси-сервера как new/url/prefix. Когда вы определяете URI в директиве proxy_pass, часть запроса, соответствующая определению location, заменяется этим URI при отправке на вышестоящий сервер для обработки.
Например, запрос /match/url/here на сервере Nginx передается на вышестоящий сервер как http://example.com/new/url/here. Часть /match/url заменяется на /new/url. Имейте это в виду.
В некоторых случаях передача URI, как описано выше, невозможна. В таких ситуациях Nginx игнорирует URI в конце определения proxy_pass. В конечном итоге на вышестоящий сервер передается либо исходный URI от клиента, либо URI, измененный другими директивами.
Примером может служить случай, когда location соответствует регулярному выражению. Nginx может оказаться не в состоянии определить, какая часть URI соответствует выражению. Поэтому он отправляет исходный URI запроса клиента. Это приводит к перезаписи и обработке URI клиента в том же блоке. В таком случае передается перезаписанный URI.
Как Nginx обрабатывает заголовки?
Заголовки имеют решающее значение для того, как сервер обрабатывает запрос. Некоторые заголовки могут содержать информацию об аутентификации. Поэтому мы должны понимать, как проксирование Nginx обрабатывает заголовки. Прокси-запрос от Nginx к вышестоящему серверу будет отличаться от запроса, пришедшего непосредственно от клиента. Некоторые из различий являются результатом заголовков, которые передаются вместе с прокси-запросом.
При проксировании запроса Nginx вносит изменения в заголовки запросов, получаемые от клиента. Некоторые из этих изменений включают в себя:
-
Удаление всех пустых заголовков. Пустые заголовки только раздувают запрос, поэтому нет смысла передавать их на вышестоящий сервер.
-
Любые заголовки, содержащие символы подчеркивания, по умолчанию считаются недействительными и поэтому удаляются из запроса. Если вы хотите изменить это поведение и разрешить Nginx интерпретировать заголовки с подчеркиванием как допустимые, вы можете установить директиву underscores_in_headers в значение «on». Если вы этого не сделаете, такие заголовки от клиента никогда не достигнут вышестоящего сервера.
-
Заголовок «Host» перезаписывается значением, указанным в переменной $proxy_host. Это IP-адрес или имя и номер порта вышестоящего сервера, как указано в директиве proxy_pass.
-
Значение заголовка «Connection» меняется на «close». Заголовок соединения содержит информацию о конкретном соединении, установленном между двумя сторонами. Когда Nginx устанавливает его значение в close, это указывает вышестоящему серверу, что соединение будет закрыто после ответа на исходный запрос, поэтому ему не следует ожидать, что это соединение будет постоянным.
Вот несколько моментов, которые мы можем отметить на основе описанных выше изменений заголовков прокси-запросов:
-
Если вы не хотите, чтобы заголовок передавался на вышестоящий сервер, то установка его значения в виде пустой строки полностью удалит его из запроса.
-
Если приложение на вашем вышестоящем сервере будет обрабатывать нестандартные заголовки, убедитесь, что в заголовках нет символа подчеркивания. При желании вы можете установить директиву underscores_in_headers в значение «on» в вашей конфигурации (это допустимо либо в контексте объявления сервера по умолчанию для комбинации IP-адрес/порт, либо в контексте HTTP). Это гарантирует, что заголовки не будут помечены как недействительные и, следовательно, действительно будут переданы на вышестоящий сервер.
-
Заголовок «Host» очень важен в большинстве ситуаций проксирования. По умолчанию он имеет значение $proxy_host — переменной, содержащей доменное имя или IP-адрес и порт, полученные из спецификации proxy_pass. Этот адрес выбирается по умолчанию и извлекается непосредственно из информации о подключении. Это единственный адрес, для которого Nginx гарантирует, что вышестоящий сервер ответит.
Ниже приведены наиболее распространенные значения для заголовка «Host»:
-
$host — переменная устанавливается в порядке предпочтения: имя хоста из самой строки запроса, заголовок «Host» из запроса клиента или имя сервера, соответствующее запросу.
-
$http_host — переменная, которая устанавливает заголовок «Host» в значение заголовка «Host» из запроса клиента. Заголовки в запросе клиента всегда доступны Nginx в виде переменных. Эти переменные начинаются с префикса $http_, за которым следует имя заголовка в нижнем регистре. Хотя переменная $http_host в большинстве случаев будет работать нормально, отсутствие в запросе клиента допустимого заголовка «Host» может привести к сбою передачи.
-
$proxy_host — переменная, которая устанавливает заголовок «Host» в комбинацию доменного имени или IP-адреса и порта, полученную из спецификации proxy_pass. Это поведение по умолчанию с точки зрения Nginx и поэтому считается безопасным. Однако это может быть не то, что требуется серверу для правильной обработки запроса.
Большинство конфигураций предполагают установку заголовка «Host» в значение переменной $host. Это очень гибкое решение, которое обеспечит передачу точно заполненных заголовков на вышестоящий сервер.
Настройка и изменение заголовков
Директива proxy_set_header позволяет нам устанавливать или изменять заголовки для прокси-соединений. Для заголовка «Host», рассмотренного ранее, мы можем сделать следующее, чтобы изменить и добавить дополнительные заголовки, часто используемые при проксировании запросов:
|
1 2 3 4 5 6 7 8 |
location /match/here { proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $schema; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://example.com/new/prefix; } |
В приведенном выше фрагменте конфигурации мы устанавливаем заголовок «Host» в значение переменной $host, которая содержит информацию об исходном запрашиваемом хосте. Мы устанавливаем заголовок X-Forwarded-Proto с информацией о схеме исходного запроса от клиента (это может быть запрос HTTP или HTTPS).
Мы передаем фактический IP-адрес клиента в X-Real-IP. Это позволяет вышестоящему серверу принимать соответствующие решения или сохранять логи на основе исходного IP-адреса клиента. Заголовок X-Forwarded-For содержит список всех IP-адресов, принадлежащих серверам, через которые клиент проксировался до достижения этой точки. В приведенном выше фрагменте кода мы устанавливаем его в значение переменной $proxy_add_x_forwarded_for. Эта переменная принимает значение исходного заголовка X-Forwarded-For, полученного от клиента, и добавляет IP-адрес прокси-сервера Nginx в конец.
Если вы хотите, чтобы директивы proxy_set_header использовались более чем в одном контексте location, вы можете вынести их в контекст server или http. Рассмотрим фрагмент конфигурации ниже:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location /match/here { proxy_pass http://example.com/new/prefix; } location /different/match { proxy_pass http://example.com; } |
Определение контекста Upstream для балансировки нагрузки проксируемых соединений
К этому моменту вы уже понимаете, как настроить простое HTTP-проксирование на один вышестоящий (upstream) бэкенд-сервер. К счастью, с помощью Nginx вы можете масштабировать такую конфигурацию, определяя пулы бэкенд-серверов для передачи им запросов на обработку.
Nginx предоставляет директиву upstream, которая используется для определения пула серверов. В конфигурации этой директивы необходимо указывать только те серверы, которые способны обрабатывать запросы клиентов. Nginx в качестве прокси-сервера позволяет масштабировать инфраструктуру с минимальными усилиями. Директива upstream должна быть указана внутри контекста http вашей конфигурации Nginx.
Вот пример, показывающий директиву upstream:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
upstream several_backend_hosts { server host1.example.com; server host2.example.com; server host3.example.com; } server { listen 80; server_name example.com; location /proxy-me { proxy_pass http://several_backend_hosts; } } |
В приведенном выше фрагменте кода конфигурации мы определили контекст upstream с именем several_backend_hosts. Имя определенного контекста теперь доступно внутри директив proxy_pass. Его можно использовать так же, как и обычный домен, как показано в примере. Внутри блока server мы передаем все запросы к example.com/proxy-me/… в пул, который мы определили с помощью директивы upstream, в данном случае several_backend_hosts. Хост в пуле выбирается для обработки входящих запросов путем применения настраиваемого алгоритма. По умолчанию выбор происходит по принципу round-robin (круговому) – каждый запрос по очереди направляется на другой хост.
Как изменить алгоритм балансировки Upstream
Как было отмечено выше, процесс выбора по умолчанию следует алгоритму round-robin. В этом разделе мы рассмотрим, как можно изменить алгоритм балансировки, используемый пулом upstream. Чтобы изменить алгоритм, необходимо включить другие директивы или флаги в контекст upstream, как описано ниже:
-
(round-robin) – если не указана другая директива балансировки upstream, то по умолчанию каждому серверу, определенному в контексте upstream, запросы передаются последовательно по очереди.
-
least_conn – эта директива указывает модулю upstream выбирать бэкенд-сервер с наименьшим количеством активных соединений. Это применимо в ситуациях, когда соединения с одним бэкенд-сервером могут сохраняться в течение некоторого времени.
-
hash – эта директива часто используется для проксирования memcached. Соединения передаются на бэкенд-серверы на основе значения случайно предоставленного ключа хэширования. Значением ключа хэширования могут быть переменные, текст или их комбинация. hash является единственным методом балансировки, требующим ввода данных от пользователей в качестве ключа для хэширования.
-
ip_hash – эта директива указывает модулю upstream распределять запросы по разным серверам на основе IP-адреса клиента. Первые три октета IP-адреса служат ключом для определения того, какой сервер должен обрабатывать запрос. Преимущество этой директивы заключается в том, что клиенты, как правило, каждый раз попадают на один и тот же сервер, что обеспечивает согласованность сессий.
Вот пример того, как мы можем добавить директиву алгоритма балансировки в контекст upstream:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { least_conn; server host1.example.com; server host2.example.com; server host3.example.com; } |
В приведенном выше фрагменте Nginx выберет любой из серверов с наименьшим количеством подключений для обработки входящего запроса. Директива ip_hash использует тот же синтаксис. Для директивы hash вам необходимо указать ключ по вашему выбору для хеширования, вот пример:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { hash $remote_addr$remote_port consistent; server host1.example.com; server host2.example.com; server host3.example.com; } |
Используемый здесь хеш будет результатом IP-адреса и порта клиента. Необязательный параметр consistent реализует алгоритм консистентного хеширования ketama. Это обеспечивает минимальное влияние на ваш кэш в случае изменения серверов upstream.
Как указать вес сервера для балансировки
По умолчанию при объявлении серверов бэкенда каждый сервер имеет одинаковый вес. Предполагается, что каждый сервер обладает ресурсами и возможностями для обработки одинакового объема нагрузки, конечно, с учетом того алгоритма балансировки, который вы укажете в контексте upstream. Чтобы изменить это поведение по умолчанию, вы можете установить альтернативный вес для каждого сервера во время объявления. Рассмотрим пример:
|
1 2 3 4 5 |
upstream backend_hosts { server host1.example.com weight=2; server host2.example.com; server host3.example.com; } |
В этом примере host1.example.com будет получать в два раза больше трафика, чем два других сервера. Вес каждого сервера по умолчанию равен единице.
Освобождение серверов бэкенда с помощью буферов
При настройке проксирования в конфигурации вашего сервера вас может беспокоить влияние добавления новых серверов на производительность. К счастью, Nginx поставляется с функциями буферизации и кэширования, которые могут помочь смягчить эти проблемы с производительностью.
Скорость двух разных соединений обязательно повлияет на работу клиента при проксировании на другой сервер:
-
Первое соединение — от клиента к прокси-серверу Nginx.
-
Второе соединение — от прокси-сервера Nginx к серверу бэкенда (upstream).
Nginx может корректировать свое поведение, чтобы помочь оптимизировать любое из соединений по мере необходимости.
Если мы отключим буферы, передача данных от бэкенда клиенту начнется сразу же через прокси-сервер Nginx. Если вы знаете, что ваши клиенты работают быстро, вы можете полностью отключить буферизацию, чтобы данные доставлялись клиенту достаточно быстро. Когда буферы включены, прокси-сервер Nginx временно сохраняет данные ответа, полученные от сервера бэкенда. Затем он отправляет данные клиенту в зависимости от его скорости. Как только ответ оказывается в буферах Nginx, он может закрыть соединение с сервером бэкенда. Затем он будет передавать данные клиенту со скоростью, которую поддерживает клиент. В то же время это позволяет серверу бэкенда продолжать обработку других входящих запросов.
По умолчанию в Nginx буферизация включена. Это связано с тем, что мы не можем знать скорость соединения клиентов. У клиентов могут быть разные соединения, в том числе более медленные. Ниже мы определим различные директивы, которые можно указать для настройки поведения буферизации Nginx. Директивы могут быть определены в контекстах http, server или location, однако следует отметить, что директивы размера настраиваются для каждого запроса. Следовательно, их увеличение сверх абсолютно необходимого может повлиять на производительность вашего сервера при слишком большом количестве входящих запросов клиентов. Вот эти директивы:
-
proxy_buffering – директива, которая управляет тем, активна ли буферизация для конкретного контекста и дочерних контекстов. По умолчанию для proxy_buffering установлено значение «on».
-
proxy_buffer_size – директива, определяющая размер буфера для хранения заголовков, полученных в ответе от бэкенд-сервера. Заголовки составляют первую часть ответа бэкенд-сервера. Буферизация этих заголовков происходит отдельно от остальной части ответа. По умолчанию установленный размер этого буфера совпадает с размером proxy_buffers. Однако, если информация в заголовках невелика, вы можете установить меньшее значение.
-
proxy_buffers – директива, управляющая количеством (первый аргумент) и размером (второй аргумент) буферов для проксированных ответов. Конфигурация по умолчанию задает 8 буферов размером, равным одной странице памяти (4k или 8k). Вы можете разрешить буферизацию большего объема информации, увеличив количество буферов.
-
proxy_max_temp_file_size – директива, задающая максимальный размер временного файла на диске для одного запроса. Временные файлы создаются, когда ответ от апстрима слишком велик, чтобы поместиться в буфер.
-
proxy_busy_buffers_size – директива, задающая максимальный размер буферов, которые могут быть помечены как «готовые для клиента» и, следовательно, занятые. Клиент может читать данные только из одного буфера за раз. Однако буферы находятся в очереди для отправки клиенту пакетами. Вы можете изменить размер буферного пространства, которому разрешено находиться в этом состоянии, изменив эту директиву.
-
proxy_temp_file_write_size – директива, определяющая объем данных, который Nginx будет записывать во временный файл за один раз, когда ответ от бэкенд-апстрима слишком велик для размещения в настроенных буферах.
-
proxy_temp_path – директива, указывающая путь к месту на диске, где Nginx должен хранить временные файлы, когда ответ от бэкенд-апстрима слишком велик для размещения в настроенных буферах.
Nginx обладает высокой гибкостью настройки, предоставляя несколько директив для тонкой настройки поведения буферизации. В большинстве случаев значения по умолчанию работают отлично. В то же время полезно знать, что вы можете скорректировать некоторые из этих значений для вашей собственной реализации. Чаще всего вам потребуется настроить директивы proxy_buffers и proxy_buffer_size.
Ниже приведен пример, который увеличивает количество доступных прокси-буферов для каждого запроса к апстриму. При этом уменьшается размер буфера, в котором хранятся заголовки:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
server { proxy_buffering on; proxy_buffer_size 1k; proxy_buffers 24 4k; proxy_busy_buffers_size 8k; proxy_max_temp_file_size 2048m; proxy_temp_file_write_size 32k; location / { proxy_pass http://example.com; } } |
Давайте посмотрим, как можно быстрее отдавать данные быстрым клиентам, полностью отключив буферизацию. Если окажется, что ваш клиент недостаточно быстр, Nginx автоматически задействует буферы. Однако сначала он сбросит данные клиенту, не дожидаясь заполнения пулов буферов. У этой конфигурации есть недостаток: соединение с апстрим-сервером остается открытым для медленных клиентов до тех пор, пока клиент не получит все данные ответа. Если буферизация отключена (установлена в «off»), будет использоваться только буфер, определенный директивой proxy_buffer_size. Ниже приведен фрагмент кода, показывающий, как отключить буферизацию:
|
1 2 3 4 5 6 7 8 9 |
server { proxy_buffering off; proxy_buffer_size 4k; location / { proxy_pass http://example.com; } } |
-
Настройка высокодоступной (HA) инфраструктуры (необязательный шаг)
Вы можете добавить избыточный набор балансировщиков нагрузки в конфигурацию прокси-сервера Nginx, сделав ее более надежной и, следовательно, отказоустойчивой (высокодоступной). Высокодоступная (HA) архитектура — это инфраструктура без единой точки отказа. Балансировщики нагрузки являются частью этой конфигурации. Имея более одного балансировщика нагрузки, вы можете предотвратить возможные простои в случае сбоя одного из них или его отключения на техническое обслуживание.
Как настроить кэширование прокси в Nginx для сокращения времени ответа
В предыдущем разделе мы обсудили, как использовать буферизацию, чтобы освободить серверы бэкенда для обработки большего количества запросов. Nginx предлагает еще одну функцию, которая позволяет кэшировать данные ответов от бэкенда. Это полностью устраняет необходимость обращаться к апстриму для всех входящих запросов.
Реализация кэша прокси
Директива proxy_cache_path позволяет настроить кэш, указывая область на диске для хранения проксируемого содержимого. Директива proxy_cache_path определяется в контексте http.
Приведенный ниже фрагмент кода конфигурации является примером реализации системы кэширования:
|
1 2 3 4 5 6 |
http { proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backendcache:8m max_size=50m; proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args"; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; } |
В этом фрагменте кода мы использовали директиву proxy_cache_path для определения каталога в файловой системе, в котором будет храниться наш кэш. В данном случае мы указали каталог /var/lib/nginx/cache. Вы можете выбрать любой другой путь к каталогу. Используйте следующие команды для создания выбранных каталогов с правильными правами доступа и владельцем:
|
1 2 3 |
sudo mkdir -p /var/lib/nginx/cache sudo chown www-data /var/lib/nginx/cache sudo chmod 700 /var/lib/nginx/cache |
В этом фрагменте кода параметр levels= определяет структуру кэша. Nginx создает ключ кэша путем хэширования значения ключа (заданного с помощью директивы proxy_cache_key). Указанные нами уровни (1:2) означают, что будет создан каталог с именем из одного символа (последний символ хэшированного значения) и подкаталог с именем из двух символов (следующие два символа с конца хэшированного значения). В большинстве случаев вам не придется об этом беспокоиться. Тем не менее, полезно знать, как это помогает Nginx быстро находить нужные значения.
Параметр keys_zone= определяет имя зоны кэша, в нашем случае мы назвали ее backendcache. Здесь мы также указываем, какой объем метаданных мы хотим хранить. В этом примере мы выделяем 8 МБ для ключей. Nginx может хранить примерно 8000 записей на каждый мегабайт. Параметр max_size задает максимальный размер самих кэшируемых данных, в нашем примере — 50 МБ.
Также обратите внимание на используемую директиву proxy_cache_key. Эта директива задает ключ, который будет использоваться для хранения кэшированных значений. Мы будем использовать этот же ключ для проверки наличия запроса в кэше. Мы настроили этот ключ как комбинацию схемы (http или https), метода HTTP-запроса, а также запрашиваемого хоста и URI.
Кроме того, мы использовали директиву proxy_cache_valid. Эту директиву можно указывать несколько раз для различных кодов состояния. Она позволяет задать время хранения значений в зависимости от кода состояния. В фрагменте кода мы указали 10 минут для успешных кодов ответов и 1 минуту для ответов 404.
Поскольку мы настроили зону кэша, следующим шагом будет применение конфигурации: нужно указать Nginx, когда использовать кэш. Ниже приведен фрагмент конфигурации, показывающий, как можно реализовать использование этого кэша:
|
1 2 3 4 5 6 7 8 9 |
server { location /proxy-me { proxy_cache backendcache; proxy_cache_bypass $http_cache_control; add_header X-Proxy-Cache $upstream_cache_status; proxy_pass http://backend; } } |
В директиве proxy_cache мы указали, что для этого контекста должна использоваться зона кэширования backendcache. Если вы выбрали другое имя в конфигурации кэша, здесь вам нужно его заменить. Для каждого допустимого запроса Nginx будет проверять кэш перед передачей запроса на бэкенд-сервер.
Мы определяем директиву proxy_cache_bypass для использования переменной $http_cache_control. Эта переменная сообщает серверу, должен ли он отвечать кэшированным ответом или свежей, некэшированной версией ресурса. Правильная настройка этой директивы позволяет Nginx корректно обрабатывать различные типы входящих запросов от клиентов.
Также указан дополнительный заголовок X-Proxy-Cache. Этот заголовок имеет значение переменной $upstream_cache_status. Он дает нам информацию о том, привел ли запрос к попаданию в кэш (cache hit), промаху (cache miss) или кэш был явно обойден. Такая информация может быть полезна для клиента и крайне важна при отладке приложений.
Важные моменты о кэшировании результатов
Хотя кэширование значительно повысит производительность вашего прокси-сервера, при его внедрении следует обратить внимание на следующее:
Любые данные, связанные с личной информацией пользователя, не должны кэшироваться, чтобы избежать ситуаций, когда данные одного пользователя видны другому.
Ваши бэкенд-серверы должны учитывать все динамические элементы вашего сайта. Мы можем указать несколько заголовков Cache-Control в нашем ответе для различных целей. Давайте обсудим их:
-
no-cache — указывает, что прокси-сервер должен проверить, изменились ли данные на бэкенде, прежде чем отдавать ответ. Это применимо для динамических и важных данных. Заголовок метаданных хэша ETag проверяется при каждом запросе, и если бэкенд возвращает то же значение хэша, то отдается предыдущее значение.
-
no-store — указывает не кэшировать никакие полученные данные, следовательно, каждый запрос будет отправляться на сервер за свежими данными. Это самый безопасный вариант для конфиденциальных данных.
-
private — указывает, что общее пространство кэша не должно кэшировать данные. Вы можете использовать этот заголовок, чтобы разрешить кэширование в браузере пользователя, но при этом сообщить прокси-серверу, что данные недействительны для последующих запросов.
-
public — указывает на публичный ответ и разрешает кэширование на любом этапе соединения.
Вы можете указать, как долго должен храниться кэш в секундах, используя заголовок max-age. Различные заголовки, определенные выше, помогут вам настроить кэширование, сохраняя конфиденциальные данные в безопасности, динамические данные — свежими и, что самое важное, повышая производительность вашего сервера.
Если ваши бэкенд-серверы работают под управлением Nginx, вы можете указать внутри блоков server, как долго кэш должен быть действителен. Вы можете сделать это, добавив директиву expires в конфигурацию, как показано ниже:
|
1 2 3 4 5 6 7 |
location / { expires 59m; } location /check-me { expires -1; } |
Первый блок разрешает кэширование контента на 59 минут, в то время как второй блок указывает на отсутствие кэширования. Эти настройки применяются к параметрам заголовков Cache-Control, например, «no-cache» для второго блока.
Вы можете использовать директиву add-header для установки дополнительных значений:
|
1 2 3 4 |
location /private { expires -1; add_header Cache-Control "no-store"; } |
Заключение
В этом руководстве мы узнали о мощных возможностях Nginx. Nginx является как веб-сервером, так и, что самое важное, обратным прокси-сервером. Архитектура Nginx позволяет ему обрабатывать тысячи одновременных соединений. Это делает его идеальным для балансировки нагрузки. Благодаря такой архитектуре проксирование запросов на другие бэкенд-серверы для обработки выполняется довольно просто.
Получив знания из этого руководства, вы сможете внедрить сложные прокси-серверы и балансировщики нагрузки благодаря гибкости Nginx.
Вот несколько ресурсов, которые вы можете найти в нашем блоге, которые помогут вам ближе познакомиться с Nginx:
-
Как установить стек LEMP (Linux, Nginx, MySQL PHP) на Ubuntu 20.04
-
Развертывание Laravel, Nginx и MySQL с помощью Docker Compose
Приятной работы!
Комментарии
Комментариев пока нет. Будьте первым.