Компрессия на лету

Как бы далеко вперед ни шагали технологии, обеспечивающие передачу данных, основным критерием оценки «быстро—медленно» остается человеческое терпение. Зарубежные исследователи пришли к выводу, что клиенты Интернет-магазина и просто среднестатистические посетители сайта готовы ждать загрузки Web-страницы не более 7—8 с. Если за это время она не откроется, то потенциальный клиент будет потерян для фирмы, поскольку предпочтет более расторопного конкурента. Каким же образом можно сохранить аудиторию? Как побыстрее получить искомую информацию? Именно эти вопросы и вызывают в основном головную боль системных администраторов и Web-мастеров, стремящихся привлечь на свой сайт новых посетителей.

Несколько лет назад, еще до того как модемы с пропускной способностью 56 кбит/с получили широкое распространение, существовало неписаное правило делать html-страницы размером не более 20—25 Кбайт, что было обусловлено опять же лимитированием времени ожидания информации. Сейчас требования к допустимому объему Web-документов не столь строги. Растет число высокоскоростных модемов у населения, расширяются корпоративные сети фирм, имеющих, как правило, свой достаточно широкий канал связи.

Понятно, что в нашей стране законы развития WWW имеют некоторые национальные особенности. Во многих случаях мы оцениваем информацию, пусть даже получаемую в час по чайной ложке, гораздо выше, чем затраченное время. Так уж сложилось, что стоимостные оценки у нас и на Западе вначале были различными. Видимо, это было связано с разницей в заработной плате. Но оставим исследование данного вопроса философам и экономистам — пусть они ломают головы и перья, а мы отметим, что ныне и для нас время ожидания в пределах 8 с становится актуальным. Любой Web-издатель понимает, что его цель — минимизировать «накладные расходы» при доставке информации адресату. Много ли способов добиться этого, сказать пока сложно. Можно, конечно, уменьшать количество картинок на html-странице, пытаться отыскать оптимальный формат для графических файлов, оптимизировать html-код или прибегать к каким-либо иным ухищрениям Web-дизайна. Кроме того, можно улучшать аппаратные характеристики серверов и подключений к каналам Интернета. Но, на мой взгляд, самый действенный метод — введение дополнительной компрессии Web-трафика.

Схема запроса и выдачи документов в Интернете выглядит следующим образом. Клиентское ПО (какой-либо браузер) посылает по протоколу HTTP запрос Web-серверу с указанием адреса того html-документа, который хочет увидеть пользователь. Web-сервер анализирует полученный запрос и отсылает требуемый файл. Такое взаимодействие прозрачно для пользователя, и он может наблюдать за процессом, ориентируясь на строку состояния браузера.

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

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

Проанализируем рис. 1.

Рис. 1. Различные подключения

Два одинаковых аналоговых модема 5 и 6 подключены к Интернету: модем 5 — непосредственно к модемному пулу 4 провайдера Интернет-услуг (2), модем 6 — к филиалу (3) провайдера, соединенному с основной точкой доступа низкоскоростным цифровым каналом связи с пропускной способностью 64 кбит/с. В качестве филиала может выступать как удаленный населенный пункт, так и офис какой-нибудь городской фирмы. Связь в данном случае будет поддерживаться, например, по каналам ISDN (сеть интегрированных цифровых услуг).

Примем, что прокси-серверы с кэшированием отсутствуют. Тогда при запросе владельцами модемов одного и того же документа с Web-сервера 1 произойдет следующее. Получив http-запрос, Web-сервер отправит требуемый документ пользователю. Передача ведется в транспортных единицах, соответствующих стеку протоколов TCP/IP, на котором основано взаимодействие в Интернете, а именно в IP-дейтаграммах. А поскольку и Web-серверы, и провайдеры Интернет-услуг обычно подключены к транспортным подсетям через высокоскоростные соединения, то все IP-пакеты быстро дойдут до аппаратуры 2, а затем начнут продвигаться к модемам со скоростью подсоединения. Кстати, в этом-то и заключается проблема «последней мили». Не имеет значения, какие каналы у всего мира, информация будет приходить к вам настолько быстро, насколько хорошим соединением вы обладаете. Следовательно, при полностью свободных каналах связи владельцы модемов 5 и 6 будут получать информацию почти с одинаковой скоростью. Иное дело, когда применяется компрессия передаваемого трафика.

