apache

Есть такой современный формат графики — AVIF, который родился из видеоформата AV1. Интересен он тем, что даёт иногда существенную выгоду от использования — в моём непоказательном эксперименте на первой попавшейся картинке он уделал формат JPEG на порядок).

Вместе с тем он неплохо поддерживается современными браузерами — 79% по данным сайта CanIUse. Это ещё без учёта полифилов.

Мне очень хочется его использовать и я ищу способ это сделать в движке «Эгея», который я использую у себя в блоге. Можно было бы просто вставлять эту картинку как HTML, но это не очень-то удобно — у «Эгеи» есть специальная разметка, которая даёт несколько плюсов — в частности с ней дружит встроенный редактор и из неё лучше готовятся поисковые снипеты.

Уровень поддержки браузерами формата графики AVIF

У меня возникла хорошая, на первый взгляд, идея чуть упростить себе жизнь через модуль mod_rewrite веб-сервера «Апач» («Эгея» его требует, у меня на хостинге он тоже используется) при помощи примерно такого правила:

<IfModule mod_rewrite.c>
AddType image/avif .avif

RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME} \.jpg$
RewriteCond "%{REQUEST_FILENAME}.avif" -s
RewriteRule ^.*$ $0.avif [END,T=image/avif]
</IfModule>

Что тут написано? Если браузер поддерживает формат AVIF (смотрим в заголовке), и запрашивает JPEG (определяется по расширению), и существует файл ненулевой длины с расширением .avif (то есть image.jpg.avif, например), то отдаём ему AVIF.

Хорошо работает, пока в папке с картинками лежит только image.jpg.avif, как только кладёшь ещё и image.jpg — перестаёт, отдаётся только она. Вчера час наверное думал что не так, пока наконец не понял — поверх «Апача» на хостинге стоит nginx, а ему мои правила по барабану.

Если картинки по урлу нет, то nginx отдаёт запрос дальше в «Апач», срабатывает правило, отдаётся AVIF, как только кладёшь JPEG, nginx его видит, отдаёт по урлу, не спрашивая «Апач» ни о чём.

Что с этим делать пока — не знаю, вероятно ничего, nginx никто отключить не даст (у меня обычный дешёвый хостинг без затей), буду думать над другими способами.

Меня кто-то убеждал буквально недавно, что Апач уже давно отдаёт статику столь же эффективно, как и nginx. На реальном весьма нагруженном проекте опыт смены одного на другое такой:

Я поставил и настроил ngnix для отдачи статического контента. Это снизило нагрузку в 2 раза…

Речь идёт о сайте president2012.ru. Версия Апача — 2-2.2.16-6+squeeze4, nginx — 0.7.67-3.

У модуля mod_rewrite сервера «Апач» есть особенность, которая иногда портит много крови — после каждого переписывания URL, он просматривает список правил снова. Если ничего не предпринять, иногда происходит зацикливание, что ввергает новичков в ступор.

Мне эта особенность ни разу не пригодилась, но избавляться от неё приходится постоянно. В комментариях на «Хабре» к статье, название которой я вынес в заголовок, подсказали очень хороший способ, добавить первым правилом следующее:

# Don't loop.
RewriteCond %{ENV:REDIRECT_STATUS} !^$
RewriteRule .* - [L]

Если перезапись URL уже происходила, то любой URL оставляем без изменений и следующего цикла обработки уже не происходит.

Видели когда-нибудь нижепроцитированное? Веб-сервер Apache на домашней машине сегодня порадовал при попытке скачать на вторую машину фильм в 3.9 гигабайта (обратите внимание на «content-length»). Корень проблемы ясен — какому-то программисту зачем-то понадобилось использовать знаковый integer для поля длины файла, соответственно всё, что больше двух гигабайт становится отрицательной длины. Чуть попозже попробую присоединить к этому файлу ещё мегабат двести и посмотреть как лопнет мозг у Apache при попытке засунуть это значение в 32 бита.

HTTP/1.1 200 OK
Date: Thu, 29 Nov 2007 18:04:09 GMT
Server: Apache/1.3.33 (Win32) PHP/5.2.0-dev
Last-Modified: Thu, 21 Jun 2007 11:27:00 GMT
ETag: "0-f702ceea-467a6084"
Accept-Ranges: bytes
Content-Length: -150810902
Connection: close
Content-Type: video/x-msvideo

Попробовал. Файл 4171 мегабайт Apache 1.3.33 показал как 74-х мегабайтный.

Знаете ли вы, что в пароле при basic auth в Apache используются только первые восемь символов? Цитата с сайта Apache:

This is a feature of the crypt library on your system: in only looks at the first 8 characters of the password. To avoid it, use the -m option to htpasswd to create md5 passwords.

