Что такое веб-сервер и как он обрабатывает HTTP-запрос

Веб-сервер — это программа, которая слушает сетевой порт (обычно 80 для HTTP и 443 для HTTPS), принимает HTTP-запросы от клиентов и возвращает HTTP-ответы: HTML-страницы, картинки, файлы или данные от приложения. Часто веб-сервером называют и сам компьютер, на котором эта программа работает, но по сути это именно софт.

Ниже разберем главное: как запрос проходит путь от браузера до ответа, чем режим отдачи статики отличается от проксирования к приложению, чем веб-сервер отличается от сервера приложений, и сравним два самых распространенных решения — nginx и Apache. Примеры проверены на сентябрь 2026.

Как веб-сервер обрабатывает HTTP-запрос

Веб-сервер работает по клиент-серверной модели. Клиент (чаще всего браузер) отправляет запрос, сервер его обрабатывает и отдает ответ. Путь одного запроса выглядит так:

1. Пользователь вводит адрес в браузере и подтверждает переход.
2. Браузер через DNS получает IP-адрес нужного хоста и устанавливает TCP-соединение (для HTTPS поверх него поднимается TLS).
3. Браузер формирует HTTP-запрос: метод (GET, POST и др.), путь, заголовки, иногда тело.
4. Веб-сервер принимает запрос, разбирает строку запроса и заголовки, определяет по пути и настройкам, какой ресурс нужен.
5. Дальше два варианта: либо сервер сам читает готовый файл с диска, либо передает запрос приложению и ждет от него ответ.
6. Сервер собирает HTTP-ответ: строка статуса (например, 200 OK), заголовки (Content-Type, Content-Length и т. п.) и тело.
7. Браузер получает ответ, проверяет статус и тип содержимого, отрисовывает страницу и догружает связанные ресурсы (CSS, скрипты, изображения).

Один такой цикл занимает доли секунды и повторяется для каждого запроса. Современный веб-сервер обслуживает много соединений одновременно и поддерживает кеширование, сжатие (gzip, brotli) и постоянные соединения (keep-alive), чтобы ускорить отдачу.

Отдача статики или проксирование: два режима работы

У веб-сервера есть два принципиально разных способа получить тело ответа. Их важно не путать.

Отдача статики — сервер сам читает файл с диска и отправляет его как есть: HTML, CSS, JavaScript, картинки, PDF. Содержимое не меняется от запроса к запросу. Это самый быстрый режим: работа сводится к чтению файла и передаче его в сеть.

Проксирование к приложению — сервер не генерирует ответ сам, а перенаправляет запрос другой программе (серверу приложений) и возвращает клиенту то, что та вернула. Так отдают динамические страницы: содержимое зависит от пользователя, параметров, данных из базы. В этом режиме веб-сервер выступает обратным прокси (reverse proxy).

На практике оба режима сочетаются в одной конфигурации: статику веб-сервер отдает напрямую (это быстро и снимает нагрузку с приложения), а запросы к API или динамическим страницам проксирует дальше.

Веб-сервер и сервер приложений: в чем разница

Эти два понятия часто смешивают, но роли у них разные. Разведем цепочку явно:

• Веб-сервер говорит на языке HTTP: принимает запрос, отдает файлы, проксирует, занимается TLS, сжатием, логами, ограничением скорости. Примеры: nginx, Apache HTTP Server.
• Сервер приложений исполняет код на конкретном языке и порождает динамический ответ: обращается к базе данных, применяет бизнес-логику, формирует HTML или JSON. Примеры: PHP-FPM, Gunicorn или uvicorn для Python, сервлет-контейнеры вроде Tomcat для Java, встроенный сервер Node.js.

Типичная связка: браузер обращается к веб-серверу, тот отдает статику сам, а динамические запросы передает серверу приложений (например, по протоколу FastCGI на PHP-FPM или по HTTP на Gunicorn). Разделение удобно: веб-сервер закрывает сеть и раздачу файлов, приложение занимается логикой. Граница нестрогая — некоторые продукты умеют и то, и другое, а простые сайты обходятся вообще без отдельного сервера приложений.

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