Например, Web-сервер 1 настроен таким образом, что когда ему присылается запрос от браузера, на лету поддерживающего архивирование, вернее, разархивирование (это видно из http-заголовков), то он предварительно сжимает отсылаемый документ. А клиентское ПО, в свою очередь, разархивирует полученную информацию перед выводом ее на экран пользователя. Почти все современные средства просмотра страниц в Интернете допускают компрессию документов. Протокол HTTP/1.1 определяет следующие форматы кодирования: gzip, compress или deflate. Выбор вида компрессии зависит от того, что позволяет клиентское ПО и что поддерживает конкретный Web-сервер.

Допустим, оба клиента, 5 и 6, запросили документ /index.html — главную страницу сервера объемом 100 Кбайт. При использовании модуля компрессии длина передаваемого блока данных составит примерно 20—25 Кбайт. Значит, пользователи быстрее увидят содержимое страницы. Недостаток — требование дополнительных процессорных ресурсов, т. е. владельцы не слишком мощных ПК заметят, что их машины слегка подтормаживают при выводе страниц на экран. Если же они будут подключены непосредственно к модемному пулу крупного провайдера (как в случае 5), то время, затраченное на формирование изображения (время разархивирования и визуализации), будет сравнимо с выигрышем, получаемым от использования компрессии. Нас же интересует достаточно распространенная ситуация, когда компрессия дает значительное повышение скорости получения информации из Интернета. Как правило, канал с пропускной способностью 64 кбит/c используется одновременно многими клиентами, в том числе и для передачи голосовых сообщений (ISDN). Тогда это звено в цепи передачи файлов от Web-сервера до конечного Web-клиента можно считать «бутылочным горлышком», ведь именно через него придется протаскивать либо 100 Кбайт исходной информации, либо 15—25 Кбайт сжатой. Понятно, что при отсутствии аппаратной компрессии в сетях типа ISDN клиенты должны заметно быстрее получать документы.

В подтверждение сказанному выше приведу гистограммы двух опросов посетителей страницы http://thermo.karelia.ru/ (на Web-сервере был установлен модуль gzip-компрессии). Мы попросили отметить, сколько времени проходит с момента запроса главной страницы сайта до времени появления текста. Измерять время полного копирования содержимого страницы со всеми изображениями не имело смысла, поскольку компрессия на лету возможна только для документов с расширениями *.shtml, *.html и *.htm, а также потому, что часть рисунков загружается с других Web-серверов (например, баннеры).

Рис. 2. Время появления текста главной Web-страницы до введения архивирования на лету

Над столбиками диаграммы (рис. 2) указано отношение (в %) числа проголосовавших в данном диапазоне времени к общему количеству участвовавших в голосовании. Наиболее вероятное время получения документа составляло 4—5 с (без gzip-компрессии) и менее 3 с (после ее установки (рис. 3)). Причем надо ориентироваться не только на относительную высоту столбиков, но и на ширину пика на полувысоте, если провести по ним огибающую. Ширина пика свидетельствует о разбросе скоростей подключения. Чем она меньше, тем с большей уверенностью можно говорить о некоей средней скорости, с которой пользователи получают информацию с Web-сервера.

Рис. 3. Продолжительность появления на экране текста главной страницы после установки архивирования на лету

На представленных гистограммах наличие правых столбиков (ожидание более 25 с) соответствует тем случаям, когда производилась смена IP-адреса сервера (в период до введения архивирования) и возникали некоторые неполадки в работе DNS-сервера провайдера (после введения архивирования). Поэтому эти столбики целесообразно исключить из рассмотрения и считать, что функция распределения имеет монотонный характер на правом крыле. Даже если отбросить все огрехи при тестировании, можно утверждать, что доля тех пользователей, чей отклик составил более 8 с, резко уменьшилась — примерно с 25 до 15%, что является весомым аргументом в пользу внедрения компрессии.

Кроме уже упомянутого выигрыша во времени применение сжатия трафика дает еще одну замечательную возможность — разгрузку сетей передачи данных. Взгляните на диаграмму (рис. 4) зависимости дневного трафика в течение недели до (дальний ряд столбиков) и после введения компрессии (ближний ряд). Если взять суммарные показатели за неделю, то получится, что общий объем отдаваемой Web-сервером информации уменьшился почти в 2,5 раза.

Рис. 4. Объем передаваемой Web-сервером информации, разнесенной по дням недели, до и после введения архивирования на лету

Этот график был построен на основе анализа журнала событий Web-сервера, причем суммарное количество посещений в течение обеих недель было примерно одинаковым.

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

Как узнать, поддерживает ли Web-сервер gzip- или какую-либо иную компрессию? Достаточно сэмулировать http-запрос в сеансе Telnet, обратившись к серверу на 80-й порт. Для этого пользователям Windows нужно, подключившись к Интернету, нажать «Пуск?Выполнить» и в строку действий ввести, например:

