NGINX проти Apache: Як вибрати найкращий веб-сервер

Уявіть собі: ви шукаєте нові кросівки, знаходите гарну пропозицію та вирішуєте перевірити її на сайті.

Ви чекаєте 10 секунд… 20 секунд… і сайт все одно не завантажується. Ви втомились чекати, тому переходите на інший сайт. Ось що, ймовірно, сталося: сайт із кросівками, ймовірно, витратив багато часу та грошей на стильні зображення та елегантні дизайни, але це все марно, якщо завантаження триває вічність.

Інтернет повний повільних вебсайтів.

Середній мобільний лендінг завантажується за 22 секунди, і це жахливо для бізнесу.

Дослідження компанії Portent виявило, що сайт, який завантажується за менш ніж одну секунду, має у три рази вищий коефіцієнт конверсії, ніж сайт, який завантажується протягом п’яти секунд.

Тепер, що це має спільного з нашим порівнянням NGINX проти Apache?

Одним із головних факторів, що впливає на швидкість сайту, є ваш веб-сервер — програмне забезпечення, яке доставляє сторінки відвідувачам.

Apache та NGINX – це два найвідоміші веб-сервери.

Станом на липень 2024 року, w3techs повідомляє, що NGINX використовується понад 34% вебсайтів, тоді як Apache підтримує 29,4%.

Чи це робить NGINX абсолютним переможцем? Ще ні.

Обидва веб-сервери працюють по-різному для різних випадків використання. У цьому посібнику ми розглянемо відмінності між Apache та NGINX і пояснимо, на що звертати увагу при виборі сервера.

Почнімо.

Що таке веб-сервери?

Веб-сервери — це програмні застосунки, які працюють на фізичному сервері та обробляють вхідні запити користувачів.

Коли ви вводите URL-адресу на кшталт “google.com”, ваш браузер надсилає запит до веб-сервера, який зберігає файли, необхідні для роботи веб-сайту.

Сервер потім надсилає відповідний вміст, чи то HTML, CSS, JavaScript, зображення чи інший тип.

Веб-сервери виконують багато важливих завдань у фоновому режимі:

• Керування з’єднаннями та запитами HTTP
• Маршрутизація запитів до необхідної бекенд-програми, якщо це необхідно (наприклад, PHP, Python або Ruby on Rails)
• Читання та запис файлів з диску для надання статичних ресурсів
• Забезпечення виконання політик безпеки
• Стиснення контенту для швидшої передачі
• Реєстрація запитів для аналізу

Тепер, коли ми розглянули, як працюють веб-сервери, давайте подивимося, як NGINX і Apache підходять до цих завдань.

Що таке Apache?

Apache HTTP Server, який часто називають Apache, – це популярне програмне забезпечення відкритого вихідного коду для веб-сервера, створене Робертом МакКулом та випущене у 1995 році. Він базується на сервері NCSA HTTPd.

Фонд Apache Software Foundation, неприбуткова організація, що підтримує проекти з відкритим вихідним кодом, розробила та продовжує підтримувати його.

Багато років Apache був найбільш використовуваним веб-сервером у світі, який підтримував багато вебсайтів. Фактично, він зіграв значущу роль у розвитку Всесвітньої мережі в її ранні дні.

Деякі основні особливості та переваги Apache:

• Модульна архітектура: Її функціональність може бути розширена за допомогою модулів для різних функцій та мов.
• Працює на різних операційних системах: Apache створений бути кросплатформенним, щоб хостити ваш веб-сервер на будь-якій операційній системі, включно з Linux, Windows та macOS.
• Розгалужена документація та велика спільнота: Допомагає користувачам та розробникам вирішувати проблеми та розробляти кращі рішення, працюючи разом.
• Гнучка конфігурація: Файли .htaccess можуть полегшити внесення конфігураційних змін, специфічних для каталогів, для користувачів.
• Функції безпеки: Apache має досить добру безпеку завдяки своїй відкритості та регулярним оновленням для усунення вразливостей та помилок.

Тим не менш, Apache має деякі обмеження:

• Більше використання пам’яті: Використовує більше пам’яті, ніж NGINX, особливо при обробці декількох одночасних з’єднань.
• Повільніше при великих навантаженнях: Може бути повільнішим за NGINX при обслуговуванні статичних файлів, особливо при великих навантаженнях.
• Складнощі для розробників у розробці та підтримці: З роками зростаюча складність кодової бази зробила його складнішим для розробки та підтримки.

