Web сервер как пишется

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «Веб-сервер» в других словарях:

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

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

ВЕБ-СЕРВЕР — Это сервер, принимающий HTTP запросы от клиентов, обычно веб браузеров, и выдающий им HTTP ответы, обычно вместе с HTML страницей, изображением, файлом, медиа потоком или другими данными. Веб серверы основа Всемирной паутины. Веб сервером… … Словарь бизнес-терминов

ВЕБ-СЕРВЕР — (англ. web server, от web паутина, сеть и server обслуживающий процессор), компьютер, подключенный к Интернету (см. ИНТЕРНЕТ), или программа, осуществляющая доступ к сетевым ресурсам или предоставляющая информацию клиентскому приложению или… … Энциклопедический словарь

веб-сервер — сущ., кол во синонимов: 1 • сервер (16) Словарь синонимов ASIS. В.Н. Тришин. 2013 … Словарь синонимов

веб-сервер — В World Wide Web программа, принимающая запросы на информацию в соответствии со стандартом HTTP. Сервер обрабатывает эти запросы и посылает нужный документ. [http://www.lexikon.ru/rekl/a eng.html] Тематики реклама EN web server … Справочник технического переводчика

Веб сервер — Архитектура серверов Wikimedia Веб сервер это сервер, принимающий веб браузеров, и выдающий им HTML страницей, изображением, файлом, медиа потоком или другими данными. Веб серверы основа Всемирной паутины. Веб сервером называют как программное… … Википедия

веб-сервер — веб се/рвер, веб се/рвера … Слитно. Раздельно. Через дефис.

Сервер приложений — (англ. application server) это программная платформа (software framework), предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений… … Википедия

Веб-приложение — Веб приложение клиент серверное приложение, в котором клиентом выступает браузер, а сервером веб сервер. Логика веб приложения распределена между сервером и клиентом, хранение данных осуществляется, преимущественно, на сервере, обмен… … Википедия

Источник статьи: http://dic.academic.ru/dic.nsf/ruwiki/33431

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Веб-сервер

Веб-сервер — сервер, принимающий HTTP-запросы от клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы, как правило, вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными [1] .

Содержание

Краткая характеристика

Понятие «Веб-сервер» может относится как к к самому серверу, как физическому хранилищу, так и к программному обеспечению.

С точки зрения железа, веб-сервер — это компьютер который хранит ресурсы сайта (HTML документы, CSS стили, JavaScript файлы и другое) и доставляет их на устройство конечного пользователя (веб-браузер и т.д.). Обычно подключен к сети Интернет и может быть доступен через доменное имя, например mozilla.org.

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

Чтобы опубликовать веб-сайт, нужно либо статический, либо динамический веб-сервер.

Статический веб-сервер, или стек, состоит из компьютера (железо) с сервером HTTP (ПО). На слэнге это называется “статикой”, потому что сервер посылает размещенные на нем файлы в браузер “как есть”.

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

Например, для получения итоговой страницы, которую вы видите в браузере, сервер приложений может заполнить HTML шаблон данными из базы данных. Такие сайты, как MDN (Mozilla Developer Network) или Википедия состоят из тысяч веб-страниц, но они не являются реальными HTML документами, лишь несколько HTML шаблонов и гигантские базы данных. Эта структура упрощает и ускоряет сопровождение веб-приложений и доставку контента.

Цель и функции веб-сервера

Цель веб-сервера проста — обслуживать одновременно большое количество клиентов, максимально эффективно используя hardware.

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

Любой веб сервер, для удобства его использования пользователями, должен иметь удобный веб-браузер. Он передает веб серверу запросы, преобразованные в URL-адреса интернет — ресурсов.

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

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

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

Технически, вы можете разместить все эти файлы на своем компьютере, но гораздо удобнее хранить их на выделенном веб-сервере, который [2] :

• всегда запущен и работает
• постоянно в сети Интернет
• имеет тот же IP адрес все время (не все провайдеры предоставляют статический IP адрес для домашнего подключения)
• обслуживается на стороне

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

Во-вторых, веб-сервер обеспечивает поддержку HTTP (hypertext transfer protocol). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

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

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

HTTP задает строгие правила, как клиент и сервер должны общаться. Мы рассмотрим непосредственно HTTP далее в техническом разделе. Вот некоторые из них:

1. Только клиенты могут отправлять HTTP запросы, и только на сервера. Сервера отвечают только на HTTP запросы клиента.
2. Когда запрашивается физический файл, клиент должен сформировать URL для сервера.
3. Веб-сервер должен ответить на каждый HTTP запрос, по крайней мере с сообщением об ошибке.

На веб-сервере, HTTP сервер отвечает за обработку входящих запросов и ответ на них:

• При получении запроса, HTTP сервер сначала проверяет существует ли ресурс по данному URL.
• Если это так, веб-сервер отправляет содержимое файла обратно в браузер. Если нет, сервер приложений создает необходимый ресурс.
• Если это не возможно, веб-сервер возвращает сообщение об ошибке в браузер, чаще всего “404 Not Found”. (Это ошибка настолько распространена, что многие веб-дизайнеры тратят большое количество времени на разработку 404 страниц об ошибках.)

Популярные веб-сервера

Apache HTTP Server

Apache HTTP Server является проектом, развиваемый The Apache Software Foundation, в рамках которого разрабатывается кроссплатформенный HTTP сервер с открытым исходным кодом. Входит в состав LAMP (комплект из Linux, Apache, MySQL, PHP) и WAMP (комплект из Windows, Apache, MySQL, PHP). Другими словами, это полнофункциональный, расширяемый веб-сервер, полностью поддерживающий протокол HTTP/1.1 и распространяющийся с открытым исходным кодом [3] .

Состав архитектуры Apache HTTP Server:

Ядро, написанное на языке программирования C, в чьи функциональные возможности входит:

• обработка конфигурационных файлов
• протокол HTTP
• система загрузки модулей

Система текстовой конфигурации, состоящая из трех уровней:

• Конфигурация сервера (httpd.conf).
• Конфигурация виртуального хоста (httpd.conf c версии 2.2, extra/httpd-vhosts.conf).
• Конфигурация уровня директории (.htaccess).

Мультипроцессорные модели (MPM), которые используются для работы с различными серверными операционными системами.(worker, pre-fork и др.) Система модулей для обеспечения:

• Поддержки языков программирования.
• Добавления функций.
• Исправление ошибок или модификация основных функций.
• Усиления безопасности.

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

Веб-сервер Apache разрабатывается и поддерживается открытым сообществом разработчиков под эгидой Apache Software Foundation и включён во многие программные продукты, среди которых СУБД Oracle и IBM WebSphere. С апреля 1996 и до настоящего времени является самым популярным HTTP-сервером в Интернете.

Apache Tomcat

Apache Tomcat — это контейнер, который позволяет вам использовать интернет приложения такие, как Java сервлеты и JSP (серверные страницы Java). Пакеты Apache Tomcat 6.0 в Ubuntu поддерживают два варианта запуска Tomcat [4] :

1. Использовать Tomcat как классический одиночный экземпляр на всю систему, который будет запускаться при загрузке системы от имени непривилегированного пользователя tomcat6.
2. Развернуть частные экземпляры, которые будут запускаться с правами вашего собственного пользователя, и вам придется запускать и останавливать их самостоятельно.

Tomcat используется в качестве самостоятельного веб-сервера, в качестве сервера контента в сочетании с веб-сервером Apache HTTP Server, а также в качестве контейнера сервлетов в серверах приложений JBoss и GlassFish. Компоненты Tomcat:

1. Catalina — контейнер сервлетов Tomcat’а, который реализует спецификацию сервлетов Servlet API. Servlet API является основой для всех остальных технологий Java, касающихся Web и дает возможность динамически генерировать любой web-контент, используя любые библиотеки, доступные для java. Архитектором Catalina являлся Craig McClanahan.
2. Coyote — компонент стека HTTP Tomcat’а, который поддерживает протокол HTTP 1.1 для веб-серверов или контейнера приложений. Coyote прослушивает входящие соединения на определённом TCP порту сервера, пересылает запросы в механизм Tomcat для обработки запросов и отправляет ответ назад запрашивающему клиенту.
3. Jasper — механизм JSP Tomcat’а. Tomcat 5.x использует Jasper 2, который является реализацией спецификации JavaServer Pages 2.0 Sun Microsystems. Jasper анализирует JSP-файлы, чтобы компилировать их в Java код, как сервлеты (которые могут быть обработаны с помощью Catalina). Во время выполнения, Jasper может автоматически обнаруживать изменения JSP-файла и перекомпилировать его. В Jasper 2, были добавлены важные особенности:

• JSP библиотеки тегов объединения — Каждый тег разметки в файле JSP обрабатывается классом обработчика тегов. Объекты класса обработчика тега может быть объединены и использованы повторно в целом JSP сервлете.
• Фоновая JSP компиляция — в то время как происходит перекомпиляция измененного JSP Java-кода, старая версия все еще доступна для серверных запросов. Старый JSP сервлет удаляется только когда новый JSP сервлет закончил перекомпиляцию.
• Компилятор Java JDT — Jasper 2 может использовать Eclipse, JDT (Средства разработки Java) компилятор Java вместо Apache Ant Ant и JAVAC.

Некоторые из свободных ресурсов и объединений Apache Tomcat включают Tomcatexpert.com (а SpringSource спонсорское сообщество разработчиков и операторов, которые работают с Apache Tomcat в крупномасштабных производственных средах) и Apache Tomcat MuleSoft (который имеет учебные руководства по установке, обновлению, Настройка, мониторинг, устранение неполадок и крепления различные версии Tomcat).

nginx

nginx считается очень быстрым HTTP сервером. Вместо Apache или совместно с ним Nginx используют, чтобы ускорить обработку запросов и уменьшить нагрузку на сервер. Дело в том, что огромные возможности, заложенные модульной архитектурой Apache, большинству пользователей не требуются. Платить же за эту невостребованную функциональность приходится значительным расходом системных ресурсов. Для обычных сайтов, как правило, характерно явное «засилье» статичных файлов (изображений, файлов стилей, JavaScript), а не скриптов. Никакого специального функционала для передачи этих файлов посетителю ресурса не требуется, так как задача весьма проста. А, значит, и веб-сервер для обработки таких запросов должен быть простым и легковесным, как Nginx. Географическая классификация клиентов по их IP-адресу производится в nginx посредством специального модуля. Система Radix tree позволяет оперативно работать с IP-адресами, занимая минимум памяти.

Источник статьи: http://ru.bmstu.wiki/%D0%92%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80

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

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

Введение

Понятие «веб-сервер» может относиться как к аппаратной начинке, так и к программному обеспечению. Или даже к обеим частям, работающим совместно.

1. С точки зрения «железа», «веб-сервер» — это компьютер, который хранит файлы сайта (HTML-документы, CSS-стили, JavaScript-файлы, картинки и другие) и доставляет их на устройство конечного пользователя (веб-браузер и т.д.). Он подключён к сети Интернет и может быть доступен через доменное имя, подобное mozilla.org .
2. С точки зрения ПО, веб-сервер включает в себя несколько компонентов, которые контролируют доступ веб-пользователей к размещённым на сервере файлам, как минимум — это HTTP-сервер. HTTP-сервер — это часть ПО, которая понимает URL-адреса (веб-адреса) и HTTP (протокол, который ваш браузер использует для просмотра веб-страниц).

На самом базовом уровне, когда браузеру нужен файл, размещённый на веб-сервере, браузер запрашивает его через HTTP-протокол. Когда запрос достигает нужного веб-сервера («железо»), сервер HTTP (ПО) принимает запрос, находит запрашиваемый документ (если нет, то сообщает об ошибке 404) и отправляет обратно, также через HTTP.

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

Статический веб-сервер, или стек, состоит из компьютера («железо») с сервером HTTP (ПО). Мы называем это «статикой», потому что сервер посылает размещённые файлы в браузер «как есть».

Динамический веб-сервер состоит из статического веб-сервера и дополнительного программного обеспечения, чаще всего сервера приложения и базы данных. Мы называем его «динамическим», потому что сервер приложений изменяет исходные файлы перед отправкой в ваш браузер по HTTP.

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

Активное изучение

Погружаемся глубже

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

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

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

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

• всегда запущен и работает
• всегда подключён к Интернету
• имеет неизменный IP адрес (не все провайдеры предоставляют статический IP-адрес для домашнего подключения)
• обслуживается третьей, сторонней компанией

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

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

Связь по HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP (англ. Hypertext Transfer Protocol — гипертекстовый транспортный протокол). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

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

Все команды являются простым человекочитаемым текстом.

Не сохраняет состояние

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

HTTP задаёт строгие правила взаимодействия клиента и сервера. Мы рассмотрим сам протокол HTTP в технической статье немного позднее. Пока достаточно знать об этих правилах:

• Исключительно клиенты могут производить HTTP-запросы, и только на сервера. Сервера способны только отвечать на HTTP-запросы клиента.
• При запросе файла по HTTP, клиент должен сформировать файловый URL.
• Веб-сервер должен ответить на каждый HTTP-запрос, по крайней мере сообщением об ошибке.

На веб-сервере HTTP-сервер отвечает за обработку входящих запросов и ответ на них.

1. При получении запроса, HTTP-сервер сначала проверяет, существует ли ресурс по данному URL.
2. Если это так, веб-сервер отправляет содержимое файла обратно в браузер. Если нет, сервер приложения генерирует необходимый ресурс.
3. Если ничто из этого не возможно, веб-сервер возвращает сообщение об ошибке в браузер, чаще всего “404 Not Found”. (Это ошибка настолько распространена, что многие веб-дизайнеры тратят большое количество времени на разработку 404 страниц об ошибках.)

Статический и Динамический контент

Грубо говоря, сервер может отдавать статическое или динамическое содержимое. «Статическое» означает «отдаётся как есть». Статические веб-сайты делаются проще всего, поэтому мы предлагаем вам сделать свой первый сайт статическим.

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

Возьмём для примера страницу, которую вы сейчас читаете. На веб-сервере, где она хостится, есть сервер приложения, который извлекает содержимое статьи из базы данных, форматирует его, добавляет в HTML-шаблоны и отправляет вам результат. В нашем случае, сервер приложения называется Kuma, написан он на языке программирования Python (используя фреймворк Django). Команда Mozilla создала Kuma для конкретных нужд MDN, но есть множество подобных приложений, построенных совершенно на других технологиях.

Существует так много серверов приложений, что довольно трудно предложить какой-то один. Некоторые серверы приложений заточены под определённые категории веб-сайтов, такие как блоги, вики-страницы или интернет-магазины; другие, называемые CMSs (системы управления контентом), более универсальны. Если вы создаёте динамический сайт, потратьте немного времени на выбор инструмента, который соответствует вашим потребностям. Если вы не хотите изучать веб-программирование (хотя это увлекательно само по себе!), то вам не нужно создавать свой собственный сервер приложения. Это будет изобретением очередного велосипеда.

Следующие шаги

Теперь, когда вы познакомились с веб-серверами, вы можете:

Источник статьи: http://developer.mozilla.org/ru/docs/Learn/Common_questions/What_is_a_web_server

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

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

Введение

Понятие «веб-сервер» может относиться как к аппаратной начинке, так и к программному обеспечению. Или даже к обеим частям, работающим совместно.

1. С точки зрения «железа», «веб-сервер» — это компьютер, который хранит файлы сайта (HTML-документы, CSS-стили, JavaScript-файлы, картинки и другие) и доставляет их на устройство конечного пользователя (веб-браузер и т.д.). Он подключён к сети Интернет и может быть доступен через доменное имя, подобное mozilla.org .
2. С точки зрения ПО, веб-сервер включает в себя несколько компонентов, которые контролируют доступ веб-пользователей к размещённым на сервере файлам, как минимум — это HTTP-сервер. HTTP-сервер — это часть ПО, которая понимает URL-адреса (веб-адреса) и HTTP (протокол, который ваш браузер использует для просмотра веб-страниц).

На самом базовом уровне, когда браузеру нужен файл, размещённый на веб-сервере, браузер запрашивает его через HTTP-протокол. Когда запрос достигает нужного веб-сервера («железо»), сервер HTTP (ПО) принимает запрос, находит запрашиваемый документ (если нет, то сообщает об ошибке 404) и отправляет обратно, также через HTTP.

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

Статический веб-сервер, или стек, состоит из компьютера («железо») с сервером HTTP (ПО). Мы называем это «статикой», потому что сервер посылает размещённые файлы в браузер «как есть».

Динамический веб-сервер состоит из статического веб-сервера и дополнительного программного обеспечения, чаще всего сервера приложения и базы данных. Мы называем его «динамическим», потому что сервер приложений изменяет исходные файлы перед отправкой в ваш браузер по HTTP.

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

Активное изучение

Погружаемся глубже

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

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

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

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

• всегда запущен и работает
• всегда подключён к Интернету
• имеет неизменный IP адрес (не все провайдеры предоставляют статический IP-адрес для домашнего подключения)
• обслуживается третьей, сторонней компанией

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

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

Связь по HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP (англ. Hypertext Transfer Protocol — гипертекстовый транспортный протокол). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

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

Все команды являются простым человекочитаемым текстом.

Не сохраняет состояние

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

HTTP задаёт строгие правила взаимодействия клиента и сервера. Мы рассмотрим сам протокол HTTP в технической статье немного позднее. Пока достаточно знать об этих правилах:

• Исключительно клиенты могут производить HTTP-запросы, и только на сервера. Сервера способны только отвечать на HTTP-запросы клиента.
• При запросе файла по HTTP, клиент должен сформировать файловый URL.
• Веб-сервер должен ответить на каждый HTTP-запрос, по крайней мере сообщением об ошибке.

На веб-сервере HTTP-сервер отвечает за обработку входящих запросов и ответ на них.

1. При получении запроса, HTTP-сервер сначала проверяет, существует ли ресурс по данному URL.
2. Если это так, веб-сервер отправляет содержимое файла обратно в браузер. Если нет, сервер приложения генерирует необходимый ресурс.
3. Если ничто из этого не возможно, веб-сервер возвращает сообщение об ошибке в браузер, чаще всего “404 Not Found”. (Это ошибка настолько распространена, что многие веб-дизайнеры тратят большое количество времени на разработку 404 страниц об ошибках.)

Статический и Динамический контент

Грубо говоря, сервер может отдавать статическое или динамическое содержимое. «Статическое» означает «отдаётся как есть». Статические веб-сайты делаются проще всего, поэтому мы предлагаем вам сделать свой первый сайт статическим.

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

Возьмём для примера страницу, которую вы сейчас читаете. На веб-сервере, где она хостится, есть сервер приложения, который извлекает содержимое статьи из базы данных, форматирует его, добавляет в HTML-шаблоны и отправляет вам результат. В нашем случае, сервер приложения называется Kuma, написан он на языке программирования Python (используя фреймворк Django). Команда Mozilla создала Kuma для конкретных нужд MDN, но есть множество подобных приложений, построенных совершенно на других технологиях.

Существует так много серверов приложений, что довольно трудно предложить какой-то один. Некоторые серверы приложений заточены под определённые категории веб-сайтов, такие как блоги, вики-страницы или интернет-магазины; другие, называемые CMSs (системы управления контентом), более универсальны. Если вы создаёте динамический сайт, потратьте немного времени на выбор инструмента, который соответствует вашим потребностям. Если вы не хотите изучать веб-программирование (хотя это увлекательно само по себе!), то вам не нужно создавать свой собственный сервер приложения. Это будет изобретением очередного велосипеда.

Следующие шаги

Теперь, когда вы познакомились с веб-серверами, вы можете:

Источник статьи: http://developer.mozilla.org/ru/docs/Learn/Common_questions/What_is_a_web_server

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Создаем свой сайт. Как устроен и работает веб-сервер

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

HTTP-сервер

На заре развития интернета сайты представляли собой простое хранилище специальным образом размеченных документов и некоторых связанных с ними данных: файлов, изображений и т.п. Для того, чтобы документы могли ссылаться друг на друга и связанные данные был предложен специальный язык гипертекстовой разметки HTML, а для доступа к таким документам посредством сети интернет протокол HTTP. И язык, и протокол, развиваясь и совершенствуясь, дожили до наших дней без существенных изменений. И только начавший приходить на смену принятому в 1999 году протоколу HTTP/1.1 протокол HTTP/2 несет кардинальные изменения с учетом требований современной сети.

Протокол HTTP реализован по клиент-серверной технологии и работает по принципу запрос-ответ без сохранения состояния. Целью запроса служит некий ресурс, который определяется единым идентификатором ресурса — URI ( Uniform Resource Identifier), HTTP использует одну из разновидностей URI — URL (Uniform Resource Locator) — универсальный указатель ресурса, который помимо сведений о ресурсе определяет также его физическое местоположение.

Задача HTTP-сервера обработать запрос клиента и либо выдать ему требуемый ресурс, либо сообщить о невозможности это сделать. Рассмотрим следующую схему:

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

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

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

Сайты того времени вообще мало походили на современные, например, ниже показан вид одного из пионеров русскоязычного интернета, сайт компании Rambler:

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

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

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

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

Стоит отметить, что SSI активно применяется и сегодня, там, где в код страницы нужно вставить некий статический контент, прежде всего благодаря простоте и нетребовательности к ресурсам.

Следующим шагом в развитии веб-технологии стало появление специальных программ (скриптов) выполняющих обработку запроса пользователей на стороне сервера. Чаще всего они пишутся на скриптовых языках, первоначально это был Perl, сегодня пальму лидерства удерживает PHP. Постепенно возник целый класс программ — системы управления контентом — CMS (Content management system), которые представляют полноценные веб-приложения способные обеспечить динамическую обработку запросов пользователя.

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

Однако сервер приложений не умеет работать с протоколом HTTP и обрабатывать пользовательские запросы, так как это задача веб-сервера. Чтобы обеспечить их взаимодействие был разработан общий интерфейс шлюза — CGI (Common Gateway Interface).

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

Для передачи данных используются стандартные потоки ввода-вывода, от веб-сервера к СGI-приложению данные передаются через stdin, принимаются назад через stdout, для передачи сообщений об ошибках используется stderr.

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

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

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

К достоинствам CGI можно отнести языковую и архитектурную независимость: CGI-приложение может быть написано на любом языке и одинаково хорошо работать с любым веб-сервером. Учитывая простоту и открытость стандарта это привело к бурному развитию веб-приложений.

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

На текущий момент CGI практически не применяется, так как ему на смену пришли более совершенные технологии.

FastCGI

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

FastCGI устраняет основную проблему CGI — повторный запуск процесса веб-приложения на каждый запрос, FastCGI процессы запущены постоянно, что позволяет существенно экономить время и ресурсы. Для передачи данных вместо стандартных потоков используются UNIX-сокеты или TCP/IP, что позволяет размещать веб-сервер и сервера приложений на разных хостах, таким образом обеспечивая масштабирование и/или высокую доступность системы.

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

Для управления FastCGI процессами и распределением нагрузки служат менеджеры процессов, они могут быть как частью веб-сервера, так и отдельными приложениями. Популярные веб-сервера Apache и Lighttpd имеют встроенные менеджеры FastCGI процессов, в то время как Nginx требует для своей работы c FastCGI внешний менеджер.

PHP-FPM и spawn-fcgi

Из внешних менеджеров для FastCGI процессов применяются PHP-FPM и spawn-fcgi. PHP-FPM первоначально был набором патчей к PHP от Андрея Нигматулина, решавший ряд вопросов управления FastCGI процессами, начиная с версии 5.3 является частью проекта и входит в поставку PHP. PHP-FPM умеет динамически управлять количеством процессов PHP в зависимости от нагрузки, перезагружать пулы без потери запросов, аварийный перезапуск сбойных процессов и представляет собой достаточно продвинутый менеджер.

Spawn-fcgi является частью проекта Lighttpd, но в состав одноименного веб-сервера не входит, по умолчанию Lighttpd использует собственный, более простой, менеджер процессов. Разработчики рекомендуют использовать его в случаях, когда вам нужно управлять FastCGI процессами расположенными на другом хосте, либо требуются расширенные настройки безопасности.

Внешние менеджеры позволяют изолировать каждый FastCGI процесс в своем chroot (смена корневого каталога приложения без возможности доступа за его пределы), отличном как от chroot иных процессов, так и от chroot веб-сервера. И, как мы уже говорили, позволяют работать с FastCGI приложениями расположенными на других серверах через TCP/IP, в случае локального доступа следует выбирать доступ через UNIX-сокет, как быстрый тип соединения.

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

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

SCGI, PCGI, PSGI, WSGI и прочие

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

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

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

SCGI (Simple Common Gateway Interface) — простой общий интерфейс шлюза — разработан как альтернатива CGI и во многом аналогичен FastCGI, но более прост в реализации. Все, о чем мы рассказывали применительно к FastGCI справедливо и для SCGI.

PCGI (Perl Common Gateway Interface) — библиотека Perl для работы с интерфейсом CGI, долгое время являлась основным вариантом работы с Perl-приложениями через CGI, отличается хорошей производительностью (насколько это применимо к CGI) при скромных потребностях в ресурсах и неплохой защиты от перегрузки.

PSGI (Perl Web Server Gateway Interface) — технология взаимодействия веб-сервера и сервера приложений для Perl. Если PCGI представляет собой инструмент для работы с классическим CGI интерфейсом, то PSGI более напоминает FastCGI. PSGI-сервер представляет среду для выполнения Perl-приложений которая постоянно запущена в качестве службы и может взаимодействовать с веб-сервером через TCP/IP или UNIХ-сокеты и предоставляет Perl-приложениям те же преимущества, что и FastCGI.

WSGI (Web Server Gateway Interface) — еще один специфичный интерфейс шлюза, предназначенный для взаимодействия веб-сервера с сервером приложений для программ, написанных на языке Phyton.

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

Сервер приложений как модуль Apache

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

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

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

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

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

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

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

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

Второе преимущество — производительность. Снова огорчим поклонников Nginx, благодаря работе в едином адресном пространстве, по производительности сервера приложений Apache + mod_php всегда будет на 10-20% быстрее любого иного веб-сервера + FastCGI (или иное CGI решение). Но также следует помнить, что скорость работы сайта обусловлена не только производительностью сервера приложений, но и рядом иных условий, в которых альтернативные веб-сервера могут показывать значительно лучший результат.

Но есть еще одно, достаточно серьезное преимущество, это возможность настройки сервера приложений на уровне отдельного сайта или пользователя. Давайте вернемся немного назад: в FastCGI/CGI схемах сервер приложений — это отдельная служба, со своими, отдельными, настройками, которая даже может работать от имени другого пользователя или на другом хосте. С точки зрения администратора одиночного сервера или какого-нибудь крупного проекта — это отлично, но для пользователей и администраторов хостинга — не очень.

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

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

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

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

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

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

Заключение

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник статьи: http://interface31.ru/tech_it/2016/03/kak-ustroen-i-rabotaet-web-server.html

Веб-сервер — Web server

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

A веб-сервер — это серверное программное обеспечение или аппаратное обеспечение, предназначенное для запуска этого программного обеспечения, которое может удовлетворить запросы клиента в World Wide Web. Веб-сервер, как правило, может содержать один или несколько веб-сайтов. Веб-сервер обрабатывает входящие сетевые запросы через HTTP и несколько других связанных протоколов.

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

Для веб-сайта с высокой посещаемостью может использоваться несколько веб-серверов; здесь серверы Dell устанавливаются вместе и используются для Wikimedia Foundation.

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

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

Многие общие веб-серверы также поддерживают сценарии на стороне сервера с использованием Active Server Pages (ASP), PHP (препроцессор гипертекста) или других языки сценариев. Это означает, что поведение веб-сервера может быть записано в отдельных файлах, в то время как фактическое программное обеспечение сервера остается неизменным. Обычно эта функция используется для генерации HTML-документов динамически («на лету»), а не для возврата статических документов. Первый в основном используется для получения или изменения информации из баз данных. Последние обычно намного быстрее и проще кэшировать, но не могут доставлять динамический контент.

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

Содержание

• 1 История
• 2 Трансляция пути
• 3 Веб-серверы в режиме ядра и в режиме пользователя
• 4 Ограничения нагрузки
  • 4.1 Причины перегрузки
  • 4.2 Симптомы перегрузки
  • 4.3 Методы защиты от перегрузки
• 5 Доля рынка
  • 5.1 Февраль 2019
  • 5.2 Июль 2018
  • 5,3 Февраль 2017
  • 5.4 Февраль 2016
• 6 См. Также
• 7 Ссылки
• 8 Внешние ссылки

История

В марте 1989 года сэр Тим Бернерс-Ли предложил новый проект для своего работодателя CERN с целью облегчения обмена информацией между учеными с помощью системы гипертекста. В результате проекта Бернерс-Ли написал две программы в 1990 году:

• A Веб-браузер под названием WorldWideWeb
• Первый в мире веб-сервер, позже известный как CERN httpd, который работал на NeXTSTEP

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

В 1994 году Бернерс-Ли решил создать Консорциум Всемирной паутины (W3C) для регулирования дальнейшего развития множества задействованных технологий (HTTP, HTML и т. Д.) В процессе стандартизации.

Преобразование пути

Веб-серверы могут отображать компонент пути в унифицированном указателе ресурсов (URL) в:

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

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

Рассмотрим следующий URL в том виде, в каком он будет запрошен клиентом по HTTP:

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

Веб-сервер на www.example.com добавит указанный путь к пути своего корневого каталога. На сервере Apache это обычно / home / www (на машинах Unix обычно / var / www ). Результатом является ресурс локальной файловой системы:

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

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

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

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

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

Веб-сервер (программа) имеет определенные ограничения нагрузки, поскольку он может обрабатывать только ограниченное количество одновременных клиентских подключений (обычно от 2 до 80 000, по умолчанию от 500 до 1000) на IP-адрес (и порт TCP), и он может обслуживать только определенное максимальное количество запросов в секунду (RPS, также известное как запросов в секунду или QPS) в зависимости от:

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

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

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

В любой момент веб-серверы могут быть перегружены из-за:

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

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

Симптомы перегруженного веб-сервера:

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

Методы защиты от перегрузки

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

• Управление сетевым трафиком с помощью:
  • межсетевых экранов для блокировки нежелательного трафика, исходящего от плохих IP-источников или имеющего плохие шаблоны
  • HTTP-менеджеров трафика, которые нужно отбросить, перенаправляйте или перезаписывайте запросы с плохими шаблонами HTTP
  • Управление полосой пропускания и формирование трафика, чтобы сгладить пики использования сети
• Развертывание сети методы кеширования
• Использование разных доменных имен или IP-адресов для обслуживания различного (статического и динамического) контента отдельными веб-серверами, например:
  • http: //images.example.com
  • http://example.com
• Использование разных доменных имен или компьютеров для отделения больших файлов от файлов малого и среднего размера; идея состоит в том, чтобы иметь возможность полностью кэшировать файлы малого и среднего размера и эффективно обслуживать большие или огромные (более 10 — 1000 МБ) файлы с помощью различных настроек
• Использование множества интернет-серверов (программ) на компьютер, каждый из которых привязан к своей собственной сетевой карте и IP-адресу
• Использование множества интернет-серверов (компьютеров), сгруппированных вместе за балансировщиком нагрузки чтобы они действовали или рассматривались как один большой веб-сервер
• Добавление дополнительных аппаратных ресурсов (т.е. RAM, дисков ) на каждый компьютер
• Настройка Параметры ОС для аппаратных возможностей и использования
• Использование более эффективных компьютерных программ для веб-серверов и т. Д.
• Использование других обходных путей, особенно если динамический контент участвует

доля рынка

Февраль 2019 г.

Ниже представлены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов на Интернет компанией W3Techs Использование веб-серверов для веб-сайтов.

Все остальные веб-серверы используются менее чем 1% веб-сайтов.

Июль 2018 г.

Ниже приведены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов в Интернете по данным W3Techs Использование веб-серверов для веб-сайтов.

Все остальные веб-серверы используются менее чем на 1% веб-сайтов.

Февраль 2017 г.

Ниже приведены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов в Интернете по Netcraft Обзор веб-серверов за февраль 2017 г..

февраль 2016

Ниже приведены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов в Интернете по Netcraft февраль Обзор веб-серверов 2016.

Apache, IIS и Nginx — наиболее часто используемые веб-серверы во всемирной паутине.

Источник статьи: http://ru.wikibrief.org/wiki/Web_server

Туториал по написанию собственного веб-сервера

Интернет играет в нашей жизни большую роль. Мы берем почту, узнаем свежую информацию, отлавливаем своих знакомых через ICQ… Но что ассоциируется со словом Интернет у большинства людей в первую очередь? Сайты. Многие при слове «Интернет» вспоминают свои любимые сайты, а некоторые (не слишком продвинутые) ставят знак равенства между WWW и Интернетом, хотя в последнем есть много другого интересного: email, IRC, p2p-сети, MUD’ы и так далее. Но World Wide Web играет доминирующую роль .

В основе WWW лежит протокол HyperText Transfer Protocol. Надо сказать, что HTTP может использоваться не только для передачи сайтов, но и для передачи всего чтобы то ни было. С помощью протокола HTTP мы можем скачать, например, недавно вышедший фильм или свежие mp3 :). В p2p-сетях HTTP-протокол применяется именно в этих целях.

