Краткое изложение 4D, систематическое введение в Nginx!

Nginx

предисловие

Часто ли вы, фронтенд-разработчик, сталкиваетесь с руководителями, которые просят вас перейти на сервер для внесения изменений?Nginxконфигурации, но вы будете увиливать от этого по причине «я передний край, я не буду этого делать»! Давайте сегодня попрощаемся с этим смущением и двинемся вперед к «настоящему» программисту! ! !

Если эта статья была вам полезна, нажмите 👍 👍 👍!

Обзор Nginx

image.png

NginxОткрытый исходный код, высокая производительность, высокая надежностьWebИ обратный прокси-сервер, и поддерживает горячее развертывание, почти 7*24 часа бесперебойной работы, даже если он работает несколько месяцев, его не нужно перезагружать, а версия ПО может быть обновлена ​​в горячем режиме при условии бесперебойного обслуживания. производительностьNginxНаиболее важным соображением является то, что он занимает меньше памяти, обладает мощными возможностями параллелизма и может поддерживать до 5 Вт одновременных подключений.NginxЭто бесплатно и может быть коммерциализировано, а настройка и использование относительно просты.

Возможности Nginx

  • Высокий параллелизм и высокая производительность;
  • Модульная архитектура делает ее очень масштабируемой;
  • Асинхронная неблокирующая модель, управляемая событиями, это иNode.jsсходство;
  • По сравнению с другими серверами он может работать несколько месяцев или даже дольше без перезапуска сервера, что делает его очень надежным;
  • Горячее развертывание и плавное обновление;
  • Полностью открытый исходный код, экологическое процветание;

Роль Nginx

Наиболее важные сценарии использования Nginx:

  1. Служба статических ресурсов, предоставляющая услуги через локальную файловую систему;
  2. Служба обратного прокси, которая включает кэширование, балансировку нагрузки и т. д.;
  3. API Служить,OpenResty;


Для передней частиNode.jsне чужой,Nginx иNode.jsМногие идеи похожи,HTTPсерверные, управляемые событиями, асинхронные неблокирующие и т. д., а такжеNginxБольшинство функций используютNode.jsтакже может быть достигнуто, ноNginx иNode.jsКонфликта нет, у всех свои области знаний.NginxХорошо справляется с обработкой базовых ресурсов на стороне сервера (переадресация обработки статических ресурсов, обратный прокси-сервер, балансировка нагрузки и т. д.),Node.jsОн лучше обрабатывает конкретную бизнес-логику верхнего уровня, и их можно идеально комбинировать.

Используйте схему для представления:
未命名文件.png

Установка Nginx

Эта статья демонстрирует, чтоLinux centOS 7.xустанавливается на операционную системуNginx, что касается установки на другие операционные системы, то можете поискать в сети самостоятельно, это очень просто.

использоватьyum УстановитьNginx:

yum install nginx -y

После завершения установки пройдитеrpm -ql nginxвид командыNginxИнформация по установке для:

# Nginx配置文件
/etc/nginx/nginx.conf # nginx 主配置文件
/etc/nginx/nginx.conf.default

# 可执行程序文件
/usr/bin/nginx-upgrade
/usr/sbin/nginx

# nginx库文件
/usr/lib/systemd/system/nginx.service # 用于配置系统守护进程
/usr/lib64/nginx/modules # Nginx模块目录

# 帮助文档
/usr/share/doc/nginx-1.16.1
/usr/share/doc/nginx-1.16.1/CHANGES
/usr/share/doc/nginx-1.16.1/README
/usr/share/doc/nginx-1.16.1/README.dynamic
/usr/share/doc/nginx-1.16.1/UPGRADE-NOTES-1.6-to-1.10

# 静态资源目录
/usr/share/nginx/html/404.html
/usr/share/nginx/html/50x.html
/usr/share/nginx/html/index.html

# 存放Nginx日志文件
/var/log/nginx

Есть две папки, представляющие наибольший интерес:

  1. /etc/nginx/conf.d/место хранения элементов подконфигурации,/etc/nginx/nginx.confОсновной файл конфигурации по умолчанию импортирует все элементы вложенной конфигурации в эту папку;
  2. /usr/share/nginx/html/Статические файлы помещаются в эту папку, а также могут быть размещены в других местах в соответствии с вашими привычками;

Общие команды Nginx

systemctlСистемная команда:

# 开机配置
systemctl enable nginx # 开机自动启动
systemctl disable nginx # 关闭开机自动启动

# 启动Nginx
systemctl start nginx # 启动Nginx成功后，可以直接访问主机IP，此时会展示Nginx默认页面

# 停止Nginx
systemctl stop nginx

# 重启Nginx
systemctl restart nginx

# 重新加载Nginx
systemctl reload nginx

# 查看 Nginx 运行状态
systemctl status nginx

# 查看Nginx进程
ps -ef | grep nginx

# 杀死Nginx进程
kill -9 pid # 根据上面查看到的Nginx进程号，杀死Nginx进程，-9 表示强制结束进程

NginxКоманда приложения:

nginx -s reload  # 向主进程发送信号，重新加载配置文件，热重启
nginx -s reopen	 # 重启 Nginx
nginx -s stop    # 快速关闭
nginx -s quit    # 等待工作进程处理完成后关闭
nginx -T         # 查看当前 Nginx 最终的配置
nginx -t         # 检查配置是否有问题

Конфигурация ядра Nginx

Структура файла конфигурации

NginxТипичный пример конфигурации для:

# main段配置信息
user  nginx;                        # 运行用户，默认即是nginx，可以不进行设置
worker_processes  auto;             # Nginx 进程数，一般设置为和 CPU 核数一样
error_log  /var/log/nginx/error.log warn;   # Nginx 的错误日志存放目录
pid        /var/run/nginx.pid;      # Nginx 服务启动时的 pid 存放位置

# events段配置信息
events {
    use epoll;     # 使用epoll的I/O模型(如果你不知道Nginx该使用哪种轮询方法，会自动选择一个最适合你操作系统的)
    worker_connections 1024;   # 每个进程允许最大并发数
}