Що таке NGINX?

NGINX (вимовляється як “Engine X”) — це безкоштовне програмне забезпечення веб-сервера з відкритим вихідним кодом, що демонструє високу продуктивність, вперше випущене у 2004 році. Його створив Ігор Сисоєв, російський програмний інженер, для вирішення проблеми одночасного доступу багатьох користувачів до вебсайту, що було викликом для інших веб-серверів, таких як Apache.

Робота Сисоєва над NGINX почалася у 2002 році. Він мав на меті вирішити “проблему C10k” — обробку 10 000 одночасних з’єднань.

Його бачення полягало в швидкому, стабільному та масштабованому сервері. Цей акцент на продуктивності робить NGINX особливо ефективним у наданні статичного вмісту, такого як HTML-сторінки, зображення та CSS-файли.

Крім своєї швидкості, NGINX відмінно справляється з роллю зворотного проксі. Він отримує запити користувачів і розумно направляє їх до інших серверів, таких як Apache або веб-додатки, оптимізуючи використання ресурсів.

Деякі з основних переваг NGINX:

• Одночасна обробка: NGINX обробляє багато користувачів одночасно без необхідності використовувати надмірну пам’ять чи потужність ЦП.
• Легко налаштувати та конфігурувати: NGINX має простий та інтуїтивно зрозумілий формат конфігураційного файлу, який допомагає користувачам легко налаштовувати веб-сервер згідно з їхніми потребами.
• Різноманітні функції для підвищення продуктивності: NGINX має багато вбудованих функцій для балансування навантаження, кешування та забезпечення безпеки веб-сайтів за допомогою шифрування SSL/TLS.
• Підтримує IMAP та POP3: NGINX також функціонує як поштовий проксі-сервер, підтримуючи протоколи, такі як IMAP та POP3.

Однак, є декілька недоліків використання NGINX:

• Налаштування за замовчуванням не є оптимальними: Алгоритми балансування навантаження за замовчуванням можуть не завжди працювати оптимально в кожній ситуації.
• Немає вбудованих компіляторів мов: Немає нативної підтримки для створення динамічних веб-сайтів за допомогою мов серверного програмування, таких як PHP або Python. Проте, можна обійти це за допомогою стороннього розширення.

Apache проти NGINX: Які різниці?

Apache колись був найпопулярнішим вибором веб-сервера. Однак NGINX швидко завоював частку ринку і зараз популярний серед багатьох веб-сайтів з високим трафіком.

Якщо ви плануєте працювати з виділеним хостингом, вибір правильного веб-сервера є важливим рішенням.

Отже, що відрізняє ці дві речі?

Давайте розглянемо детальніше.

Деталі	Apache HTTP Server	NGINX
Засновано	1995	2004
Умови ліцензування	Apache License 2.0	2-clause BSD license
Сумісність з операційними системами	Windows, Linux, macOS, системи на базі Unix	Windows, Linux, macOS, системи на базі Unix
Підтримка протоколу WebSocket	Так	Так (введено в версії 1.3.13)
Підтримка зворотного проксі	Так	Так
Конфігурація віртуальних хостів	Підтримується	Підтримується
Кешування	Доступне через модулі	Вбудовано в ядро
Споживання ресурсів (пам’ять)	Високе	Низьке
Формат налаштування та конфігурації	Текстовий	Текстовий (спрощений синтаксис)
Функції безпеки	Підтримка mod_security дозволяє гнучко налаштовувати правила та контроль доступу	Розширене фільтрування, обмеження швидкості, вбудована підтримка мінімізації DDoS-атак, та швидкодія SSL/TLS
Зашифроване зв’язування (SSL/TLS)	Підтримується	Підтримується
Обробка одночасних з’єднань	Добре	Дуже ефективно
Масштабування продуктивності	Добре	Видатно
Функціонал розподілу навантаження	Досяжний за допомогою модулів	Вбудована функція
Загальна продуктивність та швидкість	Задовільна	У два рази швидше, ніж Apache

Архітектура та конкурентність

Однією з найбільших відмінностей між NGINX та Apache є спосіб обробки вхідних запитів на низькому рівні.

Це має значний вплив на їх продуктивність та ефективність ресурсів.

Процесна архітектура Apache

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

Ці процеси або потоки керуються модулями багатопроцесорної обробки (MPMs):