Материал довольно старый, уже упоминался во множестве специализированных форумов, тем не менее мне недавно, в который раз, довелось стать участником спора «Apache 1.xx versus Apache 2.xx», поэтому небольшая цитата из небольшой статьи «Apache 1 vs Apache 2 Performance» (Ilia Alshanetsky):

• Apache 2 is about 4% faster then Apache 1 at serving static pages.
• Apache 2’s mod_deflate is over 60 percent faster then Apache 1’s mod_gzip at real time compression of static HTML pages.
• Serving PHP via Apache 2 is 27 percent slower then via Apache 1 DSO and 31 percent slower then Apache 1 static.

На этом, на какое-то время, споры хотелось бы отложить — до тех пор, пока в Apache2 не произойдут какие-то существенные изменения.

Испокон веков в Apache (внимание! речь идёт об Apache 1.x) существует модуль mod_autoindex — в комментариях в его исходном коде есть дата, видимо написания первой версии — 23 марта 1993 года. С тех пор модуль, очевидно, претерпевал какие-то изменения, но с 1993 года форматирование вряд ли изменилось — всё тот же тег PRE.

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

В моём портфолио есть несколько проектов, где приходилось изобретать какие-то вещи (где-то, наверняка, велосипеды, знания о всех готовых решениях у меня нет) для улучшения производительности. Как я уже сказал, для огранизации файловых архивов иногда очень удобно использовать модуль mod_autoindex. Удобно, да вот незадача — владельцу сервиса, как правило, помимо производительности важна такая вещь как дизайн, оформление.

Стандартный модуль Apache позволяет менять, в этом плане:

• header, т. е. часть над списком файлов (HeaderName, SuppressHTMLPreamble)
• footer, часть под списком файлов (ReadmeName)
• размер иконок (IconWidth, IconHeight)
• внешний вид иконок (AddIcon, AddIconByType, AddIconByEncoding)
• убирать из списка некоторые столбцы (SuppressLastModified, SuppressSize, SuppressDescription)
• изменять описание файла (AddDescription)
• и весьма ограниченно менять внешний вид выводимой информации (FoldersFirst, SuppressColumnSorting и т. п.)

Чаще всего этого для «упаковки» списка файлов в дизайн очень мало. Для облегчения задачи интеграции вывода mod_autoindex в дизайн я несколько усовершенствовал этот модуль. Всё по порядку.

Что умеет новый модуль

• Режим FancyIndex всегда включен и не выключается. Вряд ли найдётся много людей
  не использующих этот режим.
• В основном режиме (об этом подробнее — чуть ниже) таблица файлов выводится при
  помощи тега TABLE, где у большинства объектов (например, у первой строка, чётных
  и нечётных строк) прописаны идентификаторы CSS-классов, из чего следует, что внешний
  вид таблицы вы легко сможете задать при помощи файла стилей.
• Новая опция, позволяющая включить в листинг файла ссылку на корень сайта
  (IndexOptions +RootFolder, при использовании не забудьте добавить иконку,
  например так: «AddIcon /icons/back.gif .»)
• Появилась возможность перенести Description в отдельную (новую) строку
  (IndexOptions +DescriptionAtNewRow)
• Появилась возможность локализовать (перевести на родной язык) текстовую
  информацию модуля (директивы ParentStr, RootStr, NameStr, SizeStr, DescriptionStr, LastModifiedStr).
• С первой страницы (если пользователь находится в корне сайта) убрана
  ссылка «Parent Directory», ведущая в этом случае, на ту же самую страницу.
• Появился новый режим вывода, основанный на теге SPAN (именно он на иллюстрации),
  в частности, количество иконок в строке в этом режиме зависит от ширины окна браузера
  (IndexOptions +BoxWidth=N +BoxHeight=N +MaxIconHeight=N)

Новый режим вывода  

Новый режим вывода включается автоматически, если были использованы параметры BoxWidth и BoxHeight. Эти два параметра отвечают за размер прямоугольника, в который заключена иконка (на иллюстрации выделено чёрным) и, по сути, определяют расстояние между соседними иконками.

Размер этот нужно выбирать исходя из размеров иконки, текста названия файла и строки, где выводится размер файла, плюс некоторое пространство, необходимое для обеспечения зазора между соседними иконками. Есть ещё один параметр — MaxIconHeight, выбрать его просто — это всего лишь максимальная высота иконки в вашем наборе. Нужен этот параметр для того, чтобы подписи к иконкам располагались на одном уровне (на иллюстации — синяя линия).

В этом режиме под иконкой выводится имя файла, размер и дата модификации (если, конечно, не были использованы опции SuppressLastModified и SuppressSize), описание файла выводится в аттрибут «title» тега SPAN, охватывающего иконку и надписи (если не была использована опция SuppressDescription) — вы можете использовать DHTML, чтобы выводить информацию из title в статусную строку, всплывающую подсказку и т. п.

Пример

