Дублирование информации в World Wide Web

В апреле 1996 года состоялась рабочая встреча, организованная WWW Consortium и исследовательской лабораторией DEC, посвященная проблемам повышения эффективности и надежности технологии World Wide Web. Она собрала представителей 20 различных американских корпораций и правительственных организаций, среди которых были Xerox, Microsoft, Digital, LBNL, ISI, Hewlett-Packard. Обсуждалась, в частности, проблема неоправданно большого трафика, возникающего в рамках существующих технологий Web. В России эта проблема обостряется тем, что большинство информационных ресурсов Internet расположено за пределами нашей страны, и весь поток запросов направляется к ним через узкое горлышко каналов, связывающих российский сектор Internet с миром.

Собственно проблема повышения эффективности взаимодействия пользователей с информационными серверами Internet появилась задолго до возникновения Web - ее решали еще применительно к электронной почте и Usenet. Если говорить коротко, то "узкое место" подобных технологий, первоначально опиравшихся на UUCP, - это избыточность львиной доли информации, гуляющей по сети. Так, например, в Usenet все содержание телеконференций перекачивалось с сервера на сервер, хотя в большинстве случаев этого не требовалось. Переход к интерактивным протоколам и создание распределенных баз данных с их частичной репликацией (копированием) позволил легко выйти из затруднения.

Другой пример повышения эффективности информационного обмена - создание "зеркал" или копий некоторого информационного ресурса на другом сервере в Сети. Этот принцип широко используется при создании FTP-архивов.

В Web та же проблема проявляется несколько иначе.

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

Ориентируясь, в частности, на сообщение "Analysis of HTTP Performance problems" (http://sunsite.unc.edu/mdma-release/http-prob.html), а также статью Джеймса Гверцмана и Марго Зелцера "World-Wide Web Cache Consistency" (http://wweecs.harvard.edu/ ~vino/web/usenix.196/) можно утверждать, что у этой проблемы две составляющие: техническая, связанная с изменениями самого протокола HTTP, и организационная, изменяющая структуру взаимодействия клиент-сервер в рамках технологии Web.

В чем провинился HTTP?

Данный протокол обмена гипертекстовыми фрагментами информации представляет собой одну из опор технологии World Wide Web. Протокол строится по принципу "запрос-ответ" и достаточно прост, поскольку основан на передаче сообщений ASCII. Наиболее часто встречающейся формой запроса является запрос по методу GET. Первая строка определяет метод доступа, адрес ресурса и версию протокола, вторая - полный адрес ресурса, третья идентифицирует клиента, затем следуют строки определения типов данных, поддерживаемых клиентом. Ответ сервера столь же лаконичен, как и запрос клиента. При обращении к HTML-документу обычно передается текст документа (хотя иногда ответ может иметь и другой тип, например графический файл). Структура обмена проста и лаконична.

Однако эта простота существенно повлияла на эффективность взаимодействия при использовании транспорта TCP. Дело в том, что TCP был разработан в расчете на обмен файлами по медленным линиям связи; это предполагало его использование для работы с длительными сеансами связи типа FTP или telnet. В HTTP сеансы взаимодействия клиент-сервер короткие, зато их много. Накладные расходы на установление и поддержку связи в рамках TCP обмена для HTTP оказались сравнимы c затратами на передачу собственно информации. При этом такие механизмы протокола TCP, как "окна" и определение наилучшей скорости передачи (Slow Start), в случае больших пакетов данных или длительной сессии улучшающие характеристики обмена, для HTTP практически никак не используются. Это приводит к тому, что половина времени уходит на поддержку передачи информации, а половина - непосредственно на передачу. Кроме того, современные многопоточные клиенты способны порождать одновременно несколько запросов. На каждый из этих запросов сервер вынужден отвечать созданием соответствующей процедуры обслуживания (обычно это самостоятельный процесс или поток), что может приводить к перегрузке сервера.

Для замены HTTP 1.X консорциум W3C предлагает новый протокол HTTP-NG, позволяющий клиенту за один сеанс взаимодействия отправить серверу несколько запросов в произвольном порядке. W3C предполагает, что HTTP-NG будет использоваться не только для передачи гипертекста. В новом протоколе вводится понятие сессии. Все запросы передаются по каналу управления (очень похоже на FTP), а каждый объект возвращается сервером через свой собственный канал данных. Для обмена объектами типа видео между клиентом и сервером может запускаться свой собственный протокол обмена после получения запроса сервера.

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

Кэширование и репликация

Вопрос о кэшировании, или временном хранении информации на локальном сервере либо клиенте, возник в результате осознания того факта, что большинство пользователей обращаются к одним и тем же документам. Правило "80/20", справедливое для обычных информационных систем, трансформировалось в правило "90/10" для анализа обращений пользователей к страницам WWW. В условиях нашей страны, создание временных баз данных чужой информации на локальных серверах позволяет существенно снизить время обращения к этим данным. Известны три типа построения кэша: по времени жизни документа (TTL), по обращениям пользователей и по специальным протоколам.

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

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

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

Кэширующие серверы используют многие IP-провайдеры, однако у наших специалистов, в отличие от их зарубежных англоязычных коллег, здесь могут возникать различные проблемы. Одна из них связана с перекодировкой страниц документов "на лету". Понятно, что хранить одну и ту же информацию в различных кодировках (в наших системах обычно используются три - MS-DOS, Windows и КОИ-8) довольно накладно. Поэтому при обращении клиента к странице сервер проверяет тип клиента и преобразует страницу в тот вид, который данному клиенту нужен. Но здесь иногда возникает небольшая неувязка. При обращении к исходным страницам все обычно проходит нормально, однако если к данной странице обращались и она была занесена в кэш, то иногда пользователю документ выдается в том виде, в котором он хранится в кэше, а это значит, что пользователю X-Mosaic может быть отправлен документ в кодировке для Windows.

Mosaic как сервер приложений

Еще один способ повышения эффективности WWW - предложенная NCSA спецификация Common Gateway Interface, предназначавшаяся для расширения возможностей серверов Web. В апреле 1995 года NCSA предложила новую спецификацию под названием Common Client Interface. Данный механизм определяет правила взаимодействия прикладного программного обеспечения пользователя с программой-клиентом World Wide Web. Главной целью такого взаимодействия является доступ прикладной программы посредством клиента Web к ресурсам Сети.

Механизм основывается на протоколе типа HTTP, совместимом с MIME. Прикладная программа может запросить ресурс через клиента, отобразить информацию в рабочей области программы клиента (DISPLAY), послать данные серверу (POST) и управлять процессом соединения (SEND, DISCONNECT, QUIT). При этом разработчики утверждают, что подобная спецификация может быть реализована для Unix-платформ на базе TCP/IP, для PC - TCP/IP, DDE или OLE, для MAC - TCP/IP или Apple Events. До сих пор все расширения осуществлялись либо за счет увеличения возможностей сервера, средств CGI-скриптов, либо за счет внешних программ просмотра и немногочисленных встраиваемых расширений. CCI позволяет каждому разрабатывать свои собственные Web-приложения, используя для доступа к ресурсам сети программы-клиенты. Пока же CCI - это только предложения, не получившие еще широкого применения, но, видимо, ситуация неизбежно будет меняться.