Máy chủ proxy ngược và máy chủ HTTP trong quá trình trong Asp.Net Core

Question

Tôi đã đọc về Kestrel máy chủ web ở asp.net core app cụ thể là in-process http server và reverse proxy.

Là một nhà phát triển web theo mùa, tôi gặp khó khăn trong việc tìm hiểu ý tưởng đằng sau:

• Sự liên quan của việc thực hiện in-process http server trong ứng dụng cốt lõi?
• Tầm quan trọng của cách tiếp cận proxy ngược trên bất kỳ web server điển hình nào?
• Loại sự cố thực hiện proxy ngược lại giải quyết trong thế giới cốt lõi asp.net ngoài chuyển tiếp http request?
• Cách reverse proxy và Kestrel tương quan/giao tiếp (1:n hoặc 1:1) nếu ứng dụng cốt lõi asp.net có nghĩa là được triển khai trong vùng chứa không?

Answer 1

Theo official documentation:

ASP.NET Core được thiết kế để chạy trong tiến trình riêng của nó để nó có thể cư xử một cách nhất quán trên nhiều nền tảng. IIS, Nginx và Apache ra lệnh cho quá trình khởi động và môi trường của riêng họ; để sử dụng chúng trực tiếp, ASP.NET Core sẽ phải thích ứng với nhu cầu của từng người. Sử dụng một máy chủ web thực hiện như Kestrel cho ASP.NET Core kiểm soát quá trình khởi động và môi trường. Vì vậy, thay vì cố gắng để thích ứng với ASP.NET Core để IIS, Nginx, hoặc Apache, bạn chỉ cần thiết lập các máy chủ web để yêu cầu proxy để Kestrel. Sự sắp xếp này cho phép các lớp Program.Main và Startup của bạn về cơ bản giống nhau bất kể bạn triển khai ở đâu.

Ngoài việc có máy chủ http trong quá trình làm cho công cụ thực sự dễ dàng hơn cho nhà phát triển. Họ chỉ cần tải về khung, cài đặt nó và nó hoạt động ra khỏi hộp không có vấn đề gì hệ điều hành mà họ đang sử dụng (Windows, Linux hoặc MacOS) hoặc máy chủ web mà họ muốn sử dụng sau này. Họ chỉ cần bắn dotnet run lệnh khởi động máy chủ http với một ứng dụng web lưu trữ trên đó.

Mặc dù bạn có thể chạy nó trong môi trường phát triển khi ứng dụng sẵn sàng cho nhà phát triển sản xuất nên nhớ về bảo mật. Máy chủ web Kestrel là máy chủ web rất mới nên nó không có tất cả các tính năng bảo mật và hữu ích khác như IIS, Apache hoặc Nginx thu được trong thời gian dài của chúng. Đây là lý do duy nhất tại sao MS đề xuất sử dụng proxy ngược trong môi trường sản xuất. Mục tiêu của proxy ngược không chỉ là các yêu cầu chuyển tiếp tới máy chủ http trong quá trình, mà còn chịu trách nhiệm về bảo mật, nén và các tính năng khác mà một máy chủ web tốt có thể cung cấp.

Đối với triển khai vùng chứa, điều đó thực sự phụ thuộc vào những gì bạn muốn đạt được. Có các trường hợp khác nhau:

• Chạy ứng dụng ASP.NET Core và proxy ngược trong cùng một vùng chứa. Trong trường hợp này, ứng dụng lõi ASP.NET thường được định cấu hình để chạy trên một cổng cục bộ, ví dụ: 5000, trong khi proxy ngược lại liên kết với cổng 80. Cách tiếp cận này thường không được khuyến nghị vì thực tiễn tốt nhất cho biết "Mỗi vùng chứa phải có một mối quan tâm"
• Chạy ứng dụng proxy ngược và ASP.NET Core trong 2 vùng chứa khác nhau. Trong trường hợp này, bạn phải liên kết các vùng chứa này với nhau để chuyển tiếp các yêu cầu từ proxy ngược tới ứng dụng web.
• Chạy proxy ngược trên một vùng chứa và định cấu hình proxy đó thành proxy ngược cho nhiều vùng chứa ứng dụng cốt lõi ASP.NET.