Глава 11 7 страница

Чтобы уяснить степень различия современной Всемирной паутины от ее первоначального замысла, представим, что в своем предложении Бернерс-Ли сформулировал требование об ограничении информации, мотивируя его необхо­димостью уберечь детей от доступа к порнографическим материалам. Как бы на это отреагировало руководство CERN? Без разговоров отклонило бы. То, как меняются задачи заинтересованных лиц, мы обсудим в разделе 13.5 применительно к архитектурно-экономическому циклу Всемирной паутины.

¹ © 1996, Donna Сох, Robert Patternson; производство Национального центра но применению супер­компьютеров (National Center for Supcrcomputing Applications), Упипсрситст шт. Иллинойс, Урба- на-Шамиейн. Перепечатывается с разрешения.

 

13.3. Архитектурное решение

Архитектурной основой Всемирной паутины, принятой сначала CERN, а затем и консорциумом W3C, стало сочетание модели «клиент-сервер» и библиотеки (libWWW), скрывающей все зависимости по аппаратному обеспечению, опера­ционным системам и протоколам. На рис. 13.3 приводится схема взаимодействия производителей и потребителей контента посредством соответствующих серве­ров и клиентов. Производитель размещает на машине, исполняющей роль серве­ра, описание информации на языке HTML. Обмен информацией с клиентом осу­ществляется сервером по протоколу передачи гипертекста (hypertext transfer protocol, HTTP). Программное обеспечение сервера и клиента основывается на libWWW, что позволяет маскировать детали протокола и зависимости от платформ. Одним из элементов, расположенных на стороне клиента, является браузер, кото­рый отвечает за понятное для потребителя информации отображение HTML.

Рис. 13.3. Взаимодействие производителей и потребителей информации осуществляется посредством клиентов и серверов

 

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

Реализация первоначальных требований: libWWW

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

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

libWWW — это компактная, переносимая библиотека, которая встраивается в различные веб-приложения: клиенты, серверы, базы данных и веб-пауки. Она состоит из пяти уровней, изображенных на рис. 13.4.

Рис. 13.4. Многоуровневое представление библиотеки libWWW

 

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

На уровне ядра содержится «скелет» функциональности веб-приложения: сред­ства доступа к сети, управления данными, синтаксического анализа, регистрации и т. д. Сам по себе этот уровень не выполняет никаких действий. Он лишь предо­ставляет стандартный интерфейс веб-приложения, при том что фактическая функ­циональность последнего обеспечивается сменными модулями и вызываемыми функциями, которые это приложение регистрирует. Сменные модули (plug-ins), регистрируемые в период прогона, реализуют на практике все функции уровня ядра — они ответственны за отправку и обработку данных. Как правило, они обеспечивают поддержку протоколов, осуществляют траиспортпые функции ни.ч- кого уровня и интерпретируют форматы данных. Сменные модули можно заме­нять в динамическом режиме, что упрощает задачу введения новой функцио­нальности и даже позволяет вносить коррективы н характер неб-ириложеннй.

Вызываемые функции (call-out functions) — это еще одно средство, нрн номо- щи которого приложения могут выходить за рамки функциональности, предо­ставляемой уровнем ядра. Они являют собой произвольные прикладные функ­ции, которые вызываются перед пли после подами запросов модулям протоколов.

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

Уровень потоков предусматривает абстракцию потока данных, передаваемых между приложением и сетью.

На уровне доступа содержатся модули отдельных сетевых протоколов. Стан­дартный набор, который первоначально поддерживала библиотека libWWW, со­стоит из следующих протоколов: IITTP — базовый протокол WWW; NNTP (network news transport protocol, сетевой протокол передачи новостей) — прото­кол передачи сообщений в сети Usenet; WAIS (wide area information server, гло­бальный информационный сервер) — сетевая информационно-поисковая система; FTP (file transfer protocol, протокол передачи файлов), TELNET, rlogin, Gopher, локальная файловая система и TN3270. Многие из них в настоящее время утра- тили былое значение, однако есть и нововведения — к списку прибавился протокол HTTPS (HTTP secure, протокол защищенной передачи гипертекста). Введение новых модулей протоколов не представляет сложности, поскольку они строятся на абстракциях нижележащих уровней.

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

Выводы из опыта применения libWWW

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

♦ Необходимы формализованные интерфейсы прикладного программирования (application programming interfaces, APIs). Имеются в виду интерфейсы* которые представляют функциональность библиотеки libWWW сконстру­ированным на ее основе программам. Поскольку libWWW должна была содействовать разработке приложении на различных платформах и языках, зависимость спецификаций таких интерфейсов от конкретного языка не допускалась.