В данном пособии мы рассмотрим, как написать простой веб-сервер. Я предполагаю, что вы знакомы с основами программирования winsock и умеете создавать сокеты и коннектиться к чему-нибудь :).

Основы HyperText Transfer Protocol

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

— вид запроса. Основных два: GET и POST. Друг от друга они отличаются, главным образом, способом передачи дополнительной информации, отсылающейся вместе с запросом. В этом туториале мы рассмотрим только метод GET — функционально он похож на POST, но несколько проще. О методе POST я расскажу во второй части данного туториала, если, конечно, таковая вообще появится на свет :).

— это два байта 0Dh, 0Ah, несомненно, хорошо знакомые всем ассемблерщикам :).

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

Теперь нам нужно задать . Возьмем типичную ссылка на одном из лучших сайтов по программированию в Рунете WASM.RU (немного рекламы не помешает 🙂 ):

Здесь «http://» указывает на то, что используется протокол HTTP, «www.wasm.ru» говорит о том, что необходимо подсоединиться к сайту www.wasm.ru, а все, что идет после знака вопроса — это дополнительные параметры страницы. Последние используются не всегда и не на всех сайтах.

Предположим, что мы подсоединились к www.wasm.ru и хотим получить article.php с необходимыми параметрами. Очевидно, что раз мы уже подсоединились к данному серверу и знаем, что необходимо использовать протокол HTTP, то пересылать «http://www.wasm.ru» не нужно, а значит, мы пошлем только «/article.php?article=1016002». Теперь наш запрос к серверу выглядит так:

