Веб-сервер: что это и как он отдаёт страницы

Веб-сервер — это программа, которая ожидает входящие соединения на определённом порту, обычно 80 для HTTP и 443 для HTTPS, принимает запросы и возвращает ответы. Иногда термином называют и физический компьютер, на котором она работает, но по смыслу речь о программе.

Классические примеры: nginx, Apache HTTP Server, Caddy и встроенные серверы в средах разработки.

Часть веб-серверов встроена в языковые среды: небольшие приложения на Python или Node.js способны отвечать на запросы сами, но для публичной работы их обычно ставят за nginx.

Для пользователя сервер невидим: он замечает лишь адрес и содержимое страницы, а вся работа по разбору запроса и поиску файла происходит за доли секунды.

Когда вы вводите адрес, браузер получает IP-адрес домена через DNS, устанавливает соединение, при HTTPS согласует шифрование и отправляет запрос вида «метод, путь, заголовки». Сервер сопоставляет путь с файлом или обработчиком, формирует ответ с кодом состояния, заголовками и телом и отправляет обратно.

Для нескольких сайтов на одном адресе сервер выбирает нужный по заголовку Host. Протокол запросов описан на странице про HTTP.

Статический контент, то есть готовые файлы HTML, стили, изображения, отдаётся напрямую с диска, и здесь веб-сервер очень быстр. Динамические страницы формирует приложение: код на PHP, Python, Node.js или другом языке обращается к базе данных и собирает ответ. Веб-сервер в этом случае выступает посредником: передаёт запрос приложению через FastCGI, WSGI или обычный HTTP и возвращает результат.

Поэтому в реальных системах часто стоит связка: веб-сервер снаружи, приложение внутри, база данных за ним.

Типы содержимого сообщаются заголовком Content-Type: по нему браузер понимает, показывать ответ как страницу, изображение или скачать как файл.

Коды 2xx означают успех, 3xx — перенаправление, 4xx — ошибку клиента, например 404 для отсутствующей страницы и 403 для недоступного ресурса, 5xx — ошибку сервера. Код 500 указывает на сбой приложения, 502 и 504 — на проблемы во взаимодействии с внутренним сервером.

Каждый запрос попадает в журнал доступа: адрес клиента, время, путь, код и размер. Журнал ошибок содержит диагностику. В них ищут причину проблем и следы подозрительной активности, например перебор адресов.

Иногда сервер настроен так, что возвращает код 200 на любой адрес и показывает главную страницу. Для поисковых систем это плохо, а для проверки ошибок неудобно.

Заблуждение: сервер знает, что открывал именно этот пользователь. Он видит лишь адрес, заголовки и куки, а не личность. Ещё одно: хороший веб-сервер сам делает сайт быстрым, хотя основной вклад обычно вносят приложение и база данных.

Проверить самому можно, открыв в браузере инструменты разработчика на вкладке «Сеть»: там видны запросы, коды, заголовки и время. Просмотреть заголовки из командной строки позволяет curl с ключом -I, если он установлен.

Отдельный полезный приём — сверить, что при обращении по IP-адресу или неверному имени сервер возвращает нейтральный ответ, а не содержимое одного из сайтов.

Веб-сервер является публичной точкой входа, поэтому его обновляют и настраивают аккуратно. Отключайте вывод списков файлов в каталогах, ограничивайте доступ к служебным файлам, скрывайте версии программ и не размещайте в открытых каталогах резервные копии и конфигурации.

Для повышения скорости применяют кэширование заголовками Cache-Control, сжатие ответов, современные версии протокола HTTP и раздачу статики через CDN. Активные соединения поддерживаются механизмом keep-alive, чтобы не устанавливать соединение заново для каждого файла.

Ограничения на число запросов и размер тела помогают выдерживать всплески трафика и снижают риск перегрузки. Для защиты передачи данных включают HTTPS с актуальными версиями TLS.