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

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

Для этого нам понадобится еще одно звено между браузером и веб-сервером, которое, как модем, будет сжимать весь входящий (входящий для браузера) трафик. Звеном этим будет являться обычный с виду php-скрипт на удаленном веб-сервере. Именно этот скрипт в ответ на специально составленный запрос и будет скачивать необходимую вам страницу и уже в сжатом виде отдавать ее браузеру. Основные требования к хостингу, на котором расположен этот php-скрипт: отсутствие баннеров хостера, возможность использования CURL и GZIP (проверить их доступность можно запуском скрипта с вызовом функции phpinfo).

Чтобы лучше понять механизм работы системы промежуточного сжатия трафика, рассмотрим более подробно технологию ее работы.

На рисунке ниже представлена схема трех вариантов загрузки страницы: обычный вызов, сжатие данных на промежуточном сервере и прозрачная работа со сжатием страницы на промежуточном сервере. Рассмотрим что происходит в каждом из случаев.

2. Получение браузером страницы из сети

2.1. Обычный вызов

Допустим пользователя заинтересовала страница page.html на сервере site.com . Он набирает URL site.com/page.html в строке адреса. Браузер после этого производит по сети http-запрос страницы http://site.com/page.html (на рисунке - тонкая пунктирная стрелка, первая слева). В ответ на этот запрос веб-сервер site.com выдает http-ответ браузеру и следом за ним тело страницы page.html (на рисунке – жирная стрелка, вторая слева). После этого браузер отображает пользователю на экране монитора содержимое полученной страницы.

2.2. Сжатие данных на промежуточном сервере

Введем промежуточный сервер webzip.com между браузером и веб-сервером site.com, на котором будет происходить сжатие данных. Алгоритм получения страницы page.html такой же, как и в предыдущем случае за исключением того, что браузер запрашивает страницу не непосредственно у site.com, а через webzip.com. Причем полноразмерные (несжатые данные) идут только между site.com и webzip.com, между браузером и webzip.com тело страницы идет в сжатом виде (на рисунке - жирная пунктирная стрелка, третья слева). Заметим, что по причине использования возможностей php для сжатия страницы её адрес, запрашиваемый браузером, примет вид http://webzip.com/myzip.php?url=http://site.com/page.html. Веб-сервер (webzip.com), получив этот запрос, вызывает скрипт myzip.php, а тот в свою очередь по get-параметру (пусть им будет параметр с именем «url») вызова производит запрос на http://site.com/page.html. Полученную страницу скрипт myzip.php отдает браузеру в сжатом виде.

2.3. Прозрачная работа со сжатием страницы на промежуточном сервере

