Миниатюрный веб-сервер:
экономим циклы процессора и место на диске
Автор: (C)
Маттиас
Арндт [Matthias Arndt] Перевод: (C) Сергей Скороходов
Введение
Личный веб-сервер. Сегодня такой есть почти у каждого пользователя Linux.
Кто-то с его помощью и в самом деле предоставляет доступ к информации в сети.
Или занимается разработкой программ на PHP или CGI. А кому-то, как, например,
мне, сервер требуется лишь для того, чтобы читать в браузере программную
документацию, да время от времени "играть в веб-мастера". Я решил, что Apache --
слишком сильно для моих скромных личных потребностей. Сейчас у меня есть доступ
к провайдеру с CGI и PHP, так что дома мне эти возможности не нужны. Мне нужен
простой доступ к статическим веб-страницам и файлам и нет смысла "гонять в
бэкграунде" здоровенного Apach'а.
Результатом этих рассуждений стало прекращение эксплуатации собственного
веб-сервера Apache с его заменой на микро-сервер, запускаемый только тогда,
когда поступают запросы. Это экономит определенный объем оперативной памяти и
дискового пространства, что, впрочем, не слишком существенно -- компьютер у меня
мощный. Главное -- мне хотелось поиграть с новой программой, которая хотя и
выглядит, как игрушка, но тем не менее работает и исправно выполняет возложенные
на нее задачи.
Что же мне нужно от собственного веб-сервера?
Две простые функции, не имеющих отношения к PHP или CGI:
- обеспечение доступа к небольшому числу статических страниц и
предоставление моим друзьям возможности загружать файлы
- чтение документации к пакетам в броузере по протоколу http
Есть важный момент: совершенно необходимо, чтобы сервер хотя бы минимально
поддерживал индексирование каталогов. То есть, если URL завершается именем
каталога, то необходимо перенаправление в эту директорию (добавление завершающей
косой черты) с последующей обработкой находящегося там файла index.html. Такое
перенаправление необходимо для правильной работы относительных ссылок. Хотя
индексирование можно выполнить с помощью скриптов, автоматически запускаемых
планировщиком (cronjobs), я предпочитаю простые встроенные решения. А вот сами
по себе превосходные дополнительные возможности индексирования, имеющиеся в
Apache, мне не нужны.
Короче: мне подойдет почти любой сервер, поддерживающий протокол http, но без
излишних наворотов.
Нужно ли мне богатство дополнительных настроек?
Не факт. В смысле, факт, что не нужно. Все мои проблемы решаются с помощью
символических ссылок на ресурсы за пределами корневой директории сервера. Нет
нужды в директиве "Alias" [псевдоним] или в других заковыристых опциях. Только
указание корневой папки -- и я вполне счастлив. Ну, может быть, нужна
возможность указать порт, на котором сервер будет слушать.
Ничего больше. Мне будет достаточно простой строки запуска:
имя_выполнимого_файла /путь/к/корневой/папке
Независимый сервер или сервер, "завернутый" в сервис TCP?
Я остановился на варианте с "оберткой" [TCP wrapper]. Исполнимый файл сервера
вызывается только тогда, когда поступает запрос. Никакой возни со скриптами
инициализации. Несложная строка в /etc/inetd.conf'е -- и готово.
Производительность такой конфигурации, как говорится, "не очень". На самом
деле, если вы планируете нечто большое, чем спорадические обращения, то лучше
запустить самостоятельный сервис http, работающий постоянно.
micro_httpd
Оставив в стороне несколько воистину корявых вариантов ("на сетевых
просторах" можно найти веб-серверы, написанные на Java, bash или awk), я
остановился на компилируемой программе.
На http://www.acme.com/software/micro_httpd/
я нашел веб-сервер под названием micro_httpd. Примерно 150 строк на простом C,
делает в точности то, что мне нужно. Можно запускать через сервис TCP, никакого
CGI, никакого PHP, просто обслуживание запросов на передачу файлов и возможности
индексирования.
Я добавил в исходный код несколько дополнительных типов mime, и все
заработало "из коробки".
Получите исходники micro_http и распакуйте их.
- tar xvzf micro_http.tar.gz
- cd micro_httpd
- если нужно, подкорректируйте исходный код, например, подгоните "по себе"
#define'ы
- make
- su -c "make install"
И в /usr/local/sbin появился
двоичный файл micro_httpd.
Стукнувшись о земь обернитесь root'ом (su - плюс пароль:) и
отредактируйте /etc/initd.conf в своем любимом редакторе. Добавьте в него строку
http stream tcp nowait wwwrun /usr/sbin/tcpd /usr/local/sbin/micro_httpd /var/httpd/wwwroot/
и перезапустите суперсервер Internet inetd.
На моем SuSE 7.2 я набираю root'ом "/etc/init.d/inetd restart".
Проследите, чтобы "/var/httpd/wwwroot/ в примере выше был заменен правильным
путем к новой корневой директории документов веб.
А wwwrun замените именем любого реально существующего в вашей системе
пользователя, для пущей безопастности лучше выбрать "побесправнее".
Пришло время испытаний: поместите в новый "WWW-корень" несколько html-файлов,
доступных на чтение пользователю, под которым запускается сервер. Нацельте свой
любимый браузер на http://localhost/. Вы должны либо увидеть содержимое файла
index.html, либо автоматически создаваемый список файлов в каталоге.
Так и есть? Отлично, ваш маленкий, даже микроскопический веб-сервер
заработал.
Имейте в виду: сервис TCP wrapper записывает журнал соединений в
/var/log/messages. Но не следует ожидать от него подробного отчета в стиле
Apache. Всего лишь простые записи:
micro_httpd[886]: connect from x.x.x.x (x.x.x.x)
Но, опираясь на знание протокола http и с учетом наличия исходного кода,
вполне возможно расширить возможности ведения журнала. Оставляю это в качестве
самостоятельного упражнения для пытливого читателя.
Подведем итоги: любой веб-сервер, который можно запускать из inetd,
настраивается схожим образом. Поищите такие серверы на Freshmeat.
Заключение
Если ваши потребности не выходят за рамки описанных выше, то замена Apach'а
на "минималистский" вариант займет всего несколько минут.
Все нормально работает, но конструкция, очевидно, не выдержит слишком
большого числа запросов. Впрочем, для простого личного веб-сервера с небольшим
траффиком ее должно хватить.
По крайней мере, я стал немножко счастливие. Решайтесь, можт быть, это сможет
решить и часть ваших проблем?
[Есть еще Tux, миниатюрный веб-сервер в виде модуля ядра Linux. Он
работает похожим на micro_httpd образом и даже может перенаправлять запросы, с
которыми не может справится самостоятельно (например, обработку скриптов CGI)
на более "серьезный" веб-сервер. Однако, micro_httpd и Tux занимают разные
ниши. Tux предназначен для загруженных веб-сайтов, предоставляющих доступ к
большому числу простых файлов (например, с картинками), в этом случае, чтобы
избежать перегрузки системы, требуется сделать расход ресурсов на каждый
запрос минимальным. А micro_httpd, работающий через inetd, предназначен для
сайтов с небольшой нагрузкой, где потребность в дополнительных ресурсов,
требующиеся для выполнения каждого запроса в своем процессе, перекрываются тем
обстоятельством, что при отсутствии запросов ресурсов не требуется
вовсе. И micro httpd, и Tux, конечно, вместе занимают еще одну нишу: а
именно нишу маленьких симпатичных утилит, поиграть с которыми -- одно
удовольствие. Или, как говорит редактор LG "с правом написания" [contributing
editor] Дан Вайлдер [Dan Wilder]: "маленькие инструменты, хорошо заточенные
под одну задачу, в лучших традициях инструментария UNIX".
Если хотите больше узнать про Tux, то смотрите Руководство по
Tux 2.1 от Red Hat. Я думал, что Tux входит в стандартное ядро, но в
2.4.17 я его не нашел, так что вам придется искать его где-нибудь еще.
-Iron]
Матиас Арндт [Matthias Arndt]
Я энтузиаст Linux из северной Германии. Мне нравится простой rock'n'roll
пятедесятых годов, люблю писать истории и, естественно, публиковать их в Linux
Gazette. В настоящее время изучаю информатику [computer cience] в применении к
экономике.
Copyright (C) 2002, Matthias Arndt.
Copying license http://www.linuxgazette.com/copying.html
Published
in Issue 74 of Linux Gazette, January 2002
Команда переводчиков:
Владимир Меренков, Александр Михайлов, Иван Песин, Сергей Скороходов,
Александр Саввин, Роман Шумихин