• Prefork MPM: Оригінальна модель Apache. Кожен процес має один потік і обробляє одне з’єднання за раз. Це просто, але може бути ресурсомістким.
• Worker MPM: Використовує кілька потоків на процес, кожен обробляє одне з’єднання. Це краще, ніж prefork для пам’яті, але інтенсивний трафік та ресурсомісткі запити все ще можуть створювати затори на процесорі, що призводить до проблем з продуктивністю.
• Event MPM: Схожий на Worker MPM, але оптимізований для постійних з’єднань (пристроїв, які не можуть бути від’єднані від сервера). Однак, він все ще не повністю асинхронний.

Це всі хороші модулі, але у них є один значний недолік: Apache має створювати нові процеси або потоки для кожного вхідного з’єднання та знищувати їх після завершення. Він намагається управляти цим, заздалегідь створюючи деякі простоюючі процеси.

Однак, якщо декілька людей одночасно намагаються підключитися до сайту, Apache може перевищити свій поточний пул, і тоді йому доведеться швидко створювати більше процесів. Це займає час і споживає пам’ять.

Ця модель працює чудово для сайтів з низьким до середнього рівня трафіку. Тим не менш, Apache може почати перевантажувати сайти з великою кількістю одночасних підключень.

Усі ці окремі процеси не є дуже ефективними. Навіть з подієвим MPM, Apache не може повністю вирватися з моделі одного потоку на з’єднання.

Архітектура NGINX на основі подій

NGINX застосовує дуже відмінний підхід. Замість окремих процесів або потоків для кожного з’єднання, NGINX використовує асинхронну, орієнтовану на події архітектуру.

Ось як це працює: 

• NGINX має основний процес (зазвичай один на кожне ядро CPU), який управляє кількома робочими процесами. Кожен робітник може обробляти тисячі одночасних з’єднань. Робітникам не потрібно створювати нові потоки або направляти кожен запит до окремого процесу.
• Замість цього, робітники мають цикл подій, де вони ефективно спостерігають за новими подіями в існуючих з’єднаннях за допомогою механізмів операційної системи, таких як kqueue або epoll. Це дозволяє їм жонглювати кількома з’єднаннями в межах одного потоку. Коли відбувається подія, наприклад, надходить новий запит або сервер на бекенді відповідає, NGINX швидко спрямовує її до вільного слоту в робітнику.
• Це набагато ефективніше, ніж модель Apache. NGINX може обслуговувати величезну кількість запитів з мінімальною кількістю пам’яті. Він чудово масштабується, тому його використовують на багатьох найбільш завантажених сайтах у мережі.

Недолік полягає в тому, що NGINX не може вбудовувати інтерпретатори коду, як це робить Apache.

Отже, коли ви хочете запустити PHP або Python код, NGINX надсилає запити до окремого менеджера процесів FastCGI, такого як php-fpm. Цей процес запускає код і перекладає його на щось, що може зрозуміти браузер користувача.

З іншого боку, Apache може виконувати мови, такі як PHP, Perl та Python, у своїх процесах.

Оскільки NGINX не може, файл config може стати трохи складнішим.

Проте переваги продуктивності, зазвичай, переважають незручності.

Продуктивність

NGINX відомий високою продуктивністю при обслуговуванні статичних файлів, таких як HTML-сторінки, зображення, CSS та JavaScript.

Архітектура, заснована на подіях, допомагає, але NGINX також має деякі інші хитрощі.

По-перше, на відміну від Apache, NGINX не потребує проходження через кеш та звернення до диска для кожного запиту. Він може обслуговувати файли безпосередньо з диска. Також, NGINX усуває надлишковість, пов’язану з перевіркою дозволів та блокуванням файлів.

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

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

NGINX також має вбудований Кеш файлів. При першому запиті до файлу, NGINX читає його з диску та поміщає у свій кеш. Наступні запити до цього файлу можуть оброблятися надзвичайно швидко прямо з пам’яті без звернення до диску. Він також автоматично інвалідує кешовані дані, якщо файл на диску змінюється.

Ці оптимізації накопичуються. У бенчмарках, NGINX часто може обслуговувати статичні файли приблизно в три рази швидше, ніж Apache, особливо коли зростає кількість одночасних запитів.

Бонус: це також може допомогти вам покращити ваші основні веб-показники, даючи вам невеликий поштовх в Google.

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

Але NGINX – це те, що вам потрібно, якщо ви хочете отримати продуктивний веб-сервер відразу після встановлення.

