Здравствуйте, pagid, Вы писали:
P>Здравствуйте, okon, Вы писали:
O>>Понятно, просто у Сбера с его клиенсткой базой и возможностями маркетинга в России раскрутить любую какашку могут и насадить каждому пенсионеру. P>Сбер там не при делах.
Ну-ну.
Лев Хасис — Первый заместитель Председателя Правления Сбербанка.
В 1994 – 1999 гг. работал арбитражным управляющим, президентом ОАО «Авиакор», на Хабре проскочила информация, что он в это время урал некое оборудование стоимостью 5 миллионов долларов.
Александр Мамут. Находится в дуржеских отношениях с Игорем Шуваловым.
Явился конечным выгодоприобретателем после рейдерского отъема Евросети у Чичваркина.
Организует разнообразные юридические прокладки для ухода от ответственности.
Весной Сбербанк объявил об инвестициях в капитал Rambler Group. Денежные средства за 46,5-процентный пакет действующим акционерам — AN&N Александра Мамута и Era Capital — выплачены не будут, все средства пойдут на развитие медиахолдинга. Размер инвестиций Сбербанк не объявлял, источники РБК в апреле говорили о 9–11 млрд руб.
Вы полагаете, когда дело идет о таких суммах, Греф будет не при делах?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, CreatorCray, Вы писали:
CC>>Деньги готовы заплатить за большую пользовательскую базу, которая на него уже подсажена и которой можно продавать всяко разно, от поддержки до кастомных решений.
S>Большая пользовательская база не с потолка берется.
Насобиралась за долгие годы от отсутствия хороших альтернатив на никсах
Поди пересади их всех на новый продукт если:
1. И так работает + давно все нюансы знакомы
2. Халява же!
Здравствуйте, okon, Вы писали:
O>Сейчас отжимают нгинх , что в нашем царстве государстве вполне ожидаемое явление. O>Но меня заинтересовал другой вопрос, т.к. всегда казалось что написать прокси сервер может любой программист за день.
Я начал использовать nginx где-то в 2009-м году. До этого использовал lighttpd (пока он не стухнул).
Что тогда умел nginx:
1) Он был асинхронным. Т.е. работал всего в нескольких потоках, на тот момент большинство языков и серверов использовали модель поток-на-запрос. Статья http://www.kegel.com/c10k.html была всё ещё очень актуальна.
2) Он был быстрым. По сравнению с Апачем работал раз так в 10 быстрее, особенно на выдаче статики.
3) Для статики поддерживал sendfile() и splice().
4) При этом имел нормальный язык для конфигурации виртуальных хостов и правил перенаправления. Он прекрасно подходил для стандартной на тот момент ситуации — один хост и несколько сервисов на нём.
Сейчас такое написать будет намного проще — libuv в зубы и пишем на Rust за месяц-другой. Но в 2004-м ничего этого и близко не было.
Современные задачи уже немного поменялись, сейчас отдача статики мало кого волнует — если с этим есть проблемы, то использует CDN'ы. Зато нужна поддержка микросервисов, QUIC и т.д.
Здравствуйте, okon, Вы писали:
o> Делать быстро это хорошо, но что тут можно изобрести, считать блок данных нужно из сокета — нужно, интересно что тут можно придумать кроме как использовать стандартное апи для работы с сокетами или делать какой-то свой драйвер ? но думаю врятли они этим начали заниматься. o> ... o> Вот интересно в каком месте предложенного выше решения тормоза и как можно еще быстрее сделать ?
API — да, стандартное, но на разных системах api разное с разными особенностями и списком поддерживаемых возможностей. Вот документация по директиве listen — включение опции reuseport (начиная с nginx 1.9.1) может дать ускорение до 20% на handshake.
Ну и да, в некоторых краевых случаях берут специализированное api для работы с сетью типа dpdk или F-Stack.
Дальше у нас большинство сайтов сегодня на httpS, где для работы nginx может быть собран с разными библиотеками (OpenSSL, BoringSSL). Вот пример того, как CloudFlare выжимает миллисекунды при работе TLS. Или, например, не все мобильные устройства поддерживают расширение AES-NI для аппаратной работы с AES шифрованием. Вот пример того, как в CloudFlare динамически меняли шифр с AES на ChaCha20 для таких устройств.
С памятью тоже может быть не все так просто — запрос/ответ может иметь большой или неизвестный размер, что считать его весь в память будет нельзя. Любая работа с общими ресурсами будь то пул блоков или какой-то interprocess счетчик требует синхронизации (блокировок). Копирование любого блока памяти операция очень дорогая.
Т.е. общее направление твоей мысли верное, но вот во всех этих казалось бы мелких деталях ты проведешь 80 (если не все 99.9) процентов времени разработки.
Здравствуйте, Ops, Вы писали:
Ops>Это ты про идиотские конфиги? Там вся "уникальность" лишь в том, что ушлые ребята еще не нашли в нем фатальный недостаток, иначе б и они справились.
Давно нашли. Сперва был lighttpd, сейчас наверное haproxy, envoy и собственные проприетарные решения у AWS и Azure.
Здравствуйте, Mamut, Вы писали:
S>>Вы точно со мной сейчас разговариваете? Ощущение что вы отвечаете что-то, что я никогда не говорил. M>
M>Somerscout: Да и сейчас у него конкурентов хватает (HAProxy, Traefik), просто nginx распиарен основательно.
Высказывания "распиарен основательно" и "вложилась в международный PR" не эквивалентны ни разу. nginx, как это почти всегда и бывает, оказался в нужное время в нужном месте, остальное сделало сарафанное радио.
Здравствуйте, Anton Batenev, Вы писали:
AB>Сегодня, в эпоху множества дата-центров, chaos monkey, моды на микросервисы, где постулируется, что выпадение любой боевой единицы вплоть до целого ДЦ никак не должно влиять на сервис в целом, перед "простым прокси" возникают и решаются задачи совершенного другого порядка.
Только задачи эти энжинксом не решаются ни разу. В реальности это просто маленький заменяемый винтик в к8с.
У nginx очень много разных фич. А так да, в простейшем виде ну про день это чушь, конечно, проект такого рода надо писать с нуля с полностью оптимизированным сетевым стеком и HTTP стеком и поддержка основных стандартов на должном уровне это грубо говоря человекогод квалифицированного C или Rust разработчика. Но суть nginx в том, что он уже давно не простейший и предоставляет очень много возможностей, одним процентом которых пользуется почти каждый, но, как в ворде, у каждого этот процент разный.
По сути, конечно, несмотря на громкие слова о том, что весь интернет на nginx, прям такой огромной ценности в этом проекте я, лично, не вижу. Можно и без прокси сервера наружу смотреть, можно на апаче сидеть, можно на других прокси серверах сидеть, можно аналог написать. Тем не менее штука весьма полезная и лишаться её обидно.
Здравствуйте, Somescout, Вы писали:
S>Nginx исторически популярен, и зачастую используется даже там, где в принципе не нужен (например сейчас я бы уже не стал использовать nginx для именно реверс-прокси, когда дополнительная обработка не требуется, взял бы что-нибудь другое).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Давно нашли. Сперва был lighttpd, сейчас наверное haproxy, envoy и собственные проприетарные решения у AWS и Azure.
Ушлые ребята в перечисленном — это только AWS и Azure, но у них нишевые решения.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> AB>Сегодня, в эпоху множества дата-центров, chaos monkey, моды на микросервисы, где постулируется, что выпадение любой боевой единицы вплоть до целого ДЦ никак не должно влиять на сервис в целом, перед "простым прокси" возникают и решаются задачи совершенного другого порядка. НС> Только задачи эти энжинксом не решаются ни разу.
Решаются. В коммерческой версии чуть больше, в community меньше, в каких-то случаях требуется потанцевать с бубном. Очевидно, что на все случаи жизни варианты конфигурации не предусмотреть, но большинство базовых вещей nginx умеет.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Nginx исторически популярен, и зачастую используется даже там, где в принципе не нужен (например сейчас я бы уже не стал использовать nginx для именно реверс-прокси, когда дополнительная обработка не требуется, взял бы что-нибудь другое).
НС>Почему?
Потому что мне не нужны возможности nginx — задача банальная, реверс-проксировать примерно полсотни сайтов с бэкендов.
НС>И что взял бы?
Traefik попробовал бы, наверно — простой, тупой, поддерживает автоматическое получение сертификатов от let's encrypt.
Здравствуйте, Somescout, Вы писали:
НС>>Почему? S>Потому что мне не нужны возможности nginx — задача банальная, реверс-проксировать примерно полсотни сайтов с бэкендов.
Здравствуйте, Codealot, Вы писали:
O>>Не соглашусь, есть линукс, но платят за разработку винды и МакОС — такое же но лучше
C>Оба появились до линукса и уже имели большую базу.
Макос была полностью переписана уже после, причем без всякой обратной совместимости.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, okon, Вы писали:
O>Но меня заинтересовал другой вопрос, т.к. всегда казалось что написать прокси сервер может любой программист за день. O>Понятно что в этом прокси сервере нгних функциональщины побольше чем на день, но не вижу там никакого рокетсайнса, но что мешает вместо того чтобы отжимать — просто взять исходники и отрефакторить под свой лад. В этом случае никаких прав уже предъявить нельзя.
M>>Somerscout: Да и сейчас у него конкурентов хватает (HAProxy, Traefik), просто nginx распиарен основательно.
НС>Высказывания "распиарен основательно" и "вложилась в международный PR" не эквивалентны ни разу. nginx, как это почти всегда и бывает, оказался в нужное время в нужном месте, остальное сделало сарафанное радио.
Вобщем всё еще хуже, вера "во всемогущий PR" была сильно недооценена: не надо даже вкладываться, достаточно, что-бы тебя попиарило сарафанное радио и в результате этого в течении следующих десяти лет рядовой, вобщем-то ничем не примечательный проект зохавает половину интернетов...
Здравствуйте, okon, Вы писали:
O>И подскажите что такого уникального в этом прокси, почему его не дешевле написать с нуля и качественнее пусть 2 программистами за год за 2 млн долларов, чем покупать за несколько миллиардов. O>Просто популярное название ?
