Не числом, а уменьем

Оптимизация трафика Internet.

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

ИСТОКИ ПРОБЛЕМЫ

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

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

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

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

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

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

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

НАВОДИМ ПОРЯДОК

Самый эффективный способ решить проблему работы серверной фермы, как единого ресурса, — поставить при входе на ферму специальное устройство, чтобы оно, во-первых, маскировало IP-адреса серверов, предоставляя вовне единый, так называемый виртуальный IP-адрес, а во-вторых, равномерно распределяло нагрузку между серверами. Примерами таких устройств могут служить LocalDirector от Cisco и WebSite Director (WSD) от Radware. По сути, эти устройства работают как proxy-серверы, с той только разницей, что proxy-серверы не распределяют равномерно запросы между разными серверами. Главная задача — определение политики распределения нагрузки, которая может зависеть, в частности, от мощности каждого из серверов. Однако предоставление одного виртуального адреса на группу серверов и рациональное распределение между ними запросов — это только часть решаемой задачи.

В большинстве случаев пользователю действительно все равно, какой конкретно физический сервер предоставляет ему информацию, лишь бы URL был верный и данные доставлялись оперативно. Но так бывает не всегда. В случае ресурсов с динамически меняющимся содержимым или когда благодаря механизму «плюшек» сервер «запоминает», в каком месте был прерван предыдущий сеанс общения с пользователем, и начинает новый сеанс с того, на чем он остановился некоторое время назад, оказывается важным, чтобы персональная информация не терялась. Механизм «плюшек» поддерживается решениями как Radware, так и Cisco. Для примера мы рассмотрим, как реализована поддержка «плюшек» в LocalDirector.

LocalDirector может работать в двух режимах. В первом он просматривает запросы HTTP. Если сервер сочтет нужным установить у клиента «плюшку», то LocalDirector зафиксирует эту строку и будет знать о привязке физического сервера к физическому клиенту. Как только LocalDirector через некоторое время зафиксирует обращение того же самого клиента к ресурсу, который требует перед установкой сеанса ознакомления с «плюшкой», имеющей соответствующий идентификатор, он переадресует запрос на нужный сервер, и все дальнейшие запросы этого сеанса будут переадресовываться туда же.

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

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

Каким бы интеллектуальным не было распределение нагрузки, оно имеет смысл только в том случае, если запросы от пользователей передаются на серверы, которые в состоянии их обслужить. Всегда существует риск, что на одном из направлений может случиться сбой — проблемы возникают как на серверах (например, из-за программного обеспечения), так и с каналами (обрыв). В такой ситуации устройство, обеспечивающее распределение нагрузки в рамках серверной фермы, должно установить факт аварии и передавать запросы только на работающие серверы. Самый простой способ выяснения факта работоспособности соответствующего сервера — проверка соединения TCP/IP. На элементарном уровне это ping, но даже успешный ping не дает полной гарантии, что все в порядке с самим сервером. Таким образом, требуется более надежная проверка.

LocalDirector, например, можно настроить так, чтобы он проверял способность сервера нормально устанавливать соединение, сообразно типу сервера (в зависимости от платформы и приложений), и на основе расширенного отклика определял, все ли с ним в порядке. При этом, как только что отмечалось, LocalDirector учитывает специфику отклика на разных платформах и возможные «странности» поведения стека TCP/IP на серверах. Radware идет несколько дальше, проверяя надежность полной цепочки в трехзвенной архитектуре, если таковая служит. Когда, например, сервер Web используется в качестве промежуточного звена, скажем, интерфейса к корпоративной базе данных, абсолютная работоспособность самого сервера Web еще не гарантирует того, что запрос пользователя будет обработан должным образом (а это и есть конечная цель, ради которой реализуется решение). Поэтому WSD проверяет и способность конечного «внутреннего» звена трехзвенной архитектуры ответить на запрос. В общем случае проверяется также его соединение TCP/IP, а для некоторых приложений может быть проверен и базовый запрос (функционирование стека IP не гарантирует работы самого приложения, которое может «зависнуть» или «слететь»).

