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

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

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

Основное действие конечного пользователя в Интернете – это "переход на Web-страницу". На самом общем уровне это предполагает совместную работу пары приложений:

Web-браузера, такого как Firefox или Internet Explorer, который показывает в удобной для человеческого восприятия форме запрашиваемую страницу, которую он получает от…

Web-сервера, находящегося, как правило, на удалённой машине, который отвечает на запрос страницы потоком данных в формате HTML или аналогичном.

С браузерами имеют дело пользователи, которые подходят к их выбору и анализу с надлежащей тщательностью. Напротив, серверы видны только техническому персоналу сайтов. Более того, хотя существует множество различных Web-серверов, около 90% всех сайтов, согласно недавним исследованиям Netcraft, работают всего на двух из них - Apache и Internet Information Server (IIS). Оба эти сервера – тщательно проработанные продукты, обладающие не только очень длинным списком встроенных возможностей, но и процветающим "вторичным рынком" книг, дополнений, консультаций, провайдеров и т.д.

Web-сервер оценивается по целому ряду важнейших параметров:

Эффективность: как быстро он отвечает на запрос?

Масштабируемость: продолжает ли сервер работать надёжно, когда к нему одновременно обращаются много пользователей?

Безопасность: совершает ли сервер только те операции, которые должен? Какие возможности он предлагает для аутентификации пользователей и шифрования потока обмена информацией? Делает ли его использование более уязвимыми соседние приложения или хосты?

Работоспособность: какие у сервера режимы отказа и аварийные ситуации?

Соответствие стандартам.

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

Требования к платформе: на каких платформах возможно использование сервера? Предъявляет ли он особые требования к аппаратной платформе?

Управляемость: легко ли установить и обслуживать сервер? Совместим ли он с организационными стандартами по ведению журналов, аудиту, оценке затрат и т.д.?

Известные веб-серверы:

· Apache - свободный веб-сервер, наиболее часто используемый в UNIX-подобных операционных системах;

· IIS от компании Microsoft, распространяемый с серверными ОС семейства Windows

· nginx - свободный веб-сервер,

· lighttpd - свободный веб-сервер.

· Google Web Server - веб-сервер, основанный на Apache и доработанный компанией Google.

· Resin - свободный веб-сервер приложений.

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

· Rootage - веб-сервер, написанный на java.

· THTTPD - простой, маленький, быстрый и безопасный веб-сервер.

«Лёгкие» Web-сервера

Обычно «лёгкий» подразумевает простой, легко инсталлируемый, хорошо налаженный, нетребовательный и устойчивый – меньшего размера и менее сложный, чем Apache и IIS, которые в попытке удовлетворить свой большой рынок превратились в довольно громоздкие конструкции.

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

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

Почти все лёгкие Web-серверы имеют в той или иной степени открытый исходный код. Если нам требуется особое поведение Web-сервера, то описанные ниже серверы настолько малы, что их легко понять и, следовательно, усовершенствовать. Эти Web-серверы – отличный исходный материал для проектов, в которых Web-серверы встраиваются в специальное оборудование или в специфические приложения, предназначенные для работы на компьютерах общего назначения. Они также широко используются на обычных Web-сайтах:

· YouTube использует lighttpd для быстрой доставки архивированного контента, например, видео;

· cdServe работает на CD-дисках "German Woodworking Machinery and Tools";

· LiteSpeed «отметился» в twitter, www.funnyoride.com, www.airliners.com, WordPress.com, fanfiction.com, SlashGear, www.forumactif.com и в других заметных Web-сайтах;

· OpenSUSE, RubyOnRails, MarkaBoo и несколько других заметных сайтов опираются на Mongrel;

· thttpd работает на ht.com, mtv.com, The Drudge Report, garfield.com и др.

Лёгкие серверы играют свою роль даже в реальных вычислительных центрах, включая перечисленные выше солидные сайты и не только их. Особо высокопроизводительные сайты сегментируют свои операции, чтобы извлечь максимальную выгоду из кэширования, прокси-серверов и т.д. Сайт на основе Apache, к примеру, может иметь архитектуру, в которой медленно изменяющиеся изображения доставляются посредством «минималистского» Web-сервера из выделенной файловой системы. То, что видит в действительности конечный пользователь – это результат командной работы Apache и одного или нескольких дополнительных Web-серверов, каждый из которых играет роль, в которой он превосходит остальных. Такая конструкция может дать очень быстрые результаты с минимальными затратами на вычисления.

Хотя имеют много общего, внутри данной категории есть и различия. Большинство «лёгких» Web-серверов написаны на C, но есть и ряд успешных реализаций на других языках, в том числе на Erlang, Java, Lisp, Lua, Perl, Python и Tcl.

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

