Как работают web серверы. Веб-сервер (Web Server): для чего он нужен, как устроен и как работает В чем принцип работы сервера

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

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

Ниже мы расскажем о некоторых интересных и нетривиальных случаях.

Обнаружение неполадок

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

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

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

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

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

Примеры неполадок и способы их устранения

Сбой в работе сети на сервере

Существует вероятность, что после переноса дисков со сбойного сервера на резервный перестанет работать сеть на сервере. Это обычно происходит в случае использования операционных систем семейства Linux, например Debian или Ubuntu.

Дело в том, что при первоначальной установке операционной системы, MAC-адреса сетевых карт записываются в специальный файл, расположенный по адресу: /etc/udev/rules.d/70-persistent-net.rules.

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

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

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

Перенастройки IP-адресов после этого не требуется, сеть сразу начнет работать.

Плавающая проблема с зависаниями

Однажды к нам на диагностику поступил сервер с проблемой случайных зависаний в процессе работы. Проверили логи BIOS и IPMI - пусто, никаких ошибок. Поставили на стресс-тестирование, нагрузив все ядра процессора на 100%, с одновременным контролем температуры - завис намертво через 30 минут работы.

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

Далее следовало исключить вероятные сбои модулей оперативной памяти, поэтому поставили сервер на тест памяти с помощью достаточно популярного Memtest86+. Минут через 20 сервер ожидаемо завис, выдав ошибки по одному из модулей оперативной памяти.

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

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

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

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

Мнимое зависание сервера при установке ОС

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

К нам обратился пользователь с жалобой на зависание сервера при попытке установки операционной системы Windows Server 2008 R2. После успешного запуска инсталлятора, сервер прекращал реагировать на мышь и клавиатуру в KVM-консоли. Для локализации проблемы подключили к серверу физическую мышь и клавиатуру - все то же самое, инсталлятор запускается и перестает реагировать на устройства ввода.

На тот момент этот сервер у нас был одним из первых на базе материнской платы X11SSL-f производства Supermicro. В настройках BIOS был один интересный пункт Windows 7 install, выставленный в Disable. Поскольку Windows 7, 2008 и 2008 R2 разворачиваются на одном и том же инсталляторе, выставили этот параметр в Enable и чудесным образом мышь и клавиатура наконец-то заработали. Но это было лишь только начало эпопеи с установкой операционной системы.

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

Википедия сообщила, что проблема решается отключением в BIOS поддержки USB 3.0 (XHCI-контроллера). Когда мы открыли документацию к материнской плате, нас ожидал сюрприз - разработчики решили полностью отказаться от контроллера EHCI (Enhanced Host Controller Interface) в пользу XHCI (eXtensible Host Controller Interface). Иными словами, все порты USB на этой материнской плате являются портами USB 3.0. И если отключить контроллер XHCI, то мы этим самым отключим и устройства ввода, сделав невозможным работу с сервером и соответственно установку операционной системы.

Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы. Только интегрировав драйвера контроллера USB 3.0 и пересобрав установочный образ, мы смогли установить Windows Server 2008 R2 на этот сервер, а этот случай вошел в нашу базу знаний, чтобы инженеры не тратили лишнее время на бесплодные попытки.

Еще забавнее бывают случаи, когда клиенты привозят нам оборудование на размещение, а оно ведет себя не так, как ожидается. Именно так и произошло с дисковой полкой линейки Dell PowerVault.

Устройство представляет собой систему хранения данных c двумя дисковыми контроллерами и сетевыми интерфейсами для работы по протоколу iSCSI. Помимо этих интерфейсов присутствует MGMT-порт для удаленного управления.

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

• «iLO» у Hewlett-Packard;
• «iDrac» у Dell;
• IPMI у Supermicro.

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

Для ограничения скорости порт просто настраивается как 10BASE-T и включается в работу, имея максимальную скорость в 10 Мбит/с. После того, как все было готово - мы подключили MGMT-порт дисковой полки, но клиент почти сразу сообщил, что у него ничего не работает.

Проверив состояние порта коммутатора, мы обнаружили неприятную надпись «Physical link is down». Такая надпись говорит, что имеется проблем с физическим соединением между коммутатором и подключенным в него клиентским оборудованием.

