Kết thúc TLS hay Chuyển tiếp? Chọn Ranh giới Reverse-Proxy Webship Phù hợp

Việc lựa chọn giữa kết thúc TLS và chuyển tiếp TLS không phải là một cài đặt proxy mang tính hình thức. Nó quyết định nơi kết thúc mã hóa, hệ thống nào giữ khóa phiên, liệu Webship có thể kiểm tra HTTP hay không, và lớp nào phải thực thi bảo mật ứng dụng.

Webship mặc định là chuyển tiếp. Điều đó giữ cho ứng dụng ở dạng văn bản thuần và khóa phiên hoạt động tại nguồn. Chỉ bật chấm dứt khi biên cần hiểu và xử lý yêu cầu HTTP.

Quyết định trong một câu

Sử dụng chuyển tiếp TLS khi nguồn phải sở hữu ranh giới TLS. Sử dụng kết thúc TLS khi Webship phải định tuyến, bảo vệ, biến đổi, lưu trữ đệm hoặc quan sát lưu lượng HTTP.

Không chế độ nào là an toàn hơn một cách phổ quát. Chế độ chuyển tiếp giảm thiểu việc xử lý tài liệu nhạy cảm tại edge, nhưng loại bỏ các kiểm soát bảo mật HTTP của edge. Chế độ kết thúc thêm một điểm thực thi có thể kiểm tra, nhưng khiến Webship trở thành một phần của ranh giới TLS đáng tin cậy.

| Mối quan tâm | Chấm dứt TLS | Chuyển tiếp TLS | | --- | --- | --- | | Điểm kết TLS | Webship | Nguồn gốc | | Văn bản gốc ứng dụng tại Webship | Có | Không | | Khóa phiên hạ lưu đang hoạt động tại Webship | Có | Không | | Định tuyến theo đường dẫn hoặc phương thức HTTP | Có | Không | | WAF, API Shield, và giới hạn thân tại Webship | Có | Không | | Bộ nhớ đệm proxy, viết lại và chuyển tiếp tiêu đề | Có | Không | | Đầu vào định tuyến TCP | Quyền hạn và chính sách định tuyến HTTP | ClientHello SNI | | HTTP/3 định tuyến | Dữ liệu yêu cầu HTTP | Một nguồn UDP dùng chung | | Trách nhiệm nguồn gốc | HTTP hoặc upstream TLS được cấu hình riêng | Toàn bộ TLS, ALPN và ngăn xếp HTTP |

Vấn đề quan trọng vì vậy không phải là “Công tắc nào nhanh hơn?” Mà là “Thành phần nào phải được phép thấy và kiểm soát yêu cầu?”

Việc chấm dứt nào sẽ mang lại Webship

Với tls_termination = true, Webship hoàn tất TLS hạ nguồn và đưa yêu cầu đã giải mã vào đường dẫn HTTP reverse-proxy của nó. Điều đó làm cho các tính năng sau trở nên khả thi:

• định tuyến nhận biết đường dẫn, máy chủ và phương thức;
• Kiểm tra WAF và API Shield;
• giới hạn thân yêu cầu và thời gian chờ chính sách;
• bộ nhớ đệm proxy và việc vô hiệu hóa an toàn cho việc tạo ra;
• quản lý tiêu đề chuyển tiếp và các trường nhật ký truy cập HTTP;
• xử lý truy vấn nhận biết cơ thể, thử lại khi an toàn, và chính sách ngắt mạch;
• dịch giao thức giữa các kết nối hướng tới khách hàng và kết nối thượng nguồn.

Chế độ này cũng thay đổi trách nhiệm bảo mật. Máy chủ Webship phải bảo vệ khóa riêng của chứng chỉ, các khóa phiên, dữ liệu yêu cầu và phản hồi đã giải mã, dữ liệu quan sát và bất kỳ bản lưu trữ nào. Nếu bước nhảy tiếp theo phải được giữ mã hóa, hãy cấu hình TLS đầu nguồn kiểu riêng; nếu không, HTTP đầu nguồn sẽ ở dạng văn bản rõ ràng.

Chấm dứt là ranh giới bên phải khi Webship được mong đợi hoạt động như một điểm biên ứng dụng nhận thức, không chỉ như một lớp trung chuyển truyền tải được mã hóa.

Những gì giữ được qua

Với tls_termination = false—mặc định—Webship chuyển tiếp lưu lượng TLS hoặc QUIC được mã hóa mà không giải mã yêu cầu hoặc phản hồi HTTP. Dữ liệu văn bản gốc của ứng dụng và các khóa phiên đang hoạt động vẫn ở nguồn gốc.

Ranh giới tin cậy nhỏ hơn đó có giá trị khi chứng chỉ phải được giữ trên tầng ứng dụng, chính sách tuân thủ cấm giải mã ở biên, hoặc một định danh TLS cụ thể nguồn cần đến khách hàng mà không thay đổi. Nó cũng loại bỏ việc phân tích HTTP và công việc chính sách khỏi đường dẫn trung chuyển.

