CC BY
110
УДК 621.397:004.738
ПРИМЕНЕНИЕ ДВОЙНОГО КЭШИРОВАНИЯ И КОМПРЕССИИ ДАННЫХ ДЛЯ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ РАБОТЫ КЛИЕНТ-СЕРВЕРНЫХ ПРИЛОЖЕНИЙ
И.И. Мельников, аспирант; К.А. Демиденков, аспирант; И.А. Евсеенко, к.т.н., доцент (Белорусско-Российский университет, просп.. Мира, 43, г. Могилев, 212005, Республика Беларусь,
[email protected], [email protected], [email protected])
Многие предприятия используют клиент-серверные приложения для того, чтобы их сотрудники и клиенты могли легко работать с необходимой для них информацией на локальном компьютере. При этом данная работа не должна
осложняться задержками передачи данных по сети либо длительностью их обработки центральными серверами предприятия. Ввиду расширения предприятий, создания сервисных центров в различных регионах мира и удаленных рабочих мест стала актуальной проблема обеспечения быстрого доступа клиентов к центральным серверам и ускорения тем самым работы клиент-серверных приложений. Для ее решения предложены метод двойного кэширования (на стороне клиента и на стороне сервера) с периодическим обновлением кэша на клиентской и серверной сторонах и дополнительные меры по ускорению процесса передачи данных - компрессия и шифрование. На основе этого метода разработан WAN-акселератор, который является независимым и прозрачным для использующего его клиент-серверного приложения программным модулем. Акселератор состоит из двух частей (клиентской, или акселератора-клиента, и серверной, или акселератора-сервера), между которыми устанавливается TCP-соединение. Акселератор-клиент перехватывает HTTP-запросы, идущие от клиента, и, проведя с ними операции кэширования, компрессии и шифрования, пересылает акселератору-серверу, который, в свою очередь, проводит операции их дешифрования, декомпрессии - восстановления - и кэширования и отсылает серверу. Сервер обрабатывает HTTP-запросы, генерирует HTTP-ответы, которые приходят сначала на акселератор-сервер, где они кэшируются, сжимаются и шифруются, а затем отправляются акселератору-клиенту для дешифрования, декомпрессии - восстановления - и кэширования. При перехвате HTTP-запроса, который ранее обрабатывался акселератором, HTTP-ответ на него в лучшем случае может быть возвращен из кэша акселератора-клиента (тогда экономится время на передачу запроса, генерацию и передачу ответа), в худшем - из кэша акселератора-сервера (тогда экономится время на генерацию ответа). Для оценки эффективности разработанного акселератора был проведен ряд экспериментов, суть которых заключалась в имитации работы клиент-серверных приложений целевых предприятий, то есть в отсылке HTTP-запросов и HTTP-ответов, которые перехватывались бы акселератором. Для этого были сгенерированы наборы из нескольких сотен запросов и ответов, схожих по своей структуре с запросами и ответами, передаваемыми в рамках клиент-серверных приложений целевых предприятий. Эксперименты показали, что использование акселератора позволяет снизить среднее время ожидания ответа клиентом на 14-98 % в зависимости от пропускной способности сети и частоты повторяемости идентичных запросов/ответов. Это, в свою очередь, приводит к ускорению процесса работы пользователя и увеличению ее эффективности.
Ключевые слова: клиент-серверное приложение, WAN-акселератор, двойное кэширование, компрессия, шифрование.
USING DATA COMPRESSION AND DOUBLE CACHING TO INCREASE CLIENT-SERVER APPLICATIONS OPERATING EFFICIENCY Melnikov I.I., Postgraduate Student; Demidenkov К.А., Postgraduate Student;
Evseenko I.A., Ph.D. Tech. Sc., Associate Professor (Belarusian-Russian University, Mira Av., 43, Mogilev, 212005, Belarus, [email protected], [email protected], [email protected])
Abstract. Many organizations use client-server applications in order to afford their employees and clients an opportunity to work with necessary information on their local computers. Delays of networking and data processing on the server side must not aggravate this process. The problem of accelerating client-server applications with caching and data transfer rate increase had not existed until client-server applications had became popular in wide area networks. But the problem of granting fast access to a central server and accelerating client-server applications has become important because of enterprise expansion, creation new service centers and remote desks in different regions of the world. The double caching (caching on the client side and on the server side) with periodical client/server cache update and the additional arrangements for accelerating data transfer (compression and encryption) were proposed to solve the problem. The WAN accelerator has been developed based on this method. It is an independent program module. It is transparent for a client-server application that uses it. The accelerator contains two parts: the client part (accelerator-client) and the server part (accelerator-server). The TCP connection is established between the parts. The accelerator-client intercepts client HTTP requests, caches, compresses, encrypts them and then sends them to the accelerator-server. The accelerator-server receives the requests, decrypts, decompresses, caches them and then sends the restored HTTP requests to the server. The server processes the requests and generates the HTTP responses. The accelerator-server intercepts the responses, caches, compresses and encrypts them and after that sends them to the accelerator-client. The accelerator-client receives the responses, decrypts, decompresses and caches them and after that sends the restored HTTP responses to the client. If the identical HTTP request is intercepted by the accelerator-client, the HTTP response will be extracted from the accelerator-client cache (it is the best case because there is no need to send the HTTP request to the server and wait for the HTTP response) or from the accelerator-server cache (it is the worst case because there is a need to send the HTTP request to the accelerator-server and wait for the response from its cache but there is no need to send the HTTP request to the server and wait until the response will be generated). Test series were run to evaluate operating efficiency of the accelerator. The client and server mocks were used for this purpose. The client mock was sending the test HTTP requests and the server mock was receiving the requests and generating the test HTTP responses. The accelerator was intercepting the requests and responses. The HTTP requests and responses had the same structure like the HTTP requests and responses used by the real client-server applications in the target organizations. The test series demonstrated that usage of the accelerator could decrease response time for 14-98 % depending on network bandwidth and identical re-quest\response repetition rate. The user could see that the client-server application had been working faster.
Keywords: client-server application, WAN accelerator, double caching, compression, encryption.
Сетевые технологии стали неотъемлемой частью современного общества. Благодаря им передача информации на большие расстояния перестала быть сложной задачей. В Республике Беларусь
сетевые технологии также активно используются в разных сферах. В частности, на многих предприятиях существуют локальные сети, связывающие множество автоматизированных рабочих мест с
центральными серверами, на которых хранятся и обрабатываются данные. А некоторые предприятия используют клиент-серверные приложения, разработанные специально под свои нужды и задачи, чтобы их сотрудники и клиенты могли легко работать с необходимой для них информацией на локальных компьютерах (далее под клиентом будем понимать клиентскую часть клиент-серверного приложения, работающую на локальном компьютере сотрудника или клиента предприятия, а под сервером - серверную часть на удаленном компьютере-сервере). Ввиду ограниченности локальной сети рамками предприятия (и в связи с этим низких задержек передачи информации от клиента к серверу и обратно) вопрос об ускорении передачи данных по сети и оптимизации IP-трафика не ставился. Время обработки данных значительно превышало время их передачи, поэтому больше внимания уделялось оптимизации алгоритмов обработки и наращиванию вычислительной мощности серверов для ускорения работы сотрудника предприятия на конкретном рабочем месте.
Ситуация изменилась, когда некоторые предприятия, например «МАЗ», «Атлант», начали стремительно развиваться, создавать сервисные центры, филиалы и представительства в других странах и расширять клиентскую базу. Поддерживать связь с удаленными клиентами позволила сеть Интернет, однако из-за определенной ограниченности пропускной способности каналов связи и более высокой вероятности потерь данных увеличение времени передачи данных, а вследствие этого и замедление работы клиент-серверных приложений стало ощутимой проблемой. Кроме того, многие такие приложения не включали даже технологию сжатия (компрессии) данных, так как на момент проектирования и разработки не предусматривалось их использование в рамках более широких, чем локальная сеть предприятия, которая ограничена, как правило, зданием, несколькими корпусами или небольшой территорией.
В итоге возникли две проблемы. Во-первых, необходимы были метод и инструменты для ускорения работы клиент-серверных приложений путем снижения среднего времени ожидания клиентом ответа от сервера. Во-вторых, данный метод не должен был никоим образом затрагивать логику работы существующих клиент-серверных приложений и требовать их модификации. Другими словами, была поставлена задача разработки прозрачного для клиент-серверного приложения WAN-акселератора (Wide Area Network) (будь то программный продукт или аппаратно-программный комплекс), который позволил бы сократить время ожидания ответа клиентом, особенно в нестабильных сетях или сетях с малой пропускной способностью, и при этом был бы дешевым и простым в конфигурировании [1].
Ускорение работы клиент-серверного приложения путем предупреждения
отсылки дублирующих ответов посредством двойного кэширования
Перед разработкой акселератора были проведены детальные исследования особенностей работы существующих клиент-серверных приложений, используемых целевыми предприятиями, которые столкнулись с рассмотренной выше проблемой. Выяснилось, что в большинстве случаев клиент-серверные приложения были созданы с применением технологии WinForms на базе платформы .NET, а коммуникация между клиентской и серверной частями приложения базировалась либо на web-сервисах, либо на прямой отсылке и приеме HTTP-запросов (GET/POST-запросов) и HTTP-ответов с помощью методов . NET. При этом данные передавались по сети в виде XML-сериализо-ванных объектов на базе SOAP-протокола. В большинстве случаев алгоритмы компрессии и шифрования отсутствовали, хотя степень сжатия таких данных варьировалась от 40 до 80 %, поэтому прежде всего было предложено применить в рамках акселератора современные алгоритмы компрессии и шифрования. Но в ходе исследований была замечена еще одна существенная деталь. В приложениях в среднем 50 % ответов сервера клиенту дублировались в течение 3 часов, то есть клиент многократно запрашивал данные от сервера, которые не претерпели никаких изменений в течение 3 часов.
Необходимо было предложить способ снижения количества повторяющихся запросов/ответов, чтобы не тратить время на ожидание обработки сервером и передачу клиенту одних и тех же данных, которые можно было бы хранить в кэше. Поэтому был предложен метод двойного кэширования, то есть кэширование данных на стороне клиента и на стороне сервера. Такое решение приводит к избыточности, так как информация дублируется на стороне клиента и на стороне сервера. Однако, как будет показано далее, двойное кэширование совместно с периодическим обновлением кэша клиента и сервера позволит значительно снизить среднее время ожидания клиентом ответа от сервера.
Разработанный акселератор, как и клиент-серверное приложение, состоит из двух частей: клиентской (далее акселератор-клиент) и серверной (далее акселератор-сервер), между которыми устанавливается TCP-соединение (рис. 1). Он представляет собой прокси-сервер, через который осуществляется передача данных между клиентской и серверной частями приложения. И акселератор-клиент, и акселератор-сервер имеют свой собственный кэш в оперативной памяти либо на жестком диске компьютера-клиента и компьютера-сервера соответственно, то есть кэширование
Рис. 1. Архитектура акселератора
информации происходит как на стороне клиента, так и на стороне сервера.
При перехвате НТТР-запроса от клиента акселератором-клиентом для него формируются постоянный уникальный ключ, который создается путем хеширования строки URI запроса и, если это POST-запрос, его тела, а также временный уникальный ключ, сгенерированный случайным образом. Под временным ключом копия запроса помещается в кэш акселератора-клиента, а сам запрос направляется дальше акселератору-серверу. Акселератор-сервер получает запрос, помещает его копию под временным ключом, который в общем случае не совпадает с аналогичным ключом на клиенте, в свой кэш, вычисляет постоянный ключ, который будет совпадать с аналогичным ключом на клиенте, и направляет запрос web-сервису либо процессу-слушателю, находящемуся на стороне сервера. Web-сервис либо процесс-слушатель генерирует ответ, который приходит сначала акселератору-серверу. Последний на базе тела ответа вычисляет хеш-код, затем помещает этот код и копию ответа в кэш, связывая его с соответствующим кэшированным запросом, присваивает паре запрос-ответ постоянный ключ (временный ключ удаляется) и отсылает ответ акселератору-клиенту, который осуществляет аналогичную операцию, направляя затем ответ клиенту. Таким образом, каждый запрос и ответ на него кэшируются дважды: на клиенте и на сервере.
В случае перехвата акселератором-клиентом нового запроса последний вычисляет его хеш-код по указанному выше правилу и осуществляет поиск этого запроса по постоянному ключу в своем кэше. Если пара запрос-ответ с идентичным хеш-кодом (идентичным постоянным ключом) найдена в кэше, то акселератор-клиент посылает данный хеш-код акселератору-серверу. Тот, получив хеш-код запроса, ищет соответствующую пару запрос -ответ в своем кэше. Если такая пара имеется, то акселератор-сервер отсылает назад хеш-код ответа. Акселератор-клиент получает хеш-код ответа и
сверяет с аналогичным кодом у себя в кэше. Если коды идентичны, значит, ответ не изменился на сервере, поэтому акселератор-клиент возвращает ответ конечному клиенту из собственного кэша, не затрачивая время на отсылку запроса серверу и ожидание ответа на него. При этом акселератор-сервер сразу же после отсылки хеш-кода ответа посылает запрос, который находится в его собственном кэше, web-сервису либо процессу-слушателю, чтобы обновить соответствующий ответ. Другими словами, акселератор-сервер асинхронно обновляет собственный кэш с тем, чтобы данные в нем были как можно актуальнее. Клиенту же будет казаться, что ответ пришел почти мгновенно, так как размер хеш-кода весьма мал (32 байта) и обмен хеш-кодами акселератора-клиента и акселератора-сервера занимает очень короткое время.
В случае повторного перехвата акселератором-клиентом идентичного запроса хеш-код ответа, хранящегося в его собственном кэше, и хеш-код обновленного ответа, хранящегося в кэше акселератора-сервера, могут различаться. Это повлечет за собой передачу запроса от акселератора-клиента акселератору-серверу, чтобы обновить ответ в кэше акселератора-клиента и вернуть его более актуальную версию клиентскому приложению. Акселератор-сервер отошлет ответ из своего собственного кэша, а затем пошлет запрос web-сервису либо процессу-слушателю, чтобы снова обновить ответ. В этом случае и запрос, и ответ на него проходят по сети, однако определенная экономия времени будет и здесь, так как акселератору-серверу не нужно ждать, пока web-сервис либо процесс-слушатель обработает запрос, ведь, как было сказано выше, акселератор-сервер асинхронно обновляет свой кэш, осуществляя предза-грузку данных, которые понадобятся клиенту.
Такие архитектура и схема работы акселератора позволят значительно сократить время ожидания ответа на часто повторяемые идентичные запросы клиента, на которые приходят ответы с со-
держимым, обновляемым неинтенсивно либо не обновляемым вообще. Также асинхронное обновление кэша акселератора-сервера может значительно снизить задержки в ожидании ответа клиентом, вызванные длительностью обработки запроса web-сервисом либо процессом-слушателем (например, выборка из большого массива данных, проведение сложных расчетов и т.п.). Наличие же временных ключей позволит избежать конфликтов в случае одновременного получения идентичных запросов от нескольких клиентов в акселераторе-клиенте или нескольких акселераторов-клиентов в акселераторе-сервере.
Очевидный недостаток такой схемы состоит в том, что всегда остается вероятность хранения на стороне акселератора-сервера неактуальных данных. Снизить эту вероятность может помочь независимое асинхронное обновление кэша акселератора-сервера через определенные промежутки времени, причем для каждого запроса существует свой собственный таймер, чтобы избежать значительного роста нагрузки на web-сервис либо процесс-слушатель в случае, если бы обновлялся весь кэш целиком в один и тот же момент времени.
Эксперименты и обсуждение их результатов
Для тестирования и подтверждения эффективности разработанного акселератора были проведены эксперименты с использованием запросов и ответов, схожих по своей структуре с теми, что используются в работе клиент-серверных приложений целевых предприятий. Эксперименты были разделены на две группы: проводимые с использованием хорошо сжимаемых данных (степень сжатия свыше 90 %) и проводимые с использованием трудносжимаемых данных (степень сжатия менее 10 %).
Поскольку клиент-серверные приложения целевых предприятий работают под управлением операционных систем семейства Windows, для разработки акселератора использовалась платформа .NET на базе стандартных библиотек .NET Framework 3.5 Service Pack 1. При проведении экспериментов акселератор-клиент и акселератор-сервер работали на разных компьютерах в пределах одной локальной сети. На стороне акселератора-сервера была установлена операционная система Windows Server 2008 R2, на стороне акселератора-клиента - Windows 7 Ultimate.
Компьютеры, использовавшиеся для проведения экспериментов, располагались на малом расстоянии друг от друга, а сама сеть обладала высокой пропускной способностью и помехозащищенностью, поэтому было принято решение использовать дополнительный компьютер. Он должен был стать посредником при передаче сигнала от сервера клиенту и наоборот, и с помощью
специального программного средства WANem (Wild Area Network Emulator) имитировалась сеть с различной пропускной способностью и помехоустойчивостью (рис. 2) [2].
Компьютер-клиент
Эмулятор клиента
I
Акселератор-
Wide Area Network Emulato (WANem)
Компьютер-сервер Эмулятор
сервера
Акселератор-
îcepBT
-» HTTP-запрос ■■■» HTTP-ответ
■-> TCP-запрос -■о TCP-ответ
Рис. 2. Схема экспериментальной компьютерной сети
Размер запроса для экспериментов первой группы варьировался от 200 Кбайт до 1,5 Мбайта, а ответа - от 8 Мбайт до 12 Мбайт. Такие размеры идентичны размерам несжатого запроса и ответа клиент-серверных приложений исследуемых предприятий.
Размер запроса для экспериментов второй группы варьировался от 200 до 600 Кбайт, а ответа - от 800 Кбайт до 1,2 Мбайта. Такие размеры идентичны размерам сжатого запроса и ответа клиент-серверных приложений исследуемых предприятий.
Также в обоих случаях варьировалась пропускная способность сети в диапазоне от 512 Кбит/с до 4 Мбит/с (а именно 512 Кбит/с, 1 Мбит/с, 2 Мбит/с, 4 Мбит/с), так как сети с таким диапазоном пропускной способности наиболее часто используются на территории Беларуси.
Поскольку основной задачей разработанного акселератора является ускорение работы клиент-серверного приложения независимо от пропускной способности и состояния сети, все эксперименты проводились как на стабильной, так и на нестабильной сети, где могут происходить потери, искажение и дублирование пакетов. Для нестабильной сети были взяты следующие параметры: задержка передачи пакетов - 250 мс, доля потерянных пакетов - 5 %, доля дублирующихся пакетов - 7 %, доля поврежденных пакетов - 10 %. Такие величины были выбраны потому, что потеря всего 5-10 % пакетов в сети может привести к значительному снижению скорости передачи данных по протоколу TCP и тем самым сделать работу клиент-серверного приложения довольно медленной, если вообще возможной [3, 4].
На рисунке 3а показан график влияния двойного кэширования и компрессии на среднее время ожидания клиентом ответа при передаче данных по стабильной сети.
Как видно из рисунка 3 а, среднее время передачи несжатых данных без кэширования является
Среднее время ожидания ответа клиентом, с Среднее время ожидания ответа клиентом, с зоооооооооо ----- ----- ----- ----- ----- ----- -----
--- -- — — - --- -----
\
—-
Л Ч\
ч \
----- -----
••• • • .
500 1000 1500 2000 2 500 3000 3 500 4000 4500 0 Пропускная способность сети, Кбит/с а) 500 1000 1500 2000 2500 3000 3 500 4000 4 500 Пропускная способность сети, Кбит/с б)
0 X ф S § 100 (С m И 10 s X (С ч и i к 1 а 10000 CD X ф S § 1000 (С m 0 к 100 s X (С 4 5 1 10 к 1 а в
—- ---- -----
■ • • • - — — -
0! 0) 1 £ 0 500 1000 1500 2000 2500 3000 3500 4000 4500 £ 0 500 1000 1500 2000 2500 3000 3500 4000 4500 дн дн ее рр рС С Пропускная способность сети, Кбит/с Пропускная способность сети, Кбит/с Несжатые данные Несжатые данные без кэширования ------- Сжатые данные без кэширования ------- Сжатые данные без кэширования _ , — — — — Сжатые данные с кэшированием (повторяемость 20%) — — — — Сжатые данные с кэшированием (повторяемость 20%) м ^ ^ = в Сжатые данные с кэшированием (повторяемость 50%) = в Сжатые данные с кэшир°ванием (повторяемость 50%) .......Сжатые данные с кэшированием (повторяемость 80%) .......Сжатые данные с кэшированием (повторяемость 80%) в) г) Рис. 3. Влияние двойного кэширования и компрессии на среднее время ожидания ответа клиентом при передаче трудносжимаемых данных: а) по стабильной сети, б) по нестабильной сети и хорошо сжимаемых данных: а) по стабильной сети, б) по нестабильной сети
самым большим и варьируется от 24 с до 4 с в зависимости от пропускной способности сети. Интересно отметить, что избирательная компрессия трудносжимаемых данных без участия кэширования не снизила, а в некоторых случаях даже увеличила среднее время передачи, что связано с затратами времени на сам процесс сжатия. Тот небольшой выигрыш во времени передачи сжатых данных нивелируется временем их сжатия. В данном случае более значимым является влияние двойного кэширования запросов/ответов. Очевидно, что, чем выше частота повторяемости идентичных запросов/ответов, тем выше эффективность работы акселератора. Так, при пропускной способности сети в 512 Кбит/с и частоте повторяемости идентичных запросов/ответов в 20 % среднее время ожидания ответа клиентом, то есть время, прошедшее с момента отсылки первого байта запроса до момента приема последнего байта ответа, составляет 20 с. При частоте повторяемости идентичных запросов/ответов в 80 % оно становится равным 9 с. Таким образом, при применении акселератора для передачи трудносжи-маемых данных по стабильной сети среднее время ожидания ответа клиентом снижается на 17-79 % в зависимости от пропускной способности сети и частоты повторяемости идентичных запросов/ответов. Следует еще раз отметить, что среднее время ожидания ответа клиентом снижается вследствие не роста скорости передачи, а того, что часть запросов/ответов просто не передается по сети, так как актуальный ответ извлекается из кэша акселератора-клиента и возвращается практически мгновенно в клиентское приложение.
Такая же ситуация наблюдается и при работе в нестабильной сети (рис. 3б). В этом случае эффективность акселератора выше, поскольку при высокой частоте повторения идентичных запросов/ответов большинство ответов возвращается из кэша акселератора-клиента, то есть снижается частота отсылки запросов и получения ответов клиентом по нестабильной сети, скорость передачи данных в которой гораздо ниже, чем в стабильной сети.
Следует обратить внимание на степень изогнутости кривых на графике (рис. 3б). Она значительно меньше, чем в предыдущем случае, то есть рост пропускной способности в данном случае ведет к незначительному снижению среднего времени передачи запросов/ответов. Это связано с особенностями протокола TCP, в рамках которого используется специальный алгоритм «предотвращения перегрузки» (Congestion Avoidance) [5]. Этот алгоритм резко снижает скорость передачи вне зависимости от пропускной способности канала, пока пакеты не перестанут теряться, а затем начинает медленно повышать ее до тех пор, пока снова не начнутся потери.
Из рисунка 3б видно, что среднее время ожидания ответа клиентом при использовании акселератора в нестабильной сети снижается на 14-80 % в зависимости от пропускной способности сети и частоты повторяемости идентичных запросов/ответов.
Эффективен акселератор и при передаче хорошо сжимаемых данных (степень сжатия более 80 %) как в стабильной, так и в нестабильной сети (рис. 3в и 3г).
Как видно из рисунка 3в, акселератор позволяет снизить среднее время ожидания ответа клиентом на 86-98 % в стабильной сети в зависимости от пропускной способности и частоты повторяемости идентичных запросов/ответов. В нестабильной сети (рис. 3г) среднее время ожидания ответа клиентом может быть снижено на 98 %.
Проведенные эксперименты затронули два крайних случая: большое количество редко повторяющихся трудносжимаемых запросов/ответов и большое количество часто повторяющихся хорошо сжимаемых запросов/ответов. В обоих случаях акселератор позволил сократить среднее время ожидания ответа клиентом и ускорить его работу. Однако следует отметить, что эффективность работы акселератора зависит от того, насколько хорошо сжимаемые и часто повторяющиеся запросы/ответы используются в целевых клиент-серверных приложениях. При использовании акселератора среднее время ожидания ответа клиентом может быть снижено на 14-98 % (см. табл.).
Процент снижения среднего времени ожидания ответа клиентом при использовании акселератора
Пропускная способность Частота повторяемости сжатых данных
сети, Кбит/с 20 % 50 % 80 %
Передача трудносжимаемых данных в стабильной сети
512 17 46 63
1024 23 46 62
2048 25 57 75
4096 29 63 79
в нестабильной сети
512 15 44 77
1024 14 43 78
2048 14 45 79
4096 14 45 80
Передача хорошо сжимаемых данных в стабильной сети
512 98 98 98
1024 97 98 98
2048 94 97 98
4096 86 93 96
в нестабильной сети
512 98 98 98
1024 98 98 98
2048 98 98 98
4096 98 98 98
Для конечного пользователя это выглядит как ускорение работы клиент-серверного приложения, что приводит к повышению эффективности его труда.
Литература
1. Rose M. WAN accelerator. SearchEnterpriseWAN. URL: http://searchenterprisewan.techtarget.com/definition/WAN-accele-rator (дата обращения: 16.01.2013).
2. Nambiar M. WANem: The Wide Ares Network emulator. Performance Engineering Research Centre, Mumbai, 2009. URL: http://wanem.sourceforge.net/ (дата обращения: 16.01.2013).
3. Kurose J.F., Ross W.R. Computer Networking: A Top-Down Approach. NY: Addison-Wesley, 2009, 864 p.
4. Камер Д.Э. Сети TCP/IP: Принципы, протоколы и структура. М.: Вильямс, 2003. Т. 1. 851 с.
5. Jacobson V., Karels M.J. Congestion Avoidance and Control. Proc. SIGCOMM'88. Stanford, CA: Stanford ACM, 1988.
References
1. Rose M. WAN accelerator. SearchEnterpriseWAN. Available at: http://searchenterprisewan.techtarget.com/definition/WAN-accelerator (accessed 16 January 2013).
2. Nambiar M. WANem: The Wide Ares Network emulator. Performance Engineering Research Centre, Mumbai, 2009. Available at: http://wanem.sourceforge.net/ (accessed 16 January 2013).
3. Kurose J.F., Ross W.R. Computer Networking: A Top-Down Approach. NY, Addison-Wesley Publ., 2009, 864 p.
4. Comer D.E. Internetworking with TCP/IP. 4th ed., Prentice Hall Publ., vol. 1, 2000, 750 с. (in Russ.).
5. Jacobson V., Karels M.J. Congestion Avoidance and Control. Proc. SIGCOMM'88. Stanford, CA, Stanford ACM Publ., 1988.
Уважаемые авторы!
Рекомендации по оформлению статей размещены на сайте www.swsys.ru.
