Веб-сервер

Клиенты ПК, взаимодействующие через сеть с веб-сервером, обслуживающим только статический контент.

Внутренняя и передняя часть сервера Dell PowerEdge — компьютера, предназначенного для установки в стойку . Серверы, подобные этому, часто используются в качестве веб-серверов.

Для веб-сайта с высоким трафиком можно использовать несколько веб-серверов.

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

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

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

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

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

Такие технологии, как REST и SOAP , которые используют HTTP в качестве основы для общего взаимодействия между компьютерами, а также поддержку расширений WebDAV , расширили применение веб-серверов далеко за пределы их первоначальной цели обслуживания удобочитаемых страниц.

История

Первое веб-предложение (1989 г.) было оценено как «расплывчатое, но захватывающее…»

Первый в мире веб-сервер, рабочая станция NeXT Computer с Ethernet, 1990 год. На этикетке корпуса написано: «Эта машина является сервером. НЕ ВЫКЛЮЧАЙТЕ ЕГО ПИТАНИЕ!!»

См. также: История веб-браузера , История Всемирной паутины и История Интернета.

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

Первоначальный проект WWW (1989–1991)

В марте 1989 года сэр Тим Бернерс-Ли новый проект предложил своему работодателю в ЦЕРН , целью которого было облегчить обмен информацией между учёными с помощью системы гипертекста . Предложение под названием «Гипертекст и ЦЕРН» запросило комментарии и было прочитано несколькими людьми. В октябре 1990 года предложение было переформулировано и дополнено (соавтором выступил Роберт Кайо ) и, наконец, было одобрено.

В период с конца 1990 по начало 1991 года в результате проекта Бернерс-Ли и его разработчики написали и протестировали несколько программных библиотек, а также три программы, которые первоначально работали на ОС NeXTSTEP, установленной на рабочих станциях NeXT :

• графический веб-браузер под названием WorldWideWeb ;
• портативный веб-браузер в линейном режиме ;
• веб-сервер, позже известный как CERN httpd .

Эти ранние браузеры извлекали веб-страницы, написанные в простой ранней форме HTML , с веб-серверов, используя новый базовый протокол связи, получивший название HTTP 0.9 .

В августе 1991 года Тим Бернерс-Ли объявил о рождении технологии WWW и призвал ученых принять и развивать ее. Вскоре после этого эти программы вместе с их исходным кодом стали доступны людям, заинтересованным в их использовании. Хотя исходный код официально не лицензировался и не был размещен в свободном доступе, ЦЕРН неофициально разрешал пользователям и разработчикам экспериментировать и продолжать разработку на их основе. Бернерс-Ли начал продвигать внедрение и использование этих программ, а также их перенос на другие операционные системы .

Быстрое и бурное развитие (1991–1995 гг.)

Количество активных веб-сайтов (1991–1996 гг.)

В декабре 1991 года первый веб-сервер за пределами Европы . в SLAC (США) был установлен Это было очень важное событие, поскольку оно положило начало трансконтинентальной веб-связи между веб-браузерами и веб-серверами.

В 1991–1993 годах программа веб-сервера ЦЕРН продолжала активно разрабатываться группой www, тем временем, благодаря доступности ее исходного кода и общедоступным спецификациям протокола HTTP, начали разрабатываться многие другие реализации веб-серверов.

В апреле 1993 года ЦЕРН опубликовал публичное официальное заявление, в котором говорилось, что три компонента веб-программного обеспечения (базовый клиент линейного режима, веб-сервер и библиотека общего кода) вместе с их исходным кодом были переданы в общественное достояние . Это заявление освободило разработчиков веб-серверов от любых возможных юридических проблем, связанных с разработкой производных работ на основе этого исходного кода (угроза, которой на практике никогда не существовало).

В начале 1994 года наиболее заметным среди новых веб-серверов был NCSA httpd , который работал на различных ОС на основе Unix и мог обслуживать динамически генерируемый контент , реализуя POST Метод HTTP и CGI для связи с внешними программами. Эти возможности, наряду с мультимедийными функциями браузера Mosaic от NCSA (также способного управлять HTML- формами для отправки данных на веб-сервер), подчеркнули потенциал веб-технологий для публикации и распределенных вычислительных приложений.

