Это просто анализатор кода на bad smells. Весь рефакторинг потом ручками делать.
Есть еще очень мощная штука — github.com/jscruggs/metric_fu. Там под одной крышей собрали кучу инструментов по оценке качества кода по разнообразным метрикам.
У меня тоже WDTV Live, в один из USB вставлен DLink DWA-140 (USB WiFi адатер с поддеркой n стандарта, ~25$).
Все работает даже на родной прошивке.
Из траблов — с некоторыми версиями альтернативной прошивкой (b-rad) после полного выключения/включения адаптер мог не стартануть, и приходилось руками передергивать.
Ну и минус что одна USB-шка занята, так что если жесткий диск подключен, то уже флешку не всунуть.
Код из той статьи показывает эффективность работы с рекурсией. Тот-же JRuby если включить специальный режим оптимизации, может преобразовать ее в инлайны, тогда все будет очень быстро работать. Но теряется гибкость кода, и не все что будет работать в обычном руби сможет работать в таком режиме.
Вероятно, MacRuby делает что-то подобное, если настолько опережает даже YARV-овский байт-код (и уж тем более обычный руби).
Имхо, скорость Ruby 1.9 с YARV-ом полностью покрывает потребности в веб-разрабтке. Ну а специфичные русурсоемкие операции можно выносить и делать на сях :)
Как я понимаю, тест был на Ruby 1.9.1 в котором встроена YARV, и такая простая задача могла хорошо оптимизироваться. Если можно, сделайте еще несколько тестов, с более сложными вычислениями в коде, хотя-бы как в той статье, очень интересно посмотреть что получится.
У мака другая нумерация юзеров (uid 501 для первого юзера, а в linux uid 1000), и потому надо в параметрах экспорта конфига NFS сервера указать: insecure,all_squash,anonuid=1000,anongid=1000 (два часа в свое время маялся с этой траблой).
А если для удобства работы с тестовой системой нужен удобный рутовый доступ, то можно указать так (файл /etc/exports):
Грубо говоря, это полноценная материнская плата, но вместо процессора впаяна большая ПЛИС. Есть открытые конфигурации, позволяющие сделать из ПЛИС-а полноценный SPARC-процессор. На такой штуке даже виндовс запускают.
Не помню сколько такие платы стоят, но в крупных университетах, которые сотрудничают с SUN (к примеру, у нас в КПИ) все это предоставляется бесплатно в обучающих целях.
Система рабочая, выше в комментах уже писал о том, атаки какого уровня она выдерживает.
В самой схеме, если ее четко придерживаться, подводных камней нет. А вот в конфигах фронтендов их куча. Самый большой камень — проблемы с поисковиками. Поисковики — тоже боты (и очень глупые, умеют только посылать GET запрос), полный список их адресов все время обновляется и, практически, нигде не выкладывается (в интернете можно найти много списков, но поверьте, они далеко не полные).
Отличать их по соответствию прямому проеобразованию бекрезолва адреса бота достаточно проблематично, когда на вас приходит 50 000 гуглботов. Приходится для ботов поисковиков вести отдельный набор правил (отличаем потенциальные поисковики по юзераджентам): например, если одновременно на ноде обнаруживаем больше 3 гуглботов, срабатывает правило, которое отменяет исключения для поисковиков и любые боты начинают баниться. Дальше, как только скрипт по крону увидит окончание атаки (из аксеслога на фронтенде), исключение для поисковиков возвращается обратно. Но вместе с данной схемой еще нужно использовать онлайн списки адресов поисковых ботов, и такие адреса сразу пропускать на бэкенд, даже не записывая в аксеслог. Мы сами активно работает над этим вопросом.
По поводу флуда с эмуляцией клиента:
Честно говоря, не встречал ни одного бота, который бы умел подгружать куки, js, css и картинки. На данный момент, признаков, по которым фронтенд может отличить бота от небота достаточно, была бы фантазия.
Наши методы распознавания ботов не могу опубликовать, тут уж извините, коммерческая тайна.
Если кто-то сделает ботнет из 20 000 нод, которые смогут полностью эмулировать браузер, то жертве придется создавать собственный кластер для бекенда и оптимизировать код, генерить кучу статики — это будет уже скорее высоконагруженная, нежели DDoS устойчивая система.
Не совсем понятно.
К примеру, идет атака с одного сервера. На всех роутерах по пути пакетов не включен мултипас (то есть у них в таблице маршрутизации всего один активный маршрут к вашему адресу), соответственно все пакеты прийдут в одну точку. Этой точкой будет ваш роутер. Далее единственным способом перенаправить часть этих пакетов на территориально отдаленную ноду будет пробрасывать трафик через какой-нибудь GRE, тем самым лишний раз нагружать оборудование и канал. Вы именно это имели ввиду?
LACP (а его в данной ситуациии только для агрегации линков использовать можно, так как при отказе сервера линк скорее всего не погаснет) тут вообще не к месту, одного гигабита вполне хватает, один сервер все-равно не выдержит больше гигабита HTTP флуда (в GET запросах это фантастическая цифра).
CARP тоже не совсем то — мы ведь балансировку делаем, а не failover.
В этой схеме BGP (хоть его и придумали для других целей) самое оптимальное средство.
Если на Ваш сайт за пол года всего одна кратковременная атака — Вас может и обычный хостер потерпеть (а если не хочет — меняйте хостера).
А еще рефаунд у пейпела никто не отменял.
Описанными технологиями мы отлично владеем и Вы тоже правы — при защите одного крупного ресурса, описанная Вами технология действительно дешевле и дает хороший результат, однако такую защиту нужно строить под конкретный ресурс.
Если атака ведется не с кучки хилых зомби-хостов :), а намеренно запущена на мощных серверах, тогда возможен вариант что 200 000 (а то и до 1 000 000, если хостер атакующего закроет глаза) pps SYN флуда пойдут на одну точку геораспределенного кластера, так как будут иметь одинаковую политику маршрутизации.
Есть еще пачка мелких граблей которые вылазят при построении универсальной защиты, и эти грабли потребуют большого количества человекочасов работы и уменьшения качества сервиса.
Это просто анализатор кода на bad smells. Весь рефакторинг потом ручками делать.
Есть еще очень мощная штука — github.com/jscruggs/metric_fu. Там под одной крышей собрали кучу инструментов по оценке качества кода по разнообразным метрикам.
Все работает даже на родной прошивке.
Из траблов — с некоторыми версиями альтернативной прошивкой (b-rad) после полного выключения/включения адаптер мог не стартануть, и приходилось руками передергивать.
Ну и минус что одна USB-шка занята, так что если жесткий диск подключен, то уже флешку не всунуть.
Собственно, вот табличка совместимости WDTV с разными железками: wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=3805.
Вероятно, MacRuby делает что-то подобное, если настолько опережает даже YARV-овский байт-код (и уж тем более обычный руби).
Имхо, скорость Ruby 1.9 с YARV-ом полностью покрывает потребности в веб-разрабтке. Ну а специфичные русурсоемкие операции можно выносить и делать на сях :)
Вообще, странный результат вышел.
Есть довольно старая статья — blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html, там делают более сложный тест, и в комментариях есть результаты для MacRuby. И там MacRuby очень даже быстр.
Как я понимаю, тест был на Ruby 1.9.1 в котором встроена YARV, и такая простая задача могла хорошо оптимизироваться. Если можно, сделайте еще несколько тестов, с более сложными вычислениями в коде, хотя-бы как в той статье, очень интересно посмотреть что получится.
У мака другая нумерация юзеров (uid 501 для первого юзера, а в linux uid 1000), и потому надо в параметрах экспорта конфига NFS сервера указать: insecure,all_squash,anonuid=1000,anongid=1000 (два часа в свое время маялся с этой траблой).
А если для удобства работы с тестовой системой нужен удобный рутовый доступ, то можно указать так (файл /etc/exports):
/ 192.168.1.0/255.255.255.248(rw,async,insecure,all_squash,anonuid=0,anongid=0)
(« / — расшариваем корень», «192.168.1.0/255.255.255.248» — моя локальная подсеть)
А после не забываем сделать:
sudo exportfs -ra
Теперь возвращаемся за мак, Finder → Подключение к серверу → nfs://имя_сервера/ (или nfs://IP_сервера/).
Enjoy :)
SUN-овская плата: www.opensparc.net/fpga/sun-and-xilinx-unveil-fpga-board.html
Там есть линк на дистрибьютора: www.digilentinc.com/Products/Detail.cfm?NavTop=2&NavSub=599&Prod=XUPV5
Там много всего, смотрите сами.
На страничке платы на сайте SUN-а тоже есть линки на академические программы.
Надеюсь, будете продолжать :)
Запускают OpenSolaris, FreeBSD, Linux и еще некоторые *nix.
Грубо говоря, это полноценная материнская плата, но вместо процессора впаяна большая ПЛИС. Есть открытые конфигурации, позволяющие сделать из ПЛИС-а полноценный SPARC-процессор. На такой штуке даже виндовс запускают.
Не помню сколько такие платы стоят, но в крупных университетах, которые сотрудничают с SUN (к примеру, у нас в КПИ) все это предоставляется бесплатно в обучающих целях.
В самой схеме, если ее четко придерживаться, подводных камней нет. А вот в конфигах фронтендов их куча. Самый большой камень — проблемы с поисковиками. Поисковики — тоже боты (и очень глупые, умеют только посылать GET запрос), полный список их адресов все время обновляется и, практически, нигде не выкладывается (в интернете можно найти много списков, но поверьте, они далеко не полные).
Отличать их по соответствию прямому проеобразованию бекрезолва адреса бота достаточно проблематично, когда на вас приходит 50 000 гуглботов. Приходится для ботов поисковиков вести отдельный набор правил (отличаем потенциальные поисковики по юзераджентам): например, если одновременно на ноде обнаруживаем больше 3 гуглботов, срабатывает правило, которое отменяет исключения для поисковиков и любые боты начинают баниться. Дальше, как только скрипт по крону увидит окончание атаки (из аксеслога на фронтенде), исключение для поисковиков возвращается обратно. Но вместе с данной схемой еще нужно использовать онлайн списки адресов поисковых ботов, и такие адреса сразу пропускать на бэкенд, даже не записывая в аксеслог. Мы сами активно работает над этим вопросом.
Честно говоря, не встречал ни одного бота, который бы умел подгружать куки, js, css и картинки. На данный момент, признаков, по которым фронтенд может отличить бота от небота достаточно, была бы фантазия.
Наши методы распознавания ботов не могу опубликовать, тут уж извините, коммерческая тайна.
Если кто-то сделает ботнет из 20 000 нод, которые смогут полностью эмулировать браузер, то жертве придется создавать собственный кластер для бекенда и оптимизировать код, генерить кучу статики — это будет уже скорее высоконагруженная, нежели DDoS устойчивая система.
К примеру, идет атака с одного сервера. На всех роутерах по пути пакетов не включен мултипас (то есть у них в таблице маршрутизации всего один активный маршрут к вашему адресу), соответственно все пакеты прийдут в одну точку. Этой точкой будет ваш роутер. Далее единственным способом перенаправить часть этих пакетов на территориально отдаленную ноду будет пробрасывать трафик через какой-нибудь GRE, тем самым лишний раз нагружать оборудование и канал. Вы именно это имели ввиду?
CARP тоже не совсем то — мы ведь балансировку делаем, а не failover.
В этой схеме BGP (хоть его и придумали для других целей) самое оптимальное средство.
А еще рефаунд у пейпела никто не отменял.
А ширина действительно очень большая.
Описанными технологиями мы отлично владеем и Вы тоже правы — при защите одного крупного ресурса, описанная Вами технология действительно дешевле и дает хороший результат, однако такую защиту нужно строить под конкретный ресурс.
Если атака ведется не с кучки хилых зомби-хостов :), а намеренно запущена на мощных серверах, тогда возможен вариант что 200 000 (а то и до 1 000 000, если хостер атакующего закроет глаза) pps SYN флуда пойдут на одну точку геораспределенного кластера, так как будут иметь одинаковую политику маршрутизации.
Есть еще пачка мелких граблей которые вылазят при построении универсальной защиты, и эти грабли потребуют большого количества человекочасов работы и уменьшения качества сервиса.