Вебсервери
nginx: вебсервер, що масштабується завдяки циклам подій
nginx обробляє більше трафіку вебу, ніж будь-який інший сервер, зі структурної причини: він розв'язує C10K асинхронною моделлю, керованою подіями, замість потоку на кожне з'єднання. На практиці він виконує дві ролі одночасно, легкого сервера статичних файлів і типового для галузі reverse proxy, і більшість реальних розгортань є другим випадком. Операційна дисципліна навколо нього (перевірка конфігурації, нагляд за логами, автоматизація TLS) вирішує, чи ця потужність тиха, чи крихка.
Головне
- Архітектура event loop це весь аргумент: невелика кількість процесів worker обробляє тисячі з'єднань із дешевим перемиканням контексту, тому nginx добре проксіює багато повільних клієнтів (статичні активи, мобільні користувачі нижче за потоком) без витрат пам'яті на кожне з'єднання, як у схемах thread-per-request.
- Дві ролі в одному бінарнику: блоки server віддають статичний вміст і застосовують rewrites; блоки proxy_pass завершують TLS і передають далі до upstream-сервісів, із поведінкою, близькою до перевірок здоров'я (max_fails, timeouts, buffering), яка є поверхнею конфігурації, а не модулями, і це найбільша зміна звичок порівняно з мисленням Apache.
- Дисципліна конфігурації нудна й обов'язкова: nginx -t після кожної правки, один include-файл на сайт, щоб відкати були хірургічними, і reload (а не restart) як дія для змін на живому; публікація конфігурації, що не проходить перевірку синтаксису, це збій, який коштує півдня, але цілком відворотний.
- TLS це повноцінний рівень: сучасні вибори протоколу, налаштування session resumption і OCSP stapling, з acme.sh або certbot для автоматизації видачі; неправильно налаштований hook оновлення, що тихо падає 60 днів, це класичний збій nginx, тому сигналізуйте за віком сертифіката, а не за датою завершення.
- Чесні межі: немає динамічної системи модулів, як в Apache (статичні модулі часу компіляції, тож сторонні можливості вимагають перезбирання або пакетів дистрибутива), а поверхня reverse proxy навмисно тонка, бо відповідь nginx на складність часто полягає в тому, щоб поставити ще один інструмент спереду (обмеження швидкості в nginx плюс WAF у шарах класу modsecurity).
- Робота з продуктивністю починається з реальності, а не з культу: worker_processes = auto, worker_connections під розмір пам'яті й конверт навантаження, розуміння proxy_buffering (buffering увімкнено, це типово і правильно для більшості API), gzip/brotli для текстових типів, і логи, переглянуті на сплески 499/504 раніше, ніж спрацюють пороги дашбордів.
Польова нотатка
Конфігурація nginx, яка навчила клієнта найбільшому, була одним файлом: reverse proxy з HSTS, чесними заголовками caching і блоками server на кожен сервіс, усе під 200 рядків. Їхній попередній стек мав 4 000 рядків дубльованих include і reload, що ламав щось щокварталу. Догляд за конфігурацією це теж інженерія.
Часті запитання
nginx чи Apache: коли nginx явно правильний?
Високонавантажене reverse proxying, трафік з великою часткою статики й завершення TLS у масштабі, саме там event loop окупається. Для shared hosting на .htaccess з конфігурацією на каталог Apache лишається зручністю (наша стаття nginx проти apache чесно розбирає компроміс).
Яке правило reload проти restart?
Reload (плавний: старі worker завершують обслуговування наявних з'єднань, поки нова конфігурація бере керування) це щоденна дія; restart для зміни версії рушія і всього, що reload не охоплює; і жодне з них не замінює попередній запуск nginx -t.
Чому деякі сайти ставлять Apache за nginx?
Класичний гібридний стек: nginx завершує TLS, швидко віддає статику й проксіює динамічні запити до Apache, де .htaccess та інструменти класу mod_php очікують традиційної поведінки; ціна це ще одна рухома частина для нагляду й узгодженого налаштування.
Яких трьох перших помилок налаштування уникати?
Копіювання ручок worker і buffer з блогів без тестування під навантаженням, залишення proxy_buffering вимкненим після чийогось зауваження, що це повільно (buffering зазвичай швидший типовий варіант), і пропуск перевірки конфігурації перед reload; усі три відворотні тією дисципліною вище.
Допомога Kinetikatech: вебсервери
Вам не обов'язково ставати експертом із вебсервери: Налаштування, оптимізація й безпека вебсерверів у виробничих і тестових середовищах. Саме для цього й існує служба Оптимізація швидкості сайтів та Адміністрування серверів: налаштування, посилення захисту, моніторинг і жива людина на зв'язку цілодобово.