Azure Service Fabric: подключение через HTTP в 10-30 раз быстрее, чем через HTTPS.TLS рукопожатие занимает слишком много времени - PullRequest
Новая
       57

Azure Service Fabric: подключение через HTTP в 10-30 раз быстрее, чем через HTTPS.TLS рукопожатие занимает слишком много времени

0 голосов
/ 08 февраля 2019

У меня есть микросервис .NET Core (API), который является частью приложения Azure Service Fabric.Service Fabric состоит из 3 узлов.Я заставил службу работать как по HTTP, так и по HTTPS с действующим сертификатом.Проблема заключается в разнице в производительности между соединениями HTTP и HTTPS.

Я использую сертификат Let's Encrypt.(Я также попробовал другие бесплатные пробные SSL-сертификаты, просто чтобы увидеть, насколько это важно.) Я раскрываю конечные точки с помощью Kestrel, определяю их в Service Fabric ServiceManifest и ApplicationManifest и открываю порты с помощью Azure Load Balancer.Вот как я настраиваю конечные точки, используя Kestrel: 

.UseKestrel(options =>
{
    options.Listen(IPAddress.IPv6Any, 80);
    options.Listen(IPAddress.IPv6Any, 443, listenOptions =>
    {
        listenOptions.UseHttps("ssl.pfx", "password");
        listenOptions.NoDelay = true;
     });
})

Когда я получаю конечную точку моего API из HTTP, время отклика постоянно составляет 0,06-0,2 сек.Однако, когда я нажимаю на него по HTTPS, он не согласован и намного медленнее (обычно в 10-30 раз);время отклика отскакивает от 0,5 (редко) - 3-4 секунды.Это несоответствие недопустимо.Я подозреваю, что рукопожатие TLS занимает очень много времени.К сожалению, я понятия не имею, почему.

РЕДАКТИРОВАТЬ: Ранее связанный дубликат вопроса объясняет общее поведение для HTTPS, и я знал это раньше.Однако мой случай специфичен для описанной среды, поэтому данный ответ не полностью удовлетворяет мой вопрос.У меня есть работающее веб-приложение .NET, использующее HTTPS в Azure, которое не имеет такой большой разницы в производительности.

...