telnet thermo.karelia.ru 80

После нажатия ОК и установления связи с Web-сервером на экране появится что-либо типа:

Trying 217.107.58.235...
Connected to lab127.karelia.ru.
Escape character is ?^]?.

Далее следует сформировать сам запрос, пусть даже и не очень корректно:

GET / HTTP/1.1

и дважды нажать клавишу (набирайте указанную строчку большими буквами, пробелы есть только с двух сторон первой косой черты). Если надпись «Trying...» не появилась, значит, ваш Telnet-клиент не отображает некоторую информацию. Вам придется вслепую набрать «GET / HTTP/1.1» и дважды нажать . В ответ придет следующее:

HTTP/1.1 400 Bad Request
Date: Thu, 13 Dec 2001 09:26:49 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.6
 mod_gzip/1.3.19.1a rus/PL30.5
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

Bad Request

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /

Из всего этого замечательного мусора нас интересует лишь третья строчка, выделенная синим цветом. В ней говорится о том, что на данном ПК установлен русифицированный Web-сервер Apache версии 1.3.20, имеется поддержка PHP 4.0.6 и встроен модуль архивирования документов на лету mod_gzip1.3.19.1а. К сожалению, многие администраторы узлов в Сети изменяют строку, содержащую информацию о Web-сервере, чтобы сократить количество возможных атак на него, ведь чем меньше можно добыть информации об объекте, тем сложнее в него проникнуть. Поэтому единственно верный способ определить возможность компрессии - это сформировать полностью легальный запрос в соответствии со спецификацией HTTP/1.1. Если вместо «GET / HTTP/1.1» вы наберете

GET / HTTP/1.1
host: thermo.karelia.ru
Accept-Encoding: gzip, compress, deflate

и после того, как дважды нажмете , в ответ в теле сообщения получите нечитаемую информацию, это будет свидетельством поддержки одного из приведенных методов компрессии. А когда, как и в случае ответа «HTTP/1.1 400 Bad Request», будут видны теги языка HTML, то возможность архивирования трафика на Web-сервере либо отключена, либо вообще отсутствует.

Насколько распространена компрессия на лету в Сети? Исследование показало, что лишь небольшое количество Web-серверов сжимают исходящую информацию. Причем примерно до 1998 г. компрессия применялась более широко. Падение ее популярности связано с прогрессом в мире Web-дизайна и началом активного применения динамической генерации html-страниц. После отказа от статического содержания, а следовательно, от возможности один раз заархивировать — много раз выдавать, компрессия документов сервером перед выдачей их в транспортные сети стала зачастую невыгодной, поскольку требовала расхода дополнительных процессорных мощностей. Сейчас основное количество Web-сайтов построено по схеме с динамически изменяющимся содержимым (SSI, PHP, ASP и т.д.). В такой ситуации использование компрессии на лету вполне оправданно, а порой даже желательно, особенно тогда, когда общая загрузка процессора Web-сервера не превышает нескольких процентов от максимума. Таким образом, становится понятным, почему ни один из «монстров» Интернета не устанавливает на своей аппаратуре соответствующие модули архивирования.

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

ОБ АВТОРЕ

Алексей Петрович Мощевикин — канд. физ.-мат. наук, старший преподаватель Петрозаводского государственного университета, alexmou@lab127.karelia.ru

С секундомером в руках

Были проведены следующие тесты. Я создал текстовый файл test.txt размером около 1 Мбайт и выложил его на ближайший http-сервер. Далее попробовал загрузить его обратно, подключившись к модемному пулу провайдера с помощью модема с максимальной скоростью передачи в 33 600 бит/с и контролируя количество переданных-полученных байт в информационном окошечке удаленного соединения. Были опробованы и другие варианты. Во-первых, файл, упомянутый выше, выкладывался на сервер с именем test.html (на такие файлы настроено использование модуля gzip-компрессии), и, во-вторых, тот же файл передавался под именем test.zip в предварительно заархивированном виде (его размер был 280 538 байт, что соответствовало 28% от исходного). Результаты экспериментов приведены в таблице.

Первая строка таблицы соответствует случаю, когда аппаратная компрессия модема отсутствует и когда символы исходного документа передаются со скоростью, заявленной в аппаратуре связи. К категории устройств, работающих по такому принципу, можно отнести цифровые кабельные модемы, использующие алгоритмы передачи данных с временны/м делением (например, ISDN). Значит, пользователи модемов ISDN, имеющих скорость подключения 64 кбит/с, при чтении обычных страниц в Интернете практически ничего не выиграют по сравнению с пользователями аналоговых модемов. Основным преимуществом цифровых линий остаются более высокая надежность передачи данных и более высокая скорость аппаратного подключения к провайдеру (для коммутируемых линий).

