Lighttpd 1.4.70

А вот интересно.

По спецификации HTTP/2, если ты юзаешь noscript, AD-Block и т.д. то рекламу по трафику тебе будут все равно пихать, видеть ты ее не будешь, но лезть она к тебе будет.

Всегда интересовало, какие у него плюсы перед nginx

Как по мне значимых плюсов нет. Но просто по фану на домашнем сервере использую под некоторые задачи.

Даже как-то раз использовал его, году в 2011

У него встроенная запускалка CGI. Это было удобно в бородатые времена для быстрого деплоя. Сейчас же почти любое веб-приложение содержит на серверной стороне свой собственный бекендовый http-сервер, который потом прячут за nginx.

Использовал его в 2003-2006’м.

Всегда интересовало, какие у него плюсы перед nginx

Держи лучше минусы: «lighttpd is a single-threaded, single-process»

Там далее описывается, в каких случаях имеет смысл настроить несколько worker processes. Каждый из которых, я так понимаю, будет по-прежнему single-threaded, что есть форменная дичь. И вообще чтиво довольно тоскливое: предлагается руками замерять и твикать то, что по-хорошему должно работать само из коробки. Следствие «форменной дичи». (К слову, у nginx по дефолту один worker process с кучей потоков.)

Прекрасно они всё блокируют по HTTP/2. Точнее, блокировщик рекламы вообще не волнует, какой там протокол под капотом. Блокировщик работает на гораздо более высоком уровне через API webRequest, либо declarativeNetRequest.

The webRequest API normalizes all requests so that uBO does not have to concern itself with whatever underlying revision of the HTTP protocol is in use — that's way below uBO's scope. If ever there was a case of network requests not relayed to uBO through the webRequest API, then this a browser issue.

Всегда интересовало, какие у него плюсы перед nginx

Это совершенные разные области применения. Lighttpd отличная штука для отдачи статики (и чуть-чуть больше) для всяких локальных сервисов интерфейс к которым сделан через веб. Тот же git, например, в локалке можно через него просматривать.

По спецификации HTTP/2, если ты юзаешь noscript, AD-Block и т.д. то рекламу по трафику тебе будут все равно пихать

Если это про PUSH, то он совсем не так работает, и далеко не везде он есть, например из Хрома его нафиг выпилили

Качественно-написанный, маленький по объему кодовой базы замечательный проект, ура!

Это не PUSH. Вот:

В HTTP/2 сервер имеет право послать то содержимое, которое ещё не было запрошено клиентом. Это позволит серверу сразу выслать дополнительные файлы, которые потребуются браузеру для отображения страниц, без необходимости анализа браузером основной страницы и запрашивания необходимых дополнений. 

Это и есть PUSH, опциональная фича протокола. Рекламу так никто пушить не станет (по крайней мере, динамическую из сетей), так как файлы для пуша надо явно конфигурить на веб-сервере

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

А я и написал, что будут тупо создавать трафик.

Вот например, как это делается в nginx: https://sysadmin.pm/nginx-http-2-server-push/

В реальности в этом очень мало практической пользы и много гемора, так что фича не популярна

Дирлистинг красивее

Сплошное 4.2.

Я вообще не админ, а в чём вообще разница между разными http серверами? В чем разница между apache и nginx?

apache это легаси-хлам, который запоздало научился event loop-у (но нубы до сих пор по мануалам из 90-х настраивают его во всякие prefork с mod_php), с неудобным форматом конфигов из музея и пытающийся изображать из себя целевое приложение.

nginx (как и lighttpd) это современный веб-сервер где мусорных режимов работы изначально не было (только event loop), и работающий в прозрачной и эффективной концепции «распарсим урл, найдём к нему правило из списка, и либо отдадим статический файл, либо передадим обработку по указанному в правиле адресу (приложению)». Хотя в последнее время в nginx тоже насували какой-то ерунды (могу вспомнить lua и js), но она по дефолту не отсвечивает и надо специально искать как её включить, если нужно.

Сплошное 4.2.

По ссылке на его собственную документацию, ага. Витаминки пить не пробовали?

https://habr.com/ru/articles/260669/ Только nginx работает не через потоки

Какую «его» и причём тут ссылки? У тебя там пачка заявлений и все - вранье, за исключением одного - треды в lighttpd действительно не используются.

single-process

Враньё, сам дальше пишешь что воркеров может быть несколько.

single-threaded, что есть форменная дичь

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

К слову, у nginx по дефолту один worker process с кучей потоков.

Опять враньё. У nginx модель ровно та же, что у lighttpd - цикл обработки событий в одном треде. А количество воркеров всегда задаётся в конфиге, поэтому дефолтное значение никого не волнует (я даже никогда не интересовался какое оно).

Враньё, сам дальше пишешь что воркеров может быть несколько.

Вообще-то я в обоих случаях процитировал официальную доку. А то что она сама себе противоречит, причём на одной странице в соседних абзацах – не ко мне претензия. :)

но это совсем не те треды, как ты представлял (т.е. речи о «треде на коннект» не идёт, это как раз и есть дичь

Ну тебе конечно виднее, что я себе представлял. Я в отличие от некоторых в epoll умею, причём и в combined queue (про который ты меня тут лечишь), и в separate queues (который кстати предпочтительней при экстремальной нагрузке и примерно одинаковом времени обработки всех запросов).

У nginx модель ровно та же, что у lighttpd - цикл обработки событий в одном треде.

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

А вообще мне этот разговор надоел. Slack тот вообще свою собственную ссылку дальше первого абзаца не осилил, потому как прямо во втором абзаце речь про worker-потоки. А его послушать – так не процессами-потоками едиными жив nginx, но и духом святым. И Сысоев пророк его.

В игнор обоих.

У тебя какое-то странное представление о цикле событий. Делается так: создаётся некоторое количество воркеров, которые параллельно делают accept на слушающий сокет. Кто соединение поймал - тот дальше его и обрабатывает, на этом механика распределения нагрузки по воркерам (воркер - это процесс а не тред) заканчивается. Каждый воркер делает в цикле epoll_wait() (ну или лучше kevent()) и обрабатывает все события. Никаких «раскидываний по тредам» там не происходит, всё уже раскинуто раньше (коннекты по процессам).

Треды могут быть нужны, если у тебя монолитное приложение с единым на всех состоянием, которое ты хочешь держать в памяти процесса. Но http-сервер это явно не тот случай.

Это называется separate queues. Только worker threads эффективнее чем worker processes. Как минимум с точки зрения кеширования состояния (сессии там, справочники): нужна только одна копия кеша, и синхронизация проще.

Пока писал ответ, я вижу ты добавил этот же юз кейс. Непонятно правда, схрена ли http сервер «явно не тот случай». Как раз тот самый случай и есть. Для всякого там энтерпрайза.

И для single queue с ручным раскидыванием запросов по воркерам тоже вполне себе юз кейсы имеются.

С того что речь идёт об http-сервере (прога, которая парсит http/https и раскидывает запросы дальше, а сама напрямую отдаёт только статику). А большое глобальное состояние - это про приложение. У http-сервера оно тоже может быть (всякие ssl-кеши, не разбираюсь в них, и статистика коннектов/запросов в секунду чтобы их ограничивать), но это мелочи и они специальной shared-памятью между процессами делаются. Основной же функционал никакого состояния, кроме текущего открытого коннекта, не требует.

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

С того что речь идёт об http-сервере (прога, которая парсит http/https и раскидывает запросы дальше, а сама напрямую отдаёт только статику).

1. Я отредактировал свой предыдыдущий камент, добавив туда ссылку.

2. И вообще в целом я рассматриваю нагромождение http-серверов (один чисто прокси + статика, другой за ним «настоящий», с которым прокси тоже общается по HTTP) как и любое нагромождение слоёв, плохим дизайном. Вот single queue с ручным раскидыванием запросов по воркерам как раз и позволяет в приоритезацию, чтобы тяжёлые запросы не блокировали лёгкие, и не нужна была бы вся эта муть с проксированием.

можно отделить администрирование сетевого доступа к приложению от администрирования самого приложения,

а с другой - потому на данный момент разнообразие всяких вариаций http и ssl слишком велико, они меняются, и незачем грузить всем этим приложение

Представим себе какой-нибудь JBoss. Или даже Tomcat, у тривиальных сервлетов тоже имеется deployment descriptor, и настройки томката в его xml-ке вполне себе ортогональны настройкам приложения, хотя оно крутится в томкатовском процессе.

Не вижу никаких препятствий, чтобы разные части nginx.conf редактировались разными админами. Можно даже инклуд-файлы им сделать: один админ пусть редактирует /etc/nginx/ssl.conf, другой /etc/nginx/app.conf.

Я тут на досуге рисую веб-приложение как nginx-модуль на плюсях, и веселюсь всякий раз как вспоминаю, что мне не надо думать про SSL: спросит кто – я ему ссылку на доку nginx.

Ну, кому как. Мне вот больше нравится, когда про ssl не то что думать не надо, а его и в ldd бинарника не видно, он изолирован в процессе, отвечающем за терминирование ssl, и с полезной нагрузкой вообще почти не пересекается. Особенно с учётом отвратительного качества ssl-библиотек. А ещё в таком случае эти процессы можно и по разным железкам раскидать, если нагрузка большая - приложению с его нуждой в глобальном состоянии будет как раз хорошо, что никто не будет занимать вычислительные ресурсы его железок всякими ssl и прочими левыми расходами, увеличивая фрагментацию. И ещё, кстати, вот нашли очередной баг в openssl или в даже в протоколе, надо перезапускать всё что с ним слинковано. Если оно в отдельном процессе - приложение вообще ничего не заметит.

фильтрацией атак

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

Мой подход решает проблемы:

• Максимально возможная эффективность. Никаких прокси-слоёв и прочих фасадов, тем более взаимодействующих через сеть; максимальная интеграция с API веб-сервера. (C++ vs Java здесь в целом ортогонально, но меня всё-таки зудит заявить, что цена вопроса – 20-кратная экономия на серверах, если боттлнек - вычислительная мощность.)

• Простота развёртывания: прописать в nginx.conf пару строк load_module /lib/myapp_ngxmod.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь чтобы там был просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).

Понятно, что anti-DDoS это блокер, в отличие от. Но тут у кого какие задачи. Кроме того, если anti-DDoS предоставляется хостером (а он обычно предоставляется), то для разработчиков и админов он в целом прозрачен.

а его и в ldd бинарника не видно

Честно говоря, меня мало колышет, что видно в ldd nginx.

Особенно с учётом отвратительного качества ssl-библиотек.

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

И ещё, кстати, вот нашли очередной баг в openssl или в даже в протоколе, надо перезапускать всё что с ним слинковано. Если оно в отдельном процессе - приложение вообще ничего не заметит.

Исчезающе редкий юз-кейс. На фоне того прискорбного факта, что приложение один хрен будет падать чаще любой системной либы. А пишущих такое (или ПОД такое, как jboss), что рестартует три часа, надо увольнять за профнепригодность. Интересно, во сколько раз стал бы проще и компактней софт, если бы вдруг исчезли все эти миллионы фреймворков, переливающих из пустое в порожнее.

приложение упало – сервер нет

Я как-то про это не думал, но если идти в эту сторону, то предпочтительнее «http-сервер упал, приложение - нет». Будет как обычная потеря сети выглядеть. Впрочем, чтоб nginx падал я не замечал, а вот уже упомянутый запланированный его перезапуск из-за необходимости обновления очередной дыры в openssl уже имеет место.

Максимально возможная эффективность

Ну, да, но обычно узкое место не тут. Хотя где-то важно, наверно.

прописать в nginx.conf пару строк load_module /lib/myapp_ngxmod.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь чтобы там был просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).

Тут причина и следствие местами поменяны. Это не интерфейс влияет на язык, а наоборот. Если приложение на пхп/питоне/джаве то модулем его не вставить. Если на си - то есть выбор, но насколько он повлияет на простоту развёртывания я не уверен.

Приложение один хрен будет падать чаще любой системной либы.

Это какое-то плохое приложение.

А про качество ssl-библиотек я имел в первую очередь регулярные уязвимости.

Ну, да, но обычно узкое место не тут.

Мне частенько вспоминается статейка в чьём-то англоязычном бложике с разоблачением тезиса «база – узкое место»:

• Многие сайты рисуют внизу страницы статистику, сколько времени выполнялся собственно запрос к базе (кстати, ЛОР тоже вроде рисовал) – и это ничтожная доля от всего времени даже одного лишь сервера, не говоря уже про полный roundtrip.

• База, говорит, – узкое место только потому что плохо горизонтально масштабируется.

Тут причина и следствие местами поменяны.

Гы. Ты хотел сказать – насколько простота развёртывания повлияет на выбор языка? :)

В целом согласен, но оно как бы кумулятивно. Тут полкопейки похерили, там полкопейки – а на выходе сука jboss, и простейшая страница на крошечной тестовой базе отдаётся 40 минут.

Это какое-то плохое приложение.

Ну во-первых, зависит в первую очередь от объёма функционала. Если so-шка приложения в 10 раз объёмней so-шки openssl, довольно глупо было бы ожидать, что багов и дыр в ней меньше.

А во-вторых, мы ж говорим вовсе и не про мою so-шку, а про твои причины, по которым ты отделяешь приложение от веб-сервера. ;) И в этом твоём юз кейсе приложение будет написано скорее всего не конными д’Артаньянами-плюсовиками в сияющих белых одеждах, а веб-макаками на чём попало. :)

Дирлистинг красивее

Чем?

lighttpd мне нравится. Хороший для веб-интерсейсов на которые почти никто не заходит. Ест примерно 0 всего.

Также была добавлена поддержка HTTP/2

Кстати, а кто пользуется HTTP/2? Нафиг он нужен? Он же бинарный и неудобный?

Чем в nginx.

Чем в nginx.

Это понятно. Не понятно чем красивее?

Ничего красивее апачевского быть не может. C=N;O=A!