Веб-сервер: что это, как работает и как выбрать

Что такое веб-сервер?

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

Представьте, что человек ввёл адрес интернет-магазина и нажал Enter. Браузер отправляет запрос, а сервер решает, что именно просят: готовую картинку или страницу, которую нужно собрать, например прогноз погоды для города. Дальше он проверяет, можно ли пускать этого посетителя, находит или собирает ответ и возвращает его с кодом результата. Весь обмен идёт по протоколу HTTP, ему посвящён наш отдельный материал.

Путаницу с терминами признаёт и справка MDN: понятие может относиться к аппаратной части, к программной и к обеим сразу. Для владельца сайта различие вполне практическое. Железо арендуют у хостинга или в облаке, а программу выбирают и настраивают под проект, и от неё зависят скорость ответа, защита и число посетителей, которое выдержит страница. Найти нужную машину браузеру помогает IP-адрес, в который домен превращается при каждом заходе.

Как сервер отвечает на запрос за доли секунды

Ответ собирается из четырёх действий, и разработчики разбирают их всегда в одном порядке. Яндекс Практикум описывает путь запроса в четыре шага:

1. Сервер принимает запрос и определяет, что просят: статический файл или динамический контент.
2. Он проверяет права клиента: например, к зарубежному ресурсу может быть закрыт доступ из России.
3. Если доступ разрешён, сервер обрабатывает запрос: достаёт файл или запускает код.
4. Сервер формирует HTTP-ответ: открывает найденную страницу или показывает сообщение об ошибке.

Итог этого пути сервер сообщает кодом ответа. По справке MDN ответы сгруппированы в пять классов: информационные 1xx, успешные 2xx, перенаправления 3xx, ошибки клиента 4xx и ошибки сервера 5xx. Если страницы нет, посетитель увидит ошибку, и вместо стандартного сообщения ему лучше показать свою страницу со ссылками на разделы. Когда адрес меняется, настраивают перенаправления, подробности есть в материале про редиректы.

Коды читают не только люди, но и поисковые роботы. Документация Google описывает такую реакцию: при ошибках 5xx и 429 робот временно замедляет сканирование, а код 429 воспринимает как сигнал перегрузки сервера. Если ошибка повторяется постоянно, такие адреса со временем удаляются из индекса. С ошибками 4xx поисковик обходится мягче: адрес, который раньше был доступен, а теперь отдаёт 4xx, со временем перестаёт учитываться. Поэтому ошибки сервера чинят в первую очередь, а удалённую страницу отдают с ошибкой «не найдено» или переводят редиректом на похожую. Сайт, который долго отвечает ошибкой сервера, рискует потерять и позиции, и трафик из поиска.

Скорость ответа отзывается и в выручке. Телеком-компания Vodafone провела A/B-тест: половине посетителей рекламной страницы показывали оптимизированную версию, где, среди прочего, отрисовку виджета перенесли с браузера на сервер. Показатель LCP улучшился на 31%, продажи выросли на 8%, а доля переходов к посещениям на 15%.

Статический и динамический сервер: в чём разница

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

Динамический сервер дополняют сервером приложений и базой данных. Он нужен там, где ответ зависит от посетителя: оплата заказа, регистрация, лента новостей. По описанию MDN, такой сервер состоит из статического и дополнительного программного обеспечения, чаще всего сервера приложений и базы данных, а страницу перед отправкой в браузер он изменяет. Устроены так и очень большие проекты: это Википедия и сами страницы MDN. Тысячи страниц собираются из нескольких HTML-шаблонов и гигантских баз данных, и наполнение подставляется при каждом запросе.

Для маркетолога из этого следует простая вещь: у магазина на CMS работы у сервера больше, чем у визитки, потому что страницу приходится собирать. Спасает кэш: готовая копия лежит наготове, и сервер не собирает страницу заново, что сокращает время ответа. Если же часть работы переносят в браузер или, наоборот, на сервер, на скорость и индексацию влияет серверный рендеринг, а об устройстве самих систем управления рассказывает материал про CMS.