Теперь осталось разобраться с заголовочными полями. С их помощью клиент передает дополнительную информацию о себе или характере запроса. Например, довольно часто используемым заголовочным полем является ‘User-Agent’. Опера, скажем, шлет следующее:

User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 6.02 [en]

Другим еще более важным полем является ‘Host’. В нем задается имя веб-сервера, с которого мы хотим получить документ. «Как же так», — можете сказать вы, — «Ведь мы же уже указывали имя веб-сервера, когда создавали сокет и коннектились к нему!» Да, это так. Когда мы коннектились к серверу, мы вызвали функцию gethostbyname, которой передали имя веб-сервера, а она возвратила нам адрес структуры, содержащей адрес сервера. Дело в том, что одному IP-адресу может соответствовать несколько имен сайтов, поэтому когда веб-сервер получает запрос, он должен знать к какому сайту обращается клиент (один веб-сервер может обслуживать тысячи различных сайтов, которые физически будут расположены на одной машине с одним адресом). Для этого мы пишем в ‘Host’ адрес сайта, к которому обращаемся:

Вот как теперь выглядит наш запрос:

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

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

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

Если коды ответов жестко заданы стандартом (200 означает, что запрос был успешно обработан и будет возвращен соответствующий документ/информация), то зависит только от вашей фантазии (конечно, по смыслу оно должно совпадать с . Например, вместо «HTTP/1.1 200 Ok» мы можем послать «HTTP/1.1 200 You want it, you’ll get it» :).

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

