Кто-нибудь смог заставить SPDY работать за ELB Amazon?
Мы уже некоторое время используем nginx, скомпилированный с spdy-модулем, и, несмотря на то, что только черновик 2 спецификации удовлетворен его производительностью.
Однако теперь у нас есть потребность в горизонтальном масштабировании и помещаем наши экземпляры EC2 за балансировкой эластичной нагрузки.
Поскольку ELB не поддерживает протокол NPN, мы установили слушателей следующим образом:
SSL 443 → SSL 443
Мы также включили новый прокси-протокол, как описано здесь:
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html
Все работает полностью с этой конфигурацией. Наше приложение успешно балансируется в наших экземплярах.
Однако при запуске http://spdycheck.org/ он сообщает, что SPDY не включен. Однако, если я укажу spdycheck на эластичный IP одного экземпляра, он корректно сообщает SPDY, что он включен.
Любая помощь будет принята с благодарностью.
Ответы
Ответ 1
Выполнение SSL → SSL не отправляет целые пакеты TCP на ваш веб-сервер.
AWS делит пакеты с использованием сертификата и повторно шифрует его. Ваш бэкэнд получает только измененные пакеты.
Жизнеспособным вариантом является изменение протоколов в TCP, но вам понадобится nginx proxy patch для заголовков http или для лучшей работы.
У меня такая же проблема, и я жду, пока AWS, чтобы включить согласование NPN на ELB или nginx, добавьте патч accept-proxy в свой модуль.
Ответ 2
Мы только что выпустили его вчера вечером в https://www.ritani.com.
Вам понадобится версия nginx, которая поддерживает spdy и proxy_protocol. Мы находимся на 1.6.2.
Через AWS CLI добавьте proxy_protocol в свой ELB.
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html#enable-proxy-protocol-cli
Через веб-интерфейс AWS для этого ELB удалите всех 443 слушателей. Добавьте новый прослушиватель в качестве TCP 443 → TCP 443.
В вашем блоке сервера конфигурации nginx:
listen 443 ssl spdy proxy_protocol;
add_header Alternate-Protocol 443:npn-spdy/3;
all the standard ssl directives...
Чтобы получить сшивание ocsp для работы, мне пришлось использовать три сертификата. Стандартный способ конкатенации my.crt и my.intermediate.crt не работает. Я должен был разбить их следующим образом.
ssl_certificate /etc/nginx/ssl/my.crt;
ssl_certificate_key /etc/nginx/ssl/my.private.key;
ssl_trusted_certificate /etc/nginx/ssl/my.intermediate.crt;
Наконец, замените все экземпляры $remote_addr
на $proxy_protocol_addr
. $remote_addr теперь является elb, а $proxy_protocol_addr является удаленным клиентом ip.