ФИЛОСОФИЯ ВЕБ-СЕРВЕРА
Неважная часть
Здравствуйте коллеги программисты и те кто ими притворяются! В IT, как и в любой другой сфере жизни, существует много недопонимания при коммуникации между людьми. Однажды общаясь с уважаемыми джунами я столкнулся с очередным семантическим барьером, который и сподвиг меня написать данную статью.
Проблема: один человек говорит “веб-сервер”, а в голове у него nginx, второй думает про Go net/http, а третий вообще представляет железо. Но чем же является веб-сервер на самом деле?
Веб-сервер
Веб-сервер – это агент, который делает ресурсы World Wide Web доступными по URI и обслуживает взаимодействие через HTTP/HTTPS.
Если упрощать: принимает HTTP-запросы и выдаёт HTTP-ответы, соблюдая семантику протокола. Именно это и превращает просто сервер в веб-сервер.
Почему так:
- Web мыслится как информационное пространство, где сущности именуются URI и на них можно ссылаться, кэшировать, включать по ссылке, аннотировать и т.д.;
- HTTP в спецификации определяется как протокол для гипертекстовых информационных систем и включает схемы URI http и https.
Почему термин постоянно путают
Потому что “web server” в быту означает сразу три разные вещи:
- Железо (компьютер, на котором всё крутится);
- Софт (программа, которая принимает запросы и отдаёт ответы);
Роль в цепочке (origin, reverse proxy, cache, gateway).
MDN (Mozilla Developer Network) прямо фиксирует это раздвоение “железо vs софт”.
А спецификация HTTP отдельно описывает, что между клиентом и источником могут стоять intermediaries (proxy/gateway/tunnel), и один и тот же узел может вести себя по-разному в зависимости от запроса.
Роль веб-сервера в архитектуре
1. Держатель публичного контракта
Веб-сервер – это граница, на которой внутреннее устройство системы превращается в публичный интерфейс:
- URI/путь/параметры - о чём запрос;
- метод (GET/POST/…) - что хотят сделать;
- заголовки/negotiation - в каком виде это нужно;
- статус/заголовки/тело - что получилось.
HTTP специально описывается как stateless application-level protocol, и он определяет семантику сообщений, а не то, как ты внутри хранишь состояние/данные.
2. Узел в цепочке
Веб устроен так, что ответы могут давать не только origin, но и посредники: прокси и кэши.
Отсюда важный вывод: веб-сервер – это роль в конкретном взаимодействии, а не титул “главного сервиса”.
Зона ответственности веб-сервера
Обязанности:
- Понимать HTTP-сообщения (синтаксис, парсинг, управление соединением – для HTTP/1.1 это отдельно нормировано);
- Маршрутизировать запрос к ресурсу, выбранному по URI/Host/target-форме и т.п. (это часть корректной обработки запросов в реальном вебе);
Сформировать корректный HTTP-ответ в соответствии с семантикой протокола.
Опции (необязательные функции веб-сервера):
- раздача статики (классика, но не суть);
- TLS termination (HTTPS);
- сжатие, логирование, rate limit;
- reverse proxy / балансировка / буферизация;
кэширование.
Почему это путают: потому что популярные “веб-серверы” в индустрии реально умеют всё сразу. Например, nginx сам себя описывает как HTTP web server, reverse proxy, content cache, load balancer и т.д.
Где проходит граница: TCP-сервер vs HTTP-сервер vs веб-сервер
- TCP-сервер: принимает байты по сокету;
HTTP-сервер: понимает HTTP-сообщения и умеет отвечать по правилам HTTP;
Веб-сервер: HTTP-сервер, который обслуживает ресурсы WWW, т.е. коммуницирует в терминах URI/ресурс/представление.
Источники
Для детального изучения вопроса могу порекомендовать кучу английского текста:
RFC 9110 (HTTP Semantics), RFC 9112 (HTTP/1.1) – базовое определение, что такое HTTP, его архитектура, терминология, роль посредников, связь с http/https URI-схемами;
RFC 3986 (URI) – про URI;
MDN – человеческая формулировка про путаницу железо vs софт;
nginx.org/en/ – пример того, почему термин плавает в индустрии: один продукт закрывает несколько ролей, и люди начинают называть веб-сервером вообще всё.
Спасибо за внимание!