Знания Nginx, которые должны знать фронтенд-инженеры

внешний интерфейс Nginx
Знания Nginx, которые должны знать фронтенд-инженеры

"Видимость: 🌟🌟🌟🌟🌟"

"Вкус: яйца из шкуры тигра"

"Время приготовления: 10 мин."

Этот артикул внесен в одноименный склад во фронтовой столовойGithub github.com/Geekhyt, Добро пожаловать в кафетерий. Если вы считаете, что еда и вино по-прежнему вкусные, звезда станет большим поощрением для владельца кафетерия.

Исторический фон

Глобализация Интернета привела к быстрому росту объема данных в Интернете, вкупе с несостоятельностью закона Мура об одноядерных ЦП в начале этого века, ЦП развиваются в направлении многоядерных, а Apache явно не готов к многоядерной архитектуре, процесс может обрабатывать только одно соединение за раз, а следующее может обработать только после обработки одного запроса, что несомненно не справляется с количеством пользователей в интернете сегодня. Более того, стоимость переключения между процессами очень высока. В связи с этим появился Nginx, который легко справляется с миллионами, десятками миллионов соединений.

Преимущество Nginx

  • Высокий параллелизм и высокая производительность
  • Хорошая масштабируемость
  • Высокая надежность
  • горячее развертывание
  • Лицензия с открытым исходным кодом

Основные сценарии применения Nginx

  • Обслуживание статических ресурсов, обслуживание через локальную файловую систему
  • Обратный прокси-сервис, балансировка нагрузки
  • Служба API, контроль разрешений, снижение нагрузки на сервер приложений

Конфигурационные файлы и каталоги Nginx

пройти черезrpm -ql nginxВы можете просмотреть файлы конфигурации и каталоги установки Nginx.

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

  • /etc/nginx/nginx.conf основной файл конфигурации
  • /etc/nginx/conf.d/default.conf файл конфигурации HTTP-сервера по умолчанию
  • /etc/nginx/fastcgi_params конфигурация fastcgi
  • /etc/nginx/scgi_params конфигурация scgi
  • /etc/nginx/uwsgi_params конфигурация uwsgi
  • /etc/nginx/koi-utf
  • /etc/nginx/koi-win
  • /etc/nginx/win-utf Эти три файла являются файлами сопоставления кодировок, потому что автор русский
  • /etc/nginx/mime.types Файл, устанавливающий соответствие между Content-Type протокола HTTP и расширением
  • /usr/lib/systemd/system/nginx-debug.service
  • /usr/lib/systemd/system/nginx.service
  • /etc/sysconfig/nginx
  • /etc/sysconfig/nginx-debug Эти четыре файла используются для настройки управления демоном.
  • /etc/nginx/modules Базовые общие библиотеки и модули ядра
  • /usr/share/doc/nginx-1.18.0 справочная документация
  • /usr/share/doc/nginx-1.18.0/COPYRIGHT Уведомление об авторских правах
  • /usr/share/man/man8/nginx.8.gz инструкция
  • /var/cache/nginx Каталог кеша Nginx
  • /var/log/nginx Каталог журналов Nginx
  • /usr/sbin/nginx исполняемая команда
  • /usr/sbin/nginx-debug отлаживать и выполнять исполняемые команды

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

Переадресация прокси

Объясните прямой прокси одним предложением Объект прямого прокси — это клиент, а сервер не может видеть настоящего клиента.

resolver 8.8.8.8 # 谷歌的域名解析地址
server {
 location / {
      # 当客户端请求我的时候，我会把请求转发给它
      # $http_host 要访问的主机名 $request_uri 请求路径
      proxy_pass http://$http_host$request_uri;
 }
}

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

Объясните обратный прокси одним предложением Объект обратного прокси — это сервер, а клиент не может видеть настоящий сервер.

перекрестный домен

Кросс-доменный сценарий — это сценарий, с которым столкнутся интерфейсные инженеры, и существует множество кросс-доменных решений. Но знайте, что в производственной среде либо используйте CORS, либо обратный прокси-сервер Nginx для междоменного решения. Сделайте следующее в файле конфигурации Nginx:

server {
    listen   80;
    server_name   localhost; # 用户访问 localhost，反向代理到 http://webcanteen.com
    location / {
        proxy_pass http://webcanteen.com
    }
}

Gzip

Gzip — это очень распространенный формат сжатия данных в Интернете.Для простого текста он может быть сжат до 40% от исходного размера, что может значительно сэкономить трафик. Обратите внимание, однако, что минимальная версия HTTP, необходимая для включения Gzip, — 1.1.

location ~ .*\. (jpg|png|gif)$ {
    gzip off; #关闭压缩
    root /data/www/images;
}
location ~ .*\. (html|js|css)$ {
    gzip on; #启用压缩
    gzip_min_length 1k; # 超过1K的文件才压缩
    gzip_http_version 1.1; # 启用gzip压缩所需的HTTP最低版本
    gzip_comp_level 9; # 压缩级别，压缩比率越高，文件被压缩的体积越小
    gzip_types text/css application/javascript; # 进行压缩的文件类型
    root /data/www/html;
}

