Nginx vs apache: сравнение двух популярных веб-серверов

Nginx

Nginx — это свободный, с открытым исходным кодом, высокопроизводительный HTTP-сервер и прокси-сервер, а также IMAP/POP3 прокси-сервер. В отличие от традиционных серверов Nginx не использует потоки для обработки запросов. Вместо этого он использует гораздо более масштабируемую, управляемую событиями (асинхронную) архитектуру. Эта архитектура под высокой нагрузкой использует небольшой, и главное, предсказуемый объем памяти.

Связка Phalcon + Nginx + PHP-FPM предоставляет мощный набор инструментов, который позволяет добиться максимальной производительности ваших PHP приложений.

Установка Nginx

Nginx — это бесплатный высокопроизводительный HTTP-сервер с открытым исходным кодом и обратный прокси-сервер, а также прокси-сервер IMAP / POP3. В отличие от традиционных серверов, Nginx не использует потоки для обработки запросов. Вместо этого он использует гораздо более масштабируемую управляемую событиями (асинхронную) архитектуру

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

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

Настройка под Phalcon

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

server {
    # Порт 80 будет требовать nginx для быть запущен с правами root
    # В зависимости от того, как вы устанавливаете Nginx для использования порта 80,
    # вам нужно будет запустить сервер с `sudo` портами около 1000,
    # не требуются привилегии root
    # listen      80;

    listen        8000;
    server_name   default;

    ##########################
    # В производстве требуется SSL
    # listen 443 ssl default_server;

    # ssl on;
    # ssl_session_timeout  5m;
    # ssl_protocols  SSLv2 SSLv3 TLSv1;
    # ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    # ssl_prefer_server_ciphers   on;

    # Эти местоположения зависят от того, где хранятся сертификаты
    # ssl_certificate        /var/nginx/certs/default.cert;
    # ssl_certificate_key    /var/nginx/certs/default.key;
    ##########################

    # Это папка, в которой находится index.php
    root /var/www/default/public;
    index index.php index.html index.htm;

    charset utf-8;
    client_max_body_size 100M;
    fastcgi_read_timeout 1800;

    # Представляет корень домена
    # http://localhost:8000/
    location / {
        # Matches URLS `$_GET`
        try_files $uri $uri/ /index.php?_url=$uri&$args;
    }

    # Когда HTTP-запрос не соответствует вышеуказанному
    # и файл заканчивается на .php
    location ~ \.php(/|$) {
        # try_files $uri =404;

        # Ubuntu и PHP7.0-fpm в режиме сокета
        # Этот путь зависит от версии установки PHP
        fastcgi_pass  unix:/var/run/php/php7.0-fpm.sock;

        # В качестве альтернативы вы используете PHP-FPM в режиме TCP (обязательно для Windows)
        # Вам нужно будет настроить FPM для прослушивания через стандартный порт
        # https://www.nginx.com/resources/wiki/start/topics/examples/phpfastcgionwindows/
        # fastcgi_pass  127.0.0.1:9000;

        fastcgi_index /index.php;

        include fastcgi_params;
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        if (!-f $document_root$fastcgi_script_name) {
            return 404;
        }

        fastcgi_param PATH_INFO       $fastcgi_path_info;
        # fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
        # и установить php.ini cgi.fix_pathinfo=0

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ /\.ht {
        deny all;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires       max;
        log_not_found off;
        access_log    off;
    }
}

Запуск Nginx

Обычно запуск производится командой . Но это зависит от метода установки веб-сервера и системного менеджера вашей операционной системы.

Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)

Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:

server {
listen 80 default_server;
return 302 https://welcome.domain.ru$request_uri;
}

или независимо от протокола:

server {
listen 80 default_server;
return 302 $scheme://welcome.domain.ru$request_uri;
}
server {
listen 443 default_server;
return 302 $scheme://welcome.domain.ru$request_uri;
ssl on;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
}

* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабатывать запросы по https, необходимо указывать в настройках пути к сертификатам.

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

