|
Благодаря автоматической генерации, сложной разметке и внедрению Unicode, современные web-страницы могут иметь довольно большой размер в байтах. Это значит, что для их пересылки по сети требуется больше времени. Хорошо, когда канал связи толстый, и скорость передачи высокая. В этом случае лишние 100-200 килобайт погоды не делают. Совсем другое дело, когда ваш клиент сидит на модеме или GPRS-телефоне.
Благодаря автоматической генерации, сложной
разметке и внедрению Unicode, современные web-страницы могут иметь
довольно большой размер в байтах. Это значит, что для их пересылки по сети
требуется больше времени. Хорошо, когда канал связи "толстый", и скорость
передачи высокая. В этом случае лишние 100-200 килобайт погоды не делают.
Совсем другое дело, когда ваш клиент сидит на модеме или GPRS-телефоне на
каком-нибудь хуторе близ Диканьки, или же сервер подключен к Сети через
асимметричную ADSL-линию. Здесь каждый килобайт дорог, особенно если
кого-то из вас попросят заплатить денег за передачу этого килобайта.
В протоколе HTTP, используемом для World Wide Web, предусмотрена
возможность сжатия передаваемых данных. Для этого могут применяться
способы сжатия, сходные с программами вроде zip, gzip, bzip2, rar и т.д.
Но сжатые сервером данные (например, передаваемая HTML-стрница) не
записываются в файл на диске, а сразу передаются клиенту в сжатом виде (по
аналогии с "трубами" Linux или Unix). При этом может быть достигнута
существенная экономия трафика и времени передачи.
Из практики
известно, что не все типы файлов сжимаются одинаково хорошо. Длинный
русский текст в кодировке КОИ-8, например, может быть сжат архиватором
bzip2 в 3-4 раза. Ещё лучше сжимаются HTML-документы, благодаря
повторяющимся элементам разметки. Совсем плохо сжимаются JPEG-картинки,
потому что к ним уже применено арифметическое кодирвание (это
заключительный этап процесса сжатия JPEG). Вывод: не для всех типов
передаваемых данных целесообразно применять сжатие. Наибольший смысл оно
имеет для HTML-страниц, так как они хорошо сжимаются и имеют большой
размер.
Клиент, способный принимать информацию в сжатом виде,
сообщает об этом серверу при помощи заголовка Accept-Encoding:
GET /~dimss/ HTTP/1.1 Host: localhost ........ (часть
заголовков опущена для ясности) Accept-Encoding:
gzip,deflate ........
Сервер, видя такой заголовок, имеет право сжать содержимое своего
ответа одним из предложенных методов. О том, что данные передаются в
сжатом виде, сервер извещает клиента заголовком Content-Encoding:
HTTP/1.x 200 OK ........ (часть заголовков опущена для
ясности) Content-Encoding: gzip ........ Content-Type: text/html;
charset=utf-8
[сжатые данные, на вид -- полная абракадабра]
Использование сжатия оговаривается в спецификации протокола HTTP/1.1
(документ RFC 2616). Спецификацией предусмотрено три способа сжатия:
deflate (RFC 1951), compress (аналогичен Unix-программе compress) и gzip
(RFC 1952, аналогичен Unix-программе gzip). Наиболее практичным является
метод gzip. Его поддерживают большинство современных Web-клиентов, таких
как MS Internet Explorer, семейство Mozilla, Konqueror и др. Встречаются
клиенты, не поддерживающие gzip, например, текстовый броузер Lynx.
Естественно, сжатие на стороне сервера требует дополнительных
ресурсов. Но сжатие 200-300 килобайт текста совершенно незаметно во
времени, даже если на вашем сервере используется процессор Pentium 100 MHz
(на таком "сервере" я проводил эти эксперименты). Если HTML-страница
генерируется динамически, то время генерации почти наверняка будет
превышать время сжатия результата. А выигрыш во времени передачи по
медленной линии получается существенный, до 2-3 раз. Поэтому использование
сжатия для динамических HTML-документов целесообразно, несмотря на
дополнительную процедуру сжатия. Статические HTML-документы можно хранить
в сжатом виде, и разжимать перед передачей, если клиент не понимает gzip.
Эти функции можно возложить на Web-сервер, см. далее.
Достаточно
теории. Рассмотрим внедрение сжатия gzip на примере простого CGI-скрипта,
написанного на языке Perl. Изначально скрипт имел вид:
#!/usr/bin/perl
my $c = 'Это как-бы
документ';
print "Content-Type: text/html;
charset=koi8-r
"; print $c;
Для сжатия gzip воспользуемся библиотекой Zlib. Это быстрее, чем
вызывать внешнюю программу gzip. #!/usr/bin/perl
use
Compress::Zlib;
my $c = 'Это как-бы
документ';
# Добавились четыре
строки if(($ENV{HTTP_ACCEPT_ENCODING} || '') =~ /gzip/){ $c =
Compress::Zlib::memGzip($c); print "Content-Encoding: gzip
"; }
print "Content-Type: text/html; charset=koi8-r
"; print $c;
Приведённый пример должен быть ясен и тем, кто не программирует на
языке Perl. Естественно, внедрение сжатия в прикладном коде - это не
лучший вариант. О сжатии должна заботиться среда программирования или сам
Web-сервер.
Так, язык PHP позволяет автоматически сжимать
передаваемые страницы, для этого в php.ini есть опция
zlib.output_compression. Удивительно, что немногие администраторы и
PHP-программисты эту возможность используют.
Модули поддержки
сжатия существуют для большинства Web-серверов. Для сервера Apache 1.3
существуют дополнительные модули mod_deflate и mod_gzip. Другой вариант
mod_deflate входит в комплект поставки Apache 2.0. Сжатие gzip
поддерживается набирающим популярность сервером nginx. Сжатие deflate и
gzip поддерживает также сервер Microsoft IIS.
Надеюсь, описанный
способ поможет вам улучшить доступность ваших web-страниц для людей,
находящихся вдали от оптоволокна.
Автор: Дмитрий Иванов
Источник: www.solutions.lv/~dimss/
|
|