ngx http charset module не добавляет пробел для text/plain
Не могу понять почему nginx формирует разные заголовки. Баг? Конфиг такой:
include /etc/nginx/mime.types;
charset "utf-8";
charset_types text/xml text/plain application/javascript
application/rss+xml application/xml text/css text/javascript text/markdown
text/calendar text/x-component text/vcard text/cache-manifest text/vtt
application/json application/manifest+json;
default_type application/octet-stream;
При отправке в PHP заголовка :
header('Content-type: text/plain');
echo "test";
В браузере(в любом) по ssl HTTP 2 получаю: text/plain;charset=UTF-8 т.е.
перед charset= нет пробела. Мелочь, но хотелось бы одинакового поведения для
всех заголовков.
Для других типов такого не наблюдаю, там всё в норме, например в том же PHP
nginx выдаёт: content-type: application/xml; charset=utf-8
Хотя всё конечно не проверял, возможно глючит еще на каких-то заголовках.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,285541,285541#msg-285541
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx не добавляет необходимые библиотеки при сборке из исходников со сторонними модуямии
Спасибо. Классный мастер класс, жаль я раньше о нем не знал :(( Сберег бы время. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285435,285540#msg-285540 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Hello! On Tue, Sep 03, 2019 at 03:18:36PM +0500, Dmitry Sergeev wrote: > Добрый день, спасибо за ответ. > > On 02/09/2019 22:11, Maxim Dounin wrote: > > Just in case, для работы такая конфигурация смысла не имеет - если > > тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет > > смысл задавать, если тикеты включены. > > > > С точки зрения влияния на reload - внешний ключ позволит сохранить > > тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш > > сессий. > > > > Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - > > способ переложить хранение сессий на клиентов, и отказываться от > > этого - очевидно недальновидно с точки зрения нагрузки на сервер. > > > Да, я неверно понял доки. > > > Отмечу также, что даже в наиболее экстремальных случаях из > > представленных на графике - рост потребления процессора с ~200% до > > ~300% не выглядит сколько-нибудь фатальным. Какой-то рост > > потребления процессора при релоадах - нормален, здесь же > > наблюдается рост всего в 1.5 раза. Если это проблема - то стоит > > задуматься о добавлении мощностей и/или заняться оптимизацией > Да, сейчас это для меня просто представляет интерес, после перехода на > openssl 1.0.2g и включение http2, проблем это особых не вызывает. > > А вот то, что средняя нагрузка без тикетов заметно выше - это > > немного странно. Само хранение сессий - должно бы стоить очень > > недорого с точки зрения процессора, а в остальном разница не > > принципиальна. Но, возможно, тут дело в том, что размер кэша > > SSL-сессий просто мал для имеющегося количества клиентов, и > > поэтому при выключении тикетов handshake'и начинают происходить > > чаще, что и приводит к росту потребления процессора. > Возможно. Это немного не то, но мне было интересно как увеличение кэша > ssl сессий повлияет на нагрузку при reload'e: > > http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg > > Числами отметил разное количество ssl_session_cache от 20m до 256m. > Вроде никак не влияет. Сегодня тестил при 8K rps (вчера 5-6K). Поэтому > нагрузка скачет чуть выше. От размера кэша сессий должна зависеть высота "полки" между reload'ами. Если кэш мал - то полных handshake'ов будет больше, чем могло бы быть, и соответственно CPU usage в полке будет больше. Ну и всё это имеет смысл скорее при выключенных тикетах, о чём и шла речь выше. А на графике - они, похоже, включены. > А вот тикеты помогли вообще круто. Нагрузка поднимается всего-лишь на > 5%-10%: > http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg > > Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными > тикетами и указанными постояным ключем ssl_session_ticket_key. Ну ок, то есть как и ожидалось - пик явно из-за SSL handshake'ов, использование постоянных ключей для тикетов - лечит. > Итого: > > Сущесвтенно решить проблему помогло следующее: > 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и > при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а > раньше от 30-40 секунд, до 5 минут). > 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло > включение ssl_session_tickets(по умолчанию включено) с установелнным > ssl_session_ticket_key (по умолчанию генерируется заново при каждом > reload'e, его лучше указать чтобы этого не происходило). > > Оставил такие параметры: > > ssl_session_cache shared:SSL:20m; > ssl_session_timeout 30m; > ssl_session_tickets on; > ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - > файл с рандомными 80 или 48 байт > > Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет > (по крайней мере я этого не заметил). Использовать "ssl_session_tickets on;" - не нужно, это поведение по умолчанию. И отмечу также, что ключ для тикетов - надо периодически менять, ибо получив этот ключ - можно расшифровать весь трафик. И я бы ещё рекомендовал посмотреть в сторону ECDSA-сертификатов, там handshake банально на порядок быстрее при той же криптостойкости: $ openssl speed rsa2048 ecdsap256 ... signverifysign/s verify/s rsa 2048 bits 0.000992s 0.33s 1008.1 30297.9 signverifysign/s verify/s 256 bit ecdsa (nistp256) 0.0001s 0.0001s 17145.0 9276.9 То есть 1008.1 подписей в секунду в случае RSA 2048 bit, и 17145.0 подписей в секунду для ECDSA 256 bit. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Добрый день, спасибо за ответ. On 02/09/2019 22:11, Maxim Dounin wrote: Just in case, для работы такая конфигурация смысла не имеет - если тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет смысл задавать, если тикеты включены. С точки зрения влияния на reload - внешний ключ позволит сохранить тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш сессий. Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - способ переложить хранение сессий на клиентов, и отказываться от этого - очевидно недальновидно с точки зрения нагрузки на сервер. Да, я неверно понял доки. Отмечу также, что даже в наиболее экстремальных случаях из представленных на графике - рост потребления процессора с ~200% до ~300% не выглядит сколько-нибудь фатальным. Какой-то рост потребления процессора при релоадах - нормален, здесь же наблюдается рост всего в 1.5 раза. Если это проблема - то стоит задуматься о добавлении мощностей и/или заняться оптимизацией Да, сейчас это для меня просто представляет интерес, после перехода на openssl 1.0.2g и включение http2, проблем это особых не вызывает. А вот то, что средняя нагрузка без тикетов заметно выше - это немного странно. Само хранение сессий - должно бы стоить очень недорого с точки зрения процессора, а в остальном разница не принципиальна. Но, возможно, тут дело в том, что размер кэша SSL-сессий просто мал для имеющегося количества клиентов, и поэтому при выключении тикетов handshake'и начинают происходить чаще, что и приводит к росту потребления процессора. Возможно. Это немного не то, но мне было интересно как увеличение кэша ssl сессий повлияет на нагрузку при reload'e: http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg Числами отметил разное количество ssl_session_cache от 20m до 256m. Вроде никак не влияет. Сегодня тестил при 8K rps (вчера 5-6K). Поэтому нагрузка скачет чуть выше. А вот тикеты помогли вообще круто. Нагрузка поднимается всего-лишь на 5%-10%: http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными тикетами и указанными постояным ключем ssl_session_ticket_key. Итого: Сущесвтенно решить проблему помогло следующее: 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а раньше от 30-40 секунд, до 5 минут). 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло включение ssl_session_tickets(по умолчанию включено) с установелнным ssl_session_ticket_key (по умолчанию генерируется заново при каждом reload'e, его лучше указать чтобы этого не происходило). Оставил такие параметры: ssl_session_cache shared:SSL:20m; ssl_session_timeout 30m; ssl_session_tickets on; ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - файл с рандомными 80 или 48 байт Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет (по крайней мере я этого не заметил). Спасибо Вам большое, Ваши советы помогли полностью избавиться от этого эффекта. Надеюсь кому-то тоже будет полезна эта переписка. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как записать ключи pre-master от tls-соединений, обрабатываемых nginx?
Здравствуйте. > Hello! > > On Tue, Aug 27, 2019 at 11:50:18PM +0300, Pavel wrote: > >> Мы состоим в реестре организаторов распространения информации и >> поэтому обязаны предоставлять в надзорный орган ключи tls сессий. >> >> Для таких случаев существует механизм по перехвату вызовов библиотеки >> openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/ >> Суть простая - перед запуском демона, обрабатывающего TLS-соединения >> клиентов, через LD_PRELOAD подгружается эта библиотека и она >> сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи >> pre-master. >> >> Эта схема срабатывает с апачем, но с энжинксом ключи не пишутся. Нет >> ли идей или подсказок из-за чего это может быть и как вообще можно >> записать >> эти самые pre-master keys в энжинксе? > > [...] > >> [Service] >> Environment=SSLKEYLOGFILE=/tmp/premaster.txt >> Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so > > [...] > >> но тем не менее ключи в файл при обращении к энжинксу по https не >> пишутся. > > Скорее всего причина в том, что переменные > окружения очищаются при запуске, подробнее тут: > > http://nginx.org/r/env > Огромное спасибо! Ключи начали записываться когда добавил в nginx.conf env LD_PRELOAD=/usr/local/lib/libsslkeylog.so; env SSLKEYLOGFILE=/tmp/premaster.txt; ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