Content-Type — этот заголовок задает тип отдаваемых данных. Главнейшие типы заданы в стандарте, и от того, что вы напишите в данном поле, зависит поведение клиента при приеме данных. Например, если вы посылаете браузеру пользователя html-файл, то необходимо указать тип данных ‘text/html’, иначе браузер может отобразить файл неправильно, либо вообще не будет его отображать, а предложит пользователю его скачать.

Content-Length — здесь указывается длина данных (не включая сам ответ с заголовочными данными) в байтах.

Исходя из вышесказанного, ответ сервера будет выглядеть примерно так:

Если мы хотим отослать простой html-файл, то можем сократить ответ до следующего:

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

Сервер получает этот запрос, обрабатывает и выдает корневую страницу:

Код приложения

Анализ кода

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

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

Самое интересное находится в http_window.asm. При обработке сообщения WM_CREATE мы создаем сокет:

А потом вызываем следующую функцию:

Вот что об этой функции говорит Platform SDK:

[ начало описания функции WSAAsynctSelect ]

Функция WSAAsyncSelect указывает Windows посылать сообщения о событиях, касающихся определенного сокета.

s — Дескриптор сокета, о событиях, связанных с которым, будет сообщаться.

hWnd — Хэндл окна, которому будут посылаться эти сообщения.