Конфігурація та синтаксис

NGINX та Apache мають різні філософії конфігурації.

Apache відомий своїми широкими можливостями конфігурації. До apache2.conf, вам потрібно додати ваші правила та конфігурації до файлу .htaccess .

Файли конфігурації використовують синтаксис, схожий на XML, і пропонують неймовірну гнучкість. Apache має величезний список директив, які ви можете використовувати для тонкої настройки кожного аспекту поведінки сервера.

Ви можете встановити конфігураційні опції глобально або змінити їх для конкретних каталогів або віртуальних хостів.

Справжня сила Apache полягає в його розгалуженій екосистемі модулів. Великий асортимент офіційних та сторонніх модулів Apache дозволяє вам робити все, від переписування URL до фільтрування безпеки та передового кешування. Щоб використовувати модуль, вам потрібно завантажити його у вашу конфігурацію Apache.

З іншого боку, конфігурація Apache може швидко ускладнитися, особливо для складних налаштувань. Директиви можуть перекривати одна одну у складних ланцюжках наслідування. Опції конфігурації часто розподілені між кількома файлами у різних підкаталогах основної папки config. Це надзвичайно гнучко, але потребує часу для освоєння.

Конфігурація NGINX, з іншого боку, націлена на простоту та читабельність. Тут немає файлу .htaccess. Ви просто налаштовуєте сайти у вашому файлі NGINX.conf разом із папкою sites-enabled, і все готово.

Синтаксис запозичує стиль з поширених мов програмування. Він все ще потужний, але не такий обширний, як Apache.

Замість модулів, NGINX має менший набір основних директив та функцій, які вже вбудовані. Всі ваші опції для даної функції зазвичай знаходяться в одному блоку разом (в дужках { }).

Деякі передові функції, такі як балансування навантаження та кешування, налаштовані у головному файлі NGINX.conf, а не відокремлені у додаткові файли.

Результат полягає в тому, що конфігураційні файли NGINX, як правило, більш стислі та доступніші для читання та налаштування, ніж об’ємні файли Apache, але ви все ще можете багато з ними зробити.

Безпека

NGINX та Apache – це проекти з відкритим кодом із великими активними спільнотами розробників, які постійно працюють над виявленням та усуненням вразливостей. Обидва отримують регулярні оновлення безпеки і мають хорошу історію швидкого вирішення проблем.

Тим не менш, існують деякі відмінності у підходах до безпеки.

Ось кілька ключових моментів, які варто врахувати:

• Модульність: Модульна архітектура Apache означає, що вам потрібно активувати лише ті функції, які використовуєте, мінімізуючи потенційні точки атаки. У NGINX багато стандартних функцій вбудовані безпосередньо в ядро, що, на думку деяких, робить його менш гнучким з точки зору безпеки.
• Фільтрація запитів: NGINX має потужний вбудований механізм фільтрації запитів, який може допомогти блокувати поширені веб-атаки такі як SQL-ін’єкції та міжсайтовий скриптинг (XSS). Apache має схожі можливості за допомогою модулів на кшталт mod_security.
• Конфігурація SSL/TLS: Обидва сервери підтримують SSL/TLS для зашифрованих з’єднань, але часто кажуть, що NGINX легше налаштувати. Він має більш зрозумілу документацію та безпечніші налаштування за замовчуванням.
• Ізоляція процесів: Використання NGINX одного головного процесу з кількома робочими процесами може допомогти ізолювати проблемні зони. Prefork та worker MPMs в Apache можуть забезпечити подібну ізоляцію на рівні процесів, але за рахунок використання більшої кількості ресурсів.
• Пом’якшення DDoS-атак: Подійна архітектура NGINX та ефективне управління одночасними з’єднаннями роблять його популярним вибором для пом’якшення DDoS-атак невеликого та середнього розміру. Декілька додаткових модулів і налаштувань також можуть зробити Apache стійким до DDoS-атак.

Динамічний контент, модулі та екосистема

Apache давно є вибором для надання динамічного контенту, оскільки він легко інтегрується з мовами серверної сторони. За допомогою prefork та worker MPMs ви можете вбудувати підтримку мов, таких як PHP, Python та Perl, прямо в бінарний файл Apache.

Apache запустить інтерпретатор всередині кожного зі своїх процесів-робітників. Це просто та зручно — Apache може передавати запити для файлів .php до свого вбудованого PHP-інтерпретатора і отримувати назад оброблений результат.