От предыдущего случая данный отличается тем, что работа виртуальной сжимающей прокси для браузера, а соответственно и пользователя, не видны. Достигается это за счет введения еще одного звена, между webzip.com и браузером. Этим звеном является обычный http-прокси, который помимо всего прочего занимается переписыванием исходящих заголовков http-запросов (например, с http://site.com/page.html на http://webzip.com/myzip.php?url=http://site.com/page.html ).

3. Настройка прозрачной работы

3.1. Установка скриптов

Скачать скрипты, которые реализуют все вышеописанное, можно здесь. В архиве три файла: myzip.php, func.inc.php, log.php. Первый – основной файл, к которому обращается клиент. Второй – содержит определения функций для первого. Третий – предназначен для отображения статистики работы прокси (содержит шаблон страницы статистики, суть берется из файлов log.log и count.log).

Как уже было сказано ранее, разместить скрипты следует на любом хостинге, где есть поддержка PHP, CURL, ZLIB и отсутствуют банеры. В интернете такое можно без труда найти за 30 рублей в месяц.

Не пугайтесь платности хостинга – он с легкостью будет окупаться. Например, если вы платите 0.05 $/МБ - потребуется 20 сэкономленных мегабайт для оплаты хостинга, дальше выгода. По моему опыту это порядка 100-150 МБ веб-серфинга (среднее сжатие – в 4-7 раз, хотя встречается и до 12).

Проверить правильность работы можно, набрав в браузере следующий адрес: http://webzip.com/myzip.php?url=http://ya.ru. Если всё сделано правильно – загрузится страница яндекса с немного видоизмененным заголовком (title).

3.2. Настройка Proxomitron-а

Использовался Proxomitron ver. Naoko 4.4 (http://www.proxomitron.ru).

Итак, мы хотим добиться от проксомитрона возможности прозрачной работы с веб-проксей, иными словами скрытое преобразование исходящих URL-ов от браузера. Для этого в главном окне проксомитрона нажимаем клавишу «Заголовки» («Headers»). В открывшемся окне («Фильтры заголовков HTTP» / «HTTP Header Filters») пролистываем до строки «URL: Alias Redirector (Out)», выделяем ее. Жмем кнопку «Изменить» («Edit»), в развернувшемся окне («Редактор фильтров заголовка» / «HTTP Header filter editor») заполняем поля следующим образом (все, кроме первого):

Заголовок HTTP (HTTP Header) (!не меняем!) URL: Alias Redirector (Out)
Совпадение с URL (URL Match) *
Значение заголовка (Header Value Match) *
Текст замены (Replacement text) $RDIR(http://webzip.com/myzip.php?url=\u)
Где http://webzip.com/ - URL вашего сайта, myzip.php – имя скрипта, который вы закачали на сайт.

Вся суть в последней строке: проксомитрон будет менять любой URL (параметр «\u») от браузера на http://webzip.com/myzip.php?url= \u. Если написать вместо $RDIR команду $JUMP, то работа проксомитрона будет полупрозрачной: браузер будет просто перенаправляться на новый URL. В случае использования $RDIR – перенаправление будет происходить незаметно для браузера.

Закрываем окна, нажимая последовательно «Ок», «Применить» («Apply»), «Ок». Если есть желание не повторять эту процедуру снова – сохраните настройки.

В браузере прописываем прокси сервер с IP=127.0.0.1 и портом 8080 (порт, прослушиваемый проксомитроном по умолчанию). Убедиться в том, что система сжатия трафика работает, можно всё так же - по изменяющимся заголовкам страниц (новый <title> слева направо: исходный и переданный браузеру размер страницы в байтах, коэффициент сжатия, использование куков, get, post параметров, время генерации страницы в секундах, исходный заголовок).

Поделюсь радостью - у меня даже аська заработала сквозь проксомитрон.

4. Тестовая экономия

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

Проверил через веб-интерфейс почту на mail.ru: главная страница – уже 39 кБ экономии; вошел в ящик – уже 60 кБ; побегал по папкам, посмотрел почту; вышел - уже 300 кБ экономии. Задал парочку запросов яндексу – на выходе 570 кБ. Отправил три смски (Мегафон, Билайн, МТС). Походил по форумам на sql.ru и rsdn.ru. Поискал в гугл парочку абракадр. Смотрю на счетчик - итого два мегабайта экономии . Вроде бы пустячок, но это всего лишь час обычной работы. Что же получится у вас за месяц работы? Копейка рубль бережет.

5. Итого

Сразу предупрежу, что хостеры не очень приветствуют создание на их стороне чего-либо проксо-подобного. Используйте скрипт на свой страх и риск, отвечать вам. Однако, если вы не устраиваете публичной прокси с многогигабайтным трафиком, то вряд ли они заметят 200-500 МБ на скрипте – для них это капля в море. К тому же, если встроить скрипт сжатия в другую страницу, то заметить подвох хостеру будет еще сложнее. Она внешне (без вызова с нужным параметром «url») будет представлять собой обыкновенную домашнюю страницу. Хотя при особом желании провайдер и эту уловку обнаружит, но шанс мал. Ну, а если и обнаружит – скажете, что ваш сайт сломали и «невиноватые мы». В самом худшем случае придется сменить хостера (или аккаунт у прежнего :)).

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

Если вы заглянете в код скрипта, то обнаружите там парочку параметров, при помощи которых можно включать/выключать возможности скрипта. Например, изменение заголовка с целью вывода статистики работы скрипта (параметр MOD_TITLE). При желании к скрипту можно без труда добавить дополнительную функциональность. Например, вывод протокола работы в базу данных с целью его дальнейшего анализа (протокол по умолчанию можно посмотреть в log.php).

Замечу, что в Интернете уже существуют подобные сервисы (например, www.tcompressor.ru и www.toonel.net), как платные так и бесплатные. У них у всех есть свои плюсы и минусы. Основное достоинство применения вышеописанной технологии в том, что вы сами являетесь хозяином своего трафика (нет баннеров, нет оплаты, нет сомнительных приложений, нет хостера, размещающего сервис) – всё в ваших руках.

P.S. Не считаю свои слова истиной в последней инстанции, поэтому, если я в чем-то ошибаюсь, поправьте меня. Спасибо!

P.P.S. Уверен, скрипт тоже не без греха, поэтому поправки приветствуются!