Принцип работы apache сервер: Как установить и настроить веб-сервер Apache

Not Found (#404)

Помощь 0 Регистрация Вход

Not Found (#404) Страница не найдена

На главную

Домены

• Регистрация доменов
• Освободившиеся домены
• Промоакции
• Перенос домена
• Переадресация
• Магазин доменов

Сайты

• Конструктор сайтов
• Сайты на WordPress

Хостинг сайтов

• Хостинг
• Windows хостинг

VPS и серверы

• VPS хостинг
• Windows VPS
• Аренда серверов

Дополнения

• SSL-сертификаты
//=url(‘/free-mail’)?>

Сервисы

• Бесплатный хостинг
• Whois
• Связь с администратором домена
• Определить свой IP-адрес
• Проверка порта на доступность
• Узнать местоположение по IP
• Проверить доступность сайта

Поддержка

• Справка
• Стоимость услуг
• Способы оплаты
• Связаться с нами

Компания

• О компании
• Документы
• Офис
• Дата-центр
• Новости
• Блог
• Акции и скидки

© 2DOMAINS — регистрация доменов

• Домены оптом
• Географические домены
• Кириллические домены
• Административные домены
• Национальные домены
• Новые домены первого уровня
• Где купить домен дешево
• Дешевый хостинг
• CloudVPS
• Хостинг для сайта-визитки
• Хостинг с PHP и MySQL
• Надежный хостинг
• Самые дешевые домены
• Хостинг WordPress
• Хостинг для 1С-Битрикс
• Хостинг для Drupal
• Хостинг для Joomla
• Хостинг для MODX
• Хостинг для OpenCart
• Антивирус для хостинга
• Бэкап сайта
• Защита от DDoS-атак
• Хостинг с ISPmanager
• SSL бесплатно
• AlphaSSL
• AlphaSSL WildCard
• ExtendedSSL
• GlobalSign-сертификаты
• Comodo / Sectigo — сертификаты
• GeoTrust-сертификаты
• Symantec-сертификаты
• Thawte-сертификаты
• TrustWave-сертификаты
• Wildcard-сертификаты

Политика обработки персональных данных
Тех. поддержка: [email protected]

Указанные на сайте цены могут не включать стоимость применимых комиссий.

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

что это, зачем нужен и как настроить

480 auto

Nginx обслуживает более миллиона сайтов по всему миру и пользуется заслуженной любовью и почитанием. Однако несмотря на его популярность и большое количество материалов, вопросов по его использованию не убавляется.

В этой статье мы ответим на вопросы о том, как работает Nginx и как он читает конфигурационные файлы. А в следующем посте мы детально разберём 4 кейса его использования: от хостинга нескольких сайтов на одном сервере, до защиты от DDOS.

Коротко о Nginx

Nginx — это веб-сервер, прокси-сервер, обратный прокси-сервер, smtp-сервер и балансировщик нагрузки. Сразу раскроем все эти понятия. Магия перестает быть магией, когда понимаешь как устроен мир.

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

NGINX сочетает в себе все перечисленные возможности, хотя изначально он задумывался только как web- и smtp-сервер. NGINX был разработан Игорем Сысоевым в 2004 году. Его не устраивала скорость работы Apache. Ему нужен был web-сервер, который мог бы держать 10,000 одновременных запросов, при этом расходовать минимум памяти, не теряя производительности.

Сегодня с помощью NGINX решают следующие задачи:

• Кеширование и стриминг видео
• Отдача статического контента сайта
• Построение CDN-сетей
• Распределение нагрузки
• Обеспечение безопасности
• Работа почтовых служб
  и многое другое.

Секрет успеха NGINX в его архитектуре, которая коренным образом отличается от других веб-серверов. Давайте разберёмся, как работает NGINX?

Как работает NGINX?

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

У NGINX есть один мастер-процесс и несколько вспомогательных процессов. Например, на нашем 2 ядерном сервере, NGINX запустил 2 дополнительных процесса, обозначенных как worker process:

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

На одном ядре одновременно может находиться только один процесс или поток. Процессы на ядре постоянно подменяют друг друга, из-за чего сильно страдает производительность, когда процессов становится много. Это камень преткновения для многих современных web-приложений, которые открывают на каждое соединение свой поток.

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

 

Графически схема работы NGINX выглядит следующим образом:

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

 

Если хотите больше узнать о работе NGINX изнутри — на хабре есть отличная статья: «NGINX изнутри: рожден для производительности и масштабирования». Она, правда, старая, но очень хорошая. Рекомендуем!

 

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

Модули настраиваются через конфигурационные файлы NGINX, о них и поговорим.

Работа с конфигурационными файлами NGINX

NGINX работает с двумя уровнями конфигурационных файлов. Первый уровень — глобальный, к нему относится конфигурационный файл etc/nginx/nginx.conf. Второй уровень — локальный, к нему относятся конфигурационные файлы конкретных сайтов, расположенных, как правило, в /etc/nginx/site-available или в /etc/nginx/conf.d/

nginx.conf — это корневой конфигурационный файл NGINX. В нём содержатся его глобальные настройки:

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

С nginx.conf NGINX начинает парсить конфигурационные файлы, которые состоят из директив. Директивы могут быть простыми — однострочными, а могут быть блочными. Если блочная директива содержит другую вложенную блочную директиву, то такая блочная директива называется контекстом.

Вот пример простой однострочной директивы: access_log /var/nginx/access.log main; Параметры директивы разделяются пробелами, а в конце строки обязательно ставится точка с запятой.

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

events {
  worker_connections 1024;
}

Здесь контекст events содержит одну директиву — worker_connections, которая указывает на максимальное число одновременных соединений. Контекст может содержать вложенные контексты.

Вот пример стандартного контекста:

server {
    location / {
        root /data/www;
    }

    location /images/ {
        root /data;
    }
}

Здесь блочная директива server содержит несколько блочных директив location, организуя тем самым контекст server. Директивы вне любого контекста относятся к main.

Список основных контекстов и их значений:

• main — корень конфигурации, по сути это /etc/nginx/nginx.conf;
• events — контекст работы с соединениями;
• http — контекст работы с http-протоколом;
• server — контекст работы с сервером;
• location — контекст работы с маршрутизацией запросов.

Контекст может быть указан не явно, а через директиву include c указанием директории расположения. Это делается для экономии места и возможности отдельного изменения параметров директив server. Вот пример, как это может быть исполнено:

user www www;
worker_processes 5;
error_log logs/error.log;
pid logs/nginx.pid;
worker_rlimit_nofile 8192;

events {
  worker_connections  4096;
}

http {
  include conf/mime.types;
  include /etc/nginx/sites-enabled/*;
  index index. html index.htm index.php;

  default_type application/octet-stream;
  access_log logs/access.log  main;
  sendfile on;
  tcp_nopush on;
  }

Здесь указаны сразу две директивы include: первая директива ссылается на мимотипы файлов для отдачи, а вторая на все конфигурационные файлы расположенные в директории /etc/nginx/sites-enabled/. То есть, при чтении конфигурационного файла, include разворачивается в то, на что ссылается.

В нашем случае вместо include /etc/nginx/sites-enabled/* будут подставлены все конфигурационные файлы в директории /etc/nginx/sites-enabled/, выглядящие следующим образом:

server {
    listen 80;
    server_name  domain2.com www.domain2.com;

    location /  {
      root    /var/www/virtual/big.server.com/htdocs;
      index index.html;
      try file $uri $uri/index.html;
    }
}

Благодаря такой древовидной модели сборки конфигурационных файлов удаётся достичь гибкости управления сайтами. Например, если на одном сервере располагаются несколько сайтов и один из них нужно отключить или изменить у него настройки — достаточно выполнить нужные работы и перечитать конфигурационный файл командой nginx -s reload.

 

Структуру конфигурационных файлов разобрали, осталось ответить ещё на один вопрос — как Nginx понимает, что нужно отдавать клиенту и по какому запросу?

Nginx анализирует HTTP-запрос от клиента и ищет совпадения со значениями условий директив server_name и linsten в контексте server. Когда совпадения найдены начинает работать контекст location, который отвечает за маршрутизацию запросов.

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

Если среди location с регулярными выражениями Nginx не найдёт совпадений, он вернёт первый префиксный location — корень сайта.

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

Расставляем всё по полочкам

NGINX — это легковесный и мощный web-сервер, который способен держать до 10 тысяч одновременных соединений, расходуя при этом минимальное количество ресурсов. Чаще всего его используют в качестве прокси-сервера и обратного прокси-сервера.

NGINX обладает модульной архитектурой. Модули настраиваются через конфигурационные файлы, которые имеют древовидную структуру и собираются в единое целое при их чтении. Корневой конфигурационный файл NGINX — /etc/nginx/nginx.conf. Его NGINX читает в первую очередь, затем он читает другие конфиги, указанные в nginx.conf явным образом или с помощью директивы include.

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

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

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

В следующей статье мы приведем такие кейсы использования NGINX:

• Как разместить несколько сайтов на одном сервере?
• Связка NGINX и Python — современный сайт на Django
• Как защитить сайт от DDoS?
• Балансировка нагрузки между бекенд-серверами.

Пока мы готовим новый материал, вы можете познакомиться поближе с NGINX. На сайте https://nginx.org/ru/ доступным языком подана официальная документация и есть хорошие примеры конфигурационных файлов. Также для более глубокого понимания следующей статьи пригодятся знания по Django, Linux и Docker. Их можно взять из наших статей:

Как работает Apache? Веб-сервер Apache: архитектура, компоненты и процессы.

Apache является наиболее широко используемым веб-сервером в мире, поддерживающим более 40% всех веб-сайтов в Интернете. Это кроссплатформенный веб-сервер с открытым исходным кодом, поддерживаемый Apache Software Foundation. Apache — это кроссплатформенный сервер, что означает, что он может работать в различных операционных системах, таких как Windows, Linux и macOS.

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

Что такое архитектура веб-приложений и как в нее вписывается веб-сервер Apache?

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

Архитектура веб-приложения имеет решающее значение для его производительности, масштабируемости и удобства обслуживания. Хорошо спроектированная архитектура веб-приложения позволяет легко разрабатывать, тестировать, развертывать и поддерживать приложение. Один из наиболее распространенных стеков веб-приложений включает LAMP или Linux, Apache, MySQL и PHP.

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

Давайте посмотрим на различные компоненты типичной архитектуры веб-приложений и на то, как в нее вписывается Apache. . Этот код обычно пишется на HTML, CSS и JavaScript и отвечает за отрисовку пользовательского интерфейса и обработку взаимодействия с пользователем.

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

Серверная часть

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

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

База данных

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

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

Инфраструктура

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

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

Что такое Apache?

HTTP-сервер Apache, обычно называемый Apache, представляет собой программное обеспечение веб-сервера, созданное Apache Software Foundation. Это программное обеспечение с открытым исходным кодом, которое доступно бесплатно и используется для обслуживания веб-страниц и другого контента в Интернете.

Apache — это кроссплатформенное серверное программное обеспечение, работающее на Unix, Linux, Windows и macOS. Он способен обслуживать как статический, так и динамический контент и может быть настроен для работы с различными протоколами, такими как HTTP, HTTPS и FTP.

Как работает Apache?

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

1. Прослушиватель:

Прослушиватель — это первый компонент веб-сервера Apache. Он отвечает за прием входящих соединений от клиентов. Прослушиватель прослушивает определенный порт для входящих запросов, обычно это порт 80 для HTTP-запросов и порт 443 для HTTPS-запросов.

Когда клиент отправляет запрос на сервер, прослушиватель принимает соединение и передает его следующему компоненту в цепочке.

2. Многопроцессорный модуль (MPM):

Многопроцессорный модуль, или MPM, отвечает за обработку клиентских подключений и обработку клиентских запросов. Apache поддерживает различные MPM, включая Prefork, Worker и Event. Каждый MPM имеет свои преимущества и недостатки, и выбор MPM зависит от конкретных требований сервера.

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

3. Обработчик запросов:

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

Обработчик запросов может обслуживать статическое содержимое непосредственно с диска или передавать запрос сценарию или приложению для создания динамического содержимого. Тип обслуживаемого контента зависит от URL-адреса, запрошенного клиентом, и конфигурации сервера.

4. Генератор контента:

Генератор контента отвечает за генерацию ответа на запрос клиента. Если запрос предназначен для статического содержимого, генератор содержимого считывает содержимое с диска и отправляет его клиенту. Если запрос предназначен для динамического содержимого, генератор содержимого передает запрос сценарию или приложению для создания содержимого.

Генератор содержимого также может применять к содержимому различные фильтры, такие как сжатие, шифрование или кэширование. Эти фильтры могут повысить производительность и безопасность сервера.

5. Отправитель ответа:

Отправитель ответа отвечает за отправку ответа клиенту. После того как генератор контента сгенерировал ответ, отправитель ответа отправляет ответ клиенту с использованием соответствующего протокола, например HTTP или HTTPS.

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

Практический пример

Чтобы понять, как работает веб-сервер Apache, рассмотрим пример. Предположим, клиент запрашивает URL-адрес http://www.webquel.com с сервера, на котором работает Apache. Вот как Apache будет обрабатывать этот запрос:

1. Прослушиватель: клиент отправляет запрос на сервер, подключаясь к прослушивателю через порт 80. Прослушиватель принимает соединение и передает запрос в MPM.
2. Multi-Processing Module: MPM создает дочерний процесс или поток для обработки запроса. Дочерний процесс или поток анализирует запрос и определяет соответствующее действие.
3. Обработчик запросов: обработчик запросов получает запрос от дочернего процесса или потока и анализирует его. В этом случае запрашивается файл index.html на сервере. Обработчик запросов определяет, что это запрос статического содержимого, и считывает файл с диска.
4. Генератор контента: Генератор контента получает контент от обработчика запросов и применяет все настроенные фильтры. В этом случае генератор содержимого применяет к содержимому сжатие.
5. Отправитель ответа: Отправитель ответа получает сжатое содержимое от генератора содержимого и отправляет его клиенту с использованием протокола HTTP. Отправитель ответа также применяет к ответу заголовки, такие как тип содержимого и длина содержимого.

Подведение итогов

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

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

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

За последние пару лет тысячи новичков и опытных профессионалов изменили траекторию своей карьеры и совершили самые большие подъемы, используя проверенную структурированную учебную программу ZEN Class Full Stack Developer Bootcamp.

Не верите нам? Послушайте их своими словами. Слушайте подкаст Ишана 

Как работают веб-серверы?

Интернет служит для нас источником множества информации, и все, что нам нужно сделать, если нам нужна какая-либо информация, это просто запросить Интернет, и тогда мы получим желаемый ответ.
Но кто и как предоставляет нам эту информацию? Всему этому способствует то, что называется веб-сервером. Наряду с этим существуют браузеры как приложения, которые мы используем, такие как Internet Explorer, Mozilla Firefox, Chrome, Safari и т. д., для взаимодействия с Интернетом, просмотра и извлечения файлов на веб-серверах, известных как веб-клиенты.

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

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

Когда требуется веб-сервер?

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

• Тот, кто владеет веб-сайтом (чтобы локальная копия в их системе была похожа на то, что находится в Интернете).
• Тот, кто хочет использовать серверные технологии, такие как PHP или ColdFusion, также может использовать веб-сервер.

Как работают веб-серверы?

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

Простой процесс состоит из 4 шагов, а именно: 

• Получение IP-адреса из доменного имени: Сначала наш веб-браузер получает IP-адрес. доменное имя (например, для этой страницы доменное имя — www.geeksforgeeks.org). Он может получить IP-адрес двумя способами:
  • Путем поиска в своем кеше.
  • Путем запроса одного или нескольких серверов DNS (системы доменных имен).
• Браузер запрашивает полный URL-адрес : Узнав IP-адрес, браузер теперь запрашивает полный URL-адрес с веб-сервера.
• Веб-сервер отвечает на запрос: Веб-сервер отвечает браузеру, отправляя нужные страницы, и в случае, если страницы не существуют или возникает какая-либо другая ошибка, он отправляет соответствующее сообщение об ошибке.
  Например:  
  Возможно, вы видели Ошибка 404 при попытке открыть веб-страницу, которая представляет собой сообщение, отправляемое сервером, когда страница не существует.
  Другой распространенной ошибкой является Ошибка 401 , когда нам отказано в доступе из-за неправильных учетных данных, таких как имя пользователя или пароль, предоставленных нами.
• Браузер отображает веб-страницу: Браузер, наконец, получает веб-страницы и отображает их или отображает сообщение об ошибке.

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

• RPS: RPS означает количество запросов в секунду. Он определяет максимальное количество запросов, которые сервер может обработать от различных клиентов. Это зависит от различных других факторов, таких как версия HTTP, тип HTTP-запросов и т. д.
• Задержка: Сетевая задержка — это время ответа, которое требуется серверу для обработки каждого запроса клиента. Это рассчитывается в миллисекундах.
• Пропускная способность: Определяется как объем данных, переданных за заданный период времени. Он рассчитывается в байтах в секунду. Там, где для идеального сервера задержка должна быть очень низкой, пропускная способность должна быть очень высокой.
• Параллелизм: Поскольку RPS, задержка и пропускная способность могут сильно колебаться в зависимости от количества активных клиентов и соединений, параллелизм — это еще один параметр, который используется для проверки производительности веб-сервера. Это поддерживается веб-серверами с различными спецификациями, такими как конфигурация сервера, тип операционной системы и аппаратные ресурсы.

Популярные веб-серверы: Доступно довольно много веб-серверов, таких как Apache, Microsoft IIS, веб-сервер Nginx и веб-сервер LightSpeed. Но два самых популярных из них:

• HTTP-сервер Apache: Это самый популярный и широко используемый веб-сервер. Он разработан и поддерживается Apache Software Foundation. Программное обеспечение производится в соответствии с лицензией Apache, что делает его бесплатным и с открытым исходным кодом.
  Он доступен для различных операционных систем — Windows, Mac OS X, Unix, Linux, Solaris, Novell Netware и FreeBSD.
   
• Microsoft Internet Information Service: Microsoft IIS (Internet Information Service) является вторым по популярности веб-сервером, и его доля на рынке растет с каждым днем ​​довольно быстро, и, вероятно, в ближайшие годы он заменит Apache.
  Сервер IIS имеет все функции, как и Apache, но не с открытым исходным кодом. Он разработан и поддерживается Microsoft, поэтому он работает со всеми платформами операционной системы Windows.

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