Pull to refresh
122
0
Sergey G. Brester @sebres

Senior Engineer; Data Scientist; Security Auditor

Send message
Думаю — да, а в чем сомнения?
Вот тут ребята баунти для IPv6 открыли, кто готов вложится — деньги кидать здесь: https://www.bountysource.com/issues/1089051-ipv6-support :)
старомодный интерфейс
Насколько знаю, оно вроде даже на tcl8.6 работает (где-то видел чей-то патч). Т.е. ничто не мешает привязать к нему Ttk (темы для tk, доступны с tcl8.5) — будет выглядеть вполне себе «нативненько», думаю на любых иксах. Эх времени жаль нет совсем…
Всего 250?! Вы хоть раз такую нагрузку симулировали?
А именно воссоздадим наиболее тяжелые условия, заставив NGINX выполнять смесь блокирующих и неблокирующих чтений, когда проблема блокировок на обращениях к диску проявит себя в полной мере.
Вы через строчку читаете?
И пока дисковая подсистема делает свою работу как может, обслуживая наш “паразитный” трафик с первой машины, NGINX использует оставшиеся ресурсы процессора и пропускную способность сети, чтобы обслужить второго клиента из памяти.

Грубо говоря, есть огромный disk load (паразитный ли нет, есть не суть важно). Кэш вымывается, скорость чтения падает и т.д. Но из за того что имеем теперь пул потоков, а не один воркер, этот пул может отдать в 31 раз больше (т.е. целых 250 вместо всего 8 rps) например то, что еще или уже лежит в памяти.
Чё это?.. Первый абзац — то как-бы в шутку было. Ну а второй, ну вы ветку то просмотрите… Сплошной конструктив.
ПС. а для простыней люди давно изобрели уже спойлер.
Так то оно так. И это правда реактор на AIO. Просто тонкости реализации и «тонкие» настройки там играют очень заметную роль. Много и много фрагильнее линуксовых. Например в свое время была такая библиотека как ACE, так там до какой-то версии реактор acceptor-ов «конфликтовал» с реактором worker-ов. Ужасно бажная была реализация.
Проблема еще в том, что под win GetOverlappedResult (или WSAGetOverlappedResult) многопоточно, это не тоже самое что GetOverlappedResult многопроцессно. Вся разница в том, что оно изначально заточено под пул потоков и там более менее оптимально «ядерно» работает. В случае же много процессов есть небольшой конфликт в ядре в генераторе события и обертка над наследуемыми сокетами там в одном месте как-бы настолько синхронна (и насколько помню даже не атомарно), что не просто context switch, а процессы тупо «распараллеливаются» — это не то, чтобы узкое горлышко — по моему такое называют порогами (как на реке), т.е. потоки разных процессов их проходят друг за другом.
Кто погоняет такой реактор SoftICE-ом с дебажным win-kernel, откроет для себя много нового по поводу thread != process под windows.
Офигительный перевод Бартенева, сделаный Бартеневым )) Неделя nginx продолжается… Ура!
Ну вот это-то здесь каким местом… Или вы подозреваете, что они (конкуренты) были русские граждане? Опять все на русских валите? Вы что же это, разжигаете межнациональную вражду? ))
А по делу: давайте сюда, в эту статью, вообще весь уголовный кодекс свалим… Ребята, ну харош уже холиварить.
Ну они не мои конкуренты (я делал «аудит» почти по дружбе, для друзей очень хорошего знакомого). И я их вовсе не защищаю, я просто пытался донести опоненту всю сложность такого рода судебных разбирательств.
А так то да — редиски они конечно — тут вроде и злой умысел налицо, и мотив и т.д.
Но вот что касается доказательной базы… По крайней мере юристы компании очень сумлевались, а как выразился один мой знакомец «в суде как в открытом море — никогда не знаешь откуда ветер подует».
Ну, может или нет, доказывать конкурентам, как и причину зачем они добавили скрытый url на свои страницы.
Вам действительно лучше не «адвокадствовать»… Вы про понятие презумпции невиновности что-нибудь слышали?
У вас будет объяснение зачем, а у них?
Я жеж написал ужо, SEO например…
OK, вот вам по пунктам контраргументы:
Неправомерный доступ к серверу… так как данный url не является публично доступным
Так url возвращает 404… И как вы докажете, что это был злой умысел, что это не пострадавший сам этот url сделал недоступным (увидев что мой мандант сделал ссылку) и что «самострел» вообще не специально организован, чтобы подать на конкурента в суд?

Произошло сознательное нарушение работы сервера (ЭВМ) mysite…
… приведет к невозможности дальнейшей работы данного пользователя с сервером
Во первых нарушения работы сайта по видимому не было. Да и нарушение при вызове несуществующего url (404) — это нонсенс. А может url там все-таки раньше был (просто мой мандант хотел типа SEO сделать — накрутить себе рейтинг в поисковиках).
Во вторых очевидно, что «невозможность дальнейшей работы» с сайтом возникла в следствии по видимому некомпетентных действий администраторов самого истца. (Опять аргументы за самострел...) Или вообще это был злой умысел с его стороны, чтобы очернить ответчика.

Статья 272. Неправомерный доступ к компьютерной информации
На территории нашей страны, эта статья (вероятно из кодекса УК РФ) не действует. Адвокат истца совсем берега попутал…

Нда… я конечно жутко извиняюсь, но с таким адвокатом впору «мировое», да на любых условиях, подписывать…
Вы поймите я то как раз на стороне «истца», но экспертную оценку уже много раз делал, поэтому как раз сложность сего действа в этом конкретном случае себе очень хорошо представляю…
Ну, обычно суд в таких случаях привлекает экспертов по безопасности, а эксперту, мне кажется, тут будет сразу понятно, что это не просто пара невидимых ссылок...
Да ну? И часто вы на таких судебных заседаниях бывали?

Вот как эксперт — эксперту, прокомментируйте мне для примера пожалуйста весь ужас следующего url, только плз аргументировано:
//mysite/phpMyAdmin/
SQL injection… в поле ввел свое имя вида «vasja;select * from admin;»...
Это все ваши домыслы… Я про это в статье ни слова сказал, речь шла про bootsearch-фильтры.
Ну насчёт 100% — сомнительно, к слову например на аргумент защиты «мой мандант просто разместил у себя 3 ссылки», контраргументы поискать бы пришлось. Согласитесь, если бы не бан, такое и атакой-то назвать трудно… А за бан они не отвечают — самострел же.
«грязная» — от слова рекурсия )) а в несколько раз больше оно уже само сделает…
Да много чего можно: представьте простенький редирект на не быструю и ресурсозатратную динамику на их стороне, да с теми же инклюдами внутри. Тут или браузер клиента повесится, или… ишак сдохнет…
Ну как нашли, ему такая «грязная бомба» (по referrer) прилетала, что они сами даже без требований все убрали…
И как оно должно спасти против бана? Вы возможно не поняли — это не JavaScript и иже с ним. Например, это просто img с урлом, который «способствует» бану.
Имел ввиду nginx 4 win on reactos…
Например, работает ли то же наследование listener, shmem и т.д.
Кстати вот не пробовал… а интересно, правда. Время, будь оно неладно.
Если кто вдруг опередит, отпишитесь, плз…

Information

Rating
Does not participate
Location
Hamburg, Hamburg, Германия
Date of birth
Registered
Activity