К числу очень маленьких Web-серверов относятся:

· Cheetah Server , содержащий менее тысячи строк на C.

· DustMote , очень маленький Web-сервер, реализованный в одном Tcl-исходнике размером примерно 3000 байт.

· fnord занимает менее 20K, в зависимости от платформы и конфигурации. Несмотря на маленький размер, он поддерживает виртуальный хостинг, CGI и keep-alive.

· ihttpd , имея менее 800 строчек C, умеет обслуживать страницы, включая CGI, посредством inetd.

· mattows поддерживает CGI, насчитывая при этом всего лишь 600 строк на C.

· Scrinchy , несмотря на маленький размер - около 30 KB - поддерживает примечательно много языков сценариев, включая специализированный стековый язык под названием Sy.

Маленький размер не препятствует серьёзному использованию этих серверов; fnord, например, обслуживает тысячи одновременных соединений.

· cghttpd – минимальный Web-сервер, который можно рассматривать как эксперимент по использованию асинхронных средств, доступных в ядрах Linux серии 2.6.

· darkhttpd – быстрый однопоточный сервер HTTP/1.1.

· Gatling специально разработан для высокой производительности. Поддерживает FTP, IPv6, виртуальный хостинг, CGI и т.п.

· Kernux – модуль ядра Linux, который обеспечивает выполнение HTTP-демона.

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

· LiteSpeed Web Server – коммерческий лёгкий Web-сервер, в котором особый упор сделан на производительность и безопасность. LiteSpeed Technologies Inc. заявляет об ускорении в шесть раз для статического контента и несколько более скромных показателях для интерпретируемых страниц.

· Miniature JWS , известный также как tjws - написанный на Java Web-сервер, который обрабатывает сервлеты, JSP и тысячи параллельных соединений, занимая 77 килобайт. Его автор характеризует его так: "на 10% быстрее, чем Apache 2.x."

· Yaws – высокопроизводительный сервер HTTP/1.1, написанный на Erlang.

Многие Web-серверы реализованы как классы или библиотеки, разработанные для встраивания в большие приложения. Среди них особенно интересны:

· EHS – "встраиваемый HTTP сервер," класс C++, разработанный для встраивания в большие C++ приложения; и

· Embedded TCL Web Server , простейший Web-сервер, поддерживающий SSL и Basic Authentication и при этом фантастически быстрый – по замерам автора, не менее быстрый, чем lighttpd и AOLserver. Содержит меньше сотни строк Tcl.

На языке Python реализованы несколько Web-серверов, которые заполняют необычные ниши, в том числе:

· cdServer - маленький простой http-сервер на Python, "разработанный для выдачи (статического) контента с CD-ROM". Имеет ограниченные возможности в обслуживании динамического контента. У нас есть несколько проектов, которые включают доставку непортящихся "live CD", и инструменты типа cdServer являются для них критическими.

· edna – остроумный MP3-сервер на Python, основанный на HTTP.

Есть и другие интересные лёгкие Web-серверы, реализованные на Perl и на других, не так хорошо известных, языках:

· Camlserv – полный Web-сервер, написанный на ocaml и нацеленный на "высокоинтерактивные Web-страницы". Умещается в нескольких тысячах строчек ocaml, большинство из которых посвящено специальным возможностям работы с MySQL и HTML.

· dhttpd протоколирует обращения в том же формате, что и Apache. Имеет встроенный Perl-интерпретатор для поддержки CGI, виртуальный хостинг, IPv6, управление пропускной способностью и возможности безопасности.

· DNHTTPD написан на Perl для UNIX. Он поддерживает виртуальные хосты, SSL соединения, CGI и другое.

· Jellybean – написанный на Perl сервер Perl Object Server, основанный на HTTP.

· lns.http – общая Web-среда на LISP HTTP/1.1.

· Mongrel – библиотека и сервер для HTTP, написанные на Ruby.

· Nanoweb – быстрый, устойчивый Web-сервер, написанный на PHP. Имеет обширный список возможностей, включая полное соответствие HTTP/1.1, контроль обращений, аутентификацию, виртуальный хостинг, SSL совместимость и т.д.

· Naridesh – написанный на Perl Web-сервер.

· OpenAngel – написан на Perl. Безопасность.

· Xavante – HTTP/1.1 Web-сервер, написанный на Lua.

· XSP написан на C# и выполняет роль ведущего узла ASP.NET.

Мир Web-серверов состоит не только из Apache и IIS, их гораздо больше. В вашем распоряжении широкий выбор альтернативных решений – настолько маленьких, что их можно полностью понять, и при этом достаточно быстрых для серьёзных приложений.

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

