Comments 33
Расскажите плиз, какие ресурсы выделены под проксю, которая ходит по редиректам?
Много ли запросов которые требуют более 1го редиректа?
И какая нагрузка по запросам в секунду?
Много ли запросов которые требуют более 1го редиректа?
И какая нагрузка по запросам в секунду?
/dev/random => /dev/urandom… вы серьезно?
Когда я последний раз проводил тестирование, большая часть браузеров поддерживала TLS Session tickets, гораздо большая чем те, что поддерживали SSL Sessions. Насколько сильно кеширование увеличило производительность?
Когда я последний раз проводил тестирование, большая часть браузеров поддерживала TLS Session tickets, гораздо большая чем те, что поддерживали SSL Sessions. Насколько сильно кеширование увеличило производительность?
Процентов на 20-30% ускорил.
А трюк с рандомом — вообще чуть ли не в два раза дал эффект.
А трюк с рандомом — вообще чуть ли не в два раза дал эффект.
Неспроста, уровень энтропии в urandom намного ниже. Не боитесь за безопасность?
Это далеко не самое потенциально узкое место в безопасности. Про взлом SSL путем подбора рандомного числа я еще не слышал.
На 20-30%, по сравнению с чем? Средним временем handshake у всех клиентов (включая session tickets и тех, кто вообще не поддерживает ни то, ни другое)?
а как вы в баннерке проверяете безопасность flash содержимого? он же может подтягивать произвольные ресурсы? этот же вопрос касается и JS баннеров, которые могут по цепочке партнер->субпартнер->субпартнер подтягивать всякий раз разный код
Браузер не ругается на то, что флэш тянет что-то снаружи по небезопасному протоколу. А поскольку защищать, как вы сами понимаете, в рекламном баннере нечего (этот контент вообще никак не связан с пользователем), то проблемы, как таковой, нет.
Внешние javascript'ы залить в нашу баннерную систему нельзя (грубо говоря, форма ввода для партнеров не позволяет их вводить). Поэтому мы можем автоматом проверять код и понимать, если в нем небезопасное содержимое.
Внешние javascript'ы залить в нашу баннерную систему нельзя (грубо говоря, форма ввода для партнеров не позволяет их вводить). Поэтому мы можем автоматом проверять код и понимать, если в нем небезопасное содержимое.
а какой вообще выигрыш от введения SSL был? насколько уменьшилось количество жалоб на взломы ящиков? т.е. была ли какая то выгода от введения SSL кроме репутационных бонусов (в среде гиков знающих что такое SSL)?
К огромному сожалению, SSL имеет очень запутанные настройки и много тонкостей в реализации. Шаг влево, шаг вправо — можно получить противоположный безопасности результат. При запуске SSL сервера обязательно нужно делать независимые проверки или хотя бы пользоваться сторонними сервисами тестирования.
Если сейчас взглянуть на mail.ru через www.ssllabs.com/ssltest/analyze.html?d=mail.ru (Пример для одного из серверов в кластере: www.ssllabs.com/ssltest/analyze.html?d=mail%2eru&s=94%2e100%2e191%2e241 ) то можно увидеть несколько серьезных проблем:
Разрешение использовать SSL v.2.0, подверженность атаке CRIME и атаке BEAST, DDoS атаке CVE-2009-3555
Все проблемы закрываются корректными настройками веб-серверов, но естественно нужно дополнительно протестировать как поведет себя сервис под нагрузкой.
Почему стоит обратить на это внимание — хотя CRIME и BEAST сложны в исполнении, но есть внутреннее ощущение, что низкая энтропия urandom делают возможность атаки более, чем вероятной.
IMHO при такой нагрузке имеет смысл использовать аппаратный генератор случайных чисел — это сильно разгружает CPU и сохраняет высокий уровень энтропии.
Почему стоит закрывать возможность для DDoS — говорить не стоит :)
Если сейчас взглянуть на mail.ru через www.ssllabs.com/ssltest/analyze.html?d=mail.ru (Пример для одного из серверов в кластере: www.ssllabs.com/ssltest/analyze.html?d=mail%2eru&s=94%2e100%2e191%2e241 ) то можно увидеть несколько серьезных проблем:
Разрешение использовать SSL v.2.0, подверженность атаке CRIME и атаке BEAST, DDoS атаке CVE-2009-3555
Все проблемы закрываются корректными настройками веб-серверов, но естественно нужно дополнительно протестировать как поведет себя сервис под нагрузкой.
Почему стоит обратить на это внимание — хотя CRIME и BEAST сложны в исполнении, но есть внутреннее ощущение, что низкая энтропия urandom делают возможность атаки более, чем вероятной.
IMHO при такой нагрузке имеет смысл использовать аппаратный генератор случайных чисел — это сильно разгружает CPU и сохраняет высокий уровень энтропии.
Почему стоит закрывать возможность для DDoS — говорить не стоит :)
Вы смотрите не на mail.ru, а на e.mail.ru: www.ssllabs.com/ssltest/analyze.html?d=e.mail.ru&s=94.100.184.17
Почта отдается именно с домена e.mail.ru. А c mail.ru отдается главная страница, где https мы еще не анонсировали и только экспериментируем с ним.
Почта отдается именно с домена e.mail.ru. А c mail.ru отдается главная страница, где https мы еще не анонсировали и только экспериментируем с ним.
Привет Денис,
а вы не пробовали сравнить затраты на разработку, поддержку и сервера с покупкой готовых решений вроде F5?
а вы не пробовали сравнить затраты на разработку, поддержку и сервера с покупкой готовых решений вроде F5?
Маг, привет.
Смотря, о какой задаче идет речь. Если о поддержке https, то, как я написал в статье, проблема не в готовом или не готовом решении, а в том, что даже, если все решения уже есть (SSL поддержан везде, писать собственные алгоритмы шифрования не надо), то сделать так, чтобы все заработало на высоконагруженном проекте — это определенный челендж.
Смотря, о какой задаче идет речь. Если о поддержке https, то, как я написал в статье, проблема не в готовом или не готовом решении, а в том, что даже, если все решения уже есть (SSL поддержан везде, писать собственные алгоритмы шифрования не надо), то сделать так, чтобы все заработало на высоконагруженном проекте — это определенный челендж.
И напоследок расскажу о небольшом хаке, который тоже существенно увеличил производительность. Мы сделали линк с /dev/random на /dev/urandom. Работает быстрее, потому что /dev/random блокирующий, /dev/urandom не блокирующий. Следовательно, I/O wait сокращается. А поскольку на наших веб-серверах диски достаточно загружены (из-за логирования, приезжающей статики, сохранения атачей и т.д.), то дополнительный I/O wait оказывает существенное влияние на работу сервера в целом.
Денис, поясните, пожалуйста, как связанны ввод-вывод random/urandom и загруженные диски?
Алексей, связаны достаточно просто. Загруженные диски напрягают в целом всю подсистему ввода-вывода. И поэтому любая блокировка на файловом вводе выводе (даже не связанная с дисками, например чтение из /dev/random) может оставаться на больший срок, чем требуется для поступления данных.
жуть какая, и вы правда в это верите? чтобы перегрузить стек ввода-вывода надо сделать что-то невероятное, чтобы при этом упереться в процессор. Если вы хотите сломать мою картину мира, дайте пруф-линк пожалуйста, может это баг в ядре какой. Вобщем это заявление равносильно тому, что если я на высоконагруженном сервере по io вставлю флоппик и начну с него читать, производительность сервера упадет.
Если это будете обращаться к флоппи параллельно из 1000 потоков, то у вас все остальные io операции могут легко замедлиться. Но я сам флоппи вставлять в сервер не пробовал.
А трюк с рандомом реально помогает.
А трюк с рандомом реально помогает.
> Если это будете обращаться к флоппи параллельно из 1000 потоков, то у вас все остальные io операции могут легко замедлиться.
Из-за чего? в чем физика процесса? Может трюк с рандомом работает не из-за подсистемы ввода-вывода, а по каким-то другим причинам?
Из-за чего? в чем физика процесса? Может трюк с рандомом работает не из-за подсистемы ввода-вывода, а по каким-то другим причинам?
Я физику вам сходу не расскажу. По идее, io wait не должен влиять на поедание цпу, переключения контекстов не в счет, т.к. они случаются только при пробуждении. Но то, что много io wait'а тормозит весь сервер, это медицинский факт, который я наблюдаю за все свои 10 лет опыта работы с high load'ом.
Если у вас есть другие более менее обоснованные гипотезы, то дайте их в студию, плиз.
Если у вас есть другие более менее обоснованные гипотезы, то дайте их в студию, плиз.
Ну просто вы путаете вещи, тем самым еще и других запутываете. Да, при обращении к /dev/random процесс будет в uninterruptible sleep на ожидание ввода-вывода из него, да это увеличит показания iowait в системе, да, ваше приложение будет тормозить, потому что блокируются на чтении из /dev/random, но диски здесь совершенно не причем. Приложение которое работает с диском не будет при этом тормозить. Система — не будет тормозить. la в linux будет большим, но это говорит только о количестве процессов в uninterruptible sleep.
Sign up to leave a comment.
Силовые тренировки: раскатываем HTTPS под высокими нагрузками