Готовые страницы ускоряют и крупные проекты. Журнал Smashing Magazine, где накопились тысячи статей и больше 200 000 комментариев, перевели с динамической сборки на готовые страницы с раздачей через CDN. Как пишет Netlify, делавшая переезд, время до первой загрузки сократилось с 800 до 80 миллисекунд.

Nginx или Apache: как выбрать веб-сервер?

Готовых серверов много, но рынок поделён между несколькими. По данным W3Techs, Cloudflare Server используют 31,3% сайтов с известным веб-сервером, Nginx 30,8%, Apache 21,9% и LiteSpeed 14,3%. Ни один вариант не набирает и трети, поэтому выбирать есть из чего.

Nginx построен на событиях: каждый рабочий процесс обслуживает множество соединений. Страница проекта приводит цифру: на 10 000 неактивных keep-alive соединений уходит около 2,5 МБ памяти. Благодаря такой экономности Nginx часто ставят перед приложением как входную дверь, а детали его работы мы разбирали в отдельной статье.

У Nginx необычная для инфраструктурного софта биография. Сервер изначально разработал программист Игорь Сысоев, потом вокруг проекта выросла одноимённая компания, и, как пишет News.ru, американская F5 купила её за 670 млн долларов, оставив основателей на руководящих должностях.

Нагрузку Nginx держит и у Netflix. На серверах доставки видео Open Connect работают FreeBSD и веб-сервер Nginx, выбранный за проверенную масштабируемость и производительность. Для небольших провайдеров есть упрощённая модель с подключением 10 и 100 Гбит/с, то есть разные задачи закрывает один и тот же сервер.

У Apache сильная сторона в гибкости: через файлы .htaccess настройки меняют по папкам без доступа к главному конфигу, и поэтому его часто выбирают для виртуального хостинга. Плата за это названа в документации Apache: при включённых .htaccess сервер ищет такие файлы в каждой папке, и на каждое обращение к файлу приходятся четыре лишних обращения к файловой системе, даже если файлов нет. Сами авторы советуют держать настройки в главном конфиге, когда к нему есть доступ.

К этим двум стоит добавить узкие инструменты. Практикум называет среди прочих HAProxy, который распределяет трафик между серверами и обрабатывает до 100 тысяч соединений в секунду на одном ядре, Gunicorn, который следит за процессами приложения на Python и перезапускает упавшие, и IIS от Microsoft для динамических приложений на Windows. На Windows-инфраструктуре выбор часто делают за вас, а на Linux чаще выбирают между Nginx и Apache.

Решить, какой из них подойдёт вам, помогают три вопроса:

• На каком языке написано приложение и какой сервер для него принято ставить.
• Сколько одновременных посетителей вы ждёте в обычный день и в пик.
• Есть ли у вас доступ к главному конфигу или настройки придётся менять через .htaccess.
• Какой запас мощности нужен на случай всплеска трафика после рекламной кампании.

Почему Cloudflare ушла от Nginx и что из этого взять обычному сайту?

Nginx служил Cloudflare много лет, но на её масштабе упёрся в собственное устройство. В инженерном блоге компании сказано прямо: со временем его ограничения сделали разумной сборку нового прокси. Причин две. Запрос обслуживает один рабочий процесс, поэтому ядра нагружаются неравномерно. А пул соединений с серверами клиентов у каждого процесса свой, и чем больше процессов, тем реже удаётся использовать открытое соединение: новое стоит рукопожатий TCP и TLS.

Выход нашли в собственном прокси Pingora на Rust. По данным компании, он обрабатывает больше триллиона запросов в сутки и тратит на 70% меньше процессора и на 67% меньше памяти при той же нагрузке. У одного крупного клиента доля повторного использования соединений выросла с 87,1% до 99,92%, и новых соединений к его серверам стало в 160 раз меньше. Клиенты экономят на рукопожатиях 434 года времени в сутки, а за несколько сотен триллионов запросов сервис ни разу не упал из-за собственного кода.

Rust даёт нам уверенность, что сервис будет работать правильно

Юйчэнь Ву и Эндрю Хауэк, инженеры Cloudflare, в блоге компании

