GZIP компрессия "на лету"... Большинству эти слова ни о чем не говорят. Итак, давайте все по порядку.

    Схема запроса и выдачи документов в среде интернет выглядит следующим образом. Клиентское программное обеспечение (Internet Explorer, он же браузер) посылает HTTP (hyper text transfer protocol) запрос веб-серверу с указанием адреса конкретного html документа, который потребовался человеку. Веб-сервер анализирует запрос и либо отсылает этот документ, либо выдает какой-то код, например, код ошибки 404 (отсутствие документа с запрашиваемым адресом).

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

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

    Теперь проанализируем ситуацию, представленную на рисунке.

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

    При запросе владельцами модемов одного и того же документа с веб-сервера 1 будет происходить следующее (считается, что кэширующие прокси-серверы отсутствуют). Получив HTTP запрос, веб-сервер отправляет требуемый документ. Передача ведется в транспортных единицах, соответствующих стеку протоколов TCP/IP, на котором основано взаимодействие в сети интернет, а, именно, IP дейтаграммах. В связи с тем, что веб-серверы, равно как и провайдеры интернет-услуг, обычно подключены к транспортным подсетям через высокоскоростные соединения, все IP пакеты быстро дойдут до аппаратуры 2. А затем начнут продвигаться к модемам со скоростью соответсвующего подключения. В этом и заключается проблема "последней мили". Все равно, какие каналы у всего мира, информация будет приходить к вам настолько быстро, насколько хорошее соединение вы имеете.

    Таким образом, при полностью свободных каналах связи разницы в скорости получения информации между владельцами модемов 5 и 6 почти не будет. Другое дело, когда будет применена компрессия (сжатие) передаваемого трафика.

    Например, веб-сервер 1 настроен таким образом, что, если ему присылается запрос от браузера, который поддерживает архивацию (вернее, разархивацию) на лету (а это видно из HTTP заголовков), то он предварительно сжимает отсылаемый документ с помощью GZIP модуля. А клиентское программное обеспечение в свою очередь перед выводом информации на экран пользователя разархивирует полученную информацию. Необходимо отметить, что почти все современные средства просмотра страниц в WWW допускают использование компрессии документов. Собственно, формат кодирования может быть не только GZIP, но и COMPRESS или DEFLATE, что явствует из спецификации HTTP 1.1. Конкретное применение того или иного вида компрессии зависит от того, что позволило клиентское программное обеспечение в заголовках HTTP запроса и того, что поддерживает конкретный веб-сервер.

    Допустим, что оба клиента 5 и 6 запросили показать документ /index.html - главную страницу сервера, и ее размер будет 100кбайт. При использовании модуля компрессии длина передаваемого блока данных будет в среднем 15-25кбайт. А это значит, что пользователи раньше увидят содержимое страницы! Минусом же сжатия на лету является использование дополнительных процессорных ресурсов. Т.е. владельцы слабеньких компьютеров могут заметить, что машина начала слегка подтормаживать при выводе страниц на экран. А если же они были подключены непосредственно к модемному пулу крупного провайдера (как в случае 5), то зачастую время, затраченное на формирование изображения (время разархивации и визуализации) будет сравнимо с выигрышем при использовании GZIP компрессии.

    Рассмотрим достаточно распространенную ситуацию, когда использование компрессии дает значительный выигрыш в скорости получения информации из интернета. Обычно канал в 64кбита используется одновременно многими пользователями, в том числе и для передачи голосовых сообщений (ISDN). В этом случае именно это звено в цепи передачи файлов от веб-сервера до конечного веб-клиента будет "бутылочным горлышком". И именно через него придется протаскивать либо 100кб исходной информации, либо 15-25кб сжатой. Понятно, что в условиях отсутствия аппаратной компрессии в сетях типа ISDN пользователи должны получить заметный выигрыш во времени получения документов.

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

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

    На представленных гистограммах наличие правых столбиков (отклики более 25 секунд) соответствуют случаям, когда была произведена смена IP адреса сервера (в период ДО введения архивации), и возникновения некоторых неполадок в работе DNS сервера провайдера (ПОСЛЕ введения архивации). Поэтому их целесообразно исключить из рассмотрения и считать, что функция распределения носит монотонный характер на правом крыле.

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

    Как узнать, поддерживает ли какой-нибудь веб-сервер gzip компрессию? Достаточно сэмулировать HTTP запрос в сеансе телнета, обратившись к серверу на 80 порт. Для этого необходимо (для пользователей Windows) в состоянии подключения к сети Интернет нажать ПУСК/Выполнить и в строку действий ввести:

     telnet thermo.karelia.ru 80

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

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

Далее необходимо сформировать сам запрос, пусть даже и не очень легальный:

     GET / HTTP/1.1

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

     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

     <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
     <HTML><HEAD>
     <TITLE>400 Bad Request</TITLE>
     </HEAD><BODY>
     <H1>Bad Request</H1>
     Your browser sent a request that this server could not understand.<P>
     client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /<P>
     </BODY></HTML>

     Connection closed by foreign host.

    Из всего этого замечательного мусора нас интересует третья строчка, выделенная синим цветом. В ней говорится, что на данном компьютере установлен русифицированный веб-сервер Apache версии 1.3.20, имеется поддержка PHP 4.0.6, встроен модуль архивации документов на лету mod_gzip-1.3.19.1а.

Мощевикин А.П.
12 декабря 2001г.