Помню, давно я думал, что Интернет сосредоточен в одном месте, представлял что-то типа лаборатории, где расположено большое количество аппаратуры, поддерживающей работу всего этого. Тогда я не мог оценить масштабы Глобальной сети и сложности ее структуры. В действительности же, Интернет - это абстрактное понятие, ресурсы Интернета разбросаны по оборудованию на всем земном шаре. Для связи этого оборудования между собой на огромных расстояниях придумали специальные алгоритмы и стандарты, в частности, протокол TCP/IP , на котором в настоящее время функционирует наш Интернет. Согласно этому стандарту, каждый компьютер, находящийся в Глобальной сети, имеет свой уникальный адрес - IP-адрес . IP-адрес представляет собой последовательность четырех чисел в диапазоне от 0 до 255, разделенных между собой точками (например, 92.166.31.18). Один компьютер может связаться с другим компьютером в сети, зная его IP-адрес. Но сказать "компьютер связался с компьютером" не совсем верно, так как связываются не сами компьютеры, а сетевые службы (программы, если хотите), выполняющиеся на них. Допустим, вы отправляете электронную почту дедушке, при этом ваша почтовая программа связывается с почтовым сервером для отправки письма.

На компьютере одновременно может работать несколько сетевых программ, поэтому помимо IP-адреса для связи протоколом TCP/IP предусмотрено дополнительно такое понятие как порт . Порт - это число в диапазоне от 1 до 65536. Таким образом, минимальным условием для связи одной сетевой программы с другой является наличие у первой IP-адреса и номера порта второй. Совокупность IP-адреса и порта принято записывать через двоеточие (например, 192.168.35.2:443).

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

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

Теперь давайте на основе этих поверхностных знаний определим, что такое веб-сервер . Во-первых, судя по названию, это сетевая программа, ожидающая и принимающая соединения (сервер). По умолчанию, веб-сервер "слушает" порт под номером 80. Веб-сервер поддерживает работу одновременно с несколькими клиентами (несколько человек одновременно могут просматривать сайт). Клиентом для веб-сервера выступает веб-браузер (Internet Explorer, Opera и так далее).

Таким образом, сайт функционирует за счет веб-сервера, который отправляет странички этого сайта клиентам, запрашивающих их у него. Для того, чтобы запросить страницу необходимо знать IP-адрес компьютера, на котором запущен веб-сервер с нужным нам сайтом. Но запоминать IP-адреса неудобно, поэтому придумали доменные имена, представляющие собой некую текстовую сущность (например, yandex.ru). Очевидно, что доменные имена более понятны и более легки в запоминании. Однако, протокол TCP/IP не в состоянии найти требуемый компьютер по доменному имени, поэтому его необходимо преобразовать в IP-адрес. Для этого служат DNS-сервера, на которых расположены таблицы соответствий доменных имен и IP-адресов. Допустим, когда мы вводим в адресной строке браузера домен yandex.ru, в первую очередь посылается запрос в DNS-сервер для определения IP-адреса данного домена. Когда адрес определен, браузер пытается связаться с веб-сервером по этому адресу и по стандартному порту под номером 80. Если соединение с веб-сервером установлено, браузер запрашивает у веб-сервера требуемую страницу сайта.

В принципе, веб-сервер можно настроить на работу и на другом порту, в таком случае в браузере при запросе страницы необходимо его указывать через двоеточие после доменного имени (например, site.ru:3182).

Каким же образом происходит запрос страницы сайта у веб-сервера браузером? Понятное дело, что для взаимодействия веб-сервера и браузера необходим "общий язык", то есть некий стандарт, по которому формируются запросы и ответы. Этим стандартом служит протокол HTTP (HyperText Transfer Protocol). Этот протокол довольно прост, так как соответствует схеме "запрос-ответ". Говоря другими словами, на каждый HTTP-запрос веб-браузера веб-сервер отвечает HTTP-ответом. По своей инициативе веб-сервер HTTP-пакеты не шлет (к тому же, зачастую, после завершения операции "запрос-ответ" сервер разрывает соединение с клиентом).

Давайте рассмотрим структуру HTTP-пакета. HTTP-запрос и HTTP-ответ состоят из двух блоков - блока заголовков (headers) и блока тела пакета. Эти блоки отделены друг от друга двумя символами перевода строк (то есть между заголовками и телом расположена пустая строка). В блоке заголовков расположены различные параметры пакета, блок тела содержит какие-либо данные. Второй блок может отсутствовать, то есть HTTP-пакет может состоять только из блока заголовков. Для примера выполним запрос главной страницы сайта ya.ru и рассмотрим HTTP-пакеты, участвовавшие в нем. При запросе главной страницы браузер Firefox отправил веб-серверу следующий HTTP-запрос:

GET / HTTP/1.1 Host: ya.ru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2) Gecko/20100115 Firefox/3.6 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive

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

GET / HTTP/1.1

"GET" - тип запроса. Два наиболее распространенных типа запросов - это GET и POST. О них мы поговорим в одной из следующих статей или уроков. "/" указывает на то, что запрашивается главная страница сайта. В противном случае здесь указывается путь и имя запрашиваемой страницы или файла. "HTTP/1.1" - версия протокола HTTP.

Host: ya.ru

Параметр Host содержит домен сайта, к которому происходит обращение.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2) Gecko/20100115 Firefox/3.6

User-Agent содержит информацию о клиенте: тип браузера, операционной системы и так далее. Остальные параметры в данный момент нас особо не интересуют.

На данный HTTP-запрос веб-сервер ответил следующим HTTP-ответом:

HTTP/1.1 200 OK Server: nginx Date: Thu, 25 Feb 2010 12:31:25 GMT Content-Type: text/html; charset=utf-8 Last-Modified: Tue, 12 Jan 2010 15:29:06 GMT Transfer-Encoding: chunked Connection: keep-alive Content-Encoding: gzip ...

Пустая строка указывает на наличие блока данных (тела пакета). Как и в случае с HTTP-запросом рассмотрим наиболее важные строки полученного ответа. В первой строке указывается версия протокола HTTP (HTTP/1.1) и код результата. Код результата 200 означает, что запрос выполнен успешно. В описании протокола HTTP расписаны все коды результатов. С некоторыми из них, например, 403 и 404, мы познакомимся в будущем.

Server: nginx

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

Content-Type: text/html; charset=utf-8

Content-Type содержит тип переданных данных и, если необходимо, их кодировку (charset). Также в заголовках часто содержится параметр Content-Length, содержащий размер переданных сервером данных в байтах. В блоке тела пакета содержится код запрошенной страницы.

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

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

Допустим, пользователь сидит за компьютером, просматривает WEB страницы, и тут ему звонит друг и говорит:

«Знаешь, я только что прочел классную статью! Введи этот URL и прочти сам. Это страница ».

Пользователь вводит продиктованный URL в и нажимает кнопку «Перейти». И о чудо, независимо от того, где находится этот URL, страница появляется на экране монитора.

Следующая схема на самом простом уровне дает представление о последовательности событий, в результате которых выбранная страница попадает на экран монитора:

Браузер пользователя осуществил соединение с WEB сервером, запросил нужную страницу и получил ее.

Что происходит незаметно для пользователя

1. Браузер разделил URL на три части:

• Протокол («http»).
• Имя сервера («сайт»).
• Имя файла («web server.htm»).

Итак, что же такое «Интернет»? - это миллионы компьютеров, соединенных в огромную компьютерную сеть. Благодаря сети, компьютеры могут поддерживать связь между собой. Домашний компьютер можно подключать к Интернету, используя модем телефонной линии, устройства, работающие по технологии DSL либо кабельный модем. Эти устройства устанавливают связь с поставщиком услуг Интернета (ISP). Компьютеры компании или университета обычно снабжаются платами сетевого интерфейса (network interface card, NIC), которые подключают их непосредственно к соответствующей локальной сети (LAN). Компания может подключить свою локальную сеть к оборудованию поставщика интернет-услуг, используя высокоскоростную телефонную линию, например, линию T1. По линии T1 можно передавать приблизительно 1.5 миллиона бит в секунду, в то время как по обычной линии с использованием модема можно передавать всего от 30 000 до 50 000 бит в секунду.

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

Клиенты и серверы

В общем случае все машины в Интернете можно разделить на два типа: серверы и клиенты. Машины, предоставляющие услуги другим машинам, называют серверами (это, например, WEB серверы или FTP серверы). Машины, используемые для связи с серверами с целью получения услуг, называют клиентами. Когда пользователь подключается к Yahoo! по адресу yahoo.com , чтобы просмотреть страницу, Yahoo! выделяет машину (а возможно, кластер очень больших машин), для использования в Интернете с целью обслуживания запроса этого пользователя. Таким образом, Yahoo! предоставляет пользователю услуги своего сервера. Машина пользователя, с другой стороны, скорее всего, никому другому в Интернете услуги не оказывает. Поэтому ее называют пользовательской машиной, или клиентом. Может так быть, и это обычная практика, что одна машина в то же время является и сервером, и клиентом, однако в нашем случае будем считать, что большинство машин выполняют функции либо сервера, либо клиента.