Файлы для вывода информации так, как это изображено на иллюстрации выглядят так:

Файл «.htaccess»:

IndexOptions +SuppressHTMLPreamble +NameWidth=*
IndexOptions +SuppressLastModified +FoldersFirst +RootFolder +DescriptionWidth=*
IndexOptions +BoxWidth=80 +BoxHeight=80 +MaxIconHeight=33

HeaderName /_bolk_autoindex/.HEADER.html
ReadmeName /_bolk_autoindex/.FOOTER.html
ParentStr "Наверх"
RootStr "В корень"
NameStr "Имя"
SizeStr "Размер"
DescriptionStr "Описание"

Файл «.HEADER.html»:

<head>
    <title></title>
    <style type="text/css">
    td,
    body { background-color: white; font-family: Verdana,Tahoma; font-size:10px }
    a    { color: black; text-decoration:none }
    .cell0, .cell1 {text-align: center}
    a:hover { text-decoration: underline }
    </style>

</head>
<body>
<h4>Пример использования</h4>
Содержимое каталога:
<!--#echo var="DOCUMENT_URI" encoding="none" -->
<br clear="all" /><br />

Файл «.FOOTER.html»:

</body>

Где взять и как установить

Файл можно взять у меня на сайте (ZIP, около 15Кб), для установки нужно переписать его на место старого модуля (каталог src/modules/standard) и перекомпилировать Apache.   Проблемы и их решения

Часто, помимо имени файла, его размера и даты создания, хочется вывести другую полезную информацию — например, разрешение для картинок, ID3 теги для MP3 файлов и так далее. Для этой цели я рекомендую воспользоваться полем «Description» и директивой «AddDesription». Задачей модуля не является и, надеюсь, не будет являться (иначе это приведёт к снижению производительности) автоматический вывод информации такого рода. Напишите скрипт (кстати, возможно позднее я его выложу), который пробежит по каталогам и добавит эту информацию в соответствующие .htaccess файлы и вызывайте его далее по мере необходимости.

Один из заказчиков попросил предоставить пользователю возможность самому выбирать какой вид листинга файлов он хочет получить — табличный или в виде иконок. К сожалению, у Apache 1.x нет методов переключения конфигурации в зависимости от каких-то внешних условий «на лету», так что было выбрано такое решение. На портах 80 и 443 (обычно используется для HTTPS-соединений) были заведены два виртуальных хоста:

<VirtualHost example.com:80>
...
AccessFileName .htaccess .htaccess-table
...
</VirtualHost>

<VirtualHost example.com:443>
...
AccessFileName .htaccess .htaccess-icons
...
</VirtualHost>

где прописаны одно общее имя .htaccess-файла для общих настроек и деректив AddDescription и два разных имени для различных наборов настроек mod_autoindex. Переключение происходит перенаправлением пользователя на определённый порт.   Хотелось бы ещё…

По всем вопросам, с пожеланиями по улучшению — добро пожаловать в мой почтовый ящик, он есть на моём сайте внизу каждой страницы.

Прислали ссылку на тестирование различных веб-серверов, спасибо Валентину. Всё-таки я говорил немного не об этом (я говорил о сервере, который отдавал бы графику и видео, а более сложный контент передавал на обработку Apache), но, для интереса, потестировал и то, что есть у меня, плюс установил thttpd. Для тестирования использовал Apache Benchmark с параметром «-c 500». Машина — Pentium IV 2.80 GHz.

Итак. Лучше всех справился 0W-httpd, показав ответа 12-37ms, далее — thttpd (26-61ms), Apache, как и следовало ожидать, справился хуже всех (55-255ms). ZeroWait порадовал скоростью, но встревожил тем, что свалился во время одного из тестов.

Вопрос к уважаемой публике: имеется веб-сервер, объём отдаваемых данных таков, что перед Apache пришлось поставить маленький сервер, который отдаёт графику и видео. Вопрос такой — какие вы знаете маленькие специализированные сервера для таких целей? Одно из требований — умение ограничивать контент по IP. Я знаю следующие решения и лишь один из этих серверов умеет работать со списками IPs:

Tux — веб-сервер, работающий как модуль ядра. Сейчас поддерживается фирмой RedHat. Показывает хорошие характеристики по скорости, но не умеет работать со списками IPs.

X15 — веб-сервер фирмы Chromium. Судя по тестам — ешё быстрее Tux, хотя и работает в user space. Скачать не удалось — регистрация на сайте не работает, все ссылки ведут в никуда.

ZeroWait — решение, которое было выбрано. Характеристики устойчивости, защищённости и скорости неизвестны, но с задачей справляется. Два недостатка — почти полная неизвестность (а значит и неизвестная степень безопасности) и очень слабая документированность.

Кто-нибудь знает ещё какие-то решения? Было интересно узнать кто что использует.