wMsg — Сообщение, которое будет посылаться.

lEvent — Битовая маска, в которой задаются интересующие события.

Если вызов функции WSAAsyncSelect прошел успешно, возвращаемое значение будет равно нулю. В противном случае будет возвращено SOCKET_ERROR, а код ошибки можно будет получить, вызвав WSAGetLastError.

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

Мы задаем WM_SOCKET, определенное в http.asm, в качестве сообщение, которое будет присылаться Windows, когда произойдет интересующее нас сообщение. Необходимая информация будет находиться в wParam (дескриптор сокета, с которым связано событие) и в lParam (в нижнем слове — код события).

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

Веб-сервер будет «висеть» на localhost’е (т.е. на локальной машине) на 80-ом порту, который является стандартным HTTP-портом. Если в адресе сайта прямо не указан порт, то браузер будет обращаться к 80-ому порту.

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

[ начало описания функции listen ]

Функция listen устанавливает сокет в состояние, в котором он слушает порт на предмет входящих соединений.

backlog — Максимальное количество входящих соединений.

Если во время вызова не произошло никакой ошибки, listen возвратит ноль. В противном случае будет возвращено значение SOCKET_ERROR, а код ошибки можно будет получить с помощью функции WSAGetLastError.

Было получено сообщение WM_SOCKET. Это значит, что произошло какое-то интересующее нас событие, связанное со слушающим сокетом.

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