Sự đánh đổi là nghiêm ngặt: Webship không thể kiểm tra những gì nó không thể giải mã. Nó không thể áp dụng các quy tắc WAF HTTP, định tuyến theo đường dẫn, viết lại tiêu đề, thực thi chính sách API nhận thức nội dung thân bài, hoặc ghi nhật ký truy cập các trường HTTP. Máy chủ gốc phải tự cung cấp tất cả các kiểm soát đó.

Do đó, Pass-through không phải là “chấm dứt với ít tính năng hơn.” Nó là một kiến trúc khác với chủ sở hữu bảo mật khác.

Giới hạn theo giao thức là quan trọng

Đối với TLS HTTP/1.1 và TLS HTTP/2, Webship chỉ kiểm tra ClientHello đủ để chọn đích TCP được cấu hình theo SNI. Mỗi miền đi qua cần một tuyến path_prefix = "/" bắt tất cả vì đường dẫn yêu cầu thực tế vẫn được mã hóa. Một client không có SNI chỉ được chấp nhận khi cấu hình có một miền.

Nguồn gốc phải thương lượng ALPN của khách hàng và hỗ trợ giao thức đã chọn. Webship không thể chuyển một khách hàng HTTP/2 thành một nguồn gốc HTTP/1.1 trong khi phiên TLS đi qua mà không thay đổi.

HTTP/3 sử dụng QUIC qua UDP và có biên giới chặt chẽ hơn. Chế độ truyền trực tiếp không thể định tuyến an toàn theo HTTP authority được mã hóa, vì vậy mỗi tuyến HTTP/3 được cấu hình phải phân giải đến cùng một nguồn IP-socket UDP. Webship từ chối các socket Unix và nhiều nguồn truyền trực tiếp HTTP/3 trong quá trình xác thực cấu hình thay vì định tuyến mơ hồ một cách im lặng.

Cleartext HTTP/1.1 và h2c không bị ảnh hưởng bởi reverse_proxy.tls_termination. Cài đặt này chỉ điều khiển HTTP/1.1 TLS, HTTP/2 TLS và HTTP/3 TLS ở hạ lưu.

Dung lượng yêu cầu đã được đo

Bài kiểm tra khả năng 1.3.1 Debian của Webship đo lường hai chế độ reverse-proxy mã hóa riêng biệt. Mỗi mẫu được chấp nhận đều không có lỗi HTTP, socket, giao thức, proxy, lỗi trang chính, và mất gói HTTP/3.

| Chế độ reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Kết thúc TLS | 123,344 RPS | 124,957 RPS | 131,529 RPS | | Chuyển tiếp TLS | 203.950 RPS | 266.845 RPS | 167.010 RPS |

Chuyển tiếp phản hồi nhỏ có ít công việc ứng dụng hơn để thực hiện: nó chuyển tiếp dữ liệu vận chuyển được mã hóa thay vì kết thúc TLS, phân tích HTTP, đánh giá chính sách và tạo ra một luồng TLS hạ lưu mới. Tốc độ yêu cầu chuyển tiếp cao hơn phản ánh công việc hẹp hơn đó.

Những hàng này không đại diện cho các bộ tính năng giống nhau, và chúng không nên được sử dụng để khẳng định rằng một kiến trúc bảo mật nào đó tốt hơn một cách toàn cầu. Việc kết thúc trả phí cho các khả năng nhận biết HTTP mà chế độ chuyển tiếp cố ý không thể cung cấp.

Phát trực tuyến hàng loạt thay đổi kết quả

Cùng một chuẩn đã sử dụng một thân phản hồi chính xác 99.943.778 byte cho ma trận phát trực tuyến 100 MB. Ở đây, việc kết thúc TLS tạo ra thông lượng tải trung vị cao hơn cho cả ba giao thức:

| Chế độ reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Kết thúc TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Chuyển tiếp TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |

Tại sao hướng lại thay đổi? Ở chế độ chấm dứt, nguồn chuẩn gửi HTTP dạng văn bản rõ ràng đến Webship, và Webship sở hữu đường dẫn khối hạ lưu tối ưu. Các phản hồi lớn HTTP/1.1 và HTTP/2 có thể sử dụng kTLS Linux thích nghi và bộ đệm giới hạn theo từng loại giao vận. HTTP/3 sử dụng điều phối QUIC, DPLPMTUD và xử lý theo lô từng bộ phản ứng thay vì kTLS.

Trong chế độ truyền qua, nguồn sở hữu TLS hạ nguồn và Webship tiếp nhận luồng được mã hóa hoặc các gói QUIC kết quả. Điều đó bảo tồn ranh giới TLS của nguồn, nhưng nó không thể sử dụng đường dẫn phản hồi hàng loạt nhận biết HTTP của Webship.

Bảy mẫu HTTP/3 cũng kiểm tra độ ổn định. Truyền phát kết thúc đạt trung bình 1.938,6 MiB/s với hệ số biến thiên 2,12%; truyền thẳng đạt 1.748,5 MiB/s với hệ số biến thiên 1,65%. Cả hai đều truyền chính xác nội dung mà không có lỗi về máy khách, giao thức, và mất gói.