Во второй половине 1994 года развитие NCSA httpd застопорилось до такой степени, что группа внешних разработчиков программного обеспечения, веб-мастеров и других профессиональных деятелей, заинтересованных в этом сервере, начала писать и собирать патчи благодаря тому, что исходный код NCSA httpd был доступен общественное достояние. В начале 1995 года все эти исправления были применены к последней версии исходного кода NCSA, и после нескольких тестов HTTP-сервера Apache . был запущен проект

В конце 1994 года был выпущен новый коммерческий веб-сервер Netsite со специфическими функциями. Это был первый из многих других подобных продуктов, которые были разработаны сначала Netscape , затем Sun Microsystems и, наконец, Oracle Corporation .

первую версию IIS выпустила Windows NT для ОС В середине 1995 года компания Microsoft . Это ознаменовало появление в области технологий Всемирной паутины очень важного коммерческого разработчика и поставщика, который играл и до сих пор играет ключевую роль на обеих сторонах (клиентской и серверной) сети.

Во второй половине 1995 года количество веб-серверов ЦЕРН и NCSA начало сокращаться (в процентном отношении к глобальному использованию) из-за широкого распространения новых веб-серверов, которые имели гораздо более быстрый цикл разработки, а также больше функций, больше внесенных исправлений и большую производительность, чем предыдущие.

Взрывной рост и конкуренция (1996–2014 гг.)

Количество активных веб-сайтов (1996–2002 годы)

Sun's Cobalt Qube 3 - компьютерное серверное устройство (2002 г., снято с производства)

