Quay lại blog Webship

Kỹ thuật Webship

Webship: Máy chủ Web Tương thích RFC Nhất Thế giới

Webship biến các yêu cầu RFC thành hành vi rõ ràng trên HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, lưu trữ đệm, proxy ngược, WebTransport, ACME, và phương thức QUERY mới. Khám phá bản đồ tiêu chuẩn 52-RFC đầy đủ.

Mạng web được giữ kết nối nhờ các thỏa thuận chính xác. Trường Content-Length phải có cùng ý nghĩa ở mọi bước trung gian. Bộ nhớ đệm không được tái sử dụng phản hồi yêu cầu xác thực. Một phần trường HTTP/3 bị sai định dạng phải thất bại ở phạm vi đúng. Một phương thức an toàn phải vẫn an toàn sau khi đi qua một proxy ngược.

Webship 1.3.1 được xây dựng quanh một quy tắc: tốc độ chỉ quan trọng khi các byte giữ nguyên ý nghĩa của chúng.

Đó là lý do tại sao chúng tôi mô tả Webship là máy chủ web tổng quát tương thích RFC nhất trên thế giới. Đây là một tuyên bố kỹ thuật với một ranh giới rõ ràng, không phải là tuyên bố rằng mỗi tính năng tùy chọn trong mỗi RFC đều tồn tại. Bản đồ dưới đây liệt kê 52 RFC ảnh hưởng đến hành vi máy chủ đang hoạt động của Webship hoặc các nền tảng giao thức mà nó sở hữu. Các tiêu chuẩn hiện tại được đặt lên trước. Các tài liệu đã bị thay thế được xác định như một dòng tương thích. Các bản dự thảo đặc tả không được đổi nhãn thành RFC.

Tương thích là hành vi, không phải huy hiệu

Webship áp dụng các tiêu chuẩn tại những nơi mà các máy chủ sản xuất thường trở nên mơ hồ nhất:

  • Khung HTTP/1.1 từ chối các độ dài mâu thuẫn, mã truyền tải không hợp lệ, mục tiêu yêu cầu quá kích thước, các khối bị định dạng sai và các hình thức tấn công lén lút yêu cầu.
  • HTTP/2 và HTTP/3 từ chối các trường kết nối bị cấm, xác thực các trường giả, giới hạn các phần trường nén và giữ lỗi luồng riêng biệt với lỗi kết nối.
  • Các tệp tĩnh giữ nguyên ngữ nghĩa HEAD, bộ xác thực, thứ tự điều kiện trước, phạm vi byte, chuyển hướng và loại nội dung.
  • Proxy ngược giữ nguyên khung, hủy bỏ, phần phụ, nâng cấp, thử lại an toàn và chuyển tiếp danh tính trong khi loại bỏ các trường theo từng bước.
  • Bộ nhớ đệm tính toán tuổi, độ mới, xác thực lại, Vary, vô hiệu hóa và các quy tắc sử dụng lỗi thời thay vì coi bộ nhớ đệm như một cách viết tắt khóa-giá trị.
  • TLS, QUIC, ACME, dữ liệu sớm và WebTransport sử dụng trạng thái có giới hạn và chính sách thất bại rõ ràng.

Các quy tắc tương tự áp dụng trên đường nhanh. Webship không xác định một con đường 'đúng' và một con đường chuẩn khác.