Обычному сайту писать свой прокси ни к чему, и Nginx остаётся разумным выбором: потолок, в который упёрлась Cloudflare, у вас не наступит. Но из этой истории стоит взять два соображения. Устройство сервера определяет, как он ведёт себя при росте нагрузки, поэтому запас закладывают заранее. А повторное использование соединений, которое в Cloudflare дало главный выигрыш, на любом сайте экономит время на каждом запросе.

Запуск и настройка своего веб-сервера по шагам

Порядок настройки почти не зависит от выбранной программы. Типичный путь выглядит так:

• Установите сервер через пакетный менеджер или с официального сайта.
• Откройте конфигурационный файл, например httpd.conf у Apache, и настройте права доступа.
• Настройте безопасность: файервол блокирует нежелательный трафик.
• Включите кэширование, чтобы сервер отдавал готовые копии страниц.
• Подключите базу данных, если сервер динамический.
• Протестируйте результат: проверьте адрес в браузере и поведение при обрыве сети.

У Nginx руководство для начинающих называет главный файл nginx.conf: он лежит в каталоге /etc/nginx или в соседних, смотря как сервер установлен. Число рабочих процессов в нём советуют приравнять к числу ядер процессора, а управлять запущенным сервером позволяет тот же исполняемый файл с параметром -s.

Железо руками собирать сегодня почти не приходится: в облаке арендуют виртуальную машину и ставят на неё любой сервер. Если нагрузку нужно делить между несколькими машинами, в Яндекс Облаке есть Application Load Balancer: он распределяет трафик между бэкендами приложений и терминирует TLS-сессии с сертификатами из Certificate Manager. Проверьте результат на практике: главная страница должна открываться, несуществующий адрес возвращать ошибку, а закрытые папки не должны отдаваться браузеру. Небольшому проекту обычно хватает хостинга, где сервер уже настроен хостером, а свой сервер нужен, когда понадобятся нестандартные настройки.

Сколько железа нужно, показывает реальный проект. Через балансировщики Stack Overflow проходит 209 420 973 запроса в сутки, а страницы всех сайтов Q&A обслуживает одно приложение на девяти основных веб-серверах. Вопрос отрисовывается в среднем за 22,71 мс. Нужного размера не угадаешь по числу посетителей: его определяет то, как устроено приложение.

Что ломается, когда нагрузка выше расчётной

Хороший пример - американский портал для записи на медицинскую страховку. Страницу регистрации, как сообщал CNN, проектировали на десятки тысяч человек одновременно, но на пробном запуске за несколько дней до открытия сайт упал уже от нескольких сотен пользователей. Запуск не отложили, и вскоре после полуночи портал рухнул, когда им попробовала воспользоваться пара тысяч человек. Позже, как уточняет CNN, заявки всё же заполнили почти 500 тысяч человек, но запуск уже запомнился провалом.

Разбор проекта у консультанта Генрико Дольфинга показывает перекос. Подсистему идентификации проверяли на две тысячи одновременных пользователей, хотя ждали десятки тысяч, а бэкенд работал на 48 виртуальных машинах на двенадцати физических серверах, и после неудачного запуска его пришлось заменить. Нагрузку просчитали на бумаге, но вживую не проверили.

Обратный пример дала игра Pokémon GO. В первые 15 минут после запуска в Австралии и Новой Зеландии, как рассказывает Google Cloud, трафик ушёл далеко за ожидания разработчиков. К запуску в Японии кластер обновили так, чтобы в него можно было добавить больше тысячи узлов, и Google выделила для игры десятки тысяч ядер.

Вывод для владельца обычного сайта прост: перед рекламной кампанией выясните, сколько одновременных посетителей выдерживает связка сервера, приложения и базы. Проверяйте нагрузку выше ожидаемой, потому что реклама даёт всплеск трафика, и первым ломается слабое звено цепочки. Часто это база или форма входа, и сам веб-сервер тут ни при чём.

Перед рекламой проведите нагрузочный тест: подайте на страницу в несколько раз больше запросов, чем ждёте, и посмотрите, где растёт время ответа. Это подскажет, что усиливать: сервер, приложение или базу. Подготовьте и страницу ошибки с контактом для связи: поисковые роботы реагируют на сбои сервера так же, как и посетители.

Частые вопросы