Cấu hình chuyển tiếp một cách có chủ ý

Một cấu hình chuyển tiếp tối giản giữ định danh TLS ở trạng thái chờ để người vận hành có thể bật kết thúc sau mà không cần thay đổi đường dẫn chứng chỉ:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

Chứng chỉ Webship đã được xác thực nhưng không được sử dụng bởi các phiên thông qua đang hoạt động. Máy gốc tại 10.0.0.20:443 phải kết thúc TLS và hỗ trợ giao thức do khách hàng thương lượng.

Cho phép kết thúc khi cạnh cần HTTP

Đối với một edge nhận biết ứng dụng, hãy bật việc kết thúc và gửi lưu lượng HTTP kết quả đến nguồn gốc đã chọn:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

Cấu hình này có thể định tuyến và kiểm tra HTTP. Thêm TLS đầu nguồn khi mạng giữa Webship và nguồn gốc chưa được tin cậy hoặc tách biệt.

Chuyển chế độ mà không cần khởi động lại Webship

Webship có thể thay đổi tls_termination thông qua việc tải lại tệp cấu hình hoặc công cụ webship.reverse_proxy.apply_config MCP đã được kiểm tra phiên bản. Đọc đối tượng và phiên bản hiện tại với webship.reverse_proxy.get_config, chỉ thay đổi trường mong muốn trong toàn bộ đối tượng trả về, và gửi nó với expected_version_id phù hợp.

Các kết nối TCP mới sử dụng chế độ mới. Các client HTTP/3 kết nối lại với giao thức UDP đã được thay thế. Thay đổi đường dẫn chứng chỉ và khóa vẫn bị ràng buộc theo tiến trình và yêu cầu khởi động lại, vì vậy hãy giữ một định danh chấm dứt hợp lệ đã được chuẩn bị trước khi chuyển đổi trực tiếp.

Kiểm tra phiên bản ngăn một người vận hành ghi đè thay đổi cấu hình đồng thời. Một bản cập nhật bị từ chối sẽ để nguyên cấu hình đang chạy và cấu hình đã lưu trữ.

Một danh sách kiểm tra lựa chọn thực tế

Chọn chuyển tiếp khi tất cả những điều sau đây đều đúng:

1. Nguồn gốc phải giữ lại ranh giới chứng chỉ và khóa phiên.
2. Định tuyến TCP cấp độ SNI — hoặc một nguồn UDP HTTP/3 chia sẻ — là đủ.
3. Nguồn gốc cung cấp WAF cần thiết, xác thực, ghi nhật ký, giới hạn kích thước nội dung và các biện pháp kiểm soát lạm dụng.
4. Không cần bộ nhớ đệm biên, viết lại đường dẫn, chính sách tiêu đề chuyển tiếp hoặc chuyển đổi giao thức HTTP.

Chọn kết thúc khi bất kỳ điều nào trong số này được yêu cầu tại Webship:

1. Định tuyến theo máy chủ, đường dẫn hoặc phương thức.
2. Kiểm tra các yêu cầu với WAF hoặc API Shield.
3. Thi hành giới hạn kích thước thân, thời gian chờ HTTP, hoặc xác thực biên.
4. Lưu trữ phản hồi hoặc viết lại tiêu đề HTTP.
5. Dịch giữa các giao thức HTTP đầu ra và đầu vào.
6. Quan sát các trường HTTP tại ranh giới proxy.

Dù bạn chọn chế độ nào, hãy kiểm tra SNI, ALPN, xác thực chứng chỉ, hủy bỏ từ phía khách hàng, đóng một nửa kết nối phía trên, và tính toàn vẹn phản hồi chính xác. Đo khả năng xử lý yêu cầu và băng thông truyền phát riêng biệt: chế độ nhanh nhất cho phản hồi nhỏ không nhất thiết là chế độ nhanh nhất cho một nội dung 100 MB.

Webship đặt chế độ chuyển tiếp làm mặc định vì một proxy không nên âm thầm mở rộng phạm vi tin cậy của nó. Việc kết thúc vẫn là một lựa chọn vận hành trực tiếp và rõ ràng khi hành vi biên vi HTTP đáng để chịu trách nhiệm đó.

Đọc toàn bộ [tài liệu reverse-proxy](/docs/1.3.1), so sánh [ma trận chuẩn](/benchmarks) đã được chấp nhận, hoặc tải xuống Webship từ [Tải xuống](/downloads).

Nguồn và phương pháp nội dung

Các giá trị hiệu suất được chấp nhận là giá trị trung bình từ chuẩn đo lường năng lực Debian thống nhất Webship 1.3.1 ngày 11 tháng 9 năm 2026; các tiêu chuẩn chấp nhận của nó yêu cầu không có lỗi client, HTTP, socket, giao thức, proxy, lỗi trang chính lớn và HTTP/3 mất gói.