Ngữ nghĩa HTTP, đóng khung, lưu vào bộ nhớ đệm và sử dụng proxy

  • RFC 3986 — Nhận dạng Tài nguyên Đồng nhất (URI): Cú pháp Chung. Webship chuẩn hóa các tham chiếu Vị trí và Vị trí Nội dung tương đối, bao gồm các phân đoạn chấm, trước khi thực hiện các quyết định vô hiệu hóa bộ nhớ đệm.
  • RFC 6455 — Giao thức WebSocket. Các bản nâng cấp reverse-proxy xác thực khóa WebSocket, giá trị chấp nhận, giao thức phụ, tiện ích mở rộng và chuyển tiếp đường hầm.
  • RFC 6585 — Các Mã Trạng Thái HTTP Bổ Sung. Các trường yêu cầu vượt quá kích thước sử dụng phản hồi 431 đã được định nghĩa khi vẫn có thể gửi phản hồi HTTP.
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security chỉ được phát ra qua kênh truyền bảo mật và không bao giờ rò rỉ từ một mục cache trung lập với kênh truyền sang HTTP không mã hóa.
  • RFC 7235 — Xác thực HTTP/1.1. Các token của phương thức xác thực được phân tích mà không phân biệt chữ hoa chữ thường, bao gồm cả bề mặt điều khiển MCP được bảo vệ. Ngữ nghĩa HTTP chung của nó hiện nay nằm trong RFC 9110.
  • RFC 7239 — Phần mở rộng HTTP Forwarded. Các nhà vận hành có thể chọn một trường Forwarded theo tiêu chuẩn, các trường X-Forwarded cũ, cả hai hoặc không chọn gì; các trường nhận dạng không đáng tin cậy từ bên trong sẽ bị loại bỏ trước.
  • RFC 7540 — HTTP/2. Điều này được giữ lại như dòng tương thích với HTTP/2; hợp đồng HTTP/2 hiện tại là bản kế nhiệm của nó, RFC 9113.
  • RFC 7541 — HPACK: Nén Header cho HTTP/2. Ngăn xếp HTTP/2 do Webship sở hữu giới hạn trạng thái giải mã và bảng mã hóa trong khi vẫn giữ nguyên định dạng dây HPACK và mã Huffman.
  • RFC 7838 — Dịch vụ Thay thế HTTP. Alt-Svc quảng bá một đầu cuối HTTP/3 mà không thay đổi nguồn gốc được URL đại diện.
  • RFC 8441 — Khởi tạo WebSockets với HTTP/2. Webship hỗ trợ nền tảng thương lượng extended-CONNECT hạ nguồn. Nó không giả vờ rằng một upstream HTTP/1.1 triển khai extended CONNECT của HTTP/2; các kết hợp upstream không được hỗ trợ sẽ thất bại rõ ràng.
  • RFC 8470 — Sử dụng Dữ liệu Sớm trong HTTP. Các yêu cầu sớm mà Webship sẽ không xử lý sẽ nhận được mã 425 Quá Sớm thay vì được xử lý với giả định phát lại không an toàn.
  • RFC 8941 — Giá trị Trường Cấu trúc cho HTTP. Giá trị ưu tiên HTTP sử dụng phân tích cú pháp từ điển trường cấu trúc; các trường tùy chọn bị sai định dạng sẽ bị bỏ qua hoàn toàn.
  • RFC 9110 — Ngữ nghĩa HTTP. Các phương thức, mã trạng thái, trường, bộ xác thực, điều kiện tiên quyết, chuyển hướng, siêu dữ liệu nội dung, HEAD, CONNECT, OPTIONS, và ngữ nghĩa phạm vi chia sẻ một hợp đồng hiện tại duy nhất trên các phiên bản giao thức.
  • RFC 9111 — HTTP Caching. Webship triển khai tuổi đã được hiệu chỉnh, độ tươi rõ ràng, Vary, chỉ-nếu-được-lưu, phải-tái-xác-thực, tái-xác-thực-trung-gian, sử dụng an toàn khi lỗi thời, và việc vô hiệu hóa các URI hiệu quả và liên quan.
  • RFC 9112 — HTTP/1.1. Các quy tắc về dòng yêu cầu, trường, độ dài thân, mã hóa truyền tải, chunk, trailer, tính liên tục và đóng đều được thực thi trước khi phân phát ứng dụng.
  • RFC 9113 — HTTP/2. Thứ tự trường giả, quyền hạn, các trường kết nối bị cấm, hạn chế TE, vòng đời luồng, điều khiển luồng, GOAWAY và phạm vi lỗi được xử lý bởi đường dẫn H2 do Webship sở hữu.
  • RFC 9114 — HTTP/3. Webship sở hữu các đường đi lỗi request, control-stream, SETTINGS, critical-stream, hủy bỏ và stream-versus-connection được sử dụng bởi máy chủ HTTP/3 của nó.
  • RFC 9204 — QPACK: Nén Trường cho HTTP/3. Dung lượng bảng động bị giới hạn bởi giới hạn được quảng bá, luồng lệnh vẫn có thể phân tích cú pháp ở dung lượng bằng không, và trạng thái không hợp lệ trở thành lỗi QPACK bắt buộc.
  • RFC 9218 — Chương trình Ưu tiên Mở rộng cho HTTP. Sự khẩn cấp và hướng dẫn giao hàng từng phần định hướng việc lên lịch HTTP/3 trong khi các tham số ưu tiên chưa biết vẫn có thể mở rộng.
  • RFC 9220 — Khởi tạo WebSockets với HTTP/3. Webship triển khai nền tảng CÀI ĐẶT mở rộng-CONNECT của HTTP/3 được sử dụng bởi các giao thức tunneling hiện đại; điều đó không ngụ ý rằng mọi giao thức CONNECT có thể đều được chấp nhận.
  • RFC 9297 — HTTP Datagrams và Giao thức Capsule. Các phiên WebTransport sử dụng giải mã capsule có giới hạn và kết hợp HTTP Datagram, với các capsule không xác định được xử lý như các điểm mở rộng thay vì lỗi trình phân tích.
  • RFC 9421 — Chữ ký Thông điệp HTTP. Có thể tùy chọn nguồn gốc phản hồi Ed25519 để bao quát bản phát hành và định danh cấu hình của Webship mà không thay thế TLS hoặc xác thực ứng dụng.
  • RFC 10008 — Phương thức HTTP QUERY. Webship coi QUERY là an toàn và idempotent, giữ nguyên nội dung của nó khi qua proxy, bao gồm cả nội dung và siêu dữ liệu biểu diễn trong danh tính bộ nhớ đệm, cấm độ mới theo phán đoán, hỗ trợ hành vi điều kiện và phạm vi, và không bao giờ làm mất hiệu lực bộ nhớ đệm chỉ vì QUERY đã được sử dụng.