В конце 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 начал улучшать свою скорость и уровень масштабируемости, вводя новые функции производительности (например, 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 (по адресу по крайней мере в ближайшем будущем) также по следующим основным причинам:

• протоколы HTTP/1.x в любом случае поддерживались бы браузерами в течение очень долгого времени (возможно, навсегда), чтобы в будущем не возникло несовместимости между клиентами и серверами;
• реализация HTTP/2 считалась задачей невероятной сложности , которая могла открыть дверь совершенно новому классу ошибок , которых не существовало до 2015 года, и поэтому потребовались бы значительные инвестиции в разработку и тестирование реализации нового протокола;
• добавление поддержки HTTP/2 всегда может быть сделано в будущем, если усилия будут оправданы.

Вместо этого разработчики большинства популярных веб-серверов поспешили предложить доступность нового протокола не только потому, что у них была рабочая сила и время для этого, но и потому, что обычно их предыдущая реализация протокола SPDY могла быть повторно использована в качестве отправной точки. и потому что большинство используемых веб-браузеров реализовали это очень быстро по той же причине. Еще одна причина, побудившая этих разработчиков действовать быстро, заключалась в том, что веб-мастера чувствовали давление постоянно растущего веб-трафика и им очень хотелось установить и опробовать – как можно скорее – что-то, что могло бы резко снизить количество TCP/IP-соединений и ускорить работу. доступ к размещенным веб-сайтам.

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

Технический обзор

ПК-клиенты, подключенные к веб-серверу через Интернет

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

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

Сложность и эффективность программы веб-сервера могут сильно различаться в зависимости от (например):

• общие функции ; реализованы
• общие выполняемые задачи ;
• производительность и уровень масштабируемости, поставленные в качестве цели;
• модель программного обеспечения и методы, принятые для достижения желаемого уровня производительности и масштабируемости;
• целевое оборудование и категория использования, например встроенная система, веб-сервер с низким и средним трафиком, веб-сервер в Интернете с высоким трафиком .

Общие особенности

Хотя программы веб-серверов различаются по способу реализации, большинство из них предлагают следующие общие функции.

Это основные функции , которые обычно есть у большинства веб-серверов.

• Обслуживание статического контента : возможность предоставлять статический контент (веб-файлы) клиентам по протоколу HTTP.
• HTTP : поддержка одной или нескольких версий протокола HTTP для отправки версий HTTP-ответов, совместимых с версиями клиентских HTTP-запросов, например HTTP/1.0, HTTP/1.1 (в конечном итоге также с зашифрованными соединениями HTTPS ), плюс, если доступно, HTTP. /2 , HTTP/3 .
• Ведение журнала : обычно веб-серверы также имеют возможность регистрировать некоторую информацию о запросах клиентов и ответах сервера для регистрации файлов в целях безопасности и статистики.

несколько других, более продвинутых и популярных функций ( только очень небольшой выбор Ниже приведены ).

• Обслуживание динамического контента : возможность предоставлять динамический контент (генерируемый на лету) клиентам по протоколу HTTP.
• Виртуальный хостинг : возможность обслуживать множество веб-сайтов ( доменных имен ), используя только один IP-адрес .
• Авторизация : иметь возможность разрешать, запрещать или разрешать доступ к частям путей веб-сайта (веб-ресурсам).
• Кэш контента : возможность кэшировать статический и/или динамический контент для ускорения ответов сервера;
• Поддержка больших файлов : возможность обслуживать файлы размером более 2 ГБ в 32-разрядной ОС .
• Регулирование пропускной способности : для ограничения скорости ответов на контент, чтобы не перегружать сеть и иметь возможность обслуживать больше клиентов;
• Движок перезаписи : для сопоставления частей чистых URL-адресов (найденных в клиентских запросах) с их настоящими именами.
• Пользовательские страницы ошибок : поддержка индивидуальных сообщений об ошибках HTTP.

Общие задачи

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

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

Прочитать сообщение с запросом

Программы веб-сервера могут:

• прочитать сообщение HTTP-запроса;
• интерпретировать это;
• проверить его синтаксис;
• идентифицировать известные заголовки HTTP и извлекать из них их значения.

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

Нормализация URL-адресов

Основная статья: нормализация URL-адресов

Программы веб-сервера обычно выполняют определенный тип нормализации URL-адресов ( URL-адрес встречается в большинстве сообщений HTTP-запросов), чтобы:

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

Термин нормализация URL-адресов относится к процессу последовательного изменения и стандартизации URL-адресов. Можно выполнить несколько типов нормализации, включая преобразование схемы и хоста в нижний регистр. Среди наиболее важных нормализации — удаление "." и «..» сегменты пути и добавление косой черты в конце к непустому компоненту пути.

Сопоставление URL-адресов

Основная статья: сопоставление URL-адресов

«Сопоставление URL-адресов — это процесс, посредством которого URL-адрес анализируется, чтобы выяснить, на какой ресурс он ссылается, чтобы этот ресурс можно было вернуть запрашивающему клиенту. Этот процесс выполняется с каждым запросом, который делается на веб-сервере, с некоторые запросы обслуживаются с помощью файла, например HTML-документа или изображения gif, другие - с результатами запуска программы CGI, а третьи - с помощью какого-либо другого процесса, например, встроенного обработчика модуля, документа PHP. или Java-сервлет».

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

• Перенаправление URL-адреса , перенаправление на другой URL-адрес;
• статический запрос содержимого файла ;
• динамический запрос :
  • список файлов или других подкаталогов, содержащихся в этом каталоге;
  • другие типы динамических запросов, чтобы идентифицировать процессор программы/модуля, способный обрабатывать этот тип URL-пути, и передавать ему другие части URL-адреса , то есть обычно переменные path-info и строковые переменные запроса.

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

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

Преобразование пути URL в файловую систему

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

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

Трансляция путей в файловую систему производится для следующих типов веб-ресурсов:

• локальный, обычно неисполняемый файл (статический запрос содержимого файла);
• локальный каталог (динамический запрос: список каталогов генерируется «на лету»);
• имя программы (динамические запросы, которые выполняются с использованием интерфейса CGI или SCGI, выходные данные которых считываются веб-сервером и повторно отправляются клиенту, отправившему HTTP-запрос).

Веб-сервер добавляет путь, найденный в запрошенном URL-адресе (сообщение HTTP-запроса), и добавляет его к пути корневого каталога веб-сайта (хост). На сервере Apache это обычно /home/www/website (на машинах Unix обычно это: /var/www/website). Посмотрите следующие примеры того, к чему это может привести.

Преобразование URL-пути для запроса статического файла

Пример статического запроса существующего файла, указанного по следующему URL-адресу:

http://www.example.com/path/file.html

клиента Пользовательский агент подключается к www.example.com а затем отправляет следующий HTTP запрос /1.1:

GET /path/file.html HTTP/1.1
Host: www.example.com
Connection: keep-alive

Результатом является ресурс локальной файловой системы:

/home/www/www.example.com/path/file.html

Затем веб-сервер считывает файл , если он существует, и отправляет ответ веб-браузеру клиента. В ответе будет описано содержимое файла и будет содержаться сам файл, либо появится сообщение об ошибке о том, что файл не существует или доступ к нему запрещен.

Преобразование URL-пути для запроса каталога (без статического индексного файла)

Пример неявного динамического запроса существующего каталога, указанного по следующему URL-адресу:

http://www.example.com/directory1/directory2/

клиента Пользовательский агент подключается к www.example.com а затем отправляет следующий HTTP запрос /1.1:

GET /directory1/directory2 HTTP/1.1
Host: www.example.com
Connection: keep-alive

Результатом является путь к локальному каталогу:

/home/www/www.example.com/directory1/directory2/

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

Преобразование URL-пути для динамического запроса программы

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

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

http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15

клиента Пользовательский агент подключается к www.example.com а затем отправляет следующий HTTP запрос /1.1:

GET /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1
Host: www.example.com
Connection: keep-alive

Результатом является путь к локальному файлу программы (в данном примере — программы PHP ):

/home/www/www.example.com/cgi-bin/forum.php

Веб-сервер выполняет эту программу, передавая информацию о пути и строку запроса. action=view&orderby=thread&date=2021-10-15 чтобы у программы была информация, необходимая для запуска. (В этом случае он вернет HTML-документ, содержащий просмотр записей форума, упорядоченных по темам с 15 октября 2021 г.). В дополнение к этому веб-сервер считывает данные, отправленные из внешней программы, и повторно отправляет эти данные клиенту, сделавшему запрос.

Управление сообщением запроса

После того как запрос прочитан, интерпретирован и проверен, им необходимо управлять в зависимости от его метода, URL-адреса и параметров, которые могут включать значения заголовков HTTP.

На практике веб-сервер должен обрабатывать запрос, используя один из следующих путей ответа:

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

Размещать статический контент

Клиенты ПК, взаимодействующие через сеть с веб-сервером, обслуживающим только статический контент

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

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

ПРИМЕЧАНИЕ. При обслуживании только статического контента программа веб-сервера обычно не меняет содержимое файлов обслуживаемых веб-сайтов (поскольку они только читаются и никогда не записываются), поэтому достаточно поддерживать только эти методы HTTP :

• OPTIONS
• HEAD
• GET

Ответ на статическое содержимое файла можно ускорить с помощью файлового кэша .

Индексные файлы каталога

Основная статья: Индекс каталога веб-сервера

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

Наиболее часто используемые имена для файлов статического индекса: index.html, index.htm и Default.htm.

Обычные файлы

Если программа веб-сервера получает сообщение запроса клиента с URL-адресом, путь которого соответствует имени существующего файла , и этот файл доступен программе веб-сервера, а его атрибуты соответствуют внутренним правилам программы веб-сервера, то программа веб-сервера может отправить это сообщение. файл клиенту.

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

Предоставляйте динамический контент

Клиенты ПК, взаимодействующие через сеть с веб-сервером, обслуживающим статический и динамический контент

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

ПРИМЕЧАНИЕ. При обслуживании статического и динамического контента программа веб-сервера обычно должна поддерживать также следующий метод HTTP, чтобы иметь возможность безопасно получать данные от клиента(ов) и, таким образом, иметь возможность размещать веб-сайты с интерактивными формами. ), которые могут отправлять большие наборы данных (например, большое количество ввода данных или загрузку файлов ) на веб-сервер/внешние программы/модули:

• POST

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

три стандартных и исторических интерфейса шлюза Ниже приведены .

компьютерная графика

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

SCGI

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

FastCGI

Внешняя программа FastCGI (обычно это процесс) запускается один раз программой веб-сервера или какой-либо другой программой/процессом, а затем ожидает сетевого подключения, которое постоянно устанавливается веб-сервером; через это соединение передаются параметры запроса и считываются данные ответов.

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

Список каталогов, динамически создаваемый веб-сервером

Основная статья: Индекс каталога веб-сервера

Программа веб-сервера может быть способна управлять динамической генерацией (на лету) индексного списка файлов и подкаталогов каталога.

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

Некоторые программы веб-сервера позволяют настраивать списки каталогов, позволяя использовать шаблон веб-страницы (документ HTML, содержащий заполнители, например $(FILE_NAME), $(FILE_SIZE)и т. д., которые заменяются значениями полей каждой записи файла, найденной в каталоге веб-сервером), например index.tpl или использование HTML и встроенного исходного кода, который интерпретируется и выполняется «на лету», например index.aspи/или путем поддержки использования программ динамического индексирования, таких как CGI, SCGI, FCGI, например index.cgi, index.php, index.fcgi.

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

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

Обработка программы или модуля

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

• файлы (файловая система);
• базы данных (БД);
• другие источники, расположенные на локальном компьютере или на других компьютерах.