NGINX не має вбудованої підтримки мов серверної сторони. Вам потрібен окремий сервіс, як-от php-fpm, який виконує інтерпретацію мови для запуску PHP, Python або Ruby on Rails з NGINX. NGINX отримує запити і передає їх на backend, який обробляє код і повертає відповідь.

Це трохи більше роботи для налаштування, ніж універсальний підхід Apache. З іншого боку, це відповідає філософії NGINX робити одну річ (обробляти запити) — і робити це добре.

Щодо інших особливостей, NGINX включає в себе строгий основний набір корисних, таких як балансування навантаження, проксіювання, кешування, обмеження швидкості, стиснення та завершення SSL. Однак він не може зрівнятися з неймовірною широтою екосистеми модулів Apache. З Apache у вас є модулі для схем аутентифікації, фільтрації вмісту, вбудованих мов сценаріїв та більше.

Не кожен з цих є унікальним. NGINX може виконувати багато тих самих завдань, просто іншими шляхами. Однак, бібліотека модулів Apache досить обширна.

Якщо вам потрібна якась дуже специфічна функціональність, Apache може мати перевагу в цьому.

Проте, набір функцій NGINX достатній для більшості поширених потреб веб-сервісу.

Реальне використання, продуктивність та спільнота

Популярність NGINX зросла за останнє десятиліття.

Станом на 2022 рік він використовується на понад 34% всіх веб-сайтів у світі, у порівнянні з приблизно 29% в Apache.

Одна річ, яку вам слід пам’ятати: ви не помітите різниці між цими веб-серверами, якщо у вас не великий сайт або дуже малий сервер.

Припустимо, вам подобаються розширені параметри конфігурації Apache та всеосяжний підхід до динамічного контенту. Документи Apache є одними з найкращих, і спільнота є величезною, якщо вам коли-небудь знадобиться допомога.

NGINX може бути кращим вибором, якщо ви прагнете максимальної одночасності або створюєте великий сайт. Його архітектура трохи більш орієнтована на майбутнє та побудована для масштабування. Спільнота NGINX також швидко зростає. Документація також надійна; ви можете знайти багато посібників та підтримку.

Apache проти NGINX: Який з них підходить саме вам?

Не існує універсальної відповіді на дебати NGINX проти Apache. Проте, ось декілька корисних правил, які допоможуть вам прийняти рішення.

NGINX кращий, якщо:

• У вас дуже високонавантажений сайт.
• Вам потрібно швидко обслуговувати велику кількість статичних ресурсів.
• Ви створюєте архітектуру мікросервісів.
• Вам подобається більш стрункий стиль конфігурації.
• Ви використовуєте контейнери або хмарний хостинг, де кожен грам пам’яті має значення.

Apache краще, якщо:

• Вам потрібна глибока сумісність з функціями, які підтримуються лише Apache, такими як .htaccess.
• Ви хочете модулі для дуже специфічного функціоналу.
• Вам потрібно запускати старі веб-додатки, створені для Apache і mod_php.
• Вам просто подобається система конфігурації Apache.
• Ваш сервер в основному є розробницькою платформою, і продуктивність не є критичною.

Немає правила, яке говорить, що ви маєте обрати лише одне.

Запуск NGINX перед Apache як зворотнього проксі є дуже поширеним. Це дозволяє поєднувати неперевершене обслуговування статичних файлів та одночасну обробку NGINX із багатим підтримкою динамічних мов на бекенді від Apache — найкраще з обох світів.

Підсумок

Apache та NGINX обидва чудові, тому вибір залежить від того, що найкраще відповідає вашим потребам.

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

Розумніше кешування, налаштування баз даних, оптимізація коду та надійне обладнання можуть прискорити ваш стек набагато більше, ніж години налаштувань NGINX або Apache.

Якщо вам потрібен сервер для експериментів, спробуйте керований VPS від DreamHost. З VPS ви можете вибирати, яке програмне забезпечення інсталювати, як сервер має реагувати на запити та багато іншого. Крім того, завдяки гнучкості VPS, ви можете розміщувати кілька вебсайтів на одному сервері та розподіляти ресурси між ними відповідно.

Крім того, всі тарифні плани DreamPress тепер постачаються з NGINX.

Єдиний спосіб знайти ідеальне налаштування — експериментувати. Запустіть VPS, встановіть NGINX та Apache і подивіться, що найкраще підійде для вас!