лимит запроса

Вредоносный доступ с большим трафиком приведет к потере пропускной способности и увеличению нагрузки на сервер. Количество подключений и параллелизма одного и того же IP часто ограничено.

Существует два основных типа лимитов запросов:

  • limit_conn_module ограничение частоты соединений
  • limit_req_module ограничение частоты запросов
# $binary_remote_addr 远程IP地址 zone 区域名称 10m内存区域大小
limit_conn_zone $binary_remote_addr zone=coon_zone:10m;
server {
    # conn_zone 设置对应的共享内存区域 1是限制的数量
 limit_conn conn_zone 1;
}
# $binary_remote_addr 远程IP地址 zone 区域名称 10m内存区域大小 rate 为请求频率 1s 一次
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;
server {
    location / {
        # 设置对应的共享内存区域 burst最大请求数阈值 nodelay不希望超过的请求被延迟
        limit_req zone=req_zone burst=5 nodelay;
    }
}

Контроль доступа

Существует два основных типа контроля доступа:

  • -http_access_module Управление доступом на основе IP
  • -http_auth_basic_module доверенный вход на основе пользователя

(Доверительный вход в систему на основе пользователя не очень безопасен, в этой статье не описываются настройки)

Ниже приведены элементы управления доступом на основе IP:

server {
 location ~ ^/index.html {
  # 匹配 index.html 页面 除了 127.0.0.1 以外都可以访问
  deny 127.0.0.1;
  allow all;
 }
}

ab команда

Полное название команды ab: Apache Bench — это инструмент стресс-тестирования, который поставляется вместе с Apache, а также может тестировать другие веб-серверы, такие как Nginx и IIS.

  • -n общее количество запросов
  • -c количество одновременных запросов
ab -n 1000 -c 5000 http://127.0.0.1/

противоугонная цепь

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

location ~ .*\.(jpg|png|gif)$ { # 匹配防盗链资源的文件类型
    # 通过 valid_referers 定义合法的地址白名单 $invalid_referer 不合法的返回403  
    valid_referers none blocked 127.0.0.1;
    if ($invalid_referer) {
        return 403;
    }
}

Баланс нагрузки Баланс нагрузки

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

Nginx может предоставить нам возможность балансировки нагрузки, конкретная конфигурация выглядит следующим образом:

# upstream 指定后端服务器地址
# weight 设置权重
# server 中会将 http://webcanteen 的请求转发到 upstream 池中
upstream webcanteen {
    server 127.0.0.1:66 weight=10;
    server 127.0.0.1:77 weight=1;
    server 127.0.0.1:88 weight=1;
}
server {
    location / {
        proxy_pass http://webcanteen
    }
}

Состояние внутреннего сервера

Бэкенд-сервер поддерживает следующие конфигурации состояния:

  • down: текущий сервер не участвует в балансировке нагрузки
  • резервное копирование: резервный сервер, когда другие узлы недоступны
  • max_fails: количество раз, когда запрос может завершиться ошибкой, и если он достигнет этого, он будет спать
  • fail_timeout: время паузы сервера после сбоев max_fails, по умолчанию 10 с.
  • max_conns: ограничить максимальное количество соединений приема на сервер
upstream webcanteen {
 server 127.0.0.1:66 down;
 server 127.0.0.1:77 backup;
 server 127.0.0.1:88  max_fails=3 fail_timeout=10s;
 server 127.0.0.1:99 max_conns=1000;
}

Распределение

  • Опрос (по умолчанию), каждый запрос назначается различным внутренним серверам по очереди в хронологическом порядке.Если внутренний сервер выходит из строя, список опроса Nginx автоматически удаляет его.
  • Вес (взвешенный опрос), расширенная версия опроса, вес пропорционален вероятности доступа и в основном используется в сценариях, где производительность внутреннего сервера неравномерна.
  • ip_hash, каждый запрос распределяется в соответствии с результатом хеширования IP-адреса доступа, так что каждый доступ может иметь фиксированный доступ к внутреннему серверу.
  • url_hash распределяет запросы в соответствии с результатом хеширования URL-адреса доступа, так что каждый URL-адрес направляется на один и тот же внутренний сервер, который в основном используется, когда внутренний сервер является кешем.
  • Пользовательский хэш, основанный на любом ключевом слове в качестве ключа хэша для достижения балансировки нагрузки алгоритма хеширования.
  • честно, в зависимости от времени отклика внутреннего сервера для распределения запросов, время отклика короткое, приоритет распределяется.

❤️Любовное тройное комбо

1. Когда вы увидите это, пожалуйста, поставьте лайк и поддержите это, ваше"отличный"Это то, что побуждает меня творить.

2. Обратите внимание на фронтальную столовую официального аккаунта,"Ваша передняя столовая, не забывайте есть вовремя"!

3. Эта статья была добавлена ​​в интерфейсную столовую.Github github.com/Geekhyt, попросите звездочку, поблагодарите звезду.

Категории