[ начало описания функции accept ]

Функция accept разрешает входящее соединение.

s — Дескриптор сокета, который ранее был помещен в состояние прослушивания с помощью функции listen. Фактическое соединение осуществляется с помощью сокета, который возвращается accept’ом.

addr — Необязательный указатель на буфер, который получит адрес того, кто пытается подсоединиться к серверу.

addrlen — Необязательный указатель на двойное слово, которое содержит длину addr.

Если не произошло никакой ошибки, accept возвратит дескриптор нового сокета, через который и будет происходить соединение.

В противном случае будет возвращен INVALID_SOCKET, а код ошибки можно будет получить с помощью функции WSAGetLastError.

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

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

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

Если сокет был закрыт клиентом, то мы его тоже закрываем со своей стороны.

Для получения подробной информации о протоколе HTTP я рекомендую вам обратиться к RFC 2068.

Надеюсь, вы почерпнули из этого туториала какую-нибудь полезную информацию. Напоследок мне хотелось бы сказать, что хотя составлять конкуренцию таким грандам как Apache и IIS без веских на то оснований, возможно, и не стоит, тем не менее, собственный маленький веб-сервер может быть очень полезен. Мне, например, предложили встроить в него механизм самораспространения, «чтобы он сам приходил к людям на дом» и устанавливался «через упрощенную процедуру инсталляции» ака Outlook. Другим, менее чреватым в плане возможных последствий для автора, вариантом может быть создание утилиты удаленного (не обязательно скрытого) администрирования, причем в качестве клиента будет выступать браузер, что весьма удобно, так как отпадет надобность в написании сопутствующей серверу клиентской программы. Возможно, вы найдете еще какое-нибудь применение для http-сервера. Все в ваших руках!