Например в 1C-Битрикс существует множество модулей, таких как .

Для других CMS также можно установить модули. Вот некоторые ссылки на модули для распространенных CMS: , , .

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

Например:

header(‘HTTP/1.1 301 Moved Permanently’);

header(‘Location: http://www.example.com/’);

Если необходимо перенаправить одну единственную страницу на сайте, одним из решений может быть настройка при помощи HTML путем добавления специального тега в заголовок HTML-документа (Meta Refresh).

Например,

JavaScript – операция осуществляется непосредственно через браузер и является наиболее медленным способом. Используется, если необходим редирект с задержкой. Минусом является то, что такой редирект не будет работать, если JavaScript отключен в браузере. И не будет учтен Яндексом.

Например, window.location.href=»https://site.com»

Настройка 301 редиректа на nginx. Настройки необходимо вносить в файлах конфигураций виртуальных доменов.

Например, rewrite ^https://$host$request_uri? ;

где:

$host – имя хоста из запроса, если отсутствует – имя в поле «Host» заголовка, если тоже отсутствует – имя сервера;

$request_uri – первоначальный запрос с аргументами (все, что идет после доменного имени).

могут иметь следующие параметры:

permanent – перенаправление с кодом 301,

redirect – перенаправить с кодом 302,

last – закончить обработку с переходом в новый location,

break – закончить обработку и остаться в текущем location.

Для настройки переадресаций на сервере Apache более надежной является настройка серверных редиректов через внесение изменений в файл .htaccess. Разберем этот способ подробнее.

Как это будет работать?

Допустим, у нас есть несколько доменов example.com, sample.org, test.io. Первые два будут обрабатываться Apache, последний только Nginx. Все запросы будут поступать к Nginx, который работает на порту 80, если это запрос к одному из доменов Apache и он требует работы PHP, тогда он будет передан веб-серверу Apache, который работает на порту 8080.

Если же это запрос статического файла, то мы будем обрабатывать его тут же с помощью Nginx для увеличения производительности. Что касается поддержки SSL, то мы собираемся использовать модуль mod_pref чтобы заменить все необходимые заголовки для нормальной работы связки. Начнем с настройки Apache.

Передача реального ip (real ip) адреса клиента в nginx при proxy_pass

В предыдущем примере мы на самом деле передаем реальный ip адрес клиента с помощью директивы proxy_set_header, которая добавляет в заголовок X-Real-IP настоящий ip адрес клиента. Теперь нам нужно на принимающей стороне, то есть blog_srv сделать обратную замену — заменить информацию об адресе отправителя на ту, что указана в заголовке X-Real-IP. Добавдяем в секцию server следующие параметры:

set_real_ip_from 94.142.141.246;
real_ip_header X-Real-IP;

Полностью секция server на blog_srv в самом простом варианте получается следующей:

    server {
	listen       80 default_server;
	server_name  blog.zeroxzed.ru;
	root         /usr/share/nginx/html;
	set_real_ip_from 94.142.141.246;
	real_ip_header X-Real-IP;
        
    location / {
	index index.php index.html index.htm;
	try_files	$uri $uri/	=404;
	}

    location ~ \.php$ {
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_intercept_errors on; 
	include fastcgi_params;
	fastcgi_param       SCRIPT_FILENAME  $document_root$fastcgi_script_name;
	fastcgi_ignore_client_abort     off;
	}

    error_page 404 /404.html;
	location = /40x.html {
    }

    error_page 500 502 503 504 /50x.html;
	location = /50x.html {
    }
}

Сохраняем конфиг, перечитываем его и снова проверяем http://blog.zeroxzed.ru/myip.php. Вы должны увидеть свой реальный ip адрес. Его же вы увидите в логе web сервера на blog_srv.

Дальше рассмотрим более сложные конфигурации.

Цель и функции веб-сервера

Цель веб-сервера проста — обслуживать одновременно большое количество клиентов, максимально эффективно используя hardware.

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

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

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

А еще они могут поддерживать HTTPS, что не маловажно для защищенного соединения между сайтами и пользователями. Зачастую веб-сервер устанавливается вместе с мейл-сервером

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

С HTTP на HTTPS (другой порт)

Пример конфигурации для перенаправления запросов на другой порт — с 80 (http) на 443 (https):

server {
listen 80;
server_name domain.ru www.domain.ru;
return 301 https://$host$request_uri;
}

* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).