Серверная машина предоставляет один или несколько видов услуг в Интернете. На серверной машине могут работать специализированные программы, благодаря которым она может выполнять функции WEB сервера, сервера электронной почты и FTP сервера. Связывающиеся с серверной машиной клиенты преследуют определенную цель, поэтому они направляют свои запросы на сервер с соответствующей специализированной программой, работающий на общей серверной машине. Например, если пользователь на своей машине запустит WEB браузер, тот, скорей всего, свяжется с WEB сервером на серверной машине. Пользовательское приложение, работающее по протоколу Telnet, стремится установить связь с сервером Telnet, приложение для работы с электронной почтой вступает в контакт с сервером электронной почты и так далее…

Доменные имена и их покупка

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

Имя сайт состоит из трех частей:

• Имя хоста (www).
• Имя домена (sd-company).
• Имя домена верхнего уровня (ru).

Регистраторы

Доменными именами внутри домена .com занимается регистратор VeriSign. VeriSign также контролирует доменные имена .net . Другими доменами (такими как PRO, BIZ и ORG) управляют другие регистраторы (а именно RegistryPro, NeuLevel и Public Interest Registry). VeriSign создает имена верхнего уровня и обеспечивает уникальность всех имен в пределах домена верхнего уровня. Кроме того, VeriSign содержит контактную информацию каждого сайта и располагает базой данных о пользователях. Имя хоста создается компанией, предоставляющей для домена. Очень распространено имя хоста «www», однако в настоящее время во многих местах его либо не указывают, либо заменяют другим именем хоста, указывающим на определенное место на сайте. Например, в доменном имени энциклопедии Encarta компании Microsoft, encarta.msn.com, «encarta» обозначает имя хоста вместо www.

Чтобы все эти машины правильно работали, каждая машина в Интернете получает уникальный адрес, который называется IP адресом. IP поддерживает интернет протокол, а адреса являются 32-битными числами, которые, как правило, представляются в виде четырех «октетов» в «десятичном формате с разделительными точками». Типичный IP адрес имеет приблизительно такой вид: 216.27.61.137

Четыре числа в IP адресе называются октетами, поскольку они могут иметь значения от 0 до 255, что составляет 2 в восьмой степени возможностей на каждый октет.

Уникальный IP адрес

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

Пользователь, машина которого работает под управлением ОС Windows, может получить большое количество информации об Интернет-соединении своего компьютера, включая текущий IP адрес и имя хоста, если воспользуется командой WINIPCFG.EXE (IPCONFIG.EXE для Windows 2000/XP). В машине под UNIX, чтобы узнать IP адрес машины, нужно напечатать в командной строке nslookup, а также имя этой машины, например, SD 1 - то есть, все вместе это будет выглядеть так: «nslookup sd1.su». Имя своей машины можно определить с помощью команды hostname. (Более подробные сведения о IP адресах можно получить из информации Комитета по цифровым адресам в Интернете).

Машине, работающей в Интернете, для связи с сервером обычно нужен только IP адрес. Например, можно набрать в браузере URL 209.116.69.66 и связаться с машиной, на которой располагается WEB сервер сайта PCWork. Для связи с некоторыми серверами одного только IP адреса недостаточно, однако для большинства больших серверов этого вполне хватает - далее этот вопрос будет освещен более подробно.

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

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

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 активно применяется и сегодня, там, где в код страницы нужно вставить некий статический контент, прежде всего благодаря простоте и нетребовательности к ресурсам.

CGI

Следующим шагом в развитии веб-технологии стало появление специальных программ (скриптов) выполняющих обработку запроса пользователей на стороне сервера. Чаще всего они пишутся на скриптовых языках, первоначально это был 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.

Заключение

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

• Теги:

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

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

Функции веб сервера

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

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

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

Для чего нужен веб сервер?

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

Самые известные веб серверы

Наиболее известными и распространенными веб серверами являются Microsoft IIS и Apache. Самым популярным из них является Apache. Его программное обеспечение используется более чем на 60% всех существующих. Во многом это стало возможным благодаря тому, что Apache является бесплатным. Разработчики постоянно анализируют ошибки своего продукта и устраняют их. Недостаток программы в том, что по большому счету она предназначена для профессиональных программистов и пользователей, поэтому обслуживать и настраивать ее достаточно тяжело.

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

И Apache и IIS отлично работают со многими операционными системами, например с Mac OS, Linux, различными модификациями Microsoft Windows и многими другими. Эти два веб сервера стабильны в работе, имеют хорошую скорость, к ним можно подключить дополнительные модули.