Наконец, не стоит забывать о том, что само устройство распределения нагрузки также несовершенно и подвержено риску выхода из строя. Или, если с устройством все в порядке, могут подвести каналы связи (внутренние или наружные). Иметь хорошую избыточность на серверной ферме и при этом единственную точку входа в нее нерационально, поэтому и WSD, и LocalDirector поддерживают «горячее» резервирование. Это означает, что на входе в систему могут одновременно работать два одинаковых устройства, взаимно резервирующих друг друга. Когда оба устройства нормально функционируют, они разделяют между собой входящий трафик. При этом они постоянно обмениваются таблицами с данными о клиентах и серверах, таким образом в памяти у них хранятся копии таблиц соседа. Постоянное «общение» также является средством взаимной проверки работоспособности. Если одно из устройств выходит из строя, то второе способно прозрачным для пользователей образом взять на себя его обязанности, будучи информировано о том, какие соединения обслуживал «сосед».

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

WSD также обладает дополнительной защитной функцией предотвращения атак DDоS (Distributed Denial of Service). Если сформулировать коротко, эта атака в TCP/IP — не что иное как забрасывание сервера «пустыми» запросами на соединение. С какого-то момента поток таких запросов переполняет стек TCP/IP сервера, и тот оказывается не в состоянии отвечать на обычные запросы. Причем сам сервер может и не зависнуть (хотя вероятность этого велика), и тогда последствия атаки будут заметны не сразу. Выявив слишком большую долю пустых запросов, WSD сбрасывает их с обеих сторон, освобождая свой стек и посылая соответствующие пакеты сброса соединения на серверную ферму. Заметим, что серверная ферма, очевидно, более устойчива к DDoS, чем один сервер (вследствие распределения нагрузки), поэтому на начальном этапе атаки, т. е. до обнаружения, она не может принести сколь-либо заметного вреда

Как мы уже отмечали, в полную конфигурацию портала Internet (у провайдера или же корпоративного заказчика) могут входить также кэширующие серверы (кэш-машины) и межсетевые экраны. Оба типа устройств, по сути, являются специализированными серверами, и к ним также применим принцип распределения нагрузки. В общем и целом, основная идея работы с этими серверами такая же, как и с серверной фермой, но есть несколько существенных отличий. Если из соображений масштабируемости и надежности на входе в сеть установлено несколько межсетевых экранов, то в идеале распределение нагрузки между ними должно осуществляться с обеих сторон. В отличие от случая серверных ферм, когда инициатором запроса является всегда внешний пользователь, здесь запросы поступают с обеих сторон экрана. Таким образом, если мы хотим получить полностью сбалансированное решение, нам придется установить устройства распределения нагрузки (такие, как FireProof Radware) с обеих сторон группы межсетевых экранов. Речь идет, как минимум, о двух устройствах, а в конфигурации с резервированием — уже о четырех. (Кроме того, естественно, способ взаимодействия устройства распределения нагрузки с обслуживаемыми серверами несколько отличается в деталях — чтобы нормально функционировать, межсетевые экраны должны получать «неискаженный» трафик.)

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

Как видим, оптимизировать работу Internet-приложений в своем «подсобном хозяйстве» можно по всем фронтам. Однако и это еще не все.

ШИРЕ МАСШТАБЫ

Задача оптимизации трафика Internet не ограничивается только случаем локальных серверных ферм. Одной из особенностей Internet является распределение ресурсов в рамках глобальной сети. Самый очевидный пример — это так называемые «зеркала» сайтов. Например, количество «зеркал» одного из самых популярных Internet-архивов условно-бесплатного программного обеспечения Tucows исчисляется десятками, если уже не перевалило за сотню. Тот, кто желает воспользоваться соответствующим ресурсом, может выбрать одно из наиболее близких к нему «зеркал». Для этого он должен зайти в соответствующий раздел сайта и выбрать из списка то «зеркало», которое представляется ему наиболее «быстрым». Однако, как показывает практика, иногда с точки зрения скорости передачи далекая Америка оказывается ближе Европы или даже родной России. Поскольку тиражирование в виде «зеркал» в Tucows осуществляется почти исключительно на некоммерческой и достаточно неформальной основе владельцами локальных Internet-ресурсов (и список «зеркал» постоянно то приобретает, то теряет адреса), выбор нужного «зеркала», скорее всего, будет и в дальнейшем производиться именно путем угадывания (или на основе имеющегося опыта).

