Нам интересно, нужен ли в большинстве случаев обратный прокси-сервер, и будем признательны за дополнительную информацию.
Документация 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.
Обслуживание статического контента
Поскольку мы используем внешнюю CRN (AWS CloudFront), я предполагаю, что статическое кэширование на самом деле не дает никаких реальных преимуществ, не так ли?
Кэширование запросов
Я считаю, что это то же самое, что обслуживание статического контента, поскольку динамический контент не кэшируется в большинстве сценариев (в нашем случае - во всех сценариях).
Сжатие запросов
ASP.NET Core имеет промежуточное программное обеспечение для сжатия ответов, однако заявляет: «Производительность промежуточного программного обеспечения, вероятно, не будет соответствовать производительности серверных модулей. Сервер HTTP.sys и сервер Kestrel в настоящее время не предлагают встроенную поддержку сжатия. ».
Возможно, для проверки этого утверждения могут быть созданы некоторые контрольные показатели.
https://docs.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-2.2
Завершение HTTPS с HTTP-сервера
Я предполагаю, что большинство клиентов, имеющих балансировщики нагрузки, могут пропустить эту часть, так как HTTPS-завершение может быть выполнено на балансировщике нагрузки при необходимости.
Спасибо!
Эффи