Блок обработки может возвращать веб-контент любого типа, в том числе используя данные, полученные из хранилища данных, например:

• документ (например, HTML , XML и т. д.);
• изображение;
• видео;
• структурированные данные, например, которые могут использоваться для обновления одного или нескольких значений, отображаемых динамической страницей ( DHTML ) веб-интерфейса , и которые могут быть запрошены XMLHttpRequest API (см. также: динамическая страница ).

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

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

Программы веб-сервера могут отправлять ответные сообщения в качестве ответов на сообщения запроса клиента.

Сообщение об ошибке может быть отправлено, поскольку сообщение запроса не может быть успешно прочитано, декодировано, проанализировано или выполнено.

ПРИМЕЧАНИЕ. Следующие разделы представлены только в качестве примеров, чтобы помочь понять, что в той или иной степени делает веб-сервер; эти разделы ни в коем случае не являются ни исчерпывающими, ни полными.

Сообщение об ошибке

Программа веб-сервера может ответить на сообщение запроса клиента множеством сообщений об ошибках, в любом случае эти ошибки делятся в основном на две категории:

• Ошибки HTTP-клиента , связанные с типом сообщения запроса или доступностью запрошенного веб-ресурса;
• Ошибки HTTP-сервера из-за внутренних ошибок сервера.

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

URL-авторизация

Программа веб-сервера может проверить, является ли запрошенный путь URL-адреса:

• могут быть свободно доступны каждому;
• требует аутентификации пользователя (запрос учетных данных пользователя, например, имени пользователя и пароля );
• доступ запрещен некоторым или всем пользователям.

Если функция авторизации/прав доступа реализована и включена и доступ к веб-ресурсу не предоставлен, то в зависимости от необходимых прав доступа программа веб-сервера:

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

перенаправление URL-адресов

Основная статья: перенаправление URL-адресов

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

URL-перенаправление местоположения используется:

• исправить имя каталога, добавив последнюю косую черту «/»;
• чтобы указать новый URL-адрес для уже не существующего URL-адреса новому пути, по которому можно найти веб-ресурс такого типа.
• предоставить новый URL-адрес другому домену, если текущий домен слишком загружен.

Пример 1: URL-путь указывает на имя каталога , но не имеет конечной косой черты «/», поэтому веб-сервер отправляет перенаправление клиенту, чтобы дать ему указание повторить запрос с фиксированным именем пути.

От:
  /directory1/directory2
К:
  /directory1/directory2/

Пример 2: целый набор документов был перемещен внутри веб-сайта с целью реорганизации путей к их файловой системе.

