Введение

Компьютерное программное обеспечение, которое распространяет веб-страницы.

Веб-сервер – это компьютерное программное обеспечение и базовое аппаратное обеспечение, которое принимает запросы через HTTP (сетевой протокол, разработанный для распространения веб-контента) или его защищенную версию HTTPS. Пользовательский агент, как правило веб-браузер или веб-сканер, инициирует связь, отправляя запрос на веб-страницу или другой ресурс посредством HTTP, а сервер отвечает содержимым этого ресурса или сообщением об ошибке. Веб-сервер также может принимать и сохранять ресурсы, отправленные пользовательским агентом, если он настроен на это. Аппаратное обеспечение, используемое для работы веб-сервера, может различаться в зависимости от объема обрабатываемых запросов. В нижней части диапазона находятся встроенные системы, такие как маршрутизатор, использующий небольшой веб-сервер в качестве интерфейса конфигурации. Высокопосещаемый веб-сайт может обрабатывать запросы с помощью сотен серверов, работающих на стойках высокоскоростных компьютеров. Ресурс, отправляемый веб-сервером, может быть существующим файлом (статический контент), доступным веб-серверу, или он может быть сгенерирован в момент запроса (динамический контент) другой программой, взаимодействующей с серверным программным обеспечением. Первый обычно может быть обработан быстрее и легче кэширован для повторных запросов, в то время как второй поддерживает более широкий спектр приложений. Технологии, такие как REST и SOAP, использующие HTTP в качестве основы для общего обмена данными между компьютерами, а также поддержка расширений WebDAV, расширили применение веб-серверов далеко за пределы их первоначальной задачи – предоставления веб-страниц, читаемых человеком.

История

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

Взрывной рост и конкуренция (19962014)

В конце 1996 года существовало уже более пятидесяти известных (различных) программных продуктов для веб-серверов, доступных всем, кто хотел владеть интернет-доменным именем и/или размещать веб-сайты. Многие из них просуществовали недолго и были заменены другими веб-серверами. Публикация RFC о версиях протокола HTTP/1.0 (1996) и HTTP/1.1 (1997, 1999) вынудила большинство веб-серверов соответствовать этим стандартам (не всегда в полной мере). Использование постоянных TCP/IP соединений (HTTP/1.1) потребовало от веб-серверов как увеличения максимального количества разрешенных одновременных соединений, так и повышения их масштабируемости. В период с 1996 по 1999 год Netscape Enterprise Server и IIS от Microsoft стали одними из ведущих коммерческих решений, а среди свободно распространяемых программ с открытым исходным кодом Apache HTTP Server занял лидирующие позиции как предпочтительный сервер (благодаря своей надежности и широкому набору функций). В те годы существовал также другой коммерческий, высокоинновационный и, следовательно, примечательный веб-сервер под названием Zeus (в настоящее время прекращенный), который был известен как один из самых быстрых и масштабируемых веб-серверов на рынке, по крайней мере, до начала 2000-х годов, несмотря на относительно небольшую долю использования. Apache оставался наиболее используемым веб-сервером с середины 1996 года до конца 2015 года, когда, после нескольких лет снижения популярности, его сначала обогнал IIS, а затем Nginx. Впоследствии доля использования IIS значительно сократилась по сравнению с Apache (см. также долю рынка). Начиная с 2005–2006 годов, Apache начал улучшать свою скорость и масштабируемость, внедряя новые функции производительности (например, event MPM и новый кэш контента). Поскольку эти новые улучшения производительности изначально помечались как экспериментальные, пользователи долгое время не включали их, и Apache еще больше пострадал от конкуренции со стороны коммерческих серверов и, прежде всего, других серверов с открытым исходным кодом, которые к тому времени уже достигли гораздо более высоких показателей (особенно при обслуживании статического контента) с момента своего создания и к моменту упадка Apache могли предложить достаточно обширный список хорошо протестированных расширенных функций. Фактически, спустя несколько лет после 2000 года появились не только другие коммерческие и высококонкурентные веб-серверы, например LiteSpeed, но и множество других программ с открытым исходным кодом, часто отличного качества и с очень высокой производительностью, среди которых следует отметить Hiawatha, Cherokee HTTP server, Lighttpd, Nginx и другие производные/связанные продукты, также доступные с коммерческой поддержкой. Около 2007–2008 годов большинство популярных веб-браузеров увеличили предыдущий лимит по умолчанию в 2 постоянных соединения на домен хоста (лимит, рекомендованный RFC 2616) до 4, 6 или 8 постоянных соединений на домен хоста, чтобы ускорить загрузку тяжелых веб-страниц с большим количеством изображений и смягчить проблему нехватки постоянных соединений, выделенных для динамических объектов, используемых для двунаправленных уведомлений о событиях на веб-страницах. В течение года эти изменения в среднем почти утроили максимальное количество постоянных соединений, которые веб-серверам приходилось обрабатывать. Эта тенденция (к увеличению количества постоянных соединений) безусловно дала мощный импульс внедрению обратных прокси-серверов перед более медленными веб-серверами и предоставила еще один шанс новым веб-серверам, которые могли продемонстрировать свою скорость и способность обрабатывать очень большое количество одновременных соединений, не требуя при этом слишком большого количества аппаратных ресурсов (дорогих компьютеров с большим количеством процессоров, оперативной памяти и быстрых дисков).

