Comments 36
Торт, торт! Уже целые статьи пишут про дописывание 6 букв " http2" в конфиг. 6 букв, Карл!
Если бы все внимательно следили за обновлениями документации и возможностей NGINX и использовали новые возможности — мир был бы прекраснее, да.
Посмотрел, действительно, пока на хабре статьи, упоминающие http/2 в nginx'е были в небольшом количестве: про то, что он появится в виде экспериментального модуля для 1.9.0+ и в статье про nginscript.
Пробел – не буква, а символ, Карл! :)
UFO just landed and posted this here
Видимо, чтобы неназываемые могли блокировать по страницам, а не весь домен.
Можно работать одновременно по http и https.
Тут что-то ещё — модераторы работают очень оперативно и от провайдеров без DPI это не спасёт. Тем более, что на балансировщике сертификат стоит и используется в TM ID.
В сравнительно небольшой статье 8 ссылок на свои сайт и контакты. Мы поняли, спасибо. Скромнее надо быть.
Про сертификаты ерунда написана, ключи длиннее 2048 бит тоже имеют проблемы с совместимости и теоретически будут уязвимы только после 2030 года, нет dhparam и cipherlist.
Дали бы хоть ссылку на статью с обсуждением.
Дали бы хоть ссылку на статью с обсуждением.
А ECDSA выдаёт Comodo и Symantec, но пока это не афишируют. У последних есть занятная презентация по теме:
Symantec’s View of the Current State of ECDSA on the Web
Symantec’s View of the Current State of ECDSA on the Web
А почему infobox.ru не работает по HTTP/2?
Всему свое время. Поддержке HTTP/2 в NGINX всего несколько недель. Любые изменения тщательно тестируются, особенно когда дело касается большой и сложной инфраструктуры.
А где тестовый сайт, чтобы посмотреть как это работает у вас?
Например можно посмотреть у пользователя на le-vert.ru. Единственное — пользователь использует автомасштабирование и обычно частота CPU – 100-300 мгц для экономии.
Вебсайт – это «большая и сложная архитектура»?
Я правильно понял, что в статье вы рекомендуете пользователям включать сырой HTTP/2, а сами его не включаете?
Я правильно понял, что в статье вы рекомендуете пользователям включать сырой HTTP/2, а сами его не включаете?
В этой статье мы рассказываем о том, как включить новую возможность NGINX — HTTP/2 и какие преимущества это даст. Поддержка HTTP/2 — часть релиза NGINX (это не альфа или бета) и поддерживается разработчиками. Таким образом поддержка HTTP/2 является стабильной и готовой к использованию. Более того, некоторые наши пользователи уже используют HTTP/2. Тем не менее, при использовании любой технологии ее нужно тестировать со своим ресурсом, это нормальная практика. Если вы считаете, что поддержка HTTP/2 в NGINX сырая — вы всегда можете отправить баг-репорты разработчикам trac.nginx.org/nginx если действительно вам известно о какой-то проблеме с продуктом.
UFO just landed and posted this here
А ещё ключ длиной 4096 увеличивает время RSA-подписи почти в 7 раз, а RSA-проверки в 4 раза — относительно 2048 бит.
Что отрицательно сказывается на нагрузке на сервер и количестве новых подключений в секунду.
Что отрицательно сказывается на нагрузке на сервер и количестве новых подключений в секунду.
А сколько это в настоящих числах? А то вот случается, что 0*7=0.
Там, к сожалению, совсем не ноль.
Вот, к пример, однопоточное тестирование на Xeon X5650:
Т.е. этот совсем не слабый процессор одним ядром может всего-лишь ~60 RSA-sign транзакций в секунду.
И это притом что больше ничем он заниматься не будет, а в реальной жизни это далеко не так.
Также эти 4096 бит ложаться бременем на клиентские устройства — те же телефоны будут в несколько раз сильнее напрягаться при установке TLS соединения. Это, конечно, почти незаметно, но тем не менее.
В общем, я пришёл к выводу что пока что 4096 смысла городить нет. А когда появится — там и ECDSA станет распространён достаточно, в результате чего в 4096 необходимость вообще отпадёт.
Facebook вон не зря у себя использует сертификат SHA1 + ECDSA, при их нагрузках это выливается в экономию дофигалиарда зелёных денег на серверах и электричестве.
Вот, к пример, однопоточное тестирование на Xeon X5650:
# openssl speed rsa
...
sign verify sign/s verify/s
rsa 512 bits 0.000101s 0.000007s 9899.7 140006.3
rsa 1024 bits 0.000345s 0.000021s 2896.4 48730.2
rsa 2048 bits 0.002274s 0.000072s 439.8 13939.4
rsa 4096 bits 0.016812s 0.000272s 59.5 3670.4
Т.е. этот совсем не слабый процессор одним ядром может всего-лишь ~60 RSA-sign транзакций в секунду.
И это притом что больше ничем он заниматься не будет, а в реальной жизни это далеко не так.
Также эти 4096 бит ложаться бременем на клиентские устройства — те же телефоны будут в несколько раз сильнее напрягаться при установке TLS соединения. Это, конечно, почти незаметно, но тем не менее.
В общем, я пришёл к выводу что пока что 4096 смысла городить нет. А когда появится — там и ECDSA станет распространён достаточно, в результате чего в 4096 необходимость вообще отпадёт.
Facebook вон не зря у себя использует сертификат SHA1 + ECDSA, при их нагрузках это выливается в экономию дофигалиарда зелёных денег на серверах и электричестве.
Насколько я понимаю, то http2-траффик будет проксироваться на http1 сервер. А как быть, если я хочу шифрованное соединение, но для клиентов, что не поддерживают http2 проксировать на http1 сервер. А для других — на http2. Это реально? И ещё, как быть с websockets? У nginx есть насчёт этого страничка. Но будет ли она работать по такой схеме? Будет ли она работать просто по http2?
NGINX решает проблему с клиентами, еще не поддерживающими HTTP/2 с помощью Next Protocol Negotiation (NPM) расширения TLS.
UFO just landed and posted this here
Да я имею ввиду, что нет возможности прокинуть HTTP/2 трафик, через Nginx. Т.е. на проксируемый сервер он будет приходить всегда HTTP/1.x. И это печально. По сути ngx_http_v2_module — это некая адаптация SPDY-модуля. Да, я согласен, что на текущий момент — это именно, то что нужно. Но Вы только взгляните как устроен HTTP/2. А сейчас получается, что всё что из него можно выжать — это пакованный заголовок(?), и экономию на хэндшайках. Может это не совсем так, но факт остаётся фактом. Как управлять приоритетами, как вытолкнуть в кэш, что использовать: 1000-картинок или огромный спрайт? Вот о чём я. В общем, я читаю документацию к H2O в данный момент.
UFO just landed and posted this here
… приоритеты у nginx в планах на следующие версииПоддержка HTTP/2 с приоритизацией на основе весов и зависимостей. @ nginx.org/ru
Приоритезацией управляет клиент, а не сервер. Браузеру куда виднее, какого ресурса ему сейчас не хватает в первую очередь, и такую информацию он сообщает в nginx, а тот в свою очередь приоритизирует отдачу.
К слову сказать, приоритизация в http/2 нужна исключительно для решения проблемы самого протокола, который использует только одно соединение. Если у вас всего одна труба, то требуется тщательно выбирать в каком порядке в нее наливать. Да, http/2 — это протокол для экономии на хэндшейках и не более.
Ну и кстати, тестировали, h2o стабильно показывает худшие результаты по времени отрисовки и загрузки сайта, чем nginx c http/2 или spdy.
К слову сказать, приоритизация в http/2 нужна исключительно для решения проблемы самого протокола, который использует только одно соединение. Если у вас всего одна труба, то требуется тщательно выбирать в каком порядке в нее наливать. Да, http/2 — это протокол для экономии на хэндшейках и не более.
Ну и кстати, тестировали, h2o стабильно показывает худшие результаты по времени отрисовки и загрузки сайта, чем nginx c http/2 или spdy.
Sign up to leave a comment.
Включаем HTTP/2 в NGINX для сайта