Що таке Apache HTTP Server: 📜 Надійний ветеран веб-серверів

Коли я починав свій шлях у веб-розробці, питання “який веб-сервер використовувати?” практично не стояло. Відповідь була одна — Apache. Цей проєкт з відкритим вихідним кодом, запущений ще у 1995 році, довгий час був беззаперечним лідером і, по суті, побудував значну частину того інтернету, який ми знаємо сьогодні. Хоча Nginx сьогодні перехопив пальму першості за швидкістю, Apache залишається надзвичайно популярним, надійним та гнучким рішенням.

У цій статті я хочу віддати належне цьому “патріарху” веб-серверів. Ми розберемося, як він працює, в чому його унікальні переваги (так, вони є!), де він все ще незамінний, і як його базово налаштувати.

 

Apache: як він працює? Архітектура MPM

На відміну від Nginx з його асинхронною моделлю, Apache традиційно використовує модель “процес або потік на з’єднання”. Те, як саме він керує цими процесами та потоками, визначається MPM (Multi-Processing Module) — модулем мультиобробки. Це серце Apache, яке можна змінювати залежно від потреб.

Найпоширеніші MPM:

• Prefork (Класика): Створює окремий процес для кожного з’єднання. Дуже стабільний і безпечний (ізоляція процесів), але споживає багато пам’яті. Це був стандарт для роботи зі старим mod_php, оскільки багато PHP-розширень не були потокобезпечними.
• Worker (Гібрид): Створює кілька процесів, а кожен процес запускає багато потоків для обробки з’єднань. Значно ефективніший за Prefork у плані пам’яті, але вимагає потокобезпечних модулів.
• Event (Сучасний стандарт Apache): Подальший розвиток Worker. Він також використовує потоки, але має спеціальний потік для обробки keep-alive з’єднань. Це дозволяє робочим потокам звільнятися швидше для обробки нових запитів, що робить його ефективнішим при великій кількості одночасних з’єднань. Це відповідь Apache на виклик Nginx.

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

 

Сильні сторони Apache: чому він досі актуальний?

Незважаючи на перевагу Nginx у швидкості обробки статики та великої кількості з’єднань, Apache має кілька козирів у рукаві:

 

1. ✨ Файл .htaccess — Гнучкість на рівні папки

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

 

Як працює .htaccess?

Коли надходить запит, Apache перевіряє наявність файлу .htaccess у поточній папці та у всіх батьківських папках аж до кореня сайту. Якщо файл знайдено, Apache читає його та застосовує вказані директиви “на льоту”.

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

 

2. 🧩 Величезна кількість модулів

За десятиліття існування для Apache було створено неймовірну кількість модулів для вирішення найрізноманітніших завдань:

• mod_rewrite: Потужний інструмент для переписування URL (основа “людинозрозумілих” URL у багатьох CMS).
• mod_php: Класичний спосіб інтеграції PHP (хоча сьогодні PHP-FPM є кращим вибором).
• mod_security: Популярний веб-фаєрвол (WAF).
• mod_ssl: Для роботи з HTTPS.
• …та сотні інших.

Хоча Nginx теж має модулі, їхня екосистема значно менша, і часто додавання стороннього модуля вимагає перекомпіляції Nginx.

 

3. 📜 Гнучкість конфігурації та сумісність

Конфігураційні файли Apache (зазвичай httpd.conf або apache2.conf та файли віртуальних хостів) мають дуже гнучкий синтаксис. Завдяки своїй довгій історії, Apache чудово сумісний практично з будь-яким ПЗ та операційною системою.

 

4. 📚 Документація та спільнота

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

 

Слабкі сторони Apache (у порівнянні з Nginx)

1. Продуктивність під високим навантаженням: Особливо при використанні старих MPM (Prefork), Apache споживає значно більше пам’яті та гірше справляється з великою кількістю одночасних з’єднань, ніж Nginx.
2. Повільніша віддача статики: Nginx спроєктований для максимально швидкої віддачі статичних файлів, Apache тут програє.
3. Вплив .htaccess на швидкість: Зручність .htaccess обертається додатковими перевірками файлової системи при кожному запиті.

 

Практика: базова конфігурація Apache для сайту на PHP (з mod_php)

Давайте я покажу приклад простого віртуального хоста для Apache, який використовує класичний mod_php. Цей підхід зараз не є найпродуктивнішим (Nginx + PHP-FPM краще), але він досі часто зустрічається на віртуальних хостингах.

Файл конфігурації (наприклад, /etc/apache2/sites-available/my-site.conf):

<VirtualHost *:80>
    # Ім'я сервера
    ServerAdmin webmaster@example.com
    ServerName example.com
    ServerAlias www.example.com
    # Коренева папка сайту
    DocumentRoot /var/www/my-site/public
    # Налаштування логів
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    # Налаштування для папки сайту
    <Directory /var/www/my-site/public>
        # Дозволяємо використання .htaccess
        AllowOverride All
        # Дозволяємо доступ
        Require all granted        
        # Налаштування для PHP (якщо використовується mod_php)
        # Наприклад, увімкнення відображення помилок для розробки
        php_flag display_errors on
        php_value error_reporting E_ALL
    </Directory>
</VirtualHost>
# Конфігурація для HTTPS (порт 443) буде схожою, 
# але з додаванням директив SSLEngine, SSLCertificateFile тощо.
# Про перехід на HTTPS я писав тут: 
# https://sebweo.com/yak-perejti-z-http-na-https-prosta-instruktsiya-vstanovlennya-ssl/

Після створення конфігурації її потрібно увімкнути (sudo a2ensite my-site.conf) та перезавантажити Apache (sudo systemctl reload apache2).

 

Висновок: надійний “робочий кінь”, який ще послужить