От:
  /directory1/directory2/2021-10-08/
К:
  /directory1/directory2/2021/10/08/

Пример 3: целый набор документов был перенесен на новый сайт , и для доступа к ним теперь обязательно использовать защищенные HTTPS-соединения.

От:
  http://www.example.com/directory1/directory2/2021-10-08/
К:
  https://docs.example.com/directory1/2021-10-08/

Приведенные выше примеры представляют собой лишь некоторые из возможных видов перенаправления.

Успешное сообщение

Программа веб-сервера может ответить на действительное сообщение запроса клиента успешным сообщением, необязательно содержащим запрошенные данные веб-ресурса .

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

Кэш контента

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

Контент обычно кэшируется по его происхождению, например:

• статический контент:
  • файловый кэш ;
• динамический контент:
  • динамический кэш (вывод модуля/программы).

Кэш файлов

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

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

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

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

Широкое распространение RAID и/или быстрых твердотельных накопителей (устройств хранения данных с очень высокой скоростью ввода-вывода) немного уменьшило, но, конечно, не устранило преимущество наличия файлового кэша, встроенного в веб-сервер.

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

Динамический контент, выводимый внутренним модулем или внешней программой, не всегда может меняться очень часто (при наличии уникального URL с ключами/параметрами) и поэтому, возможно, на некоторое время (например, от 1 секунды до нескольких часов и более), результирующий выходные данные могут быть кэшированы в оперативной памяти или даже на быстром диске .

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

В любом случае, в большинстве случаев такого рода кеши реализуются внешними серверами (например, обратным прокси-сервером ) или путем хранения вывода динамических данных на отдельных компьютерах, управляемых конкретными приложениями (например, memcached ), чтобы не конкурировать за аппаратные ресурсы (ЦП, ОЗУ). , диски) с веб-сервером(ами).

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

Программное обеспечение веб-сервера может быть либо встроено в ОС и выполняться в пространстве ядра , либо выполняться в пространстве пользователя (как и другие обычные приложения).

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

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

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

Спектакли

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

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

Показатели производительности

Для программного обеспечения веб-сервера основными ключевыми показателями производительности (измеренными в различных условиях эксплуатации ) обычно являются как минимум следующие (т. е.):

• количество запросов в секунду ( RPS , аналогично QPS , в зависимости от версии и конфигурации HTTP, типа HTTP-запросов и других условий работы);
• количество соединений в секунду ( CPS ), — количество соединений в секунду, принимаемых веб-сервером (полезно при использовании HTTP/1.0 или HTTP/1.1 с очень низким лимитом запросов/ответов на соединение, т.е. 1..20);
• задержка сети + время ответа на каждый новый клиентский запрос; обычно инструмент тестирования показывает, сколько запросов было удовлетворено в течение определенного периода времени (например, в течение 1 мс, 3 мс, 5 мс, 10 мс, 20 мс, 30 мс, 40 мс) и/или самого короткого, среднего и самого длительного времени ответа;
• пропускная способность ответов , в байтах в секунду.

Среди условий работы количество (1 .. n ) одновременных клиентских подключений, используемых во время теста, является важным параметром, поскольку позволяет сопоставить параллелизма уровень , поддерживаемый веб-сервером, с результатами тестируемых показателей производительности.

Эффективность программного обеспечения

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

• однопроцессный или многопроцессный ;
• однопоточный (без потока) или многопоточный для каждого процесса;
• использование сопрограмм или нет;

... и другие методы программирования , такие как (например):

• минимизация возможных промахов кэша ЦП ;
• минимизация возможных ошибочных прогнозов ветвей ЦП на критических для скорости путях;
• минимизация количества системных вызовов, используемых для выполнения определенной функции/задачи;
• другие трюки;

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

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

Условия эксплуатации

Существует множество условий эксплуатации, которые могут повлиять на производительность веб-сервера; Значения производительности могут варьироваться в зависимости от (т. е.):