Источник статьи: http://sciencestory.ru/tutorial-po-napisaniyu-veb-servera/

Веб-сервер

Программа, которая умеет отвечать на HTTP-запросы.

Кратко

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

Как понять

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

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

Веб-сервер работает по следующей схеме:

Сервер получает запросы от клиентов и отправляет им ответы. В основе работы веб-сервера лежит протокол HTTP.

Протокол HTTP

Протокол HTTP и модель OSI подробно описаны в статьях:

Протокол HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) работает с текстовыми сообщениями, которые пересылаются от клиента к серверу (HTTP-запрос) и обратно (HTTP-ответ). Структура сообщения следующая:

1. Стартовая строка (Starting line) говорит нам, запрос или ответ содержит сообщение;
2. Заголовки (Headers) описывают тело сообщения, параметры передачи и прочие сведения;
3. Тело сообщения (Message Body) содержит данные.

Стартовая строка

В стартовой строке запроса указывается метод, ссылка и версия протокола, разделённые пробелом, например:

1. Метод запроса;
2. Путь на сайте (тот, что указывается после доменного имени);
3. Протокол, который используется.

Методы HTTP-запроса устанавливают назначение запроса. Среди наиболее используемых GET , POST и OPTIONS . Когда вы набираете адрес в адресной строке браузера и переходите по ссылке, обычно вы пользуетесь методом GET , то есть методом для получения запрашиваемой информации. POST часто используется для отправки данных из форм, а OPTIONS — для определения набора методов на сервере, доступных по адресу.