Новые вызовы (2015 г. и последующие годы)

В 2015 году RFC опубликовали новую версию протокола [HTTP/2], и поскольку реализация новых спецификаций была совсем нетривиальной, среди разработчиков менее популярных веб-серверов (например, с долей использования ниже 1–2%) возникла дилемма: добавлять поддержку новой версии протокола или нет. Поддержка HTTP/2 часто требовала радикальных изменений внутренней реализации из-за множества факторов (практически всегда требовались зашифрованные соединения, возможность различать соединения HTTP/1.x и HTTP/2 на одном и том же TCP-порту, двоичное представление HTTP-сообщений, приоритезация сообщений, сжатие HTTP-заголовков, использование потоков, также известных как подсоединения TCP/IP, и связанное с ними управление потоком и т. д.), поэтому некоторые разработчики этих веб-серверов решили не поддерживать новую версию HTTP/2 (по крайней мере, в ближайшем будущем) по этим основным причинам.

В 2020–2021 годах динамика внедрения HTTP/2 (ведущими веб-серверами и популярными веб-браузерами) частично повторилась после публикации предварительных версий будущих RFC о протоколе HTTP/3.

Списки в каталоге

Программа веб-сервера может поддерживать динамическое генерирование (на лету) списка содержимого каталога, включающего файлы и подкаталоги. Если программа веб-сервера настроена соответствующим образом, запрошенный URL-путь соответствует существующему каталогу, доступ к нему разрешен, и в этом каталоге не найден статический индексный файл, то динамически (на лету) генерируется веб-страница (обычно в формате HTML), содержащая список файлов и/или подкаталогов указанного каталога. В случае невозможности генерации возвращается ошибка. Некоторые программы веб-серверов позволяют настраивать отображение содержимого каталогов, предоставляя возможность использования шаблона веб-страницы (HTML-документа, содержащего заполнители, например, $(FILE NAME), $(FILE SIZE) и т.п., которые заменяются значениями полей каждой записи файла, найденной в каталоге веб-сервером), например, index.tpl, или использование HTML и встроенного исходного кода, который интерпретируется и выполняется на лету, например, index.asp, а также поддержку динамических программ-индексов, таких как CGI, SCGI, FCGI, например, index.cgi, index.php, index.fcgi. Использование динамически генерируемых списков каталогов обычно избегают или ограничивают несколькими выбранными каталогами веб-сайта, поскольку их генерация требует значительно больше ресурсов операционной системы, чем отправка статической индексной страницы. Основное назначение списков каталогов – предоставление возможности загрузки файлов (особенно когда их имена, размеры, даты изменения или атрибуты могут изменяться случайным образом или часто) без необходимости предоставления дополнительной информации запрашивающему пользователю.

Отправить ответную сообщение

Программы веб-сервера способны отправлять сообщения-ответы в ответ на запросы клиентов. Ошибки сервера HTTP возникают из-за внутренних ошибок сервера. Когда клиентский браузер получает сообщение об ошибке, и если эта ошибка связана с основным запросом пользователя (например, с URL веб-ресурса, такого как веб-страница), то обычно это сообщение об ошибке отображается в окне или сообщении браузера.

Кэш файлов