Ниже минимальная конфигурация nginx: статика отдается напрямую, а все запросы к /api/ уходят на приложение, слушающее локально на порту 8000.

server {
    listen 80;
    server_name example.com;

    # Статика: nginx сам читает файлы с диска
    location / {
        root /var/www/html;
        index index.html;
    }

    # Проксирование: /api/ уходит серверу приложений на 127.0.0.1:8000
    location /api/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

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

nginx -t

При корректном конфиге вывод такой:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Теперь простой запрос к статике покажет заголовки ответа:

curl -i http://example.com/

Ответ начинается со строки статуса и заголовков:

HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html
Content-Length: 1024
Connection: keep-alive

Частая ошибка — обратиться к /api/, когда сервер приложений не запущен. nginx примет запрос, но не сможет соединиться с бэкендом:

curl -i http://example.com/api/users

HTTP/1.1 502 Bad Gateway
Server: nginx
Content-Type: text/html

Статус 502 Bad Gateway означает, что проксирование дошло до nginx, но приложение на порту 8000 не ответило. Исправление — запустить сервер приложений (проверить, что процесс слушает нужный порт) и убедиться, что proxy_pass указывает на его реальный адрес.

nginx и Apache: сравнение

nginx и Apache HTTP Server закрывают одни и те же задачи, но по-разному устроены внутри. На сентябрь 2026 актуальны стабильная ветка nginx 1.30.x и Apache HTTP Server 2.4.68.

Выбор зависит от задачи, а не от того, что «лучше вообще»:

• Нужен быстрый фронт, обратный прокси или балансировщик под высокой нагрузкой — обычно берут nginx.
• Нужны гибкие правила на уровне каталога через .htaccess или тесная интеграция с модулями (частый случай на классическом виртуальном хостинге) — удобнее Apache.
• Оба варианта нередко сочетают: nginx стоит спереди и отдает статику, а Apache обрабатывает динамику за ним.

Как обрабатываются соединения

Способ обработки соединений — главное архитектурное различие между веб-серверами, и именно оно влияет на поведение под нагрузкой.

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

Apache исторически предлагает несколько моделей (MPM). prefork создает отдельный процесс на соединение, worker использует процессы с потоками, а event (по умолчанию в большинстве сборок 2.4) приближает Apache к событийной модели и лучше работает с keep-alive. Выбор MPM влияет на память и совместимость с модулями. Это упрощенная картина: точное поведение зависит от настроек (число процессов, потоков, лимиты соединений) и версии.

Выводы

• Веб-сервер принимает HTTP-запросы и возвращает ответы; определять его лучше через протокол HTTP, а не через «железо».
• У сервера два режима получения тела ответа: отдать готовый файл (статика) или проксировать запрос серверу приложений (динамика); на практике их сочетают.
• Веб-сервер и сервер приложений — разные роли: первый говорит по HTTP и раздает файлы, второй исполняет код и порождает динамику.
• nginx и Apache решают схожие задачи, но различаются моделью соединений и настройкой; выбор идет от задачи, а не от абстрактного «лучше».
• Модель обработки соединений (событийная у nginx, MPM у Apache) — ключевое различие, заметное под высокой нагрузкой.

Где применяется / связь с практикой

Веб-сервер — базовый навык для любого, кто разворачивает сайты и приложения: администраторов, бэкенд-разработчиков, DevOps-инженеров. Настройка nginx или Apache, проксирование к приложению, TLS, логи и права доступа — все это ежедневная практика. Большинство серверов работает на Linux, поэтому уверенная работа в командной строке и понимание файловой системы и процессов идут в комплекте.

FAQ

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

Можно ли обойтись без сервера приложений?
Да, если сайт состоит только из статических файлов (HTML, CSS, картинки): их веб-сервер отдает сам. Сервер приложений нужен, когда содержимое генерируется динамически — под пользователя, из базы данных.

Что означает ошибка 502 Bad Gateway?
Веб-сервер работает как прокси и попытался передать запрос бэкенду, но не получил корректного ответа: приложение не запущено, упало или указан неверный адрес. Проверяют, слушает ли процесс нужный порт, и корректность настроек проксирования.