Методы HTTP-запроса позволяют не только получать страницы по определённому адресу, но и организовывать обмен данными между клиентом и веб-сервером. Для этого могут использовать, например, REST API, о котором подробнее написано в статье «API. Что это и зачем нужно?».

Адрес, который вы вводите в адресной строке браузера, в протоколе HTTP определяется как URI (Uniform Resource Identifier), то есть последовательность символов, идентифицирующая абстрактный или физический ресурс.

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

Стартовая строка HTTP-ответа содержит:

1. информацию о версии протокола, как в запросе;
2. код состояния (Status Code), который однозначно определяет реакцию сервера на запрос;
3. пояснение (Reason Phrase) к коду ответа для пользователя (является необязательным).

Во время отладки веб-приложений вы часто будете встречать коды ответов 200 , 404 и 500 . Коды ответов, которые начинаются на 2xx , сервер возвращает, если запрос клиента был удачным. Запросы 4xx сообщают клиенту об ошибке, а 5xx — о том, что веб-сервер не справился с запросом клиента.

Вы всегда можете посмотреть коды ответов в справочнике «HTTP Status Codes».

Заголовки

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

Пример заголовков запроса:

Тело сообщения

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

Модули и расширения

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

Сжатие данных

Загрузка страниц будет происходить быстрее, если размер ответа сервера будет маленьким. Поэтому любой современный сервер содержит модуль сжатия. Перед отправкой клиенту данные запаковываются, а на стороне клиента распаковываются с помощью одного из алгоритмов сжатия. Долгое время для этого использовался формат сжатия gzip, и все популярные браузеры его поддерживают.

В последние годы браузеры стали поддерживать ещё два формата: zopfli и brotli. Наиболее перспективным и эффективным является brotli, он поддерживается всеми современными браузерами.

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

Шифрование данных

При передаче данных пользователей важно их шифровать. Интернет построен так, что пакеты данных пользователей проходят множество сетевых узлов, прежде чем окажутся на целевом устройстве. Если данные не зашифрованы, то каждый из промежуточных узлов может просматривать их в открытом виде. Подробнее о безопасности использования Интернета написано в статье «Безопасность веб-приложений и распространённые атаки».

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

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

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

Проксирование

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

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

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

Аутентификация и авторизация

Идентификация — процесс присваивания какого-либо имени объекту (например, пользователю или программе). Когда человек покупает билет на поезд или самолёт, необходимо представиться. В этот момент он проходит процедуру идентификации.

Аутентификация — подтверждение подлинности объекта. При покупке билета или уже на стойке регистрации нужно предъявить паспорт, чтобы доказать, что это тот самый человек, на которого оформлен билет. То есть аутентифицировать — значит подтвердить идентификатор объекта.

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

С помощью заголовков в HTTP-сообщениях можно осуществлять аутентификацию и авторизацию пользователей. В современных системах всё чаще применяют более сложные способы аутентификации и авторизации, а этот способ называют базовым (basic auth).

Для аутентификации пользователей нужно отдать веб-серверу учётные данные пользователя, то есть представиться и предъявить пару имени пользователя и пароля в качестве доказательства, что это тот самый пользователь.

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

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

Пример заголовка для авторизации клиента на сервере:

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

Есть и другие способы аутентификации и авторизации, которые поддерживаются веб-сервером.

Кэширование

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

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

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

Источник статьи: http://doka.guide/tools/web-server/