Уеб сървъри
nginx: уеб сървърът, който мащабира чрез цикъл от събития
nginx обработва повече от уеб трафика, отколкото всеки друг сървър, по структурна причина: решава C10K с асинхронен модел, задвижван от събития, вместо с нишка на връзка. На практика той изпълнява две роли едновременно, лек сървър за статични файлове и обратен прокси по подразбиране в индустрията, и повечето реални внедрявания са втората. Оперативната дисциплина около него (тестване на конфигурацията, наблюдение на логовете, автоматизация на TLS) решава дали тази мощ ще бъде тиха или крехка.
Ключови точки
- Архитектурата с цикъл от събития е целият аргумент: малък брой работни процеси обслужват хиляди връзки с евтини превключвания на контекста, затова nginx се справя отлично с проксиране на много бавни клиенти (статични ресурси, мобилни потребители надолу по веригата), без да изразходва памет за всяка връзка, както правят дизайните с нишка на заявка.
- Две роли в един бинарник: блоковете server отдават статично съдържание и прилагат пренаписвания; блоковете proxy_pass прекратяват TLS и препращат към upstream услуги, с поведение около здравето (max_fails, timeouts, buffering), което е конфигурационна повърхност, а не модули, най-голямата промяна в навиците спрямо мисленето за Apache.
- Конфигурационната дисциплина е скучна и задължителна: nginx -t след всяка промяна, отделен include файл за всеки сайт, за да е точен откатът, и reload (не restart) като действие за живи промени; публикуването на конфигурация, която не минава теста за синтаксис, е прекъсване, което струва следобед, но е напълно предотвратимо.
- TLS е първокласен слой: съвременни избори на протокол, настройки за подновяване на сесията и OCSP stapling, с acme.sh или certbot за автоматично издаване; погрешно конфигурираната hook за подновяване, която мълчи 60 дни, е класическото прекъсване на nginx, затова следете възрастта на сертификата, вместо да чакате изтичането.
- Честните ограничения: няма динамична екосистема от модули като Apache (статични модули по време на компилация, така че функции от трети страни изискват прекомпилация или пакети на дистрибуцията), а повърхността на обратния прокси е умишлено тънка, защото отговорът на nginx на сложността често е да се сложи друг инструмент отпред (ограничаване на скоростта в nginx плюс WAF в слоеве от класа на modsecurity).
- Оптимизацията започва от реалността, а не от култове: worker_processes = auto, worker_connections съобразени с паметта и обхвата на натоварването, разбиране на proxy_buffering (включен по подразбиране и правилен за повечето API), gzip/brotli за текстови типове и преглед на логовете за скокове на 499/504, преди да звъннат праговете на таблото.
Бележка от терен
Конфигурацията на nginx, която научи клиента най-много, беше един файл: обратен прокси с HSTS, честни заглавки за кеширане и отделни блокове server за всяка услуга, всичко под 200 реда. Предишният им стек имаше 4 000 реда дублирани include файлове и reload, който чупеше нещо всеки тримесечие. Поддръжката на конфигурацията е инженерство.
Често задавани въпроси
nginx срещу Apache: кога nginx е очевидно правилният избор?
При висококонкурентно обратно проксиране, трафик с много статично съдържание и прекратяване на TLS в мащаб цикълът от събития се изплаща точно там. За shared хостинг, задвижван от .htaccess с конфигурация по директории, Apache остава по-удобен (статията ни nginx срещу Apache разглежда компромиса честно).
Какво е правилото reload срещу restart?
Reload (плавно: старите работни процеси довършват текущите връзки, докато новата конфигурация поема) е ежедневното действие; restart е за смяна на версията на двигателя и за всичко, което reload не хваща; и нито едното не замества пускането на nginx -t първо.
Защо някои сайтове слагат Apache зад nginx?
Класическият хибриден стек: nginx прекратява TLS, отдава статиката бързо и проксира динамичните заявки към Apache, където .htaccess и инструментите от класа на mod_php очакват традиционно поведение; цената е още един движещ се компонент за наблюдение и последователна настройка.
Кои са първите три грешки при настройка, които да избягвате?
Копиране на параметри за worker и буфери от публикации в блогове без тест под натоварване, оставяне на proxy_buffering изключен, след като сте чули, че е бавен (буферирането обикновено е по-бързата настройка по подразбиране), и пропускане на теста на конфигурацията преди reload; и трите са предотвратими с дисциплината по-горе.
Как Kinetikatech помага с уеб сървъри
Не е нужно да ставате експерт по уеб сървъри: Конфигуриране, оптимизация и сигурност на уеб сървъри в производствени и развойни среди. Точно затова съществува Оптимизация на скоростта на сайта и Сървърна администрация: въвеждане в експлоатация, укрепване, мониторинг и дежурен човек денонощно.