Giao thức vận chuyển và kiểm soát tắc nghẽn QUIC

TLS, chứng chỉ và quản lý chứng chỉ tự động

WebTransport: chính xác về những gì được tiêu chuẩn hóa

WebTransport qua HTTP/3 không được tính là RFC thứ năm mươi ba. Tính đến Webship 1.3.1, ánh xạ dây của nó vẫn là bản thảo draft-ietf-webtrans-http3-16. Webship triển khai bản thảo đó trên nền HTTP/3 được chuẩn hóa, CONNECT mở rộng, QUIC DATAGRAM, HTTP Datagram, và các lớp Capsule đã nêu ở trên. Nó cũng triển khai phần mở rộng RESET_STREAM_AT đã được thương lượng, cần thiết để giữ lại tiền tố nhận dạng phiên đáng tin cậy khi một luồng WebTransport bị đặt lại.

Sự khác biệt đó rất quan trọng. Sự tương thích tiêu chuẩn không được cải thiện chỉ bằng cách gọi một bản nháp là RFC. Nó được cải thiện bằng cách theo dõi bản nháp một cách rõ ràng, tách nó khỏi các đường dẫn HTTP thông thường, thương lượng mọi phần mở rộng, giới hạn mọi tài nguyên phiên, và kiểm tra hành vi hủy và thất bại.

Tại sao phạm vi này lại quan trọng trong sản xuất

Một lỗi tiêu chuẩn hiếm khi xảy ra một mình. Việc xử lý HSTS không chính xác có thể vượt qua ranh giới bộ nhớ đệm. Một lệnh QPACK bị sai định dạng có thể kết thúc các yêu cầu không liên quan. Một giả định dữ liệu sớm không an toàn có thể phát lại một thao tác. Một khóa bộ nhớ đệm QUERY bỏ qua phần thân yêu cầu có thể trả về kết quả của một truy vấn khác. Một proxy loại bỏ phần phụ lục hoặc xử lý hủy không đúng cách có thể thay đổi giao thức ứng dụng một cách âm thầm.

Kiến trúc của Webship coi những điều này như các mối quan tâm có liên kết. Giới hạn của trình phân tích cú pháp, kiểm tra bảo mật, bộ nhớ đệm, proxy ngược, trạng thái truyền tải và công cụ đo lường đều chia sẻ các hợp đồng rõ ràng. Kết quả là một máy chủ có thể chuyển giữa HTTP/1.1, HTTP/2, HTTP/3, phân phối tĩnh, proxy ngược, truyền trực tuyến và WebTransport mà không cần định nghĩa khác nhau về sự đúng đắn cho mỗi chế độ.

Xác minh tuyên bố

Đừng tin một nhận định tuyệt đối. Hãy đọc [tài liệu Webship 1.3.1](/docs/1.3.1), kiểm tra cấu hình và ranh giới giao thức, và tái hiện hành vi đã công bố. Sau đó [tải Webship](/downloads) và thử các trường hợp biên mà hệ thống của bạn quan tâm.

Kỹ thuật Webship

Phát trực tuyến với Webship: Lưu lượng cao mà không đánh đổi độ chính xác

Tìm hiểu cách Webship phục vụ và đại diện cho các tệp phương tiện lớn qua HTTP/1.1, HTTP/2 và HTTP/3 sử dụng kTLS thích ứng, điều tiết BBR, bộ đệm giới hạn và cổng toàn vẹn không lỗi.

Đọc bài viết

Máy chủ Web của bạn là một quyết định chi phí hạ tầng

Webship kết hợp khả năng phân phối Rust cao, các giao thức hiện đại, bảo vệ tích hợp sẵn, khả năng quan sát tại chỗ và vận hành tích hợp AI trong cùng một môi trường chạy — mang đến cho các đội hạ tầng một con đường đáng tin cậy để giảm số lượng máy chủ và các thành phần biên.

Đọc bài viết

Webship 1.3.1: Nâng cao HTTP/2 và Khả năng Reverse-Proxy

Webship 1.3.1 tăng khả năng trực tiếp h2c lên 34,19%, trực tiếp HTTP/2 TLS lên 26,67%, và reverse-proxy H1 lên 15,10% so với 1.2.0, đồng thời củng cố tính ổn định và độ chính xác của truyền tải.

Đọc bài viết