Также мы можем добавить условие, чтобы не перенаправлять на https для определенных ссылок, например:

server {
listen 80;
server_name domain.ru www.domain.ru;
if ($uri !~ /page.html){
return 301 https://$host$request_uri;
}
}

* в данном примере запрос на страницу /page.html будет открыт по http.

Step 5 — Proxy and Upstream Configuration

В NGINX конфигурация upstream определяет набор целевых серверов, которые будут обрабатывать трафик. В этом случае два кластера были назначены.

В Envoy это управляется кластерами.

Envoy Clusters

Эквивалент upstream определяется как кластеры. В этом случае были определены хосты, которые будут обслуживать трафик. Способ доступа к хостам, например время ожидания, определяется как конфигурация кластера. Это позволяет более точно контролировать зернистость таких аспектов, как время ожидания и балансировка нагрузки.

При использовании обнаружения службы STRICT_DNS Envoy будет непрерывно и асинхронно разрешать указанные цели DNS. Каждый возвращенный IP-адрес в результате DNS будет считаться явным хостом в восходящем кластере. Это означает, что если запрос возвращает два IP-адреса, Envoy предположит, что в кластере есть два хоста, и оба должны быть сбалансированы по нагрузке. Если хост удален из результата, Envoy предполагает, что он больше не существует, и будет отбирать трафик из любых существующих пулов соединений.

Для получения дополнительной информации см. .

Nginx, запрет доступа по IP

Если не добавить эту конфигурацию, то при попытке доступа через IP адрес будет открывать один из сайтов, при этом с предупреждением того, что в сертификате указано другое имя. Это событие явно лишнее. Для исправление нужно создать отдельную конфигурацию Nginx, в которой указать возврат ошибки 404, при попытке запроса страницы по IP адресу.

nano /etc/nginx/sites-available/ip.conf

server {
listen 80;
server_name 194.54.162.250 192.168.5.254;
return 404;
}

ln -s /etc/nginx/sites-available/ip.conf /etc/nginx/sites-enabled/

nginx -t

systemctl restart nginx

пример отработки конфигурации

Задача, которая решалась в прошлом году покупкой недешевого Mikrotik-а, выделением 4-ех ip(по 3-ем линкам WAN!), имеет простое решение — немножко времени+Nginx.

Шаг 3 — Конфигурация Server

В блоке конфигурирования HTTP, конфигурация NGINX указывает прослушивать порт 8080 и отвечать на входящие запросы для доменов one.example.com и www.one.example.com.

Внутри Envoy этим управляют Слушатели.

Слушатели Envoy

Самый важный аспект начала работы с Envoy Proxy — это определение слушателей. Вам нужно создать файл конфигурации, который описывает, как вы хотите запустить экземпляр Envoy.

Приведенный ниже фрагмент создаст нового слушателя и свяжет его с портом 8080. Конфигурация указывает Envoy Proxy, к каким портам он должен быть привязан для входящих запросов.

Envoy Proxy использует нотацию YAML для своей конфигурации. Для знакомства с этой нотацией, посмотрите здесь ссылку.

Нет необходимости определять server_name, так как фильтры Envoy Proxy справятся с этим.

Передача https через nginx с помощью proxy pass

Если у вас сайт работает по https, то достаточно настроить ssl только на nginx_srv, если вы не беспокоитесь за передачу информации от nginx_srv к blog_srv. Она может осуществляться по незащищенному протоколу. Рассмотрю пример с бесплатным сертификатом let’s encrypt. Это как раз один из кейсов, когда я использую proxy_pass. Очень удобно настроить на одном сервере автоматическое получение всех необходимых сертификатов. Сейчас будем считать, что у вас стоит certbot и все готово для нового сертификата, который потом будет автоматически обновляться.