• настройки веб-сервера (в том числе тот факт, включен ли файл журнала и т. д.);
• версия HTTP, используемая клиентскими запросами;
• средний тип HTTP-запроса (метод, длина HTTP-заголовков и необязательное тело);
• является ли запрашиваемый контент статическим или динамическим;
• ли контент кэшируется или нет (сервером и/или клиентом);
• ли контент сжимается на лету (при передаче), предварительно сжимается (т. е. когда файловый ресурс хранится на диске уже в сжатом виде, чтобы веб-сервер мог отправить этот файл непосредственно в сеть с единственным указанием на то, что его содержимое сжато) или не сжат вообще;
• зашифрованы ли соединения или нет;
• средняя скорость сети между веб-сервером и его клиентами;
• количество активных TCP- соединений;
• количество активных процессов, управляемых веб-сервером (включая внешние программы CGI, SCGI, FCGI);
• аппаратные программные и ограничения или настройки ОС компьютера (ов), на котором работает веб-сервер;
• другие незначительные условия.

Бенчмаркинг

Основная статья: Сравнительный анализ веб-серверов

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

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

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

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

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

В любой момент веб-серверы могут быть перегружены по одной или нескольким из следующих причин (например).

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

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

Симптомы перегруженного веб-сервера обычно следующие (например).

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

Техники борьбы с перегрузкой

Чтобы частично преодолеть ограничения нагрузки выше среднего и предотвратить перегрузку, большинство популярных веб-сайтов используют общие методы, подобные следующим (например).

• Настройка параметров ОС в соответствии с возможностями оборудования и его использованием.
• Настройка параметров веб-серверов для повышения их безопасности и производительности.
• Развертывание методов веб-кэширования (не только для статического содержимого, но, по возможности, и для динамического содержимого).
• Управление сетевым трафиком с помощью:
  • Брандмауэры для блокировки нежелательного трафика, исходящего от плохих IP-источников или имеющего неверные шаблоны;
  • Менеджеры HTTP-трафика для удаления, перенаправления или перезаписи запросов с неверными HTTP ; шаблонами
  • Управление пропускной способностью и формирование трафика для сглаживания пиков использования сети.
• Использование разных доменных имен , IP-адресов и компьютеров для обслуживания разных видов (статического и динамического) контента; цель состоит в том, чтобы разделить большие или огромные файлы ( download.*) (этот домен также можно заменить CDN ) из файлов небольшого и среднего размера ( static.*) и с основного динамического сайта (возможно, там, где некоторое содержимое хранится во внутренней базе данных ) ( www.*); Идея состоит в том, чтобы иметь возможность эффективно обслуживать большие или огромные (более 10–1000 МБ) файлы (возможно, регулирование загрузки) и полностью кэшировать файлы малого и среднего размера, не влияя на производительность динамического сайта при большой нагрузке, используя различные настройки. для каждого (группы) компьютеров веб-сервера, например:
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• Использование множества веб-серверов (компьютеров), сгруппированных за балансировщиком нагрузки, так что они действуют или рассматриваются как один большой веб-сервер.
• Добавление дополнительных аппаратных ресурсов (например, оперативной памяти , быстрых дисков ) на каждый компьютер.
• Использование более эффективных компьютерных программ для веб-серверов (см. также: эффективность программного обеспечения ).
• Использование наиболее эффективного интерфейса шлюза веб-сервера для обработки динамических запросов (запуск одной или нескольких внешних программ каждый раз при получении динамической страницы снижает производительность).
• Использование других методов программирования и обходных путей , особенно если задействован динамический контент, для ускорения HTTP-ответов (т. е. избегая динамических вызовов для получения объектов, таких как таблицы стилей, изображения и сценарии), которые никогда не меняются или меняются очень редко, путем копирования этот контент в статические файлы один раз, а затем синхронизировать их с динамическим контентом).
• Использование последних эффективных версий HTTP (например, помимо использования обычного HTTP/1.1 путем включения HTTP/2 и, возможно, HTTP/3 , если доступное программное обеспечение веб-сервера имеет надежную поддержку последних двух протоколов), чтобы значительно сократить количество TCP/IP-соединения, запускаемые каждым клиентом, и размер обмениваемых данных (из-за более компактного представления заголовков HTTP и, возможно, сжатия данных).