♦ Функциональность и представляющие ее интерфейсы прикладного програм­мирования должны быть многоуровневыми. Разные приложения обращают­ся к разным ступеням абстракции обслуживания, организовать которые проще всего посредством уровней.

♦ Библиотека должна поддерживать динамический, расширяемый набор ха­рактеристик. Все эти характеристики должны быть заменяемыми, в гом числе в период прогона.

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

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

Ранний вариант архитектуры «клиент-сервер», реализованный при помощи libWWW

На рис. 13.5 изображено представление размещения типичной клиент-серверной модели Всемирной паутины, построенной с участием libWWW. Там же показано представление декомпозиции на модули HTTP-клиента и серверных компонен­тов представления размещения. На этой схеме четко прослеживаются некоторые особенности libWWW. Во-первых, далеко не все элементы модели «клиент-сер­вер» строятся на ее основе. К примеру, от нее никак не зависит пользовательский интерфейс. Во-вторых, имена диспетчеров не обнаруживают точного соответствия с именами уровней. В то время как диспетчеры доступа, протоколов и потоков четко связаны с уровнями доступа и потоков, диспетчер кэширования обращает­ся к службам прикладного уровня. Диспетчеры потоков в рамках пары «клиент- сервер» управляют низкоуровневой передачей данных и тем самым обеспечива­ют для остальных элементов системы прозрачность информационного обмена.

Диспетчер пользовательского интерфейса ответствен за «облик и дух» пользо­вательского интерфейса клиента. С другой стороны, пользуясь расширяемостью набора ресурсов, доступных системе \YW\V, другой ллсмент — диснетчср пред­ставлений — можетделегировать полномочия по отображению информации внеш­ним программам (просмотра). Так происходит с ресурсами, которые известны системе, но которые диспетчер пользовательского интерфейса нс поддерживает напрямую. В частности, большинство веб-браузеров делегируют внешней про­грамме обязанности по отображению файлов PostScript и.pdf. Такое решение возникло как компромисс между стремлением к интеграции пользовательского интерфейса (способной стабилизировать его представление и, следовательно, повысить практичность), с одной стороны, и расширяемостыо — с другой.

 

 

 

Рис. 13.5. Представление размещения клиент-серверной модели Всемирной паутины, а также представление декомпозиции на модули клиента HTTP и серверных компонентов

Диспетчер пользовательского интерфейса забирает запрос на поиск информа­ции, поданный пользователем в виде URL, а затем передает эти данные диспет­черу доступа. Диспетчер доступа проводит проверку иа наличие запрошенного URL в кэше и интерпретирует историческую навигацию (например, «Назад»). Если файл присутствует в кэше, он извлекается из диспетчера кэширования и пе­редается диспетчеру представлений для отображения пользовательским интер­фейсом или внешней программой просмотра. В случае отсутствия файла в кэше диспетчер протоколов определяет тип запроса и запускает для его обслуживания соответствующий стек протоколов. С помощью последнего клиентский диспет­чер протоколов передает запрос на сервер. Получив от сервера ответ, выражен­ный в форме документа, диспетчер потоков передает его диспетчеру представле­ний, который, в свою очередь, обеспечивает его отображение. При попытке установления соответствия типа документа внешним программам просмотра дис­петчер представлений обращается за помощью к конфигурационному файлу уп­равления статическим представлением (mimerc, mailcap и т. д.).

В обязанности HTTP-сервера входит обеспечение прозрачного доступа к фай­ловой системе — благо именно она является источником документов, которые передаются в WWW. HTTP-сервер управляет доступом либо напрямую (для из­вестных типов ресурсов), либо через посредника, называемого общим шлюзовым интерфейсом (common gateway interface, CGI). CGI обрабатывает те типы ресур­сов, с которыми не может справиться сервер, а также рассматриваемые ниже рас­ширения функциональности сервера. До появления этих расширений в WWW- серверах реализовывалось подмножество определенных HTTP-запросов, которые предусматривали поиск документов и связанной с ними метаинформации, а так­же исполнение программ, размещенных на стороне сервера, средствами CGI.

Получив запрос, диспетчер потоков на стороне сервера определяет его тип и при помощи распознавателя путей устанавливает путь к указанному URL. Для проверки полномочий доступа, которыми обладает запрашивающий клиент, IITTP- сервер обращается к таблице доступа. Если речь идет об обращении к защищен­ным данным, сервер может запустить сеанс парольной аутентификации клиента. Затем, приняв допущение об аутентификации, сервер обращается к файловой системе (расположенной за его границами) и записывает запрошенную инфор­мацию в выходной поток. Для исполнения программы средствами CGI ей предо­ставляется процесс (новый или освобожденный в результате опроса), после чего выходные данные исполняемой программы фиксируются диспетчером потоков сервера, и он, в свою очередь, передает их клиенту.

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

Общий шлюзовой интерфейс (CGI)