Плохо обжатый коннектор, сломанный разъем, перебитые жилы в кабеле - вот небольшой перечень проблем, которые приводят именно к отсутствию линка. Разумеется, наши инженеры сразу взяли тестер витой пары и проверили соединение. Все жилы идеально прозванивались, оба конца кабеля были обжаты идеально. К тому же, включив в этот кабель тестовый ноутбук, мы получили как и положено соединение со скоростью 10 Мбит/с. Стало ясно, что проблема на стороне оборудования клиента.

Поскольку мы всегда стараемся помочь нашим клиентам в решении проблем, решили разобраться, что именно вызывает отсутствие линка. Внимательно изучили разъем порта MGMT - все в порядке.

Нашли на сайте производителя оригинальную инструкцию по эксплуатации, чтобы уточнить - возможно ли со стороны программного обеспечения «погасить» данный порт. Однако такой возможности не предусматривалось - порт в любом случае поднимался автоматически. Несмотря на то, что подобное оборудование должно всегда поддерживать Auto-MDI(X) - иными словами правильно определять какой кабель включен: обычный или кроссовер, мы эксперимента ради обжали кроссовер и включили в тот же порт коммутатора. Пробовали принудительно выставлять параметр дуплекса на порту коммутатора. Эффект был нулевой - линка не было и идеи уже заканчивались.

Тут кто-то из инженеров высказал абсолютно противоречащее здравому смыслу предположение, что оборудование не поддерживает 10BASE-T и будет работать только на 100BASE-TX или даже на 1000BASE-X. Обычно любой порт, даже на самом дешевом устройстве совместим с 10BASE-T и вначале предположение инженера отмели как “фантастику”, но от безысходности решили попробовать переключить порт в 100BASE-TX.

Нашему удивлению не было предела, линк мгновенно поднялся. Чем именно обусловлено отсутствие поддержки 10BASE-T на порту MGMT остается загадкой. Такой случай - очень большая редкость, но имеет место быть.

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

Отказ турбин охлаждения

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

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

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

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

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

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

А где же диски?

В некоторых случаях причина проблемы порой настолько нетривиальна, что на ее поиск уходит очень большое количество времени. Так и получилось, когда один из наших клиентов пожаловался на случайный отвал дисков и зависание сервера. Аппаратная платформа - Supermicro в корпусе 847 (форм-фактора 4U) с корзинами для подключения 36-ти дисков. В сервере было установлено три одинаковых RAID-контроллера Adaptec, к каждому подключено по 12 дисков. В момент возникновения проблемы, сервер переставал видеть случайное количество дисков и зависал. Сервер вывели из продакшн и приступили к диагностике.

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

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

Переустановили контроллер в другой слот, заменили бэкплейн и SATA-кабели от контроллера до бэкплейна. Неделя тестов и снова диски выпали - сервер вновь завис. Обращение в поддержку Adaptec результатов не принесло - они проверили все три контроллера и проблем не обнаружили. Заменили материнскую плату, пересобрав платформу чуть ли не с нуля. Все, что вызывало малейшие сомнения заменили на новое. И проблема вновь проявилась. Мистика да и только.

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

Заключение

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

Вот такие забавные случаи были в нашей практике.
А с какими сталкивались вы? Добро пожаловать в комментарии.

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

Введение

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

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

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

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

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

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

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

Активное изучение пока не доступно. .

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

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

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

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

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

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

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

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

Связь по HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP (англ. H ypert ext T ransfer P rotocol - гипертекстовый транспортный протокол ). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если ежедневно используется компьютер, который подключен к сети, если на мобильном гаджете тоже подключен Интернет, то каждый пользователь время от времени сталкивается со словом – «сервер». Причем это слово может встречаться в разных сочетаниях, и не каждый пользователь понимает, о чем идет речь. Что же скрывается до словом «сервер», да и зачем он пользователям нужен?

Под понятием «сервер» может скрываться аппаратное устройство и программное обеспечение для него (аппаратный и виртуальный). Аппаратный сервер – это отдельный компьютер. Он нужен для обеспечения работы других ПК и офисной техники. Виртуальный сервер – это ПО. При этом конкретный сервер объединяет эти два вида.

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

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

Поломка сервера или сбой в его работе может закончиться катастрофой

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

Сервер обеспечивает выход в Сеть. Все сайты хранятся на серверах. Это обеспечивает виртуальный хостинг. Такую услугу предоставляют хостинговые компании.

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

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

Больше видео на нашем канале - изучайте интернет-маркетинг с SEMANTICA

Любой компьютер можно сделать сервером. Для этого нужно установить специальную оболочку.