# http段配置信息
# 配置使用最频繁的部分，代理、缓存、日志定义等绝大多数功能和第三方模块的配置都在这里设置
http { 
    # 设置日志模式
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;   # Nginx访问日志存放位置

    sendfile            on;   # 开启高效传输模式
    tcp_nopush          on;   # 减少网络报文段的数量
    tcp_nodelay         on;
    keepalive_timeout   65;   # 保持连接的时间，也叫超时时间，单位秒
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;      # 文件扩展名与类型映射表
    default_type        application/octet-stream;   # 默认文件类型

    include /etc/nginx/conf.d/*.conf;   # 加载子配置项
    
    # server段配置信息
    server {
    	listen       80;       # 配置监听的端口
    	server_name  localhost;    # 配置的域名
      
    	# location段配置信息
    	location / {
    		root   /usr/share/nginx/html;  # 网站根目录
    		index  index.html index.htm;   # 默认首页文件
    		deny 172.168.22.11;   # 禁止访问的ip地址，可以为all
    		allow 172.168.33.44；# 允许访问的ip地址，可以为all
    	}
    	
    	error_page 500 502 503 504 /50x.html;  # 默认50x对应的访问页面
    	error_page 400 404 error.html;   # 同上
    }
}
  • mainГлобальная конфигурация, действующая глобально;
  • eventsВлияние конфигурацииNginxсетевое соединение между сервером и пользователем;
  • httpНастройка большинства функций, таких как прокси, кэш, определение журнала и настройка сторонних модулей;
  • serverНастройте соответствующие параметры виртуального хоста,httpВ блоке может быть больше одногоserver кусок;
  • locationдля согласования конфигурацииuri;
  • upstreamНастройте конкретный адрес внутреннего сервера, что является неотъемлемой частью конфигурации балансировки нагрузки;


Используйте диаграмму, чтобы четко показать его иерархию:
未命名文件 (4).png

Основные параметры основного раздела конфигурационного файла

user

указано для запускаNginx изwokerВладелец и группа дочернего процесса, где группу можно не указывать.

user USERNAME [GROUP]

user nginx lion; # 用户是nginx;组是lion

pid

указано для запускаNginx masterосновной процессpidПуть хранения файла.

pid /opt/nginx/logs/nginx.pid # master主进程的的pid存放在nginx.pid的文件

worker_rlimit_nofile_number

уточнитьworkerМаксимальное количество файловых дескрипторов, которые может открыть дочерний процесс.

worker_rlimit_nofile 20480; # 可以理解成每个worker子进程的最大连接数量。

worker_rlimit_core

уточнитьworkerПосле аварийного завершения дочернего процессаcoreфайл для документирования проблем анализа.

worker_rlimit_core 50M; # 存放大小限制
working_directory /opt/nginx/tmp; # 存放目录

worker_processes_number

уточнитьNginxактивированworkerКоличество дочерних процессов.

worker_processes 4; # 指定具体子进程数量
worker_processes auto; # 与当前cpu物理核心数一致

worker_cpu_affinity

положить каждыйworkerдочерний процесс и нашcpuФизическая привязка ядра.

worker_cpu_affinity 0001 0010 0100 1000; # 4个物理核心，4个worker子进程


未命名文件 (1).png

положить каждыйworkerдочерний процесс и конкретныйCPUФизическая привязка ядра, преимущество состоит в том, чтобы избежать того жеworkerдочерний процесс в другомCPUВключите ядро, инвалидация кеша, снизьте производительность. Но на самом деле это не позволяет избежать переключения процессов.

worker_priority

уточнитьworkerдочерний процессniceзначение для регулировки пробегаNginxПриоритет , обычно устанавливается на отрицательное значение, чтобы отдать приоритет вызову.Nginx.

worker_priority -10; # 120-10=110，110就是最终的优先级

LinuxЗначение приоритета процесса по умолчанию равно 120, чем меньше значение, тем выше приоритет;niceДиапазон-20 прибыть+19.

[Примечание] Значение приоритета приложения по умолчанию — 120 плюс.niceЗначение равно его конечному значению, чем меньше значение, тем выше приоритет.

worker_shutdown_timeout

уточнитьworkerТайм-аут, когда дочерний процесс корректно завершает работу.

worker_shutdown_timeout 5s;

timer_resolution

workerДля точности таймера, используемого внутри дочернего процесса, чем больше интервал настройки, тем меньше системных вызовов, что способствует повышению производительности, и, наоборот, чем больше системных вызовов, тем снижается производительность.

timer_resolution 100ms;

существуетLinuxВ системе, когда пользователю нужно получить таймер, ему нужно отправить запрос к ядру операционной системы, если есть запрос, то будут накладные расходы, поэтому чем больше интервал, тем меньше накладные расходы.

daemon

уточнитьNginxРежим работы , передний план или фон, передний план используется для отладки, а фон используется для производства.

daemon off; # 默认是on，后台运行模式

Основные параметры раздела событий конфигурационного файла

use

NginxКакую событийную модель использовать.

use method; # 不推荐配置它，让nginx自己选择

method 可选值为：select、poll、kqueue、epoll、/dev/poll、eventport

worker_connections

workerМаксимальное количество одновременных подключений, которые может обработать дочерний процесс.

worker_connections 1024 # 每个子进程的最大连接数为1024

accept_mutex

Открывать ли мьютекс балансировки нагрузки.

accept_mutex on # 默认是off关闭的，这里推荐打开

директива имя_сервера

Указывает доменное имя виртуального хоста.

server_name name1 name2 name3

# 示例：
server_name www.nginx.com;

Четыре способа записи соответствия доменных имен:

  • Точное совпадение:server_name www.nginx.com ;
  • Левый подстановочный знак:server_name *.nginx.com ;
  • Конфигурация правой стороны:server_name www.nginx.* ;
  • Регулярный матч:server_name ~^www\.nginx\.*$ ;

Приоритет соответствия:Точное соответствие > Совпадение с подстановочным знаком слева > Совпадение с подстановочным знаком справа > Совпадение с регулярным выражением

server_nameПример конфигурации:

1. Настроить локальныйDNSРазобратьvim /etc/hosts(macOS система)

# 添加如下内容，其中 121.42.11.34 是阿里云服务器IP地址
121.42.11.34 www.nginx-test.com
121.42.11.34 mail.nginx-test.com
121.42.11.34 www.nginx-test.org
121.42.11.34 doc.nginx-test.com
121.42.11.34 www.nginx-test.cn
121.42.11.34 fe.nginx-test.club

[Примечание] Имя виртуального домена используется здесь для тестирования, поэтому вам необходимо настроить локальный домен.DNSРазрешение, если вы используете доменное имя, приобретенное в облаке Alibaba, вам необходимо настроить разрешение доменного имени в облаке Alibaba.

2. Настройте облако AlibabaNginx,vim /etc/nginx/nginx.conf 

# 这里只列举了http端中的sever端配置

# 左匹配
server {
	listen	80;
	server_name	*.nginx-test.com;
	root	/usr/share/nginx/html/nginx-test/left-match/;
	location / {
		index index.html;
	}
}

# 正则匹配
server {
	listen	80;
	server_name	~^.*\.nginx-test\..*$;
	root	/usr/share/nginx/html/nginx-test/reg-match/;
	location / {
		index index.html;
	}
}

# 右匹配
server {
	listen	80;
	server_name	www.nginx-test.*;
	root	/usr/share/nginx/html/nginx-test/right-match/;
	location / {
		index index.html;
	}
}

# 完全匹配
server {
	listen	80;
	server_name	www.nginx-test.com;
	root	/usr/share/nginx/html/nginx-test/all-match/;
	location / {
		index index.html;
	}
}

3. Анализ доступа

  • при посещенииwww.nginx-test.com, все можно сопоставить, поэтому выберите «точное совпадение» с наивысшим приоритетом;
  • при посещенииmail.nginx-test.comКогда будет выполнено «левое сопоставление»;
  • при посещенииwww.nginx-test.orgКогда будет выполнено «правильное совпадение»;
  • при посещенииdoc.nginx-test.comКогда будет выполнено «левое сопоставление»;
  • при посещенииwww.nginx-test.cnКогда будет выполнено «правильное совпадение»;
  • при посещенииfe.nginx-test.club, будет выполнено «обычное сопоставление»;

root

Указывает местоположение каталога статических ресурсов, которое может быть записано вhttp,server,locationи т.п. конфигурация.

root path

例如：
location /image {
	root /opt/nginx/static;
}

当用户访问 www.test.com/image/1.png 时，实际在服务器找的路径是 /opt/nginx/static/image/1.png

[Уведомление]rootбудет комбинировать путь определения сURIналоженный,aliasЗатем берется только путь определения.

alias

Он также указывает местоположение каталога статических ресурсов, его можно записать только вlocation середина.

location /image {
	alias /opt/nginx/static/image/;
}

当用户访问 www.test.com/image/1.png 时，实际在服务器找的路径是 /opt/nginx/static/image/1.png

[Примечание] Обязательно добавьте в конце псевдоним/, и он может находиться только вlocation середина.

location

Путь конфигурации.

location [ = | ~ | ~* | ^~ ] uri {
	...
}

Правила соответствия:

  • =точное совпадение;
  • ~Регулярное сопоставление с учетом регистра;
  • ~*Регулярное сопоставление без учета регистра;
  • ^~Остановить поиск при совпадении;


Приоритет соответствия:=  > ^~  > ~  > ~*> без символов.

Пример:

server {
  listen	80;
  server_name	www.nginx-test.com;
  
  # 只有当访问 www.nginx-test.com/match_all/ 时才会匹配到/usr/share/nginx/html/match_all/index.html
  location = /match_all/ {
      root	/usr/share/nginx/html
      index index.html
  }
  
  # 当访问 www.nginx-test.com/1.jpg 等路径时会去 /usr/share/nginx/images/1.jpg 找对应的资源
  location ~ \.(jpeg|jpg|png|svg)$ {
  	root /usr/share/nginx/images;
  }
  
  # 当访问 www.nginx-test.com/bbs/ 时会匹配上 /usr/share/nginx/html/bbs/index.html
  location ^~ /bbs/ {
  	root /usr/share/nginx/html;
    index index.html index.htm;
  }
}

обратная косая черта в месте

location /test {
	...
}

location /test/ {
	...
}
  • Без/при посещенииwww.nginx-test.com/test час,NginxУзнайте, есть лиtestкаталог, если он естьtestв каталогеindex.html; если нетtest содержание,nginxузнаем, есть лиtestдокумент.
  • пояс/при посещенииwww.nginx-test.com/testчас,NginxУзнайте, есть лиtestкаталог, если он естьtestв каталогеindex.html, если его нет, он не будет искать существованиеtestдокумент.

return

Остановить обработку запроса, вернуть код ответа напрямую или перенаправить на другойURL ;воплощать в жизньreturnПосле команды,locationПоследующие инструкции не будут выполняться.

return code [text];
return code URL;
return URL;

例如：
location / {
	return 404; # 直接返回状态码
}

location / {
	return 404 "pages not found"; # 返回状态码 + 一段文本
}

location / {
	return 302 /bbs ; # 返回状态码 + 重定向地址
}

location / {
	return https://www.baidu.com ; # 返回重定向地址
}

rewrite

Переписать в соответствии с указанными правилами сопоставления регулярных выраженийURL.

语法：rewrite 正则表达式 要替换的内容 [flag];

上下文：server、location、if

示例：rewirte /images/(.*\.jpg)$ /pic/$1; # $1是前面括号(.*\.jpg)的反向引用


flagЗначение необязательных значений:

  • lastпереписанныйURLИнициируйте новый запрос и введите сноваserverсегмент, попробуйте еще разlocationсовпадения в ;
  • breakИспользуйте переписанный напрямуюURL, больше не соответствует другимlocationкитайское предложение;
  • redirectВозвращает 302 Временное перенаправление;
  • permanentвернуть 301 постоянный редирект;
server{
  listen 80;
  server_name fe.lion.club; # 要在本地hosts文件进行配置
  root html;
  location /search {
  	rewrite ^/(.*) https://www.baidu.com redirect;
  }
  
  location /images {
  	rewrite /images/(.*) /pics/$1;
  }
  
  location /pics {
  	rewrite /pics/(.*) /photos/$1;
  }
  
  location /photos {
  
  }
}

По этой конфигурации анализируем:

  • при посещенииfe.lion.club/search, он автоматически перенаправит нас наhttps://www.baidu.com.
  • при посещенииfe.lion.club/images/1.jpg, первый шаг переписываетURL заfe.lion.club/pics/1.jpg ,оказатьсяpics изlocation, продолжайте переписыватьURL заfe.lion.club/photos/1.jpg ,оказаться/photos изlocationИдти заhtml/photosНайдите в каталоге1.jpgстатические ресурсы.

если директива

语法：if (condition) {...}

上下文：server、location

示例：
if($http_user_agent ~ Chrome){
  rewrite /(.*)/browser/$1 break;
}


conditionУсловия анализа:

  • $variableТолько для переменных пустое значение или строка, начинающаяся с 0, будет рассматриваться какfalse иметь дело с;
  • = или!=равные или неравные;
  • ~Регулярный матч;
  • ! ~нерегулярный матч;
  • ~*Регулярное сопоставление без учета регистра;
  • -f или! -fОбнаружение наличия или отсутствия файлов;
  • -d или! -dОбнаружение существования или отсутствия каталога;
  • -e или! -eОбнаружение наличия или отсутствия файлов, каталогов, символических ссылок и т. д.;
  • -x или! -xПроверить, является ли файл исполняемым или нет;


Пример:

server {
  listen 8080;
  server_name localhost;
  root html;
  
  location / {
  	if ( $uri = "/images/" ){
    	rewrite (.*) /pics/ break;
    }
  }
}

при посещенииlocalhost:8080/images/, войдетifКазнить по приговоруrewrite Заказ.

autoindex

Запросы пользователей на/В конце указана структура каталогов, которую можно использовать для быстрого создания веб-сайта для загрузки статических ресурсов.

autoindex.confИнформация о конфигурации:

server {
  listen 80;
  server_name fe.lion-test.club;
  
  location /download/ {
    root /opt/source;
    
    autoindex on; # 打开 autoindex，，可选参数有 on | off
    autoindex_exact_size on; # 修改为off，以KB、MB、GB显示文件大小，默认为on，以bytes显示出⽂件的确切⼤⼩
    autoindex_format html; # 以html的方式进行格式化，可选参数有 html | json | xml
    autoindex_localtime off; # 显示的⽂件时间为⽂件的服务器时间。默认为off，显示的⽂件时间为GMT时间
  }
}

при посещенииfe.lion.com/download/, сервер будет/opt/source/download/Файлы по пути отображаются, как показано на следующем рисунке:

image.png

Переменная

NginxПользователю предоставляется множество переменных, но, в конце концов, это данные, сгенерированные полным процессом запроса.NginxЭти данные предоставляются пользователю в виде переменных.

Вот некоторые переменные, которые обычно используются в проектах:

имя переменной значение
remote_addr  клиентIP адрес
remote_port  клиентский порт
server_addr  СерверIP адрес
server_port  порт сервера
server_protocol  протокол сервера
binary_remote_addr  Клиент в бинарном форматеIP адрес
connection  TCPпорядковый номер соединения, увеличивающийся
connection_request  TCPТекущее количество запросов на подключение
uri  Запрошенный URL без параметров
request_uri  Запрошенный URL, включая параметры
scheme  имя протокола,http илиhttps 
request_method  метод запроса
request_length  Длина всего запроса, включая строку запроса, заголовок запроса и тело запроса.
args  Все строки параметров
arg_参数名  Получить конкретное значение параметра
is_args  URLЕсть ли параметры в , если да, вернуть?, иначе вернуть пустое
query_string  иargs такой же
host  в запросеHost, если запрос неHostстроку, найдите ее в заголовке запроса и, наконец, используйтеnginxустановить вserver_name.
http_user_agent  Пользовательский браузер
http_referer  по каким ссылкам пришел запрос
http_via  После каждого уровня прокси-сервера будет добавлена ​​соответствующая информация.
http_cookie  получить пользователейcookie 
request_time  Время, затраченное на обработку запроса
https  Он включен?https, если да, вернутьon, иначе вернуть пустое
request_filename  Полный путь к файлу, к которому будет осуществляться доступ в файловой системе диска.
document_root  Зависит отURI иroot/aliasПуть к папке, сгенерированный правилом
limit_rate  Верхнее предельное значение скорости при возврате ответа

Пример демонстрацииvar.conf:

server{
	listen 8081;
	server_name var.lion-test.club;
	root /usr/share/nginx/html;
	location / {
		return 200 "
remote_addr: $remote_addr
remote_port: $remote_port
server_addr: $server_addr
server_port: $server_port
server_protocol: $server_protocol
binary_remote_addr: $binary_remote_addr
connection: $connection
uri: $uri
request_uri: $request_uri
scheme: $scheme
request_method: $request_method
request_length: $request_length
args: $args
arg_pid: $arg_pid
is_args: $is_args
query_string: $query_string
host: $host
http_user_agent: $http_user_agent
http_referer: $http_referer
http_via: $http_via
request_time: $request_time
https: $https
request_filename: $request_filename
document_root: $document_root
";
	}
}

когда мы посещаемhttp://var.lion-test.club:8081/test?pid=121414&cid=sadasd, из-заNginxнаписано наreturnметод, поэтомуchromeБраузер по умолчанию загрузит для нас файл, и содержимое загруженного файла показано ниже:

remote_addr: 27.16.220.84
remote_port: 56838
server_addr: 172.17.0.2
server_port: 8081
server_protocol: HTTP/1.1
binary_remote_addr: 茉
connection: 126
uri: /test/
request_uri: /test/?pid=121414&cid=sadasd
scheme: http
request_method: GET
request_length: 518
args: pid=121414&cid=sadasd
arg_pid: 121414
is_args: ?
query_string: pid=121414&cid=sadasd
host: var.lion-test.club
http_user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36
http_referer: 
http_via: 
request_time: 0.000
https: 
request_filename: /usr/share/nginx/html/test/
document_root: /usr/share/nginx/html

NginxКонфигураций по-прежнему много.Выше приведен лишь список некоторых часто используемых конфигураций.В реальных проектах вам все равно нужно научиться обращаться к документации.

Основные понятия приложения Nginx

Прокси — это гипотетический уровень сервера между сервером и клиентом, прокси будет получать запрос клиента и пересылать его на сервер, а затем пересылать ответ сервера клиенту.

Будь то прямой прокси или обратный прокси, вышеперечисленные функции реализованы.

image.png

прямой прокси

Прокси-сервер вперед, то есть сервер между клиентом и сервером-источником, чтобы получить контент с сервера-источника, клиент отправляет запрос на прокси-сервер и указывает цель (сервер-источник), а затем прокси-сервер пересылает на источник сервер Запрос и возврат полученного контента клиенту.


Форвард-прокси для нас, то есть для клиента.Клиент может получить доступ к ресурсам сервера, к которым он не может получить доступ по форвард-прокси.

Форвард-прокси прозрачен для нас и непрозрачен для сервера, то есть сервер не знает, получает ли он доступ с прокси или с реального клиента.

обратный прокси

  • Обратный прокси* (Reverse Proxy) означает, что прокси-сервер принимает запросы на подключение в Интернете, затем перенаправляет запрос на сервер во внутренней сети и возвращает результат, полученный от сервера, клиенту, запрашивающему подключение в Интернете. прокси-сервер ведет себя как обратный прокси-сервер для внешнего мира.


Обратный прокси-сервер обслуживает сторону сервера.Обратный прокси-сервер может помочь серверу получать запросы от клиента, помогать серверу выполнять переадресацию запросов, балансировку нагрузки и т. д.

Обратный прокси прозрачен для сервера и непрозрачен для нас, то есть мы не знаем, что обращаемся к прокси-серверу, а сервер знает, что его обслуживает обратный прокси.

Преимущества обратного прокси:

  • скрыть настоящий сервер;
  • Балансировка нагрузки облегчает горизонтальное расширение внутренних динамических сервисов;
  • Динамическое и статическое разделение повышает надежность системы;


Так что же такое «движение и статическое разделение»? Что такое балансировка нагрузки?

Динамическое и статическое разделение

Разделение динамических и статических средств вwebВ серверной архитектуре - метод архитектурного проектирования, который отделяет статические страницы от динамических страниц или интерфейсов статического содержимого и интерфейсов динамического содержимого для доступа из разных систем, тем самым обеспечивая доступность и ремонтопригодность всей службы.

未命名文件.png

Вообще говоря, необходимо разделить динамические ресурсы и статические ресурсы, потому чтоNginxТакие функции, как высокий параллелизм и кэширование статических ресурсов, статические ресурсы часто развертываются вNginx начальство. Если запрос относится к статическим ресурсам, перейдите непосредственно в каталог статических ресурсов для получения ресурсов.Если запрос относится к динамическим ресурсам, используется принцип обратного прокси-сервера для пересылки запроса соответствующему фоновому приложению для обработки, тем самым реализуя динамические и статическое разделение.

После разделения внешнего и внутреннего интерфейса скорость доступа к статическим ресурсам может быть значительно улучшена.Даже если динамические сервисы недоступны, доступ к статическим ресурсам не пострадает.

балансировки нагрузки

Как правило, клиент отправляет несколько запросов на сервер, сервер обрабатывает запросы, и некоторым из них может потребоваться работа с некоторыми ресурсами, такими как базы данных, статические ресурсы и т. д. После завершения обработки сервером результаты возвращаются клиенту. .

Для ранних систем эта модель предъявляла несложные функциональные требования и могла работать с относительно небольшим числом одновременных запросов, а стоимость также была низкой. Поскольку объем информации продолжает расти, объем доступа и данных быстро растет, а сложность системного бизнеса продолжает расти, этот подход больше не может соответствовать требованиям.Когда параллелизм особенно велик, сервер подвержен краху .

Очевидно, это проблема, вызванная узким местом в производительности сервера.Помимо машины с кучей, самое главное - это балансировка нагрузки.

В случае взрывного роста запросов производительность одной машины не может удовлетворить требованиям, какой бы сильной она ни была.В это время возникла концепция кластеризации.Для задач, которые не могут быть решены одним сервером, серверы могут быть использованы, а затем запросы могут быть распределены по каждому серверу.Нагрузка распределяется по разным серверам, что является балансировкой нагрузки, а ядром является «распределение давления».NginxРеализация балансировки нагрузки обычно относится к переадресации запросов на кластеры серверов.

Чтобы привести конкретный пример, когда вы едете в метро в вечерний час пик, у входа на станцию ​​​​часто будет громко говорить персонал метро: «Пожалуйста, идите.B рот,BНаселение мало, вагон пустой...", роль этого персонала - балансировка нагрузки.
未命名文件 (3).png

NginxСтратегии реализации балансировки нагрузки:

  • Стратегия опроса: стратегия, принятая по умолчанию, назначает серверу опрос всех клиентских запросов. Эта стратегия может работать нормально, но если один из серверов находится под слишком большой нагрузкой и возникает задержка, это повлияет на всех пользователей, назначенных этому серверу.
  • Политика минимального количества подключений. Отдавайте приоритет запросам менее загруженным серверам, это может сбалансировать длину каждой очереди и избежать добавления дополнительных запросов к загруженным серверам.
  • Политика самого быстрого времени отклика: отдавайте приоритет серверу с самым коротким временем отклика.
  • клиентipСтратегия связывания: из той жеipЗапрос всегда выделяется только одному серверу, что эффективно решает проблему существования динамических веб-страниц.sessionПоделитесь проблемой.

Фактическая конфигурация Nginx

Перед настройкой таких функций, как обратный прокси-сервер и балансировка нагрузки, мы должны освоить два основных модуля.NginxЯдрами в конфигурации приложения являются:upstream,proxy_pass.

upstream

Он используется для определения соответствующей информации вышестоящего сервера (со ссылкой на сервер приложений, предоставляемый в фоновом режиме).

未命名文件 (2).png

语法：upstream name {
	...
}

上下文：http

示例：
upstream back_end_server{
  server 192.168.100.33:8081
}

существуетupstreamКоманды, которые можно использовать в:

  • serverОпределить адрес вышестоящего сервера;
  • zoneОпределить общую память для использованияworkerдочерний процесс;
  • keepaliveВключить постоянные соединения для восходящих служб;
  • keepalive_requestsМаксимальное количество запросов на длительное соединениеHTTPномер;
  • keepalive_timeoutВ состоянии простоя период тайм-аута длительного соединения;
  • hashАлгоритм балансировки хеш-нагрузки;
  • ip_hash в соответствии сIPАлгоритм балансировки нагрузки для расчета хэша;
  • least_connАлгоритм балансировки нагрузки с наименьшим количеством подключений;
  • least_timeАлгоритм балансировки нагрузки с кратчайшим временем отклика;
  • randomалгоритм случайной балансировки нагрузки;

server

Определите адрес вышестоящего сервера.

语法：server address [parameters]

上下文：upstream

parametersНеобязательное значение:

  • weight=numberЗначение веса, по умолчанию 1;
  • max_conns=numberМаксимальное количество одновременных подключений к вышестоящему серверу;
  • fail_timeout=timeВремя, когда сервер недоступен;
  • max_fails=numerколичество проверок того, что сервер недоступен;
  • backupРезервный сервер, включается только тогда, когда другие серверы недоступны;
  • downСервер тегов долгое время недоступен и поддерживается в автономном режиме;

keepalive

ограничить каждыйworkerМаксимальное количество простаивающих длинных соединений между дочерними процессами и вышестоящими серверами.

keepalive connections;

上下文：upstream

示例：keepalive 16;

keepalive_requests

Одно длинное соединение может обрабатывать большинствоHTTPколичество запросов.

语法：keepalive_requests number;

默认值：keepalive_requests 100;

上下文：upstream

keepalive_timeout

Максимальное время удержания для незанятых длинных соединений.

语法：keepalive_timeout time;

默认值：keepalive_timeout 60s;

上下文：upstream

Экземпляр конфигурации

upstream back_end{
	server 127.0.0.1:8081 weight=3 max_conns=1000 fail_timeout=10s max_fails=2;
  keepalive 32;
  keepalive_requests 50;
  keepalive_timeout 30s;
}

proxy_pass

Используется для настройки прокси-сервера.

语法：proxy_pass URL;

上下文：location、if、limit_except

示例：
proxy_pass http://127.0.0.1:8081
proxy_pass http://127.0.0.1:8081/proxy

URLПринцип параметра

  1. URLдолжно бытьhttp илиhttpsНачало;
  2. URLможет содержать переменные;
  3. URLли принестиURI, напрямую повлияет на запрос, отправленный восходящемуURL;


Давайте рассмотрим два общихURLИспользование:

  1. proxy_pass http://192.168.100.33:8081 
  2. proxy_pass http://192.168.100.33:8081/

Разница между двумя вариантами использования заключается в том, что/и без/, они сильно отличаются при настройке прокси:

  • Без/означаетNginxне будет изменять пользователяURL, но напрямую на вышестоящий сервер приложений;
  • пояс/означаетNginxизменит пользователяURL, метод модификации заключается вlocation ПослеURLот пользователяURLУдалить;


Без/Использование:

location /bbs/{
  proxy_pass http://127.0.0.1:8080;
}

анализировать:

  1. Запрос пользователяURL:/bbs/abc/test.html 
  2. запрос поступаетNginx изURL:/bbs/abc/test.html 
  3. Запрос поступает на вышестоящий сервер приложенийURL:/bbs/abc/test.html 


пояс/Использование:

location /bbs/{
  proxy_pass http://127.0.0.1:8080/;
}

анализировать:

  1. Запрос пользователяURL:/bbs/abc/test.html 
  2. запрос поступаетNginx изURL:/bbs/abc/test.html 
  3. Запрос поступает на вышестоящий сервер приложенийURL:/abc/test.html 


не сращенный/bbs, это иroot иaliasРазница между ними постоянна.

Настроить обратный прокси

Для того, чтобы продемонстрировать ближе к реальности, автор подготовил два облачных сервера, их публичная сетьIPОни есть:121.42.11.34 и121.5.180.193.

мы кладем121.42.11.34Сервер используется в качестве вышестоящего сервера и настроен следующим образом:

# /etc/nginx/conf.d/proxy.conf
server{
  listen 8080;
  server_name localhost;
  
  location /proxy/ {
    root /usr/share/nginx/html/proxy;
    index index.html;
  }
}

# /usr/share/nginx/html/proxy/index.html
<h1> 121.42.11.34 proxy html </h1>

Перезагрузка после завершения настройкиNginxсерверnginx -s reload.

Пучок121.5.180.193В качестве прокси-сервера сервер настроен следующим образом:

# /etc/nginx/conf.d/proxy.conf
upstream back_end {
  server 121.42.11.34:8080 weight=2 max_conns=1000 fail_timeout=10s max_fails=3;
  keepalive 32;
  keepalive_requests 80;
  keepalive_timeout 20s;
}

server {
  listen 80;
  server_name proxy.lion.club;
  location /proxy {
  	proxy_pass http://back_end/proxy;
  }
}

локальная машина для доступаproxy.lion.clubдоменное имя, поэтому вам нужно настроить локальныйhosts, через команду:vim /etc/hostsВойдите в файл конфигурации и добавьте следующее:

121.5.180.193 proxy.lion.club

image.png

анализировать:

  1. при посещенииproxy.lion.club/proxyпрошел, когдаupstreamконфигурация найдена121.42.11.34:8080;
  2. Таким образом, адрес доступа становитсяhttp://121.42.11.34:8080/proxy;
  3. Подключен к121.42.11.34сервер, нашел8080порт предоставляетсяserver;
  4. пройти черезserver оказаться/usr/share/nginx/html/proxy/index.htmlресурсы и, наконец, отображается.

Настроить балансировку нагрузки

Настройка балансировки нагрузки в основном предназначена для использованияupstreamинструкция.

мы кладем121.42.11.34Сервер используется в качестве вышестоящего сервера и настроен следующим образом (/etc/nginx/conf.d/balance.conf):

server{
  listen 8020;
  location / {
  	return 200 'return 8020 \n';
  }
}

server{
  listen 8030;
  location / {
  	return 200 'return 8030 \n';
  }
}

server{
  listen 8040;
  location / {
  	return 200 'return 8040 \n';
  }
}

После завершения настройки:

  1. nginx -tПроверьте правильность конфигурации;
  2. nginx -s reloadперезагружатьNginxсервер;
  3. воплощать в жизньss -nltКоманда для проверки того, занят ли порт, чтобы судитьNginxПравильно ли запущена служба.


Пучок121.5.180.193В качестве прокси-сервера сервер настроен следующим образом (/etc/nginx/conf.d/balance.conf):

upstream demo_server {
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

Перезагрузка после завершения настройкиNginxсервер. И он настроен на клиенте, к которому нужно получить доступipСвязь сопоставления с доменным именем.

# /etc/hosts

121.5.180.193 balance.lion.club

Выполнить на клиентской машинеcurl http://balance.lion.club/balance/ Заказ:

image.png

Нетрудно заметить, что конфигурация балансировки нагрузки вступила в силу, и выдаваемые нам вышестоящие серверы каждый раз разные. Это распределение вышестоящего сервера с помощью простой стратегии опроса.

Далее узнаемNginxдругие стратегии распределения.

хеш-алгоритм

формулируя ключевые слова какhash key, на основеhashАлгоритмы сопоставляются с конкретными вышестоящими серверами. Ключевые слова могут содержать переменные и строки.

upstream demo_server {
  hash $request_uri;
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

hash $request_uriуказать использованиеrequest_uriпеременная какhash изkeyзначение, если доступURIЕсли он останется прежним, он всегда будет распространяться на один и тот же сервер.

ip_hash

По запросу клиентаipвыносить суждения, покаipЕсли адрес не меняется, он всегда будет назначен одному и тому же хосту. Он может эффективно решить фоновый серверsessionсохранить проблему.

upstream demo_server {
  ip_hash;
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

Алгоритм наименьших соединений

каждыйworkerДочерний процесс получает информацию о внутреннем сервере, считывая данные из общей памяти. выбрать сервер с наименьшим количеством установленных соединений для распределения запроса.

语法：least_conn;

上下文：upstream;

Пример:

upstream demo_server {
  zone test 10M; # zone可以设置共享内存空间的名字和大小
  least_conn;
  server 121.42.11.34:8020;
  server 121.42.11.34:8030;
  server 121.42.11.34:8040;
}

server {
  listen 80;
  server_name balance.lion.club;
  
  location /balance/ {
  	proxy_pass http://demo_server;
  }
}

В итоге вы обнаружите, что настройка балансировки нагрузки совсем не сложна.

Настроить кеш

Кэширование может очень эффективно повысить производительность, поэтому, будь то клиент (браузер) или прокси-сервер (Nginx), и даже вышестоящие серверы в некоторой степени участвуют в кэшировании. Видно, что кеширование очень важно в каждой ссылке. Давай учитьNginxКак установить стратегию кэширования в .

proxy_cache

Храните некоторые ресурсы, к которым уже обращались раньше и к которым можно будет обращаться снова, чтобы пользователи могли получить их напрямую с прокси-сервера, тем самым снизив нагрузку на вышестоящий сервер и ускорив общую скорость доступа.

语法：proxy_cache zone | off ; # zone 是共享内存的名称

默认值：proxy_cache off;

上下文：http、server、location

proxy_cache_path

Установите путь хранения файлов кеша.

语法：proxy_cache_path path [level=levels] ...可选参数省略，下面会详细列举

默认值：proxy_cache_path off

上下文：http

Значение параметра:

  • pathПуть хранения файла кеша;
  • level pathУровень каталога ;
  • keys_zoneустановить общую память;
  • inactiveЕсли к нему не обратиться в течение указанного времени, кеш будет очищен, по умолчанию 10 минут;

proxy_cache_key

установить кеш-файлkey.

语法：proxy_cache_key

默认值：proxy_cache_key $scheme$proxy_host$request_uri;

上下文：http、server、location

proxy_cache_valid

Настройте, какие коды состояния можно кэшировать и как долго.

语法：proxy_cache_valid [code...] time;

上下文：http、server、location

配置示例：proxy_cache_valid 200 304 2m;; # 说明对于状态为200和304的缓存文件的缓存时间是2分钟

proxy_no_cache

Определяет соответствующие условия сохранения в кеш, если хотя бы одно значение строкового параметра не пусто и не равно "0", то ответ не будет сохранен в кеш.

语法：proxy_no_cache string;

上下文：http、server、location

示例：proxy_no_cache $http_pragma    $http_authorization;

proxy_cache_bypass

Определяет условие, при котором ответ не будет извлечен из кэша.

语法：proxy_cache_bypass string;

上下文：http、server、location

示例：proxy_cache_bypass $http_pragma    $http_authorization;

переменная upstream_cache_status

Он хранит информацию о том, попал ли кеш или нет, и будет установлен в информации заголовка ответа, что очень полезно при отладке.

MISS: 未命中缓存
HIT： 命中缓存
EXPIRED: 缓存过期
STALE: 命中了陈旧缓存
REVALIDDATED: Nginx验证陈旧缓存依然有效
UPDATING: 内容陈旧，但正在更新
BYPASS: X响应从原始服务器获取

Экземпляр конфигурации

мы кладем121.42.11.34Сервер используется в качестве вышестоящего сервера и настроен следующим образом (/etc/nginx/conf.d/cache.conf):

server {
  listen 1010;
  root /usr/share/nginx/html/1010;
  location / {
  	index index.html;
  }
}

server {
  listen 1020;
  root /usr/share/nginx/html/1020;
  location / {
  	index index.html;
  }
}

Пучок121.5.180.193В качестве прокси-сервера сервер настроен следующим образом (/etc/nginx/conf.d/cache.conf):

proxy_cache_path /etc/nginx/cache_temp levels=2:2 keys_zone=cache_zone:30m max_size=2g inactive=60m use_temp_path=off;

upstream cache_server{
  server 121.42.11.34:1010;
  server 121.42.11.34:1020;
}

server {
  listen 80;
  server_name cache.lion.club;
  location / {
    proxy_cache cache_zone; # 设置缓存内存，上面配置中已经定义好的
    proxy_cache_valid 200 5m; # 缓存状态为200的请求，缓存时长为5分钟
    proxy_cache_key $request_uri; # 缓存文件的key为请求的URI
    add_header Nginx-Cache-Status $upstream_cache_status # 把缓存状态设置为头部信息，响应给客户端
    proxy_pass http://cache_server; # 代理转发
  }
}

Кэш настроен так, мы можем/etc/nginx/cache_tempНайдите соответствующий файл кеша по пути.

Для некоторых страниц или данных с очень высокими требованиями к реальному времени не стоит устанавливать кеш.Давайте посмотрим, как настроить контент, который не кешируется.

...

server {
  listen 80;
  server_name cache.lion.club;
  # URI 中后缀为 .txt 或 .text 的设置变量值为 "no cache"
  if ($request_uri ~ \.(txt|text)$) {
  	set $cache_name "no cache"
  }
  
  location / {
    proxy_no_cache $cache_name; # 判断该变量是否有值，如果有值则不进行缓存，如果没有值则进行缓存
    proxy_cache cache_zone; # 设置缓存内存
    proxy_cache_valid 200 5m; # 缓存状态为200的请求，缓存时长为5分钟
    proxy_cache_key $request_uri; # 缓存文件的key为请求的URI
    add_header Nginx-Cache-Status $upstream_cache_status # 把缓存状态设置为头部信息，响应给客户端
    proxy_pass http://cache_server; # 代理转发
  }
}

HTTPS

учимся настраиватьHTTPSПеред этим давайте кратко рассмотримHTTPSКаков рабочий процесс? Как он зашифрован и защищен?

Рабочий процесс HTTPS

  1. Клиентский (браузерный) доступhttps://www.baidu.comвеб-сайт Байду;
  2. Сервер Baidu возвращаетсяHTTPS в использованииCAсертификат;
  3. Браузерная аутентификацияCAЯвляется ли сертификат юридическим сертификатом;
  4. Если проверка пройдена, сертификат действителен, генерируется строка случайных чисел и шифруется с помощью открытого ключа (предоставляется в сертификате);
  5. Отправить случайное число, зашифрованное открытым ключом, на сервер Baidu;
  6. Сервер Baidu получает зашифрованный текст, расшифровывает его с помощью закрытого ключа и получает случайное число (шифрование с открытым ключом, дешифрование с закрытым ключом и наоборот);
  7. Сервер Baidu шифрует отправляемый в браузер контент случайными числами и передает его в браузер;
  8. В это время браузер может использовать случайное число для расшифровки и получения реального содержимого передачи сервера;

ЭтоHTTPSОсновной принцип работы использует симметричное шифрование и асимметричные секреты для обеспечения безопасности передаваемого контента.

Дополнительные сведения о HTTPS можно найти в другой статье автора «Изучение протокола HTTP»..

Настроить сертификаты

Загрузите сжатый файл сертификата, который имеетNginxпапка, положитьxxx.crt иxxx.keyСкопируйте файл в каталог сервера и настройте его следующим образом:

server {
  listen 443 ssl http2 default_server;   # SSL 访问端口号为 443
  server_name lion.club;         # 填写绑定证书的域名(我这里是随便写的)
  ssl_certificate /etc/nginx/https/lion.club_bundle.crt;   # 证书地址
  ssl_certificate_key /etc/nginx/https/lion.club.key;      # 私钥地址
  ssl_session_timeout 10m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 支持ssl协议版本，默认为后三个，主流版本是[TLSv1.2]
 
  location / {
    root         /usr/share/nginx/html;
    index        index.html index.htm;
  }
}


После этой конфигурации вы можете получить к ней обычный доступHTTPSверсия сайта.

Настройка междоменного CORS

Давайте кратко рассмотрим, что происходит в разных доменах.

Определение перекрестного домена

Политика того же источника ограничивает взаимодействие документов или сценариев, загруженных из одного источника, с ресурсами из другого источника. Это важный механизм безопасности для изоляции потенциально вредоносных файлов. Операции чтения между разными источниками обычно не допускаются.

Определение гомологии

Две страницы имеют один и тот же источник, если их протокол, порт (если указан) и доменное имя совпадают.

приведенный ниже совпадает с URL-адресомhttp://store.company.com/dir/page.htmlПример исходника для сравнения:

http://store.company.com/dir2/other.html 同源
https://store.company.com/secure.html 不同源，协议不同
http://store.company.com:81/dir/etc.html 不同源，端口不同
http://news.company.com/dir/other.html 不同源，主机不同

Различные источники имеют следующие ограничения:

  • WebНа уровне данных политика одного и того же источника запрещает сайтам из разных источников читать данные текущего сайта.Cookie,IndexDB,LocalStorageданные.
  • DOMуровне, политика того же происхождения ограничиваетJavaScriptскрипт на текущийDOMОперации чтения и записи объекта.
  • На сетевом уровне политика одного и того же источника ограничиваетXMLHttpRequestОтправляйте данные сайта на сайты из разных источников.

Nginx решает принцип кроссдоменности

Например:

  • внешний интерфейсserverДоменное имя:fe.server.com 
  • Доменное имя серверной службы:dev.server.com 


я сейчас вfe.server.com правильноdev.server.comПри оформлении запроса должен быть междоменный.

Теперь нам просто нужно начатьNginxсервер, будетserver_nameУстановить какfe.server.comЗатем установите соответствующийlocationЧтобы перехватить внешние запросы, требующие междоменного доступа, и, наконец, проксировать запрос обратноdev.server.com. Например, следующая конфигурация:

server {
	listen   		 80;
	server_name  fe.server.com;
	location / {
		proxy_pass dev.server.com;
	}
}


Это прекрасно обходит политику браузера с одинаковым происхождением:fe.server.comвизитNginx изfe.server.comотносится к доступу того же происхождения, в то время какNginxЗапросы, пересылаемые сервером, не запускают политику браузера с тем же источником.

Настройте, чтобы включить сжатие gzip

GZIPтри стандартныхHTTPОдин из форматов сжатия. В настоящее время большинство веб-сайтов используютGZIPкоробка передачHTML,CSS,JavaScriptи другие файлы ресурсов.

Для текстовых файлов,GZiPЭффект очень очевиден, и трафик, необходимый для передачи, сократится примерно до1/4~1/3.

Не каждый браузер поддерживаетgzip, как узнать, поддерживает ли клиентgzipНу и в шапке запросаAccept-Encodingдля определения поддержки сжатия.
image.png
включитьgzipТребуется поддержка как клиента, так и сервера, если клиент поддерживаетgzip, то до тех пор, пока сервер может вернутьgzipфайл можно включитьgzip, мы можем пройтиNginxконфигурация, позволяющая серверу поддерживатьgzip. следующееrespone серединаcontent-encoding:gzip, что означает, что сервер включенgzipкомпрессионный метод.
image.png
существует /etc/nginx/conf.d/Создайте новый файл конфигурации в папкеgzip.conf:

# # 默认off，是否开启gzip
gzip on; 
# 要采用 gzip 压缩的 MIME 文件类型，其中 text/html 被系统强制启用；
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

# ---- 以上两个参数开启就可以支持Gzip压缩了 ---- #

# 默认 off，该模块启用后，Nginx 首先检查是否存在请求静态文件的 gz 结尾的文件，如果有则直接返回该 .gz 文件内容；
gzip_static on;

# 默认 off，nginx做为反向代理时启用，用于设置启用或禁用从代理服务器上收到相应内容 gzip 压缩；
gzip_proxied any;

# 用于在响应消息头中添加 Vary：Accept-Encoding，使代理服务器根据请求头中的 Accept-Encoding 识别是否启用 gzip 压缩；
gzip_vary on;

# gzip 压缩比，压缩级别是 1-9，1 压缩级别最低，9 最高，级别越高压缩率越大，压缩时间越长，建议 4-6；
gzip_comp_level 6;

# 获取多少内存用于缓存压缩结果，16 8k 表示以 8k*16 为单位获得；
gzip_buffers 16 8k;

# 允许压缩的页面最小字节数，页面字节数从header头中的 Content-Length 中进行获取。默认值是 0，不管页面多大都压缩。建议设置成大于 1k 的字节数，小于 1k 可能会越压越大；
# gzip_min_length 1k;

# 默认 1.1，启用 gzip 所需的 HTTP 最低版本；
gzip_http_version 1.1;

На самом деле, вы также можете использовать такие инструменты сборки интерфейса, какwebpack,rollupСделайте это, когда производственный пакет сделанGzipсжать, затем положитьNginxНа сервере это может снизить нагрузку на сервер и увеличить скорость доступа.

оNginxЗдесь изучается практическое применение, я считаю, что, освоивNginxБазовая конфигурация и фактическая боевая конфигурация, мы можем легко справиться с любыми потребностями, которые возникнут позже. Далее давайте изучим немного глубжеNginxархитектура.

Архитектура Nginx

Структура процесса

многопроцессная структураNginxСхема модели процесса:

未命名文件.png

в нескольких процессахNginxАрхитектура процесса показана на рисунке ниже, и там будет родительский процесс (Master Process), у него будет много дочерних процессов (Child Processes).

  • Master ProcessИспользуется для управления дочерними процессами, но сам по себе не обрабатывает запросы пользователей.
    • дочерний процессdownЕсли уронить, тоMasterПроцесс отправляет сообщение о том, что в данный момент он недоступен.MasterПроцесс запустит новый дочерний процесс.
    • Файл конфигурации был измененMasterПроцесс уведомитworkПроцесс получает новую информацию о конфигурации, что мы называем горячим развертыванием.
  • Дочерние процессы взаимодействуют через разделяемую память.

Принцип перегрузки конфигурационного файла

reloadПроцесс перезагрузки файла конфигурации:

  1. В направленииmasterпроцесс отправкиHUPСигнал(reload Заказ);
  2. masterПроцесс проверяет правильность синтаксиса конфигурации;
  3. masterПроцесс открывает прослушивающий порт;
  4. masterПроцесс начинается заново с новым файлом конфигурацииworkerдочерний процесс;
  5. masterпроцесс до старогоworkerдочерний процесс отправитьQUITСигнал;
  6. СтарыйworkerПроцесс закрывает дескриптор прослушивания и закрывает процесс после обработки текущего соединения;
  7. весь процессNginxОн всегда работает бесперебойно, реализуя плавное обновление, и пользователи не знают об этом;

Модульный механизм управления Nginx

NginxВнутренняя структура состоит из основных частей и ряда функциональных модулей. Это разделение должно сделать функцию каждого модуля относительно простой, легкой в ​​разработке, а также легко расширить функцию системы.NginxМодули независимы друг от друга, с низкой связанностью и высокой связностью.
image.png

Суммировать

Я считаю, что благодаря изучению этой статьи вы должны ознакомиться сNginxиметь более полное представление.

Чтобы увидеть все это здесь, просто нажмите 👍👍👍.

Категории