Информация, которую сервер возвращает клиенту, по большей части является статической; изменениям она подвержена только в рамках собственной файло­вой системы. Сценарии CGI, напротив, подразумевают возможность возврата динамической, индивидуальной для каждого запроса информации. Исторически сложившаяся роль CGI заключается в расширении функциональности сервера по части ввода информации, поиска и щелчков на изображениях. Впрочем, чаще всего CGI используется для создания виртуальных документов (virtual docu­ments) — документов, которые синтезируются динамически в ответ на запросы пользователей. К примеру, если пользователь ищет в Интернете конкретную ин­формацию, поисковая система генерирует ответ па каждый поисковый запрос;

сценарий CGI создает из ответа новый HTML-документ и возвращает сто пользо­вателю.

Сценарии CGI сохранили гибкость, характерную для ранних, основанных на библиотеке libWWW вариантов архитектуры. На рис. 13.5 CGI изображен как внешний по отношению к HTTP-серверу элемент. Сценарии C.GI пишутся на разных языках — как компилируемых (С. C++, Fortran), так и интерпретиру­емых (Perl, Visual Basic. AppleScript и т. д.). Сценарии CGI позволяют разработ­чикам произвольным образом расширять функциональность сервера — в частно­сти, производить информацию, возвращаемую сервером пользователю.

С другой стороны, поскольку в сценариях CGI может содержаться любая функ­циональность С, Perl и других языков, в системе защиты машины, на которой они устанавливаются, образуется серьезная брешь. К примеру, с помощью сцена­рия (исполняемого как отдельный от сервера процесс) на хосте от имени удален­ного пользователя можно запустить любую команду. Эта угроза, которую демон­стрируют исполняемые на стороне сервера сценарии (в том числе CGI), заставила выставить к Всемирной паутине новое требование, касающееся повышения безо­пасности. Механизм реализации этого требования с помощью HTTPS описыва­ется в следующем разделе.

Вероятно, наиболее важным результатом введения в архитектуру веб-техно- лопш CGI явилась возможность «размещать» (put) в сети информацию — в до­полнение к стандартной для сервера операции ее «получения» (get). Впрочем, это требование, выдвинутое еще к первоначальному проекту WWW, так и не удалось реализовать в полной мере. CGI позволяет пользователям размещать информацию только посредством специализированных механизмов — например, вносить записи в базу данных путем заполнения формы.

С помощью технологии CGI — в основном за счет обеспечения возможностей обработки сервером произвольных ресурсов и (ограниченного) размещения пользо­вателями данных — удалось решить множество проблем, присущих первоначаль­ному проекту libWWW. С другой стороны, у CGI есть несколько существенных недостатков. Один из них связан с безопасностью, другой — с переносимостью. Сценарии CGI, написанные на Visual Basic, AppleScript и С Shell, работают в сре­дах Windows, Macintosh и UNIX соответственно. Переносить эти сценарии с од­ной платформы на другую довольно сложно.

Таблица 13.2. Реализация задач по качеству, заданных для первоначальной версии WWW Задача Как реализована Какие тактики применялись Удаленный доступ Способность к взаимодействию Расширяемость программного обеспечения Масштабируемость Организация WWW на основе сети Интернет Маскировка деталей конкретной платформы при помощи библиотеки libWWW Локализация расширений протоколов и типов данных в библиотеке libWWW; возможность введения подключаемых компонентов (апплетов и сервлетов) Применение архитектуры «клиент- сервер», поддержание ссылок на данные, являющиеся локальными относительно местоположения ссылающихся данных Применение предписанных протоколов Общие абстрактные службы Информационная закрытость Общие абстрактные службы Информационная закрытость Замена компонентов Конфигурационные файлы Введение параллелизма Снижение вычислительных издержек

 

 

Реализация первоначальных задач по качеству

Реализация первоначально сформулированных для Всемирной паутины задач по качеству — удаленному доступу, способности к взаимодействию, расширяемости и масштабируемости — расписана в табл. 13.2.

13.4. Еще одна итерация архитектурно­экономического цикла: эволюция вариантов веб-архитектуры систем электронной коммерции

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

Согласно первоначальной концепции, Всемирная паутина должна была стать коллекцией документов, основанной на гипертексте. С точки зрения электрон­ной коммерции WWW является коллекцией данных. Эти две концепции отчасти находятся в противоречии друг с другом. К примеру, сложности вызывает задача «проталкивания» информации пользователю. Общеупотребительная методика обновления данных предусматривает их регулярную перезагрузку; однако сами по себе изменения, происходящие с данными, не приводят к обновлению экрана. Другая проблема связана с кнопками «Назад» в различных браузерах — в опре­деленных обстоятельствах их употребление приводит к выводу на экран устарев­ших данных.

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

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

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

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

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

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

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