Предостережения относительно использования протоколов HTTP/2 и HTTP/3

Даже если новые протоколы HTTP (2 и 3) обычно генерируют меньше сетевого трафика для каждого запроса/ответа, они могут потребовать больше ресурсов ОС (т. е. ОЗУ и ЦП), используемых программным обеспечением веб-сервера (из-за зашифрованных данных , большого количества потоковых буферов и другие детали реализации); кроме того, HTTP/2 и, возможно, даже HTTP/3, в зависимости от настроек веб-сервера и клиентской программы, могут быть не лучшими вариантами для загрузки данных больших или огромных файлов на очень высокой скорости, поскольку их потоки данных оптимизированы для одновременного выполнения. запросов, поэтому во многих случаях использование соединений HTTP/1.1 TCP/IP может привести к лучшим результатам/более высокой скорости загрузки (ваш результат может отличаться) .

Доля рынка

Дополнительная информация о программах HTTP-сервера: Категория: Программное обеспечение веб-сервера.

Диаграмма:
Доля рынка всех сайтов для наиболее популярных веб-серверов, 2005–2021 гг.

Диаграмма:
Доля рынка всех сайтов наиболее популярных веб-серверов, 1995–2005 гг.

Ниже приведены последние статистические данные о рыночной доле всех сайтов лучших веб-серверов в Интернете от Netcraft .

Веб-сервер: доля рынка всех сайтов.

Дата	nginx (Nginx, Inc.)	Апач ( АСФ )	OpenResty (Фонд программного обеспечения OpenResty)	Сервер Cloudflare ( Cloudflare, Inc. )	IIS ( Майкрософт )	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%	Н/Д	Н/Д	28.42%	1.66%	Менее 19%
февраль 2018 г.	24.32%	27.45%	Н/Д	Н/Д	34.50%	1.20%	Менее 13%
февраль 2017 г.	19.42%	20.89%	Н/Д	Н/Д	43.16%	1.03%	Менее 15%
февраль 2016 г.	16.61%	32.80%	Н/Д	Н/Д	29.83%	2.21%	Менее 19%

ПРИМЕЧАНИЕ. (*) процент округлен до целого числа, поскольку его десятичные значения не публикуются на исходной странице (на графике отображается только округленное значение).

См. также

• Сервер (вычисления)
• Сервер приложений
• Сравнение программного обеспечения веб-сервера
• HTTP-сервер (основная часть программы веб-сервера, обслуживающей HTTP-запросы)
• HTTP-сжатие
• Веб-приложение
• Веб-приложение с открытым исходным кодом
• Список пакетов AMP
• Вариант объекта
• Виртуальный хостинг
• Веб-хостинг
• Веб-контейнер
• Веб-прокси
• Веб-сервис

Стандартные интерфейсы шлюза веб-сервера, используемые для динамического содержимого :

• CGI Общий интерфейс шлюза
• SCGI Простой общий интерфейс шлюза
• FastCGI Интерфейс быстрого общего шлюза

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

• Серверная часть SSI включает редко используемые статические HTML-документы, содержащие директивы SSI, которые интерпретируются серверным программным обеспечением для включения небольших динамических данных «на лету» при обслуживании страниц, например даты и времени, другого статического содержимого файла и т. д.
• SAPI Интерфейс прикладного программирования сервера :
  • ISAPI Интерфейс прикладного программирования Интернет-сервера
  • NSAPI Netscape Интерфейс прикладного программирования сервера
• PSGI Perl Интерфейс шлюза веб-сервера
• WSGI Python Интерфейс шлюза веб-сервера
• Rack Rack Интерфейс шлюза веб-сервера
• JSGI JavaScript Интерфейс шлюза веб-сервера
• Java-сервлет , страницы JavaServer
• Активные страницы сервера , ASP.NET

Внешние ссылки

• Mozilla: что такое веб-сервер?
• Netcraft: новости об опросе веб-серверов