Требования к технической части определяются количеством размещенных ресурсов и требованиями к скорости. Чем они больше, тем мощнее должен быть компьютер.
Чтобы было понятно, приведем аналогию. Вы заходите в библиотеку и просите выдать вам книгу. Библиотекарь находит нужную и передает вам. Библиотека - это сервер, в ней хранятся все данные. Библиотекарь - это оболочка, которая приняла запрос и направила ответ. Вы - клиент.
Можно отправить библиотекаря за дополнительной информацией – аналогично щелчку по ссылке. Разница в том, что один и тот же ресурс в интернете могут одновременно читать неограниченное число пользователей.
Обслуживание клиента производится по схожему принципу: приходя за книгой, мы можем задать вопрос библиотекарю (поисковая система) или заглянуть в указатель (ЯндексКаталог). Это помогает найти нужную информацию.

Что делает веб-сервер

Его главная задача – хранение информации. Страницы, файлы, изображения, текстовый контент.
Задачи:

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

Чтобы понять, как работает веб-сервер, надо иметь представление о принципах передачи информации в сети. В основе лежат правила, называемые протоколами: любой URL начинается с указания типа (ftp, http://, https:// и пр.).
Hyper Text Transfer Protocol – протокол передачи . Страницы сайта всегда имеют вид гипертекстового документа. Это конечный результат работы любой серверной или клиентской программы.

• Когда пользователь вводит адрес или нажимает ссылку, браузер передает запрос, кодируя информацию по этим правилам.
• Хост, к которому привязан этот адрес, запускает программы сервера. Каждая из них выполняет свои функции.
• Полученные данные расшифровываются, команды выполняются.
• Формируется гипертекст, кодируется и отправляется обратно.
• Браузер получает ответ, преобразовывает код в html и показывает на экране страницу.

Что нужно для веб-сервера

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

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

Когда решен вопрос с сервером, надо привязать к нему статический IP-адрес.

Сайт становится доступен на веб-сервере после того, как зарегистрировано доменное имя, выполнено преобразование адресов службой DNS - связывание IP-адреса (например, 111.111.111.111) и доменного имени (www.site.com).

Самые распространенные сервера

Apache

Это бесплатный, свободно распространяемый продукт, у которого есть масса преимуществ:

• Постоянная поддержка разработчиков.
• Модули для работы с серверными языками программирования PHP, Perl, Python, Ruby, ASP и т.д.
• Открытый код. Доработкой под свои нужды занимаются разные программисты. Например, русскоязычное сообщество адаптирует его к русской кодировке.
• . Изначально был создан под Unix, но сейчас поддерживается Windows, Mac OS, BSD, Linux, OS/2 и Novell NetWare.
• Безопасность.

При инсталляции укажите имя вашего хоста, например, localhost. В папку htdocs, которая лежит внутри папки Apachex.x (где x.x – номер версии) скопируйте любую html-страницу. Или создайте ее в блокноте, введя любой текст и сохранив с расширением html.

Когда в папке появился файл, откройте браузер и наберите адрес: localhost://ИМЯ СТРАНИЦЫ.html. На экране появится ваш текст – страница открыта с сервера. Если вы увидели ошибку «Не удается получить доступ к сайту», значит не запущен Apache. Его значок находится в трее.
Нажмите на него и выберите «Play». После этого все заработает.

NGNIX

Доля работающих на нем активных площадок составляет 21,13% (исследования Netcraft). Его в основном используют крупные компании и профессиональные разработчики: Yandex, Mail.ru, Rambler и пр. NGNIX выдерживает огромную нагрузку посетителей, надежен, безопасен и продуман.
Распространяется свободно, но появились платные версии Plus, стоимость от 2,500 $.

IIS

Его известность обеспечена громким именем разработчика. Представляет собой набор веб служб и интегрирован с Windows. Родной платформой программирования является ASP.NET, но можно внедрить и альтернативу, например, РНР.

Для полноценного хостинга требуется установка серверной операционной системы от Microsoft – Windows Server. 6-я версия вообще не была предназначена для хостинга, полноценная поддержка началась в 7-й. Приобретается он автоматически вместе с операционной системой и зависит от ее характеристик.

Установочные пакеты

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

• OpenServer. Портативная среда разработки, включающая множество баз данных, языков программирования и их версий, а также дополнительные сервисы. Например, интерфейс работы с БД PhpMyAdmin. На сегодняшний день это самый популярный инсталляционный набор. Работает даже с флешки. Бесплатно скачивается на низкой скорости. За 100 рублей скорость увеличивается в разы.
• Xampp. Активно поддерживаемый пакет: Apache, Php, Perl, MariaDB и пр. Имеет панель управления. Скачивается бесплатно.
• . Очень удобный набор всех нужных инструментов, включающий Apache, PHP, MySQL, PhpMyAdmin. К сожалению, последняя версия включает устаревшие дистрибутивы. В целом для обучения подойдут и они. Судя по форуму проект больше не поддерживается.

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

В общем - статья представляет собой глобальный обзор "что бывает". Без циферок.

Статья написана на основе опыта работы с серверами:

• Apache, Lighttpd, Nginx (на C)
• Tomcat, Jetty (на Java)
• Twisted (Python)
• Erlang OTP (язык Erlang)
• и операционными системами Linux, FreeBSD

Тем не менее, принципы достаточно общие, поэтому должны распространяться в каком-то виде на OS Windows, Solaris, и на большое количество других веб-серверов.

Цель веб-сервера

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

Работа с соединениями

С чего начинается обработка запроса? Очевидно - с приема соединения от пользователя.

Для этого в разных OS используются разные системные вызовы. Наиболее известный и медленный на большом количестве соединений - select . Более эффективные - poll, kpoll, epoll.

Современные веб-серверы постепенно отказываются от select.

Оптимизации ОС

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

• пока не пришли данные (dataready)
• пока не пришел целиком HTTP-запрос (httpready)

На момент написания статьи оба способа поддерживаются во FreeBSD (ACCEPT_FILTER_HTTP, ACCEPT_FITER_DATA), и только первый - в Linux (TCP_DEFER_ACCEPT).

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

Соединение принято

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

Во всех серверах используется асинхронный подход.

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

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

Основные стратегии работы с worker"ами

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

Тип worker"а

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

Процесс

Различные worker"ы могут быть процессами. В этом случае они не взаимодействуют между собой, и данные различных worker"а полностью независимы друг от друга.

Поток

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

Адресное пространство

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

Внутри сервера

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

Плюсом является отсутствие пересылки данных из одного адресного пространства в другое.

Снаружи сервера

Worker может быть запущен вообще независимо от сервера и принимать данные на обработку по специальному протоколу (например FastCGI).

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

Рождение worker"ов

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

Основных стратегий - две.

Статика

Количество рабочих может быть жестко фиксированно. Например, 20 рабочих процессов всего. Если же все рабочие заняты и приходит 21й запрос - сервер выдает код Temporary Unavailable - "временно недоступен".

Динамика

Для более гибкого управления ресурсами - рабочие могут порождаться динамически, в зависимости от загрузки. Алгоритм порождения рабочих может быть параметризован, например (Apache pre-fork), так:

• Минимальное количество свободных рабочих = 5
• Максимальное количество свободных рабочих = 20
• Всего рабочих не более = 30
• Начальное количество рабочих = 10

Чистка между запросами

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

Чистый

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

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

Персистентный

Никакой очистки состояния. В результате - экономия ресурсов.

Разбор типичных конфигураций

Посмотрим, как эти комбинации работают на примере различных серверов.

Apache (pre-fork MPM) + mod_php

Для обработки динамических запросов используется модуль php, работающий в контексте сервера.

• Процесс
• Внутри сервера
• Динамика
• Чистый

Apache (worker MPM) + mod_php

Для обработки динамических запросов используется модуль php, работающий в контексте сервера.

При этом, так как php работает в адресном пространстве сервера, разделяемые потоками данные периодически портятся, поэтому связка нестабильна и не рекомендована. Это происходит из-за ошибок в mod_php, который включает в себя ядро PHP и различные php-модули.

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

• Поток
• Внутри сервера
• Динамика
• Чистый

Apache (event mpm) + mod_php

Event MPM - это стратегия работы с worker"ами, которую использует только Apache. Все - точно так же, как с обычными потоками, но с небольшим дополнением для обработки Keep-Alive

Установка Keep-Alive служит для того, чтобы клиент мог прислать много запросов в одном соединении. Например, получить веб-страницу и 20 картинок. Обычно, worker заканчивает обработку запроса - и ждет какое-то время (keep-alive time), не последуют ли в этом соединении дополнительные запросы. То есть, просто висит в памяти.

Event MPM создает дополнительный поток, который берет на себя ожидание всех Keep-Alive запросов, освобождая рабочего для других полезных дел. В результате, общее количество worker"ов значительно сокращается, т.к никто теперь не ждет клиентов, а все работают.

• Поток
• Внутри сервера
• Динамика
• Чистый

Apache + mod_perl

Особенность связки Apache с mod_perl - в возможности вызывать Perl-процедуры по ходу обработки запроса апачем.

Благодаря тому, что mod_perl работает в одном адресном пространстве с сервером - он может регистрировать свои процедуры через Apache hooks, на разных стадиях работы сервера.

Например, можно работать на той же стадии, что и mod_rewrite, переписывая урл в хуке PerlTransHandler.

Следующий пример описывает rewrite с /example на /passed, но на перле.

# в конфиге апача при включенном mod_perl PerlModule MyPackage::Example PerlTransHandler MyPackage::Example # в файле MyPackage/Example.pm package MyPackage::Example use Apache::Constants qw(DECLINED); use strict; sub handler { my $r = shift; $r->uri("/passed") if $r->uri == "/example" return DECLINED; } 1;

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

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

• Процесс/поток - зависит от MPM
• Внутри сервера
• Динамика
• Персистентный

Twisted

Этот асинхронный сервер написан на Python. Его особенность - в том, что программист веб-приложения сам создает дополнительных рабочих и дает им задания. # пример кода на сервере twisted # долгая функция, обработка запроса def do_something_big(data): .... # в процессе обработки запроса d = deferToThread (do_something_big, "параметры") # привязать каллбеки на результат do_something_big d.addCallback(handleOK) # .. и на ошибку при выполнении do_something_big d.addErrback(handleError)

Здесь программист, получив запрос, использует вызов deferToThread для создания отдельного потока, которому поручено выполнить функцию do_something_big. При успешном окончании do_something_big, будет выполнена функция handleOK, при ошибке - handleError.

А текущий поток в это время продолжит обычную обработку соединений.

Все происходит в едином адресном пространстве, поэтому все рабочие могут разделять, например, один и тот же массив с пользователями. Поэтому на Twisted легко писать многопользовательские приложения типа чата.

• Поток
• Внутри сервера
• Динамика
• Персистентный

Tomcat, Servlets

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

• Поток
• Внутри сервера
• Динамика
• Персистентный

FastCGI

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

Есть два способа порождения таких worker"ов.

1. Интегрированный с сервером
2. Отдельный от сервера

В первом случае сервер сам создает внешние рабочие процессы и управляет их числом.

Во втором случае - для порождения рабочих процессов используется отдельный "spawner", второй, дополнительный сервер, который умеет общаться только по FastCGI-протоколу и управлять рабочими. Обычно spawner порождает рабочих в виде процессов, а не потоков. Динамика/Статика - определяется настройками spawner"а, а Чистый/Персистентный - характеристиками рабочего процесса.

Пути работы с FastCGI

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

получить запрос -> отдать на обработку в FastCGI -> подождать ответа -> отдать ответ клиенту.

Второй способ используют сервера типа lighttpd/nginx/litespeed/и т.п.

получить запрос -> отдать на обработку в FastCGI -> обработать других клиентов -> отдать ответ клиенту, когда придет.

Отмеченное отличие позволяет Lighttpd + fastcgi работать эффективнее, чем это делает Apache, т.к пока процесс Apache ждет - Lighttpd успевает обслужить другие соединения.

Режимы работы FastCGI

У FastCGI есть два режима работы.

• Responder - обычный режим, когда FastCGI принимает запрос и переменные, и возвращает ответ
• Authorizer - режим, когда FastCGI в качестве ответа разрешает или запрещает доступ. Удобно для контроля за закрытыми статическими файлами

Оба режима поддерживаются не во всех серверах. Например, в сервере Lighttpd - поддерживаются оба.

FastCGI PHP vs PERL

PHP-интерпретатор каждый раз очищает себя перед обработкой скрипта, а Perl - просто обрабатывает запросы один за другим в цикле вида:

Подключить модули; while (пришел запрос) { обработать его; print answer; } Поэтому Perl-FastCGI гораздо эффективнее там, где большУю часть времени выполнения занимают include вспомогательных модулей.

Резюме

В статье рассмотрена общая структура обработки запросов и виды worker"ов. Кроме того, заглянули в Apache Event MPM и способы работы с FastCGI, посмотрели сервлеты и Twisted.

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