Эталонная архитектура современной системы электронной коммерции изо­бражена на рис. 13.6. Функция взаимодействия программы просмотра с пользо­вателем, как правило, осуществляется веб-браузером (кроме того, это может быть киоск, устаревшая система или какое-либо другое устройство с подключением к Сети). Функция бизнес-правил и бизнес-приложений обычно реализуется серве­рами приложений и транзакций. Уровень служб обработки данных в большинстве случаев воплощается в современной базе данных, хотя не исключаются и другие варианты — соединения с устаревшими системами и подключение к устаревшим базам данных. Изображенную схему часто называют n-звенной архитектурой (при­чем в данном случае п = 3). Звено (tier) представляет собой элемент функцио­нальности, на который можно отвести отдельную физическую машину.

Рис. 13.6. Эталонная архитектура системы электронной коммерции

 

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

Рис. 13.7. Типичная система электронной коммерции

 

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

Изображенные на рис. 13.7 элементы мы намерены обсудить ниже в контек­сте атрибутов качества, реализации которых они способствуют.

Браузеры ради модифицируемости

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

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

HTTPS ради безопасности

Поданный пользователем запрос необходимо передать па целевой веб-сайт. Пере­дача обычно осуществляется средствами HTTP, однако если речь идет о секрет­ной информации, вроде номеров кредитных карт и идентификационных номеров, применяется протокол HTTPS (HTTP Secure). В HTTPS в качестве нодпротоко- ла HTTP применяется протокол защищенных сокетов (Secure Sockets Layer, SSL) от компании Netscape. Для отправки зашифрованных запросов на службы ТСР/ IP он использует порт 443 (стандартный порт HTTP — 80). Шифрование данных в рамках SSL производится с помощью 128-бптной пары открытого/секретного ключей — этот уровень шифрования при обмене небольшими пакетами коммер­ческой информации в рамках коротких транзакций считается достаточным.

Прокси-серверы ради производительности

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

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

Маршрутизаторы и брандмауэры ради безопасности

Запросы, отправляемые браузером (ив некоторых случаях обрабатываемые про­кси-сервером), прибывают на маршрутизатор, расположенный в сети предприя­тия электронной коммерции. Иногда эта сеть защищается брандмауэром, а в не­которых случаях маршрутизатор перенаправляет HTTP-запросы на автономный брандмауэр. Маршрутизаторы часто проводят трансляцию сетевых адресов (net­work address translation, NAT) — иначе говоря, преобразуют IP-адреса из внешне видимых во внутренние. IP-адреса для любого возвращаемого с веб-сервера трафи­ка, напротив, транслируются из внутренних во внешне видимые. NAT — это один из инструментов методики выравнивания нагрузки, к рассмотрению которой мы вернемся чуть позже.

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

большим распространением пользуются фильтры пакетов (packet filters) и при­кладные посредники (application proxies). Фильтры пакетов исследуют заголовки всех входящих пакетов TCP и IP, и в случае обнаружения злонамеренного пове­дения (например, попытки подключения через несанкционированный порт или отправки файлов неразрешенных типов) пакет отклоняется. В контексте переда­чи данных в WWW фильтры пакетов хороши тем, что исследуют каждый пакет в отдельности и не делают попыток фиксировать историю предыдущих сеансов связи.

Брандмауэры типа «прикладной посредник», как и предполагает их название, ориентированы на конкретное применение. Как правило, они интерпретируют прикладные протоколы и поэтому при фильтрации трафика опираются на извест­ные модели поведения. К примеру, прикладной посредник может отказать в при­еме HTTP-отклика, если перед этим на соответствующий узел не был отправлен HTTP-запрос. Брандмауэры такого типа работают значительно медленнее филь­тров пакетов; связано это с тем, что, во-первых, они сохраняют историческую информацию значительного объема, а во-вторых, механизм обработки в них зна­чительно сложнее.

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

Компоненты, обеспечивающие выравнивание нагрузки, а следовательно, произ­водительность, масштабируемость и готовность, в обязательном порядке присут­ствуют на всех уважающих себя веб-сайтах электронной коммерции. Функция блока выравнивания нагрузки заключается в распределении «нагрузки» — вхо­дящих запросов HTTP и HTTPS — между участниками пула компьютеров с про­граммным обеспечением веб-сервера. (Как мы говорили в главе 5, выравнивание нагрузки соответствует тактике «внедрения физического параллелизма»). Блок выравнивания нагрузки может перенаправить запрос на другой компьютер само­стоятельно (и прозрачно) или отослать веб-клиенту ответ с соответствующей инструкцией. Несмотря на то что перенаправление проходит незаметно для ко­нечного пользователя, фактически оно приводит к дополнительному круговому обращению.

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