Однако, если речь идет об ресурсах Internet, целиком подконтрольных одной компании, этот процесс можно попытаться оптимизировать. Идеальный случай — пользователь набирает один адрес, а оказывается там, где ближе, причем не с точки зрения географии, а с учетом всех непредсказуемых особенностей маршрутизации трафика Internet на конкретный момент. Интуитивно понятно, что формально подход должен быть таким же, как при распределении нагрузки между серверными фермами. Пользователь, набирая известный ему адрес (URL), попадает на одну точку входа, а оттуда перенаправляется на адрес реальный. Разница только в том, что логика переадресации будет уже иной. А, кроме того, в «локальном» случае, какой бы ни была конечная точка, устройство пропускает трафик через себя (и «за себя»); если же речь идет о глобально распределенных ресурсах, то переадресацию надо осуществлять уже на удаленные серверы. Cisco и Radware предлагают для решения этих задач устройства DistributedDirector и WSD-DS (смысл последних двух букв очевиден) соответственно.

Рисунок 1. WSD определяет лучший путь методом триангуляции.

Общий принцип работы обоих устройств примерно одинаков, хотя и существуют некоторые отличия. Основная задача при обслуживании запроса пользователя — вычисление расстояния от него до всех «зеркал», причем под расстоянием понимается скорость отклика. Очевидно, что, находясь в стороне ото всех потенциальных участников сеанса TCP/IP, определить его невозможно, поэтому измерения требуется производить со стороны «зеркал». Radware предлагает использовать на каждом «зеркале» WSD-DS. Каждое «зеркальное» устройство получает запрос от главного, проводит соответствующие измерения и посылает ему результат. Главное устройство выбирает наилучший из них и перенаправляет клиента на соответствующий адрес. Механизм переадресации может быть разным, его мы коснемся чуть позже (см. Рисунок 1). Очевидно, что при наличии нескольких серверных ферм использование WSD-DS (устройство способно выполнять функции и «локального» WSD) становится весьма эффективным, однако в случае распределенных одиночных серверов (а может быть и такая ситуация) такой подход становится не очень экономичным. DistributedDirector, в свою очередь, не имеет «локальной» функциональности, но при этом не требует и наличия своих двойников на каждом «зеркале».

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

Вместо этого Cisco предлагает использовать на граничных маршрутизаторах «зеркал» агенты, поддерживающие специальный протокол DRP (см. Рисунок 2). Именно эти агенты и производят измерения (определение Distributed, т. е. распределенный, в названии устройства, в свете такого подхода становится легко объяснимым). Разумеется, для того, чтобы агенты работали, граничные маршрутизаторы должны быть от Cisco. Это ограничивает применение данного подхода, поэтому Cisco дополняет его менее точным, но уже не зависящим от того, какие маршрутизаторы стоят в сети, методом анализа топологии. DistributedDirector анализирует топологию маршрутизации в сети, выбирая в качестве сервера назначения тот, путь от которого до клиента имеет в рамках этой топологии наименьшую длину (см. Рисунок 3). Не очень точно (все же загрузка маршрутизаторов не учитывается), но вполне корректно в некотором приближении. Кроме того, будучи устройством, не привязанным к конкретному сайту, DistributedDirector может обслуживать несколько доменов одновременно.

Рисунок 3. Для наиболее точного выбора пути DistributedDirector требует работы агентов.

WSD-DS, в принципе, тоже способен поддерживать одиночные удаленные серверы-«зеркала», но только если они используются как удаленный резерв основного ресурса. Если серверная ферма на входе испытывает перегрузку, то WSD-DS перенаправит входящий трафик на удаленный сервер. Естественно, такой режим работы автоматически предполагает, что перегрузка носит временный взрывной характер, и через некоторое время основная ферма снова сможет обслуживать запросы, а «зеркало» снова перейдет в резерв. Дело в том, что WSD-DS сможет выяснить доступность удаленного сервера, но его загрузку определить не в состоянии (весь трафик пойдет напрямую между сервером и клиентами), так что есть риск перегрузки удаленного сервера при слишком долгом использовании. Кстати, возможность задать входной порог нагрузки делает более эффективным и выбор наилучшего «зеркала». WSD-DS перегруженного зеркала сообщит о том, что «мест нет», и даже, если «зеркало» находится ближе всего к клиенту, переадресация произойдет не на него, а на следующее по списку «зеркало».