Для этого нам надо на nginx_srv добавить еще один location — /.well-known/acme-challenge/. Полная секция server нашего тестового сайта на момент получения сертификата будет выглядеть вот так:

server {
    listen 80;
    server_name blog.zeroxzed.ru;
    access_log /var/log/nginx/blog.zeroxzed.ru-access.log;
    error_log /var/log/nginx/blog.zeroxzed.ru-error.log;

    location /.well-known/acme-challenge/ {
	root /web/sites/blog.zeroxzed.ru/www/;
    }

    location / {
	proxy_pass http://192.168.13.31;    
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Real-IP $remote_addr;
    }
}

Перечитывайте конфиг nginx и получайте сертификат. После этого конфиг меняется на следующий:

server {
    listen 80;
    server_name blog.zeroxzed.ru;
    access_log /var/log/nginx/blog.zeroxzed.ru-access.log;
    error_log /var/log/nginx/blog.zeroxzed.ru-error.log;
    return 301 https://$server_name$request_uri; # редирект обычных запросов на https
    }

server {
    listen 443 ssl http2;
    server_name blog.zeroxzed.ru;
    access_log /var/log/nginx/blog.zeroxzed.ru-ssl-access.log;
    error_log /var/log/nginx/blog.zeroxzed.ru-ssl-error.log;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/blog.zeroxzed.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.zeroxzed.ru/privkey.pem;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    location /.well-known/acme-challenge/ {
	root /web/sites/blog.zeroxzed.ru/www/;
    }
    location / {
	proxy_pass http://192.168.13.31; 
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Real-IP $remote_addr;
    }
}

Проверяем, что получилось.

Тест и перезагрузка Монит

После внесения каких-либо изменений необходимо протестировать конфигурацию Monit:

Вы должны увидеть следующее сообщение: Синтаксис файла управления ОК. Затем проверьте, запущен ли Monit, с помощью следующей команды:

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

Если Monit не запущен, запустите его, используя команду. Вся последовательность команд для тестирования и перезагрузки Monit показана на рисунке ниже.

Монит Тест и Перезагрузка

Теперь запустите веб-браузер и перейдите на один из следующих URL-адресов в зависимости от того, как настроен ваш Monit (обязательно используйте правильный номер порта):

HTTP: // локальный: 2812
http: // IPADDRESS: 2812 (IP-адрес локальной сети)
http://domain.com:2812 (если ваше доменное имя указывает на ваш сервер)

Вы должны увидеть состояния веб-сервера Apache и MySQL, как показано на рисунке ниже (NGINX не показан на этом примере изображения).

Мониторинг Apache и MySQL с помощью Monit

То есть для мониторинга состояния веб-сервера с помощью Monit. Как вы можете видеть, Monit обеспечивает автоматический мониторинг состояния веб-сервера, что может быть очень полезно для системных администраторов. На странице Monit Wiki есть несколько примеров. Больше примеров Monit для домашнего сервера, чтобы следовать, поэтому продолжайте проверять.

Источник записи: https://www.smarthomebeginner.com

1 Apache

Это почти синоним Всемирной паутины, и он до сих пор поддерживает большинство веб-сайтов в мире.

Причиной доминирования Apache является три момента: открытая лицензия, раннее вступление в игру (эта штука была выпущена еще в 1995 году!) и простое развертывание PHP.

Последнее стало возможным благодаря модулю mod_php, что означало, что установка Apache – это все, что вам нужно сделать для разработки на PHP.

Вот что еще делает Apache великолепным:

