Как справиться с внезапным всплеском новых подключений HTTPS?

Спасибо @MichaelHampton за вашу помощь.

Я нашел решение своей проблемы, и, надеюсь, это может помочь другим (особенно, если вы используете Java).

Я слышал много предложений просто увеличить nofiles чтобы разрешить больше подключений, но я хотел бы начать с повторения, что проблема не в том, что сервер не может устанавливать больше подключений, а в том, что он не может устанавливать подключения достаточно быстро и разрывать подключения.

Моя первая попытка решить эту проблему заключалась в увеличении очереди подключений через net.ipv4.tcp_max_syn_backlog, net.core.somaxconn и снова в конфигурации сервера приложения, где это необходимо. Для vertx это server.setAcceptBacklog(...);. Это привело к принятию большего количества соединений в очереди, но не ускорило установление соединений. С точки зрения подключающегося клиента, они больше не сбрасывали соединения из-за переполнения, просто установление соединений занимало гораздо больше времени. По этой причине увеличение очереди подключений не было реальным решением и просто заменяло одну проблему другой.

Пытаясь сузить круг проблем в процессе подключения, я попробовал те же тесты с HTTP вместо HTTPS и обнаружил, что проблема полностью исчезла. Моя конкретная проблема была с самим TLS-рукопожатием и способностью серверов удовлетворить его.

Еще немного покопавшись в моем собственном приложении, я обнаружил, что замена стандартного SSLHandler Javas на собственный (OpenSSL) значительно увеличила скорость подключения через HTTPS.

Вот изменения, которые я внес для своего конкретного приложения (с использованием Vertx 3.9.1).

1. Добавить netty-tcnative зависимости

<!-- https://mvnrepository.com/artifact/io.netty/netty-tcnative -->
<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-tcnative</artifactId>
    <version>2.0.31.Final</version>
    <classifier>osx-x86_64</classifier>
    <scope>runtime</scope>
</dependency>

<!-- https://mvnrepository.com/artifact/io.netty/netty-tcnative -->
<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-tcnative</artifactId>
    <version>2.0.31.Final</version>
    <classifier>linux-x86_64-fedora</classifier>
    <scope>compile</scope>
</dependency>

Первая зависимость - это проверка osx во время выполнения. Второй - для centos linux при компиляции. linux-x86_64 также доступен для других вкусов. Я пытался использовать boringssl так как openssl не поддерживает ALPN но через много часов я не смог заставить его работать, поэтому я решил пока жить без http2. Поскольку большинство соединений отправляют только 1-2 небольших запроса перед отключением, это действительно не проблема для меня. Если бы вы могли использовать boringssl вместо этого это, вероятно, предпочтительнее.

2. Потому что я не использую убер-версию зависимости. Мне нужно было установить зависимости os для centos. Это было добавлено в Dockerfile

RUN yum -y install openssl
RUN yum -y install apr

3. Чтобы сервер vertx использовал OpenSSL вместо версии Java, установите параметры OpenSSL на сервере (даже если это просто объект по умолчанию)

httpServerOptions.setOpenSslEngineOptions(new OpenSSLEngineOptions());

4. Наконец, в моем сценарии запуска я добавил io.netty.handler.ssl.openssl.useTasks=true вариант для Java. Это указывает обработчику ssl использовать задачи при обработке запросов, чтобы не блокировать.

java -Dio.netty.handler.ssl.openssl.useTasks=true -jar /app/application.jar

После этих изменений я могу устанавливать соединения намного быстрее с меньшими накладными расходами. То, что раньше занимало десятки секунд и приводило к частому сбросу соединения, теперь занимает 1-2 секунды без сброса. Могло быть лучше, но это большое улучшение по сравнению с тем, где я был.

Хорошее исправление !.

Так что, похоже, это уровень SSL, он определенно должен выполнять гораздо больше обработки с точки зрения сетевых рукопожатий и криптографических преобразований, требующих ресурсов. Если ваш SSL не может переложить часть обработки на оборудование, SSL определенно может увеличить нагрузку на ваши серверы, и, как вы узнали, не все библиотеки SSL созданы равными!

Эти проблемы - отличный кандидат на использование обратного прокси-сервера переднего плана. В идеале это может быть размещено перед вашим приложением и обрабатывать все SSL-соединения с клиентами, а затем выполнять http для вашей серверной части.

Вашему исходному приложению нужно сделать немного меньше, поскольку ваш обратный прокси-сервер переднего плана может поглотить всю работу SSL и управление TCP-соединением.

Apache и NGNIX могут это сделать, и у них есть несколько вариантов для балансировки нагрузки этих подключений к наименее загруженному внутреннему серверу.

Вы обнаружите, что NGNIX может выполнять завершение SSL намного быстрее, чем Java, и даже если Java может, вы распределяете обработку управления подключением между машинами, тем самым уменьшая нагрузку (память / cpu / disk io) на ваш внутренний сервер. Вы получаете побочный эффект упрощения конфигурации серверной части.

Обратной стороной является использование http между вашим прокси и приложениями, что в некоторых сверхбезопасных средах нежелательно.

Удачи!