Исторически сложилось так, что статическое содержимое, содержащееся в файлах, к которым требовался частый, произвольный и быстрый доступ, с середины 1960-х / 1970-х годов в основном хранилось на электромеханических дисках. К сожалению, операции чтения и записи на такие устройства всегда считались очень медленными по сравнению со скоростью оперативной памяти, поэтому, начиная с ранних операционных систем, сначала были разработаны кэши дисков, а затем и подсистемы кэширования файлов ОС для ускорения операций ввода-вывода часто используемых данных и файлов. Даже при использовании кэша файлов ОС относительная и периодическая медлительность операций ввода-вывода, связанных с каталогами и файлами, хранящимися на дисках, вскоре стала узким местом в повышении производительности, ожидаемой от высокопроизводительных веб-серверов, особенно с середины 1990-х годов, когда веб-трафик в Интернете начал расти экспоненциально вместе с постоянным увеличением скорости интернет- и сетевых каналов. Проблема дальнейшего эффективного ускорения обслуживания статических файлов, тем самым увеличения максимального количества запросов/ответов в секунду (RPS), начала изучаться с середины 1990-х годов с целью разработки полезных моделей кэширования, которые можно было бы реализовать в программах веб-серверов. В настоящее время многие популярные и высокопроизводительные программы веб-серверов включают в себя собственный файловый кэш, работающий в пользовательском пространстве, оптимизированный для использования веб-сервером и использующий их собственную реализацию и параметры. Широкое распространение RAID и/или быстрых твердотельных накопителей (оборудование для хранения данных с очень высокой скоростью ввода-вывода) несколько снизило, но, конечно, не устранило преимущество наличия файлового кэша, встроенного в веб-сервер.

Динамический кэш

Динамический контент, генерируемый внутренним модулем или внешней программой, может не меняться очень часто (при заданном уникальном URL с ключами / параметрами), поэтому в течение определенного времени (например, от 1 секунды до нескольких часов и более) полученный результат может быть сохранен в кэше в оперативной памяти или даже на быстром диске. Типичное применение динамического кэша – это веб-сайты с динамическими страницами, содержащими новости, погоду, изображения, карты и т.п., которые обновляются нечасто (например, каждые n минут) и к которым одновременно обращается большое количество пользователей. В таких случаях полезно возвращать кэшированный контент (без обращения к внутреннему модулю или внешней программе), поскольку у пользователей часто отсутствует актуальная копия запрашиваемого контента в кэше браузера. Как правило, такие кэши реализуются на внешних серверах (например, с использованием обратного прокси) или путем хранения динамических данных на отдельных компьютерах, управляемых специализированными приложениями (например, memcached), чтобы избежать конкуренции за аппаратные ресурсы (CPU, RAM, диски) с веб-серверами.

Веб-серверы в режиме ядра и пользовательского режима

Программное обеспечение веб-сервера может быть либо встроено в ОС и выполняться в пространстве ядра, либо выполняться в пространстве пользователя (как и другие обычные приложения). Веб-серверы, работающие в режиме ядра (обычно называемые веб-серверами пространства ядра), могут иметь прямой доступ к ресурсам ядра и, следовательно, теоретически могут быть быстрее, чем те, которые работают в пользовательском режиме; однако запуск веб-сервера в режиме ядра имеет и недостатки, например: сложности в разработке (отладке) программного обеспечения, а критические ошибки во время выполнения могут привести к серьезным проблемам в ядре ОС. Веб-серверы, работающие в пользовательском режиме, должны запрашивать у системы разрешение на использование дополнительной памяти или ресурсов процессора. Эти запросы к ядру не только занимают время, но и могут быть не удовлетворены, поскольку система резервирует ресурсы для собственного использования и несёт ответственность за совместное использование аппаратных ресурсов со всеми другими запущенными приложениями. Выполнение в пользовательском режиме также может означать использование большего количества копирований буферов/данных (между пользовательским пространством и пространством ядра), что может привести к снижению производительности веб-сервера в пользовательском режиме. В настоящее время почти всё программное обеспечение веб-серверов выполняется в пользовательском режиме (поскольку многие из вышеупомянутых небольших недостатков были устранены благодаря более быстрому оборудованию, новым версиям ОС, значительно более быстрым системным вызовам ОС и новому оптимизированному программному обеспечению веб-серверов). Также см. сравнение программного обеспечения веб-серверов, чтобы узнать, какие из них работают в режиме ядра или в режиме пользователя (также называемом пространством ядра или пространством пользователя).

Выступления

Для улучшения пользовательского опыта (на стороне клиента / в браузере) веб-сервер должен быстро отвечать (как можно скорее) на запросы клиентов; если скорость ответа на контент не ограничена (через конфигурацию) для определенных типов файлов (например, больших или очень больших файлов), то и возвращаемый контент данных должен передаваться максимально быстро (с высокой скоростью передачи). Иными словами, веб-сервер должен всегда быть отзывчивым, даже при высокой нагрузке веб-трафика, чтобы общее время ожидания ответа пользователем (сумма времени работы браузера + времени сети + времени отклика веб-сервера) оставалось минимальным.

