Hiệu suất phát trực tuyến không chỉ là mối quan tâm của trình phát video. Các sản phẩm phần mềm, trọng số mô hình, bản sao lưu, thư viện âm thanh và các xuất API lớn đều phụ thuộc vào những nguyên tắc cơ bản giống nhau: di chuyển dữ liệu nhanh chóng, giữ nguyên tải trọng chính xác, tôn trọng áp lực ngược, và dừng một cách sạch sẽ khi một khách hàng ngắt kết nối.
Webship coi những yêu cầu đó như một vấn đề vận chuyển duy nhất qua HTTP/1.1, HTTP/2, HTTP/3, giao file trực tiếp, proxy ngược, và WebTransport. Đường đi nhanh chỉ hữu ích khi nó bảo toàn khung, hủy, trailer, kiểm tra bảo mật và bộ nhớ giới hạn.
Đã đo công suất phát trực tuyến 100 MB
Webship 1.3.1 khả năng chạy Debian đo trung bình thông lượng tải trọng với một thiết bị cố định 100 MB. Mỗi mẫu được chấp nhận yêu cầu chính xác phần thân phản hồi 99,943,778 byte và không có lỗi nào về khách hàng, giao thức, proxy, lỗi trang chính, và HTTP/3 mất gói.
| chế độ Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | Giao tập tin trực tiếp | 4.194,8 MiB/s | 3.574,3 MiB/s | 2.096,9 MiB/s | | Proxy ngược với kết thúc TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Proxy ngược với truyền TLS | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |
Trong so sánh được ghi lại, Webship đã tạo ra trung bình trực tiếp và kết thúc TLS cao nhất cho mọi giao thức được đo. Ma trận đầy đủ bao gồm Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora và Bun trên [trang chuẩn đánh giá](/benchmarks).
Những con số này đo lường khả năng trên máy chủ chuẩn. Chúng không phải là lời hứa cho một đường truyền internet tùy ý. Độ trễ lưu trữ, băng thông mạng, thời gian đi về, mất gói tin, chính sách TLS, tính đồng thời và hành vi nguồn vẫn xác định tốc độ truyền thực tế.
Một nhị phân, ba chiến lược vận chuyển
Một phản hồi lớn không hưởng lợi từ cùng một chính sách như một tài liệu HTML nhỏ. Webship giữ cho đường dẫn yêu cầu thông thường thận trọng và chỉ thúc đẩy một phản hồi hàng loạt đã được chứng minh.
HTTP/1.1: ít chuyển đổi hơn xung quanh tệp
Trên Linux, Webship giữ phần đầu phản hồi và tải tệp trong một khoảng TCP cork cố gắng tốt nhất. Khi một phản hồi TLS lớn đủ điều kiện cho đường dẫn hàng loạt, việc gửi tệp trực tiếp có thể chuyển từ bản ghi Rustls sang TLS kernel một chiều được kiểm toán và sử dụng sendfile mà không sao chép tải tệp qua bộ đệm ứng dụng.
Kết nối vẫn bắt đầu trong TLS ở không gian người dùng. Các phản hồi nhỏ vẫn ở đó. Webship chỉ yêu cầu chuyển sang kTLS sau khi một thân phản hồi ít nhất 1 MiB chứng minh rằng kết nối đang truyền dữ liệu lớn.
HTTP/2: xử lý theo lô mà không phá vỡ điều khiển luồng
Kỹ thuật ghép kênh HTTP/2 làm cho việc đệm không kiểm soát trở nên tốn kém. Webship gom các lần ghi trong khi vẫn giữ được giới hạn điều khiển luồng của luồng và kết nối. Đối với việc phát trực tiếp với mức đồng thời cao, bộ đệm ghi TLS 128 KiB có thể chứa hai khung DATA 64 KiB, trong khi ngân sách gửi kết nối vẫn rõ ràng và có giới hạn.
Một khung thân nguồn đã sẵn sàng có thể được lấy trước mà không cần vượt qua Hyper framing, phụ đề, hủy, kiểm tra hoặc phản áp lực. Điều đó giảm một vòng lập lịch có thể tránh được trong khi vẫn giữ nguyên hợp đồng giao thức.
HTTP/3: Tốc độ QUIC thay vì kTLS
HTTP/3 không bao giờ sử dụng đường dẫn TCP kTLS. Webship áp dụng điều tiết QUIC nhận thức vận chuyển, phân đoạn gói dữ liệu có giới hạn, DPLPMTUD và chia lô vi mô theo bộ hẹn giờ từng bộ phản ứng. Các phản hồi HTTP/3 lớn và các phiên WebTransport được chấp nhận có thể chọn BBR mà không thay đổi chính sách CUBIC được sử dụng bởi lưu lượng thông thường.
Chứng nhận ổn định HTTP/3 tập trung sử dụng bảy mẫu được chấp nhận. Truyền phát kết thúc TLS đạt trung bình 1.938,6 MiB/s với hệ số biến thiên 2,12%. Truyền qua TLS đạt 1.748,5 MiB/s với hệ số biến thiên 1,65%. Cả hai loạt đều không có lỗi về toàn vẹn thân bài, client, giao thức và mất gói.
Giao trực tiếp hay proxy ngược?
Sử dụng giao hàng trực tiếp khi Webship sở hữu cây tập tin đã triển khai. Điều này loại bỏ bước nguồn và cho phép đường dẫn tệp tĩnh hiệu quả nhất.
Một trang web đa giao thức tối giản trông như thế này:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"Sử dụng kết thúc TLS với reverse-proxy khi Webship phải định tuyến theo đường dẫn, áp dụng kiểm tra WAF hoặc API Shield, thực thi giới hạn nội dung thân, thêm tiêu đề chuyển tiếp, hoặc quan sát các trường HTTP:
[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 = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]Đặt tls_termination = false khi nguồn gốc phải giữ nguyên văn bản thuần túy của ứng dụng và các khóa phiên hoạt động. Chế độ truyền thẳng không thể kiểm tra các trường HTTP được mã hóa. Vì vậy, truyền thẳng TCP định tuyến theo ClientHello SNI, trong khi truyền thẳng HTTP/3 yêu cầu một nguồn UDP chung.
Điều chỉnh streaming hàng loạt một cách rõ ràng
Đối với streaming TLS HTTP/2 có độ đồng thời cao, Webship ghi lại các thiết lập gắn liền với quy trình này:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"Ngân sách kết nối ở trên cung cấp 128 KiB tín dụng cho 256 luồng hoạt động. Hãy coi đó là một quyết định về năng lực, không phải là mặc định chung. Đo lường bộ nhớ, độ trễ và thông lượng với mức đồng thời dự kiến của bạn trước khi tăng nó.
Trên Linux, tải các module kernel TLS và BBR và cho phép tài khoản dịch vụ Webship chọn BBR. Webship thất bại trước khi gắn kết khi khả năng kernel cần thiết của nó không có sẵn, vì vậy một triển khai không thể âm thầm chọn đường đi tối ưu trong khi chạy mà không có nó. Các hệ điều hành khác vẫn giữ các đường đi Rustls và kiểm soát tắc nghẽn di động được tài liệu hóa cho nền tảng của họ.
WebTransport là một hình dạng phát trực tuyến khác
WebTransport kết hợp các luồng tin cậy và các gói dữ liệu không tin cậy qua một phiên bảo mật. Nó không sử dụng TCP kTLS. Điểm cuối chẩn đoán giới hạn của Webship xác thực nguồn và thực thi các giới hạn về phiên, luồng, viên nang, gói dữ liệu, byte và thời gian nhàn rỗi.
Trong lần chạy công suất 1.3.1, WebTransport trực tiếp đạt 1.018,1 MiB/s cho các luồng đáng tin cậy và 1.038,9 MiB/s cho các datagram. Chuyển tiếp TLS đạt lần lượt 548,6 MiB/s và 629,7 MiB/s. Cả hai chế độ đều vượt qua tất cả năm mẫu với số mẫu bị từ chối bằng không, số datagram bị mất bằng không và số lỗi nghiêm trọng của khách hàng bằng không.
Ưu tiên HTTP/3 cho khách hàng WebTransport mới. Đường dẫn HTTP/2 tồn tại để tương thích với các cài đặt bản nháp đã hết hạn cũ hơn.
Những gì cần xác minh trước khi đưa vào lưu lượng sản xuất
- Kiểm tra chính xác kích thước phương tiện hoặc hiện vật mà bạn sẽ cung cấp, không chỉ một phản hồi nhân tạo nhỏ.
- Xác minh độ dài phản hồi và bản tóm tắt nội dung tại phía khách hàng.
- Hủy bài tập, yêu cầu phạm vi, độc giả chậm, và hành vi nửa đóng của nguồn.
- Đo thông lượng duy trì cùng với CPU, bộ nhớ, lỗi ổ cắm, việc gửi lại, và độ trễ đuôi.
- Xác thực riêng biệt các chế độ trực tiếp, kết thúc TLS và chuyển tiếp; chúng có các ranh giới bảo mật và định tuyến khác nhau.
- Giữ chế độ ghi nhận tắt cho lưu lượng sản xuất bình thường, sau đó bật chẩn đoán có giới hạn một cách có chủ ý khi điều tra.
- Kiểm tra lại kTLS và BBR trên Linux sau khi thay đổi kernel, container hoặc sandbox của systemd.
Phát trực tuyến nhanh khi toàn bộ đường dẫn hợp tác. Thiết kế của Webship giữ các tối ưu hóa dữ liệu lớn theo giao thức nhưng vẫn duy trì một mô hình hoạt động và một chuẩn độ chính xác.
Đọc toàn bộ [tài liệu Webship 1.3.1](/docs/1.3.1), kiểm tra [phương pháp đánh giá chuẩn và ma trận đối thủ](/benchmarks), hoặc tải xuống bản build đã ký từ [Tải về](/downloads).