Доступен на всех платформах – Linux, Windows, MacOS и других платформах.
Это сервер по умолчанию для всех общих хостингов CPanel, что позволяет легко настраивать и изменять сайты.
Тонны функциональности, предлагаемые через большую коллекцию модулей. Независимо от того, насколько сложны ваши потребности, у Apache обязательно будет существующий модуль.
Конфигурация для каждого каталога через файлы .htaccess.
Поддержка HTTP/2, сжатие, статические файлы и балансировка нагрузки.
Режимы MPM и FastCGI для обеспечения высокого параллелизма.
Легкий скриптинг через Lua.

Apache подходит для вас?

Было время, когда Nginx (который мы рассмотрим далее) взлетел из-за своей высокой производительности, но Apache догнал его после выпуска 2.2.

Тем не менее, как и все ранние веб серверы, Nginx отнял много внимания, чтобы вы могли столкнуться с некоторой (недействительной) критикой его возможностей.

Блокировка прямого доступа к Apache (опционально)

Поскольку Apache прослушивает порт на публичном IP-адресе, он доступен кому угодно. Его можно заблокировать с помощью следующей команды IPtables в наборе правил брандмауэра.

Обязательно используйте IP-адрес своего сервера вместо выделенного красным адреса в примере. Когда ваш брандмауэр заблокирует порт , убедитесь в недоступности Apache через этот порт. Для этого откройте браузер и попробуйте получить доступ к любому из доменных имен Apache через порт . Например: http://example.com:8080

Браузер должен вывести сообщение об ошибке Unable to connect (Не удается подключиться) или Webpage is not available (Страница недоступна). Если используется опция IPtables , сторонний наблюдатель не увидит разницы между портом и портом, где отсутствует какое-либо обслуживание.

Примечание. По умолчанию правила IPtables теряют силу после перезагрузки системы. Существует несколько способов сохранения правил IPtables, но проще всего использовать параметр в хранилище Ubuntu.

Теперь настроим Nginx для обслуживания статических файлов для сайтов Apache.

Шаг 2 — Конфигурация NGINX

Первая часть nginx.conf определяет некоторые внутренние компоненты NGINX, которые должны быть настроены.

Worker Connections (Рабочие соединения)

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

Envoy Proxy по-разному управляет рабочими процессами и соединениями.

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

Прослушивание каждого слушателя (listener)
Принятие новых подключений
Создание набора фильтров для соединения
Обработка всех операций ввода-вывода за время существования соединения.

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

Для каждого рабочего потока в Envoy существует соединение в пуле. Таким образом, пулы соединений HTTP/2 устанавливают только одно соединение для каждого внешнего хоста за раз, при наличии четырех рабочих потоков будет четыре соединения HTTP/2 для каждого внешнего хоста в стабильном состоянии. Сохраняя все в одном рабочем потоке, почти весь код может быть написан без блокировок, как если бы он был однопоточным. Если рабочих потоков выделено больше чем необходимо, это может привести к не рациональному использованию памяти, созданию большого количества простаивающих соединений и уменьшения числа возвратов соединения обратно в пул.

Для получения дополнительной информации посетите Envoy Proxy blog.

Конфигурация HTTP

Следующий блок конфигурации NGINX определяет настройки HTTP, такие как:

Какие mime типы поддерживаются
Тайм-ауты по умолчанию
Конфигурация Gzip

Вы можете настроить эти аспекты с помощью фильтров в Envoy Proxy, что мы обсудим позже.

Шаг 3. Установка Nginx в Debian 11.

Теперь мы запускаем следующую команду, чтобы установить Nginx в вашу систему Debian:

sudo apt install nginx

После завершения установки запустите Nginx и добавьте его для автоматического запуска при запуске системы, используя:

sudo systemctl start nginx
sudo systemctl enable nginx

Проверьте установку:

nginx -v

Затем настройте Nginx в качестве обратного прокси-сервера для передачи входящих запросов на сервер Apache с помощью следующей команды:

nano /etc/nginx/sites-enabled/default

Вставьте следующую конфигурацию в свой файл, затем сохраните и выйдите:

