Первый запрос на новое подключение к конечной точке API ядра .NET через HTTPS значительно медленнее, чем HTTP - PullRequest
Новая
       28

Первый запрос на новое подключение к конечной точке API ядра .NET через HTTPS значительно медленнее, чем HTTP

0 голосов
/ 30 июня 2019

Я разрабатываю базовый API .NET, и мне нужно настроить HTTPS для него. Однако я столкнулся с проблемой - одна и та же конечная точка работоспособности гораздо медленнее при вызове из HTTPS, чем из HTTP (примерно на 4-5 секунд медленнее). Я понимаю, что HTTPS, естественно, медленнее, чем HTTP, из-за рукопожатия TLS, однако 5 секунд - это слишком большая задержка - обычно я бы это сделал за исключением ~ 2 секунд. Может быть, у кого-нибудь есть идея, почему это так?

Упомянутый API - это встроенное ядро ​​.NET 2.2, запускаемое в контейнере Docker под оркестратором контейнера сервисной фабрики Azure. Служебная структура запускается только одним узлом. Балансировщик нагрузки находится перед сервисной матрицей.

  • Сначала я попробовал фактическую конечную точку, которая извлекает некоторые данные;
  • Теперь я упростил его до точки работоспособности, без доступа к базе данных или аутентификации, он просто возвращает ответ OK (200);
  • Я сократил сервисную матрицу до одного узла, чтобы исключить балансировщик нагрузки из уравнения;
  • Я посмотрел на то, что браузеры показывали мне время запроса, и результаты:

HTTPS: request via https, request is 5 seconds slower than via http

Как вы можете видеть, рукопожатие TLS занимает 2,6 секунды, в то время как 2,8 секунды теряются из-за блокировки, что также странно, поскольку этого не происходит при подключении через обычный HTTP.

HTTP: request via http, request is 5 seconds faster than via https

Поскольку ярлыки не на английском языке, я переведу их так, чтобы все могли понять:

  • Заблокированные
  • разрешение DNS
  • Подключение
  • TLS рукопожатие
  • Отправка
  • Ожидание
  • Прием

URL-адрес, который я тестирую: https://taxfreesystem.com:8081/api/health (HTTPS) и http://taxfreesystem.com:8080/api/health (HTTP), возможно, любой из вас получит некоторые сведения только после его посещения. Если потребуется дополнительная информация, я предоставлю ее. Ожидаемый результат будет для рукопожатия TLS и блокировки в общей сложности <= 2 секунд. </p>

РЕДАКТИРОВАТЬ : Я забыл упомянуть, что я встраиваю сертификат SSL непосредственно в каждую базовую службу .NET отдельно, например, в файл Program.cs : 

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

Я буду хранить сертификат в хранилище ключей Azure в будущем, однако на данный момент это может быть важной деталью для решения этой проблемы. Возможно, инициализация каждой службы как таковой вызывает некоторую задержку.

EDIT2 : хранение сертификата в хранилище ключей Azure не имеет значения. Должно быть что-то не так с моей конфигурацией.

...