Теперь коснемся вкратце механизма переадресации. В случае протокола HTTP — все весьма просто: поддержка переадресации заложена в сам протокол, поэтому клиенту достаточно послать соответствующий ответ HTTP, и он в дальнейшем будет работать уже с «зеркалом». Но когда речь идет о других протоколах (ftp, например), такой подмоги уже не будет. Здесь WSD-DS и DistributedDirector выступают в роли серверов DNS (для этого их надо зарегистрировать с соответствующими полномочиями на первичном доменном сервере). Получая запрос на домен, они, произведя необходимые вычисления, выдают наилучший IP-адрес. WSD-DS в ответ на запрос выдает всегда два IP-адреса («зеркала» и свой) на тот случай, если за время сеанса «зеркало» по какой-то причине пропадет. Если бы адрес был только один, то ближайший к клиенту сервер DNS упорно предлагал бы ему из своего кэша неактуальный адрес; если же в кэше будет два адреса, то в таком случае клиент сможет вернуться к главной точке входа.

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

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

А ЧТО У НАС?

Известна проблема, известно ее решение, но насколько актуальна задача оптимизации трафика Internet в нашей стране? Чтобы ответить на этот вопрос, надо попытаться понять, в какой степени распространены у нас критически важные для бизнеса приложения, использующие Internet. Собственно Internet-экономика в России находится как минимум в зачаточном состоянии, что не удивительно, учитывая состояние экономики «офф-лайновой». Поэтому говорить о том, что рынок просто жаждет заполучить решения, о которых шла речь выше, не приходится. Тем не менее в какой-то степени у нас представлены все или почти все виды бизнеса, где Internet используется в качестве интерфейса с клиентами и/или партнерами. Основной вопрос — насколько представители каждой из этих категорий бизнеса нуждаются в оптимизации своих порталов Web и готовы инвестировать в них средства?

Чтобы найти ответ на данный вопрос, прежде всего следует оценить степень важности приложений Internet для различных категорий бизнеса. Очевидно, что более критичны такие приложения для компаний, единственным средством ведения бизнеса которых является Internet. Два самых крупных по представительности направления в этой категории — это Internet-магазины и так называемые контент-провайдеры. Как ни парадоксально, именно данная категория заказчиков пока что наименее заинтересована в решениях для оптимизации трафика Internet. Бизнес магазинов пока что еще не вышел на тот уровень, при котором нет отбоя от клиентов. Соответственно, потребность в повышении производительности порталов пока не актуальна, равно как и необходимые для этого средства. У контент-провайдеров, в принципе, такая потребность есть, но поскольку их бизнес носит весьма виртуальный характер (товаром является либо предоставляемая информация, либо обеспечиваемая ею посещаемость сайтов, т. е. аудитория для баннерной рекламы), то и экономические отношения здесь имеют характер не менее виртуальный. В силу этого оказывается проще идти экстенсивным путем (например, у таких компаний нередко складываются специфические экономические отношения как с провайдерами, так и с компаниями другого профиля), поскольку такой подход наиболее удобен.

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

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

Кроме того, не стоит забывать о корпоративном секторе. Идея корпоративных порталов Web приобретает в настоящий момент большую популярность. Порталы используются как для обслуживания внутрикорпоративных потребностей, так и для предоставления доступа к актуальной информации партнерам и клиентам. Отчасти это вариации на тему Intranet, отчасти — реализация принципа B2B. Но в любом случае если бизнес серьезный (а к таким решениям склоняются преимущественно очень крупные заказчики), то проблему оптимизации трафика Internet решать придется очень скоро. Учитывая географию нашей страны, можно предполагать, что и решения в области оптимизации трафика до распределенных ресурсов выглядят в наших условиях достаточно перспективными.

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

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

ЗАКЛЮЧЕНИЕ

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