Самая важная информация в таблице находится в последнем столбце. Оказывается, введение любого вида компрессии существенно увеличивает скорость передачи, измеряемую в символах исходного текста в секунду. А скорость, измеряемая в байтах в секунду, остается почти постоянной и соответствует скорости аппаратного подключения (в данном случае 31 200 бит/c). Качество компрессии зависит от того, какое аппаратное (АКМ) или программное (КНЛ, Zip) сжатие используется. Показателен также случай (последняя строчка таблицы), когда на уже сжатый при помощи Winzip файл накладываются КНЛ и АКМ, что приводит к незначительному дополнительному выигрышу в скорости.

Если проанализировать четвертую строчку таблицы, можно прийти к выводу о добавлении некоей транспортной информации объемом около 4% от исходного уже заархивированного файла. Размер последнего, как уже отмечалось, изначально составлял 280 538 байт, тогда как принятыми оказались 292 600 байт. Следовательно, при передаче любых данных по Сети к ним добавляется небольшой довесок, как правило, в виде заголовков межсетевого, транспортного и прикладного уровней стека TCP/IP.

Уже упоминалось, что тестовый файл был сжат до 28% от первоначального объема. Используемый архиватор Winzip, как, впрочем, и gzip, не оптимизирован на сжатие html-документов. Если в будущих версиях HTTP будет заявлен какой-то другой специфический вид компрессии, разработанный специально для html-контента, то это даст еще больший выигрыш в скорости.

HTTP — протокол доставки гипертекстовых документов

Сейчас все средства просмотра страниц в Интернете должны соответствовать спецификации HTTP/1.1, представленной в июне 1999 г. (RFC 2616). Под этой аббревиатурой понимается протокол, обеспечивающий функционирование Сети и являющийся его базовой транспортной подсистемой.

Любой стандарт, связанный с Интернетом, публикуется в виде RFC-документов (Request for Comments - запрос на рецензию и комментарии). Основным разработчиком алгоритмов и процедурных правил клиент-серверного Web-взаимодействия следует признать Тима Бернерс-Ли (T.Berners-Lee), участвовавшего в создании всех версий протокола HTTP, начиная с HTTP/0.9 (1991 г.), HTTP/1.0 (окончательно утвержденного в RFC 1945 в мае 1996 г.) и заканчивая HTTP/1.1 (RFC 2068 и RFC 2616). Все упомянутые RFC-документы можно найти по адресу http://www.w3.org/ («штаб-квартира» WWW).

Протокол HTTP описывает порядок действий клиентского программного обеспечения в момент запроса им гипертекстовых документов и другой информации у серверов, а также отправку ответов этими серверами. Ранние версии протокола позволяли строить запрос в упрощенной форме, тогда как HTTP/1.1 требует, чтобы были явно указаны несколько полей внутри него, например поле host. Браузеры могут заполнять специальные поля в заголовке HTTP-запроса для того, чтобы сервер присылал им документ лишь тогда, когда он устарел. Кроме того, они управляют кэшированием информации в промежуточных прокси-серверах, ставят указания о возможности архивирования содержимого ответа и кодировке символов. Также правилом «хорошего тона» можно считать отсылку серверу URL?а документа, спровоцировавшего данный запрос, и дополнительной текстовой информации, называемой cookies (файл персонализации). Последняя возможность активно используется Web-мастерами для учета посещаемости их ресурсов, возможности корректировки внешнего вида сайта, сохранения определенных настроек пользователя и т.д.

Вот так, например, выглядит HTTP-запрос, посылаемый браузером открытым текстом внутри TCP-сообщения.

GET /index.shtml HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible;
 MSIE 5.0; Windows NT; DigExt)
Host: thermo.karelia.ru
Connection: Keep-Alive
Cookie: voted=21; uid=45639

В нем запрашивается index.shtml — главная страница сервера thermo.karelia.ru. При этом указываются:

• версия HTTP;
• возможность gzip- и deflate-компрессии;
• сигнатура браузера, сформировавшего запрос (Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt));
• имя Web-сервера (thermo.karelia.ru);
• правило поддержания общения между браузером и Web-сервером (постоянное соединение);
• полученные ранее этим пользователем файлы персонализации (voted со значением "21" и uid со значением "45639").

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