server {

listen 80;
index index.php index.html index.htm;

server_name your-server-ip;
                
location / {
proxy_pass http://localhost:8000;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

Сохраните и закройте файл, затем проверьте Nginx на наличие синтаксических ошибок с помощью следующей команды:

nginx -t
sudo systemctl restart nginx

Настройка прокси Nginx

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

Сначала установите Nginx, если вы этого еще не сделали:

Дальше создадим виртуальный хост Nginx с несколькими доменами, с помощью которого и будет выполняться проксирование Nginx:

Для использования nginx в качестве прокси мы передаем в команде proxy_pass адрес и порт веб-сервера, а в заголовках передаем те значения, которые будут нужны Apache для правильного формирования документа. Сохраните файл и активируйте его:

Затем проверьте конфигурацию и перезапустите Nginx:

Теперь вы можете проверить работу вашего сайта в браузере, если вы откроете скрипт phpinfo, то увидите, что он был обработан с помощью Apache, но возвращен Nginx.

Как вы могли убедится, теперь применяется nginx в качестве прокси. Теперь можно закрыть прямой доступ к Apache из сети с помощью iptables:

Выступления

Чтобы улучшить взаимодействие с пользователем, веб-серверы должны быстро (как можно скорее) отвечать на запросы клиентов; если ответ содержимого не регулируется (конфигурацией) для некоторых типов файлов (например, больших файлов и т. д.), также необходимо как можно скорее отправить содержимое возвращаемых данных (высокая скорость передачи).

Для программного обеспечения веб-сервера основные ключевые статистические данные о производительности (измеренные при различной нагрузке клиентов и запросов на каждого клиента):

количество максимальных запросов в секунду (RPS, аналогичноQPS, в зависимости от версии и конфигурации HTTP, типа HTTP-запросов и т. д.);
время отклика с задержкой в сети (обычно в миллисекундах) для каждого нового клиентского запроса;
пропускная способность в байтах в секунду (в зависимости от размера файла, кэшированного или некэшированного содержимого, доступной пропускной способности сети, типа используемого протокола HTTP и т. д.).

Выше трех показателей производительности могут заметно отличаться в зависимости от количества активных TCP-соединений, поэтому четвертый статистический показатель — это уровень параллелизма, поддерживаемый веб-сервером при определенной конфигурации веб-сервера, типе ОС и доступных аппаратных ресурсах.

И последнее, но не менее важное: конкретная модель сервера, используемая для реализации программы веб-сервера, может влиять на производительность и уровень масштабируемости, который может быть достигнут при большой нагрузке или при использовании высокопроизводительного оборудования (много процессоров, дисков и т. Д.).. Производительность веб-сервера обычно оценивается с помощью одного или нескольких доступных
инструментов автоматизированного нагрузочного тестирования .

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

HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP (hypertext transfer protocol). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

Протокол представляет собой набор правил для связи между двумя компьютерами. HTTP является текстовым протоколом без сохранения состояния и обладает следующими свойствами:

Текстовый (Все команды представлены в текстовом виде и пригодны для восприятия человеком) .
Не сохраняет состояние(ни клиент, ни сервер, не помнят о предыдущих соединениях. Например, опираясь только на HTTP, сервер не сможет вспомнить введенный вами пароль или на каком шаге транзакции вы находитесь. Для таких задач, вам потребуется сервер приложений.)

HTTP задает строгие правила, как клиент и сервер должны общаться. Мы рассмотрим непосредственно HTTP далее в техническом разделе. Вот некоторые из них:

Только клиенты могут отправлять HTTP запросы, и только на сервера. Сервера отвечают только на HTTP запросы клиента.
Когда запрашивается физический файл, клиент должен сформировать URL для сервера.
Веб-сервер должен ответить на каждый HTTP запрос, по крайней мере с сообщением об ошибке.

На веб-сервере, HTTP сервер отвечает за обработку входящих запросов и ответ на них:

При получении запроса, HTTP сервер сначала проверяет существует ли ресурс по данному URL.
Если это так, веб-сервер отправляет содержимое файла обратно в браузер. Если нет, сервер приложений создает необходимый ресурс.
Если это не возможно, веб-сервер возвращает сообщение об ошибке в браузер, чаще всего “404 Not Found”. (Это ошибка настолько распространена, что многие веб-дизайнеры тратят большое количество времени на разработку 404 страниц об ошибках.)

3 Caddy

Caddy – одна из самых интересных новых платформ, вызывающих обсуждения в сообществе open source.

Считайте Caddy Nginx-подобным веб-сервером (схожий синтаксис и все такое), но он упрощает все до приятной крайности.

Например, интеграция Let Encrypt для SSL может быть выполнена всего в три строки конфигурации.

Вот почему Caddy привлекает массу внимания:

HTTPS включен по умолчанию

Да, вам не нужно ничего делать для установки или обновления SSL-сертификатов.
HTTP/2 получает основное внимание.
Заменяет ключи билета сеанса TLS по умолчанию. Это обеспечивает намного более безопасное управление соединением TLS, которое не уязвимо для подобных Heartbleed решений.
Нет зависимостей (это скомпилированная Golang двоичная кодовая база, которая не зависит ни от каких системных библиотек)
Обслуживает статические файлы в текущем каталоге по умолчанию!
Встраиваемый – может использоваться как библиотека в других программа

Если вы жаждете простоты и не хотите работать с непонятными конфигурациями, такие как Apache и Nginx,с Caddy вы почувствуете себя как на свежем воздухе.

Тем не менее, он работает лучше всего, когда вы принимаете настройки по умолчанию.

Например, если вы хотите использовать свой провайдер SSL или иметь отдельный каталог для статических файлов (что почти всегда так и есть ) и т. д., преимущества исчезают.

Настройка сайтов HTTPS с Let’s Encrypt (опционально)

На этом шаге мы настроим сертификаты TLS/SSL для обоих доменов, размещенных в Apache. Мы получим сертификаты посредством Let’s Encrypt. Nginx поддерживает конечные узлы SSL, и поэтому мы можем настроить SSL без изменения файлов конфигурации Apache. Модуль обеспечивает установку в Apache переменных среды, необходимых для бесшовной работы приложений за обратным прокси-сервером SSL.

Вначале мы разделим блоки обоих доменов так, что у каждого из них будет собственный сертификат SSL. Откройте в своем редакторе файл :

Измените файл, чтобы он выглядел следующим образом, сайты и должны находиться в собственных блоках:

/etc/nginx/sites-available/apache

Мы используем Certbot для генерирования сертификатов TLS/SSL. Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется.

Прежде всего, добавьте официальное хранилище Certbot:

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

Установите пакет Certbot’s Nginx с :

После установки используйте команду для генерирования сертификатов для и :

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

Если это первый запуск , вам будет предложено указать адрес эл. почты и принять условия обслуживания. После этого свяжется с сервером Let’s Encrypt и отправит запрос с целью подтвердить, что вы контролируете домен, для которого запрашиваете сертификат.

Далее Certbot запросит желаемый вариант настройки HTTPS:

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

Теперь выполните команду для второго домена:

Откройте один из доменов Apache в браузере с помощью префикса ; откройте , и вы увидите следующее:

Посмотрите раздел PHP Variables. Для переменной SERVER_PORT задано значение 443 и протокол HTTPS включен, как если бы осуществлялся прямой доступ к Apache через HTTPS. При такой настройке переменных не нужно специально настраивать приложения PHP для работы за обратным прокси-сервером.

Теперь отключим прямой доступ к Apache.

Заключение

На этом все по работе gitlab за nginx proxy. Настройка очень простая, продуктом пользоваться удобно. Настроить типовой ci/cd на базе докера очень просто. В будущем опишу такой пример. Так что рекомендую Gitlab для совместной работы команды. Минус у него только один — очень требователен к ресурсам.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .