Comments 166
Да, я тоже сейчас задумываюсь о том, как отдавать трафик WebSockets, и вообще не знал о том, что существуют какие-то готовые решения.
А какие версии браузеров уже поддерживают WebSockets?
нативно — только хром.
Chrome, Safari, также ожидается поддержка в Firefox 4, IE 9. По Opera пока не в курсе.
для старых браузеров можно использовать различные костыли, например,
code.google.com/p/jquery-graceful-websocket/
для старых браузеров можно использовать различные костыли, например,
code.google.com/p/jquery-graceful-websocket/
UFO just landed and posted this here
Да, скорее всего так и есть. И это было бы замечательно, т.к. в остальном nginx меня полностью устраивает.
Нужна фича? Ждем следующих релизов!
Общество потребления.
Нужная фича? Напиши!
Общество потребления.
Нужная фича? Напиши!
Насчёт HTTP/1.0 — в смысле? Там же есть HTTP/1.1, права, в очень странном и своеобразном виде.
Можно про вид, пожалуйста, рассказать подробнее?
«It is an HTTP/1.0 proxy without the ability for keep-alive requests yet. (As a result, backend connections are created and destroyed on every request.) Nginx talks HTTP/1.1 to the browser and HTTP/1.0 to the backend server. As such it handles keep-alive to the browser.»
Т.е., насколько я понимаю, со стороны пользователя он HTTP/1.1. А вот со стороны сервера — 1.0. Т.е. в пределах одного соединения клиент может сделать несколько запросов (HTTP/1.1). Но они они будут обработаны, как несколько независимых HTTP 1.0 запросов.
Т.е., насколько я понимаю, со стороны пользователя он HTTP/1.1. А вот со стороны сервера — 1.0. Т.е. в пределах одного соединения клиент может сделать несколько запросов (HTTP/1.1). Но они они будут обработаны, как несколько независимых HTTP 1.0 запросов.
Ах, да, при этом заголовки он естественно серверу отдаёт в формате 1.1, но с пометкой HTTP/1.0 :)
Т.е тупо берёт от клиента заголовок и на каждый новый запрос повторяет его изменив 1.1 на 1.0. В целом работает не плохо :)
Т.е тупо берёт от клиента заголовок и на каждый новый запрос повторяет его изменив 1.1 на 1.0. В целом работает не плохо :)
Основная разница, между HTTP/1.0 и HTTP/1.1 это cunked передача, keep-alive и hosts, так, к слову
Согласен :) Но говорить, что keep-alive это «к слову» сильно не правильно. Без него нагрузка на сервер за счёт новых подключений будет колоссальной.
Зато с ним, возникает вопрос про утилизацию соеденений. Т.е. либо надо иметь pool соеденений, который будет использоваться, либо открывать на каждого пользователя новое keep-alive соеденение и закрывать как уйдет пользователь, либо придумывать асинхронный HTTP.
Т.е. с ходу, я не уверен что keep-alive до backend будет сильным плюсом. Особенно в контексте сложности реализации этого в nginx
Т.е. с ходу, я не уверен что keep-alive до backend будет сильным плюсом. Особенно в контексте сложности реализации этого в nginx
Разве он в proxy_pass не отдает только HTTP/1.0?
Если не секрет, чем nginx лучше lighttpd и почему именно nginx — прорыв?
Я сейчас хочу как-раз на lighttpd перейти с nginx'а ибо конфиг вкуснее, fcgi умеет сам пускать и прочие пряники. Где в нем плохо и почему все на nginx сидят — пока не вижу.
Я сейчас хочу как-раз на lighttpd перейти с nginx'а ибо конфиг вкуснее, fcgi умеет сам пускать и прочие пряники. Где в нем плохо и почему все на nginx сидят — пока не вижу.
Потому что Русское, патриотизм итп — мнение минимум двух человек.
Когда я им hightload настраивал на apache+squid, ребята смотрели большими глазами.
Когда я им hightload настраивал на apache+squid, ребята смотрели большими глазами.
Т.е. функционально — ничем не лучше? И где «прорыв» то?
Лично для меня nginx стал прорывов после Apache.
С lightppd я дела не имел, да и смысла не видел.
Конфиги nginx нравятся.
Обидно, что последний год nginx банально не совместим с моими требованиями.
С lightppd я дела не имел, да и смысла не видел.
Конфиги nginx нравятся.
Обидно, что последний год nginx банально не совместим с моими требованиями.
Вернее, глотком свежего воздуха, если быть точнее.
Потому что когда-то, когда было мало памяти, апач был 1.3 и имел некультурных размеров footprint, nginx на самом деле многих спас. Равно как и sphinx — кривые базы mysql, и так далее.
В целом я не против nginx, но сам его не использую, руководствуясь одним принципом — apache пока что мейнстрим, а в лайте конфиги читабельнее.
В целом я не против nginx, но сам его не использую, руководствуясь одним принципом — apache пока что мейнстрим, а в лайте конфиги читабельнее.
А причем sphinx к кривым базам MySQL? :)
в lighttpd конфиги становятся адскими при боле-менее сложной конфигурации
достаточно посмотреть как там SSL запускается чтобы понять что курят разработчики.
достаточно посмотреть как там SSL запускается чтобы понять что курят разработчики.
Посмотрите на RoadMap и на списки рассылки lighttpd. Там всё очень грустно.
В nginx еще грустнее, на самом деле )
Ну по крайней мере новую версию с нуля писать навряд ли будут. И там и там свои проблемы. Но у лайти проблемы серьёзнее. Там даже что-бы патч сконтрибьютить надо угрохать туеву хучу времени. Ну и скажу как человек работающий в группе, которая делает исключительно высоконагруженные сервисы — мы пока остановились на nginx. и его возможностей хватает.
в nginx почти нельзя отдать свой патч, так, к слову
Дык пишите патчи, которые принимают
hello world патчи, что ли? Пошукайте в гугле по словам «catap nginx».
Как количество написанного соотносится с трудностями «отдать свой патч»?
А слово «качество» тоже забыли? Только не надо заводить волынку, что «раз этого нет, то это не нужно». Этого нет и это НУЖНО.
То, что это кому-то нужно еще не повод принимать патчи.
Повод принять патч — очевидная полезность для большинства и удовлетворительное качество патча.
Видимо, чего-то в них не хватает, раз не принимают.
Повод принять патч — очевидная полезность для большинства и удовлетворительное качество патча.
Видимо, чего-то в них не хватает, раз не принимают.
А большинство никто не спрашивал, нужно ему это или нет. Опросов на сайте не устраивал, всё исключительно на усмотрение лидера проекта.
Дык что мешает сделать опрос? Или это Игорь должен делать? :-)
А неважно. Важно, что патч (какой бы он хороший ни был) в апстрим не принимается.
У владельца апстрима может быть море причин не принимать патч. Например, он не хочет его поддерживать в будущем. Может, просто вредный владелец.
Но факт есть факт: патч далеко не так просто внести в апстрим, особенно нетривиальный.
У владельца апстрима может быть море причин не принимать патч. Например, он не хочет его поддерживать в будущем. Может, просто вредный владелец.
Но факт есть факт: патч далеко не так просто внести в апстрим, особенно нетривиальный.
> Важно, что патч (какой бы он хороший ни был) в апстрим не принимается.
Да ладно? В последнее время почти половина записей в changes — это сторонние патчи.
И если какой-то патч не принимается, очевидно, на это есть причина.
Да ладно? В последнее время почти половина записей в changes — это сторонние патчи.
И если какой-то патч не принимается, очевидно, на это есть причина.
Макса? Так всему что сейчас попадает в upstream уже более полугода-года.
Причина почему не принимаются патчи вполне понятна. Нет тестов. И пока не будет внятной системы тестирования (она есть, но Игорь ее не включает), не понятно, что делает патч реально. Т.е. мелочь, да, он охотно принимает. А что-то крупное, увы, нет.
Причина почему не принимаются патчи вполне понятна. Нет тестов. И пока не будет внятной системы тестирования (она есть, но Игорь ее не включает), не понятно, что делает патч реально. Т.е. мелочь, да, он охотно принимает. А что-то крупное, увы, нет.
А вы посмотрите на обилие сторонних патчей, так, к слову. Просто кричать что вы пишете не так, это хорошо, но как мне найти вас в changes? Я там есть, а вы?
redmine.lighttpd.net/wiki/lighttpd2/ Так уж грустно?
грустно ибо уже скоро год как
ибо скоро год что?
Я его гонял, оно достаточно стабильно и большинство модулей уже реализовано.
Разработчики в ирц подтвердили, что его уже можно пробовать. Просто у них весьма странное отношение к подготовке релизов. 1.5 ветка, тоже, фактически, не была выпущена, но является стабильной.
Я его гонял, оно достаточно стабильно и большинство модулей уже реализовано.
Разработчики в ирц подтвердили, что его уже можно пробовать. Просто у них весьма странное отношение к подготовке релизов. 1.5 ветка, тоже, фактически, не была выпущена, но является стабильной.
Скоро год как нет хотя бы бета релиза
ветка 1.5 далеко не стабильная — любые бэкэнды отличные от writev глючат по чёрному при нагрузке.
Даже tarball-ы уже для 1.5 не собирают.
ветка 1.5 далеко не стабильная — любые бэкэнды отличные от writev глючат по чёрному при нагрузке.
Даже tarball-ы уже для 1.5 не собирают.
При какой, в цифрах, нагрузке начинаются проблемы? Года 2 использую 1.5 ветку с gthread-aio бекэндом и с проблемами не сталкивался.
вот багрепорт которому 2 (два!) года:
вот = redmine.lighttpd.net/issues/1665
«linux-aio* backends are disabled in recent versions» каково, а?
«linux-aio* backends are disabled in recent versions» каково, а?
ваш коммент, конечно всколыхнул мою тревогу на счет выбора nginx для себя, но непродолжительное гугление подсказало, что lighttpd не настолько хорош
www.wikivs.com/wiki/Lighttpd_vs_nginx
hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps
течь — это плохо
www.wikivs.com/wiki/Lighttpd_vs_nginx
hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps
течь — это плохо
January 10, 2007 @ 4:41 am — дата ни о чём не говорит?
redmine.lighttpd.net/issues/show/758 открыт
кроме того дата 2009
кроме того читаем по линками
кроме того отвечаем по делу
— есть патч, который устраняет данную проблему?
— есть бенчмарки?
— есть практический опыт?
кроме того дата 2009
кроме того читаем по линками
кроме того отвечаем по делу
— есть патч, который устраняет данную проблему?
— есть бенчмарки?
— есть практический опыт?
# Status changed from New to Invalid
в каком месте он открыт?
Это как бабки на лавочке перед подъездом: «А я слышала, что он течёт...» Где вообще подтверждение, что на сегодняшний день течёт какая-то из веток, будь то 1.4, 1.5 или 2.0?
в каком месте он открыт?
Это как бабки на лавочке перед подъездом: «А я слышала, что он течёт...» Где вообще подтверждение, что на сегодняшний день течёт какая-то из веток, будь то 1.4, 1.5 или 2.0?
Summary: lighttpd of course had some memory leaks (and perhaps even has today), but this bug is not about these problems.
The main problem here is that the memory gets fragmented, and that is why malloc()/free() doesn't return the memory to the system; the memory is not lost to lighttpd, and lighttpd/malloc() will reuse the memory.
закрыт он собственно не потому, что он исправлен, а потому что там оффтоп пошел.
собственно если вы спец в нем, то рассказывайте свой опыт использования, а то вопросы я вроде бы задал, а ответы так и не сказаны.
The main problem here is that the memory gets fragmented, and that is why malloc()/free() doesn't return the memory to the system; the memory is not lost to lighttpd, and lighttpd/malloc() will reuse the memory.
закрыт он собственно не потому, что он исправлен, а потому что там оффтоп пошел.
собственно если вы спец в нем, то рассказывайте свой опыт использования, а то вопросы я вроде бы задал, а ответы так и не сказаны.
последняя стабильная версия как показывает практический опыт не течёт совсем
Кто вам сказал что nginx лучше lighttpd? Или что nginx — прорыв?
nginx — просто удобный сервер, которым пользуются миллионы сайтов. А про lighttpd такого не скажешь.
nginx — просто удобный сервер, которым пользуются миллионы сайтов. А про lighttpd такого не скажешь.
nginx еще пол года назад находился на уровне лайти. Всплеск сейчас по причине того, что многие ру-хостеры ставят его мордой вперед ибо ру-зоне нгинкс очень популярен.
Я сильно подозреваю, что причина — патриотизм, а не реальные факты.
Я сильно подозреваю, что причина — патриотизм, а не реальные факты.
Давайте посмотрим, что было пол года назад.
К патриотизму популярность, увы, вряд ли имеет отношение, учитывая, что часть рунета, покрытая nginx-ом явно меньше 6.5% от общего кол-ва сайтов в мире.
К патриотизму популярность, увы, вряд ли имеет отношение, учитывая, что часть рунета, покрытая nginx-ом явно меньше 6.5% от общего кол-ва сайтов в мире.
За полгода никаких прорывов!
nginx приятен своей системой разработки. 95% кода написано Игорем. Остальные 5% это мелкие-мелкие патчи. Сам nginx простой и тупой. Он сам проще, чем его реализация SSI (sic!). У него хороший, код, написанный в одном стиле. Про лайти я такое, увы, сказать не могу.
Потому что быстрый и есть passenger для Rails
lighttpd даже не полностью поддерживает HTTP 1.1 протокол.
Например Continue, от чего некоторые сервисы не работают.
Он медленно развивается, предоставляет меньший функционал.
Например Continue, от чего некоторые сервисы не работают.
Он медленно развивается, предоставляет меньший функционал.
трололо. lighttpd «не полностью» поддерживает vs nginx «вообще не поддерживает»
лучше сразу знать что вообще не поддерживает чем мучится а потом находить server.reject-expect-100-with-417
можно узнать в каком месте nginx не поддерживает HTTP/1.1?
То что вы в этом вопросе трололо и так понятно.
nginx полностью поддерживает протокол HTTP 1.1, в отличие от lighttpd, в котором полную поддержку уже 3 года обещают.
nginx полностью поддерживает протокол HTTP 1.1, в отличие от lighttpd, в котором полную поддержку уже 3 года обещают.
UFO just landed and posted this here
Уверен, Игорь Сысоев добавит работу с вебсокетами как будет в этом реальная необходимость.
как будет что-то готовое и рабочее я перенесу все проекты как в свое время слетел с апача, когда более 400 сайтов было апач стал некоторым образом не работать )
А чего это он стал у вас некоторым образом не работать? На сколько сильно нагружены сайты?
понятие сильно у разных по разному, средняя нагрузка на сайт около 1000 посетителей в день. уников. он падать стал.
Сколько хитов в месяц? 1000 посетителей в день это вообще не нагрузка. У меня в десять раз больше и все нормально. Я даже поверх этого количества еще атаку с помощью ab запускал. И все стоит, не падает. centos.org вообще фиг знает, сколько в день испытывает. А там тоже апач стоит.
дайте адресок) я попробую в личку)
1. У меня еще доры там были я их не считал вообше.
2. с 10 раз больше сателитов? или что за сайты.
3. у меня еще джанго
4. в скупе всего я перелез на нгикс
5. скорость работы стала выше — это стало видно даже без тестов.
1. У меня еще доры там были я их не считал вообше.
2. с 10 раз больше сателитов? или что за сайты.
3. у меня еще джанго
4. в скупе всего я перелез на нгикс
5. скорость работы стала выше — это стало видно даже без тестов.
www.gsmforum.ru
Внизу страницы есть счетчики.
Внизу страницы есть счетчики.
) один сайт ) вы говорили в 10 раз больше. я иммено перешел больше не в нагрузке, а в количестве.
Честно говоря, звучит как чушь. Мой хостер использует апач. У них на сервере наверное около пары сотен сайтов висит.
ок чуш так чуш настаивать не буду ) «пары сотен сайтов висит» — это не серьего, я говорил что начал испытывать трудности с 400 сайтами.
и если быть более правдивым, то у многих хостеро апач сидит за нгиксом
и если быть более правдивым, то у многих хостеро апач сидит за нгиксом
Я думаю, что у вас проблема в ограничении на файловые дескрипторы:
serverfault.com/questions/151245/what-is-the-maximum-number-of-virtualhosts-apache-can-handle
serverfault.com/questions/151245/what-is-the-maximum-number-of-virtualhosts-apache-can-handle
Что это? Беглая мысль субботним вечером или наброс на вентилятор?
Широкий кругозор? Так расскажите людям, зачем люди используют инджайн икс и почему два предложенных решения являются конкурентами.
Иначе это просто субботний наброс на вентилятор.
Широкий кругозор? Так расскажите людям, зачем люди используют инджайн икс и почему два предложенных решения являются конкурентами.
Иначе это просто субботний наброс на вентилятор.
О, черт. Через двадцать минут понедельник. Ну, вы меня понимаете :-)
Это мысли после того, когда опять не удалось решить задачи с помощью nginx.
Решил сэкономить время сообщества, рассказав о найденных альтернативах. Немного сумбурно, конечно.
Решил сэкономить время сообщества, рассказав о найденных альтернативах. Немного сумбурно, конечно.
Итак типичное применение прокси-сервера для сайте — это поиск подходящего обработчика, и проброс соединения до него. Далее отдача результата клиенту.
Бонус: прокси-сервер берёт на себя взаимодействие с медленными клиентами, снижая затраты на незавершенный ответ.
Бонус: Часто прокси-сервер используется для балансирования нагрузки и т.д.
Некоторые прокси-сервера также удобны для отдачи статики (nginx, lighttpd).
В высоконагруженных системах популярны схемы из цепочек прокси-серверов (от двух).
HA Proxy отличается тем, что его время отклика в среднем ниже, и он не умеет отдавать статику. При этом он нормально отдаёт бэкэнду запросы HTTP/1.1, не портя их. В последних версиях поддерживается драфт WebSockets.
Бонус: прокси-сервер берёт на себя взаимодействие с медленными клиентами, снижая затраты на незавершенный ответ.
Бонус: Часто прокси-сервер используется для балансирования нагрузки и т.д.
Некоторые прокси-сервера также удобны для отдачи статики (nginx, lighttpd).
В высоконагруженных системах популярны схемы из цепочек прокси-серверов (от двух).
HA Proxy отличается тем, что его время отклика в среднем ниже, и он не умеет отдавать статику. При этом он нормально отдаёт бэкэнду запросы HTTP/1.1, не портя их. В последних версиях поддерживается драфт WebSockets.
yaws посмотри
UFO just landed and posted this here
Это верно, пока устоявшегося стандарта нет, ни одну реализацию нельзя назвать законченной.
Это было бы верно для стабильной версии.
Версия в разработке всегда должна быть на грани.
Версия в разработке всегда должна быть на грани.
Тогда какой смысл писать proxy-сервер для этого?
Именно сейчас пишутся проекты, включая создание production-окружения, для технологий ближайшего будущего.
Соответственно, нужны и прокси-сервера.
Соответственно, нужны и прокси-сервера.
Зачем? Зачем нужно лишнее звено в этом контексте? Может стоит построить ферму web-sockets, взять loadbalancer а не proxy и быть счастливым? У меня ощущение что вы не понимаете что такое nginx.
nginx неплохо работает и как load balancer, хотя, конечно, не в этом его предназначение.
Смысл в том, что мне надо отдавать через 80 порт и статику, и классический Web (Rails), так и видеопотоки по RTMP(T), и данные через Web Sockets.
Соответственно, сейчас у меня впереди стоит HA Proxy, за ним параллельно работают nginx + unicorn, node.js и видеосервер.
Смысл в том, что мне надо отдавать через 80 порт и статику, и классический Web (Rails), так и видеопотоки по RTMP(T), и данные через Web Sockets.
Соответственно, сейчас у меня впереди стоит HA Proxy, за ним параллельно работают nginx + unicorn, node.js и видеосервер.
Не, как loadbalancer он очень уныл. У него плохая статистика. haproxy красив. Цитрикс вообще сказка.
А что мешает сделать разные фермы? Т.е. отдельно статику, отдельно класический web, отдельно порнушку, отдельно спам от клиентов? Собирать все вместе, красиво, не спорю, но дюже странно. Т.е. я не понимаю зачем совмещать все в кучу, если оно, хорошо, параллелится.
А что мешает сделать разные фермы? Т.е. отдельно статику, отдельно класический web, отдельно порнушку, отдельно спам от клиентов? Собирать все вместе, красиво, не спорю, но дюже странно. Т.е. я не понимаю зачем совмещать все в кучу, если оно, хорошо, параллелится.
Вы куда-то вперед паровоза бежать бросились.
Неплохо ты Сысоеву присунул
Неплохо бы он присунул, если бы написал свой сервер, столь же легкий, удобный и надежный, но с поддержкой Web Sockets. А так, в воду пернул, просто.
Уверен, когда-нибудь в nginx появится и поддержка Web Sockets.
Но она нужна уже сейчас, равно как и полноценная поддержка HTTP/1.1.
Но она нужна уже сейчас, равно как и полноценная поддержка HTTP/1.1.
Я это читал, ты выше написал.
Где она нужна? Примеры? Больших нужных проектов которым это нужно?
Полбраузера поддерживает эту технологию, и всё! Не учитывая приблуд флешевых
Где она нужна? Примеры? Больших нужных проектов которым это нужно?
Полбраузера поддерживает эту технологию, и всё! Не учитывая приблуд флешевых
Что не работает из HTTP/1.1 при общение с клиентом?
Речь не про общение с клиентом. Мне нужна работа с апстримом по HTTP/1.1
я бы не отказался хотя бы от проксирования websocket соединения
Детка, это OpenSource. Тебе надо — ты и пиши.
Прежде чем писать свой велосипед, лучше попробовать найти подходящий.
Эта заметка вообще-то именно этому и посвящена.
Эта заметка вообще-то именно этому и посвящена.
Эта заметка, явный, не прикрытый, наброс на nginx. Основной дух заметки, nginx гавно, напишите для меня что я хочу. Если вам это действительно надо, мои контакты в профиле. Ты можешь мне позвонить: +1.949.2.666.273 и вскоре появится реализация web sockets в nginx, если она тебе действительно нужна.
Хорошо, свяжусь.
Мне действительно нужна поддержка запуска fcgi…
На удаленном сервере, да?
Нет. На том-же, на чем и енджин крутиться. Сейчас приходится за ним пускать опача ради джанги, что меня надо признать сильно гнетет.
- django умеет ловко сама быть fastcgi сервером, для этого у manager.py есть runfcgi
- что мешает запускать ваш сайт, как сервис в системе?
e.g. джанго-сайтов на сервере крутиться штук 20 и периодически добавляются. Гемороя с настройкой гораздо больше, нежели если-бы нгинкс умел стартовать сам.
Я бы для этого использовал супервизоры процессов, они могут автоматически стартовать скрипты при появлении симлинка в каталоге, к примеру.
runit, DJB daemontools, или upstart.
runit, DJB daemontools, или upstart.
Создайте папочку, /etc/django-sites.d куда складывайте symlinks до корней этих сайтов, и дальше, просто, скриптом их запускайте. Тут не много нужно сил (час) что бы написать этот скрипт.
Почему nginx не должен запускать сайты, тоже понятно. Это очень узкий функционал, который, фактически, используется тем, кому уже нужен nginx но еще нагрузка (пока) позволяет жить на одном сервере. Этот функционал позволяет допустить ошибку в дизайне системе, связанную со стартом приложения. Лучше, все-же, подумать про это, чем потом, в горячке и панике, когда клиентов у ваших сайтов будет сотни тысяч, понимать, как его разнести.
Почему nginx не должен запускать сайты, тоже понятно. Это очень узкий функционал, который, фактически, используется тем, кому уже нужен nginx но еще нагрузка (пока) позволяет жить на одном сервере. Этот функционал позволяет допустить ошибку в дизайне системе, связанную со стартом приложения. Лучше, все-же, подумать про это, чем потом, в горячке и панике, когда клиентов у ваших сайтов будет сотни тысяч, понимать, как его разнести.
Проблема решается написанием sh скрипта за 20 минут.
Socket.IO для Node.js
> В настоящее время, к сожалению, этот продукт тормозит развитие Web, так как является динозавром эпохи HTTP/1.0.
Фигню говорите. WebSocket — до сих пор в черновиках W3C и там часто вносятся координальные изменения.
Нет проблемы написать модуль к nginx'у.
А вообще, у меня просто phpDaemon с websocket-сервером висит отдельно от nginx всё отлично. А ваш пост УГ, батенька.
Фигню говорите. WebSocket — до сих пор в черновиках W3C и там часто вносятся координальные изменения.
Нет проблемы написать модуль к nginx'у.
А вообще, у меня просто phpDaemon с websocket-сервером висит отдельно от nginx всё отлично. А ваш пост УГ, батенька.
Вроде бы, всегда было деление: nginx — легкий вебсервер. кеширователь, и прочее, а не балансер. И основная цель — снизить нагрузку на бекенд. И зачем ему тогда проксировать вебсокеты?
Еще вот это можно попробовать: trafficserver.apache.org/
Sign up to leave a comment.
Замены для nginx (Web Sockets)