Пределы нагрузки

Веб-сервер (установка программы) обычно имеет предопределенные лимиты нагрузки для каждой комбинации рабочих условий, также из-за ограничений ресурсов операционной системы и из-за того, что он может обрабатывать лишь ограниченное количество одновременных клиентских подключений (обычно от 2 до нескольких десятков тысяч для каждого активного процесса веб-сервера, см. также проблемы C10k и C10M). Когда веб-сервер приближается к своим лимитам нагрузки или превышает их, он перегружается и может стать недоступным.

Причины перегрузки

В любой момент веб-серверы могут быть перегружены из-за одной или нескольких из следующих причин (например). Избыток легитимного веб-трафика. Тысячи или даже миллионы клиентов, одновременно подключающихся к веб-сайту за короткий промежуток времени, например, эффект Slashdot. Распределенные атаки типа «отказ в обслуживании». Атака типа «отказ в обслуживании» (DoS-атака) или распределенная атака типа «отказ в обслуживании» (DDoS-атака) — это попытка сделать компьютер или сетевой ресурс недоступным для его законных пользователей. Компьютерные черви, которые иногда вызывают аномальный трафик из-за миллионов зараженных компьютеров (не координируемых между собой). XSS-черви могут вызывать высокий трафик из-за миллионов зараженных браузеров или веб-серверов. Интернет-боты. Трафик, который не фильтруется или не ограничивается на крупных веб-сайтах с ограниченными сетевыми ресурсами (например, пропускной способностью) и/или аппаратными ресурсами (процессорами, оперативной памятью, дисками). Замедление работы интернета (сети) (например, из-за потери пакетов), в результате чего запросы клиентов обрабатываются медленнее, а количество соединений увеличивается настолько, что достигаются предельные значения сервера. Веб-серверы, обслуживающие динамический контент, ожидающие медленных ответов от серверной части (например, баз данных), возможно, из-за слишком большого количества запросов, смешанных с большим количеством вставок или обновлений данных в БД; в этих случаях веб-серверам приходится ждать ответа от серверной части, прежде чем отвечать HTTP-клиентам, но во время этого ожидания поступает слишком много новых клиентских соединений/запросов, что приводит к перегрузке. Частичная недоступность веб-серверов (компьютеров). Это может произойти из-за планового или срочного обслуживания, обновлений, а также из-за аппаратных или программных сбоев, например, сбоев в серверной части (например, базы данных); в этих случаях оставшиеся веб-серверы могут получить чрезмерную нагрузку и перегрузиться.

Симптомы перегрузки

Симптомы перегруженного веб-сервера обычно следующие (например). Запросы обрабатываются с (возможно, значительными) задержками (от 1 секунды до нескольких сотен секунд). Веб-сервер возвращает код ошибки HTTP, такой как 500, 502, 503, 504, 408, или даже периодически возникающий 404. Веб-сервер отклоняет или разрывает (прерывает) TCP-соединения до того, как вернуть какой-либо контент. В очень редких случаях веб-сервер возвращает только часть запрошенного содержимого. Такое поведение можно рассматривать как ошибку, даже если оно обычно является следствием перегрузки.

Доля рынка

Ниже приведены последние статистические данные о доле рынка всех сайтов ведущих веб-серверов в Интернете по данным Netcraft. + Веб-сервер: Доля рынка всех сайтов Дата nginx (Nginx, Inc.) Apache (ASF) OpenResty (OpenResty Software Foundation) Cloudflare Server (Cloudflare, Inc.) IIS (Microsoft) GWS (Google) Другие октябрь 2021 34.95% 24.63% 6.45% 4.87% 4.00% (*) 4.00% (*) Менее 22% февраль 2021 34.54% 26.32% 6.36% 5.0% 6.5% 3.90% Менее 18% февраль 2020 36.48% 24.5% 4.00% 3.0% 14.21% 3.18% Менее 15% февраль 2019 25.34% 26.16% N/A N/A 28.42% 1.66% Менее 19% февраль 2018 24.32% 27.45% N/A N/A 34.50% 1.20% Менее 13% февраль 2017 19.42% 20.89% N/A N/A 43.16% 1.03% Менее 15% февраль 2016 16.61% 32.80% N/A N/A 29.83% 2.21% Менее 19%

Примечание: (*) – процент округлен до целого числа, так как десятичные значения не публикуются источником (в графике отображается только округленное значение).