Нужен ли обратный прокси на ядре ASP.NET? - PullRequest
0 голосов
/ 07 мая 2019

Нам интересно, нужен ли в большинстве случаев обратный прокси-сервер, и будем признательны за дополнительную информацию.

Документация Kerstel / Nginx утверждает: «Kestrel отлично подходит для обслуживания динамического контента из ASP.NET Core. Однако возможности веб-обслуживания не так богаты, как у серверов, таких как IIS, Apache или Nginx. Обратный прокси-сервер может выполнять такую ​​работу, как обслуживание статического контента, кэширование запросов, сжатие запросов и завершение HTTPS с HTTP-сервера. Обратный прокси-сервер может находиться на выделенном компьютере или может быть развернут рядом с HTTP-сервером ». https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-2.2

Может ли кто-нибудь поделиться своими идеями, если это действительно актуально в настоящее время?

В нашем случае мы используем экземпляры Docker с внешней балансировкой нагрузки (AWS ALB). В каждом экземпляре Docker запущено как Nginx, так и наше основное приложение ASP.NET. Мы не могли понять точных преимуществ использования Nginx.

  1. Обслуживание статического контента Поскольку мы используем внешнюю CRN (AWS CloudFront), я предполагаю, что статическое кэширование на самом деле не дает никаких реальных преимуществ, не так ли?

  2. Кэширование запросов Я считаю, что это то же самое, что обслуживание статического контента, поскольку динамический контент не кэшируется в большинстве сценариев (в нашем случае - во всех сценариях).

  3. Сжатие запросов ASP.NET Core имеет промежуточное программное обеспечение для сжатия ответов, однако заявляет: «Производительность промежуточного программного обеспечения, вероятно, не будет соответствовать производительности серверных модулей. Сервер HTTP.sys и сервер Kestrel в настоящее время не предлагают встроенную поддержку сжатия. ». Возможно, для проверки этого утверждения могут быть созданы некоторые контрольные показатели. https://docs.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-2.2

  4. Завершение HTTPS с HTTP-сервера Я предполагаю, что большинство клиентов, имеющих балансировщики нагрузки, могут пропустить эту часть, так как HTTPS-завершение может быть выполнено на балансировщике нагрузки при необходимости.

Спасибо! Эффи

...