WEB-технологии

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

 

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

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

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

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

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

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

Шаг 1 необходим, потому что  входящий запрос может и не содержать реального имени файла в виде строкового литерала. Например, URL может быть вот таким: http://www.cs.vu.nl. Здесь имя файла отсутствует. Этот URL необходимо дополнить неким именем файла по умолчанию. К тому же современные браузеры могут указывать язык пользователя по умолчанию (например, итальянский или английский), что позволяет серверу выбирать веб-страницу на соответствующем языке, если таковая существует. Вообще говоря, расширение имени - задача не такая уж тривиальная, как может показаться, поскольку существует множество соглашений об именовании файлов.

Шаг 2 состоит в проверке идентификационных данных клиента. Это нужно для отображения  страниц, недоступных для широкой  публики.

Шаг 3 проверяет наличие  каких-либо ограничений, накладываемых на данного клиента и его местоположение.

На шаге 4 проверяются  ограничения на доступ к запрашиваемой  странице. Если определенный файл (например, .htaccess) присутствует в том же каталоге, что и нужная страница, он может ограничивать доступ к файлу. Например, можно установить доступ к странице только для сотрудников компании.

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

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

Шаг 8 предназначен для различных  задач, таких как построение профиля  пользователя, сбор статистики и т. д.

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

Рисунок 4 - серверная форма

 

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

Другая проблема, возникающая  при использовании серверных  ферм, состоит в том, что TCP-соединение клиента заканчивается на входном  модуле, то есть ответ в любом  случае должен пройти через входной  модуль. Эта ситуация показана на рис. 5, а. Здесь как входящий запрос A), так и исходящий ответ B) проходят через входной модуль. Иногда для  обхода этой проблемы применяется хитрость под названием передача TCP. Суть ее в том, что TCP-соединение продлевается до конечного (обрабатывающего) узла, и он может самостоятельно отправить ответ напрямую клиенту (рис. 5, б). Эта передача соединения для клиента незаметна.

Рисунок 5 - Обычный запрос-ответный обмен (а); обмен запросами и ответами при передаче TCP (б)

 

3. HTTP — протокол передачи гипертекста

Стандартный протокол для  передачи данных по Всемирной паутине  — это HTTP (HyperText Transfer Protocol — протокол передачи гипертекста). Он описывает сообщения, которыми могут обмениваться клиенты и серверы. Каждое взаимодействие состоит из одного ASCII-запроса, на который следует один ответ, напоминающий ответ стандарта RFC 822 MIME. Все клиенты и все серверы должны следовать этому протоколу. Он определен в RFC 2616.

1. Соединения

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

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

Это соображение привело  к созданию протокола HTTP 1.1, который поддерживал устойчивые соединения. Это означало, что появилась возможность установки TCP-соединения, отправки запроса, получения ответа, а затем передачи и приема дополнительных запросов и ответов. Таким образом, снизились накладные расходы, возникавшие при постоянных установках и разрывах соединения. Стало возможным также конвейеризировать запросы, то есть отправлять запрос 2 еще до прибытия ответа на запрос 1.

2. Методы

Несмотря на то что HTTP был разработан специально для использования в веб - технологиях, он был намеренно сделан более универсальным, чем это было необходимо, так как рассчитывался на будущее применение в объектно-ориентированных приложениях. По этой причине в дополнение к обычным запросам веб-страниц были разработаны специальные операции, называемые методами. Они обязаны своим существованием технологии SOAP. Каждый запрос состоит из одной или нескольких строк ASCII, причем первое слово является именем вызываемого метода. Встроенные методы перечислены в таблице на рис.6. Помимо этих общих методов, у различных объектов могут быть также свои специфические методы. Имена методов чувствительны к регистру символов, то есть метод GET существует, a get — нет.

Рисунок 6 - Встроенные методы HTTP-запросов

 

Метод GET запрашивает у  сервера страницу (под которой  в общем случае подразумевается  объект, но на практике это обычно просто файл), закодированную согласно стандарту MIME. Большую часть запросов к серверу  составляют именно запросы GET.

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

Метод PUT является противоположностью метода GET: он не читает, а записывает страницу. Этот метод позволяет создать  набор веб-страниц на удаленном  сервере. Тело запроса содержит страницу. Она может быть кодирована с помощью MIME. В этом случае строки, следующие  за командой PUT, могут включать различные  заголовки, например, Content-Type или заголовки аутентификации, подтверждающие права абонента на запрашиваемую операцию.

Метод POST несколько напоминает метод PUT. Он также содержит URL, но вместо замены имеющихся данных новые данные «добавляются» (в неком общем  смысле) к уже существующим. Это может быть публикация сообщения в конференции или добавление файла к электронной доске объявлений BBS. На практике ни PUT, ни POST широко не применяются.

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

Метод TRACE предназначен для  отладки. Он приказывает серверу  отослать назад запрос. Этот метод  особенно полезен, когда запросы  обрабатываются некорректно и клиенту  хочется узнать, что за запрос реально  получает сервер.

Метод CONNECT в настоящее  время не используется. Он зарезервирован для будущего применения.

Метод OPTIONS позволяет клиенту  узнать у сервера о его свойствах  или о свойствах какого-либо конкретного  файла.

В ответ на каждый запрос от сервера поступает ответ, содержащий строку состояния, а также, возможно, дополнительную информацию (например, веб-страницу или ее часть). Строка состояния  может содержать трехразрядный  код состояния, сообщающий об успешном выполнении запроса или о причинах неудачи. Первый разряд предназначен для  разделения всех ответов на пять основных групп, как показано в таблице  на рис.7. Коды, начинающиеся с 1 Aхх), на практике используются редко. Коды, начинающиеся с 2, означают, что запрос был обработан успешно и данные (если их запрашивали) отосланы. Коды Зхх сообщают клиенту о том, что нужно попытать счастья в другом месте — используя либо другой URL, либо свой собственный кэш.

Рисунок 7 - Группы кодов состояния, содержащиеся в ответах сервера

 

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

3. Пример  использования HTTP

Поскольку HTTP является текстовым  протоколом, взаимодействие с сервером посредством терминала (который  в данном случае выступает как  противоположность браузеру) можно  организовать достаточно просто. Необходимо лишь установить TCP-соединение с портом 80 сервера. Читателю предоставляется  возможность самому посмотреть, как  работает этот сценарий (предпочтительнее запускать его в системе UNIX, поскольку  некоторые другие системы могут  не отображать статус соединения). Итак, последовательность команд такова:

Рисунок 8 - последовательность команд HTTP-протокола

 

Эта последовательность команд устанавливает telnet-соединение (то есть ТСР- соединение) с портом 80 веб-сервера IETF, расположенного по адресу www.ietf.org.

Результат сеанса связи  записывается в файл log, который затем  можно просмотреть. Далее следует  команда GET. Указывается имя запрашиваемого файла и протокол передачи. Следом идет обязательная строка с заголовком Host. Пустая строка, которая находится за ней, также обязательна. Она сигнализирует серверу о том, что заголовки запросов закончились. Командой close (это команда программы telnet) соединение разрывается.