WebSocket là gì? Bắt tay, Khung, và Dữ liệu Full-Duplex

Giới thiệu

Một WebSocket là một kênh giao tiếp liên tục, song công toàn phần bắt đầu với một thủ tục bắt tay tương thích với HTTP và sau đó trao đổi các khung WebSocket. Mọi điểm cuối đều có thể gửi tin nhắn ứng dụng khi có dữ liệu, mà không cần tạo một yêu cầu HTTP mới cho mỗi tin nhắn.

Giao thức cung cấp khung, thông điệp điều khiển, quy tắc che chắn, ngữ nghĩa đóng, và các trường bắt tay liên quan đến gốc. Nó không định nghĩa schema thông điệp của ứng dụng, mô hình ủy quyền, lịch sử sự kiện, hoặc chiến lược phục hồi trạng thái. Những điều đó vẫn là công việc thiết kế cho dịch vụ.

Sự Bắt Tay Khai Mạc

Khách hàng gửi một yêu cầu HTTP với Upgrade, Connection, Sec-WebSocket-Key, Sec-WebSocket-Version, và thường là Origin và sở thích subprotocol. Một máy chủ chấp nhận tính toán giá trị Sec-WebSocket-Accept cần thiết và trả về 101 Switching Protocols.

Sau đó, các ngữ nghĩa thông điệp HTTP thông thường không còn xác định dữ liệu trên kết nối đó nữa. RFC 6455 xác định giao thức WebSocket, bao gồm các trường bắt tay, các phương thức URI đã đăng ký, bố cục khung và mã đóng.

Khung và Tin nhắn

Dữ liệu ứng dụng được truyền tải trong các thông điệp văn bản hoặc nhị phân. Một thông điệp có thể chiếm một khung hoặc bị phân mảnh qua nhiều khung. Các khung điều khiển mang tín hiệu đóng, ping và pong và có các ràng buộc giúp quản lý kết nối phản hồi kịp thời.

Các trình duyệt khách ẩn các khung họ gửi đến máy chủ; máy chủ không ẩn các khung gửi đến khách. Việc ẩn không phải là mã hóa. Sử dụng wss để TLS cung cấp tính bảo mật, tính toàn vẹn và xác thực máy chủ. Việc xác thực nội dung tin nhắn vẫn thuộc về ứng dụng.

Thay đổi Hình dạng API của Full Duplex

Với HTTP yêu cầu-phản hồi, hành động của khách hàng một cách tự nhiên kết hợp với một phản hồi. Lưu lượng WebSocket có thể đến từ cả hai hướng vào bất kỳ thời điểm nào, do đó ứng dụng cần các loại thông điệp, định danh tương quan, quy tắc sắp xếp, phong bì lỗi và đàm phán phiên bản.

Một lệnh nên chỉ ra liệu nó mong đợi một sự thừa nhận, một kết quả, hay một chuỗi cập nhật. Các sự kiện nên bao gồm đủ thông tin về danh tính và phiên bản để áp dụng một cách không thay đổi. Nếu không có hợp đồng rõ ràng, một socket trở thành một chuỗi các đối tượng JSON không rõ ràng mà khó phát triển.

Chu kỳ Kết nối và Khôi phục Trạng thái

Một WebSocket có thể đóng lại vì chính sách ứng dụng, triển khai máy chủ, trạng thái mạng không hoạt động, thiết bị ngủ, hành vi proxy hoặc mất đường dẫn. Các khung ping và pong có thể kiểm tra tính khả thi, nhưng chúng không phục hồi các sự kiện kinh doanh đã bị bỏ lỡ.

Thiết kế lại phản hồi một cách riêng biệt với việc đồng bộ trạng thái. Sau khi kết nối mới, khách hàng có thể gửi ID sự kiện đã thấy lần cuối, yêu cầu một ảnh chụp nhanh, hoặc đăng ký lại các chủ đề. Tiêu chuẩn WebSockets của WHATWG định nghĩa hành vi API trình duyệt trong khi để việc khôi phục ứng dụng cho dịch vụ.

Ranh giới Bảo mật

Xác thực nguồn gốc cho khách hàng trình duyệt, xác thực người dùng, ủy quyền mỗi đăng ký và lệnh, áp dụng giới hạn kích thước tin nhắn và từ chối các phụ giao thức không được hỗ trợ. Một socket đã kết nối không phải là ủy quyền vĩnh viễn; quyền hạn và thời gian phiên có thể thay đổi trong khi nó vẫn mở.

Tránh đặt bí mật lâu dài trong URL vì các điểm cuối có thể xuất hiện trong nhật ký. Áp dụng giới hạn tần suất và mức độ đồng thời cho từng danh tính, phân tích payload một cách thận trọng, và đóng kết nối với các mã được kiểm soát. TLS bảo vệ việc vận chuyển, trong khi ủy quyền kinh doanh bảo vệ các tài nguyên.

Mở rộng và Áp lực ngược

Một máy chủ WebSocket giữ trạng thái kết nối cho nhiều khách hàng. Các triển khai nhiều phiên bản cần một lớp định tuyến hoặc xuất bản-theo dõi để một sự kiện được tạo ra trên một nút đến được một kết nối thuộc về nút khác. Việc rút lui kết nối trong quá trình triển khai cũng cần một quy trình rõ ràng.

Một khách hàng chậm có thể tích lũy thông điệp gửi đi nhanh hơn mức mà mạng có thể chấp nhận. Ràng buộc mỗi hàng đợi gửi, hợp nhất các cập nhật trạng thái có thể thay thế, và ngắt kết nối các khách hàng không thể theo kịp theo một chính sách đã được tài liệu hóa. Tài liệu tham khảo API WebSocket của MDN lưu ý rằng giao diện trình duyệt cổ điển không cung cấp áp lực ngược tích hợp sẵn.

WebSocket là gì? Bắt tay, Khung và Kế hoạch Xác thực Dữ liệu Full-Duplex

WebSocket là toàn phần. Khách hàng và máy chủ có thể gửi độc lập sau khi bắt tay. Xác thực tuyên bố đó qua toàn bộ con đường sản xuất. Bắt đầu với một giao dịch đại diện nhỏ, ghi lại hành vi đã đàm phán tại khách hàng và điểm biên, và xác nhận rằng ứng dụng nhận các trường, khung hoặc sự kiện mà nó mong đợi qua cổng, proxy, điểm kết thúc chứng chỉ và chính sách mạng được sử dụng bởi giao thông thực tế.

Biến giả định thiết kế đầu tiên thành một bài tập thất bại: yêu cầu wss cho các điểm cuối sản xuất. Sau đó xem xét áp lực tài nguyên xung quanh giả định thứ hai: Xác thực giá trị Origin của trình duyệt. Một triển khai đúng nên thất bại trong các giới hạn đã tài liệu, phát hành kết nối và trạng thái bộ đệm, và để lại dấu vết giải thích kết quả mà không phơi bày thông tin xác thực hoặc tải trọng riêng tư.

Chỉnh sửa cộng tác và bảng điều khiển tương tác thử nghiệm các phần khác nhau của thiết kế, vì vậy kiểm tra tính tương thích nên bao gồm cả hai hình dạng lưu lượng nơi chúng có liên quan. Thêm một trình duyệt hiện tại, một khách hàng không phải trình duyệt, một đường truyền mạng chậm hơn, và trung gian hỗ trợ lâu nhất. Ghi lại lựa chọn phiên bản, thời gian sống kết nối, độ tuổi thông điệp hoặc phản hồi, độ sâu hàng đợi và lý do đóng cho con đường ưu tiên và bước lùi của nó.

Xem xét ngữ nghĩa và vận tải như các lớp riêng biệt trong quá trình thử nghiệm. Một kết nối thành công không chứng minh rằng ứng dụng đã xử lý đúng thứ tự, ủy quyền, hủy bỏ, bộ đệm, phát lại, hoặc phục hồi trạng thái. Tương tự, lỗi ứng dụng không chứng minh giao thức đã đàm phán thất bại. Gán thẻ quan sát với tài nguyên, phạm vi người dùng, hoạt động logic và danh định kết nối, sau đó so sánh những gì mỗi điểm cuối tin là đã xảy ra. Sự tách biệt này làm cho công việc về năng lực trở nên hữu ích hơn: các nhóm có thể thấy liệu độ trễ đến từ việc thiết lập kết nối, phân phối mạng, hàng đợi, xử lý ứng dụng, sê-ri hóa, hoặc một người nhận chậm. Giữ nội dung riêng tư ra khỏi thông tin telemetry thường xuyên trong khi vẫn giữ lại đủ dữ liệu về thời gian và kết quả để tái hiện quyết định.

Nơi WebSocket là gì? Bắt tay, Khung và Dữ liệu Full-Duplex Xuất Hiện trong Thực Tế

WebSocket là gì? Danh sách kiểm tra Sản xuất Bắt tay, Khung và Dữ liệu Full-Duplex

• Yêu cầu wss cho các điểm cuối sản xuất. Chuyển điểm này thành một bài kiểm tra tiếp nhận viết để các người đánh giá có thể phân biệt hành vi dự kiến với một chi tiết triển khai ngẫu nhiên.
• Xác thực giá trị Origin của trình duyệt. Đặt tên thành phần sở hữu thiết lập và người hoặc đội phản ứng khi hành vi quan sát được thay đổi.
• Xác thực trước khi chấp nhận các thuê bao có quyền hạn. Ghi lại tín hiệu liên quan trong nhật ký hoặc dấu vết, sau đó xác minh rằng tín hiệu sống sót qua mọi proxy, cổng và ranh giới dịch vụ trong con đường thực.
• Ủy quyền cho mọi loại thông điệp. Thử nghiệm quyết định với một trường hợp bình thường, một đồng nghiệp chậm, một kết nối đóng, một đầu vào quá lớn, và một sự không phù hợp về phiên bản hoặc khả năng.
• Đặt kích thước khung và thông điệp tối đa. Tài liệu mặc định an toàn và điều kiện chính xác cho phép một ngoại lệ; các ngoại lệ ẩn có thể trở thành vấn đề tương tác trong các thay đổi sau này.
• Định nghĩa chính sách ping, nhàn rỗi và đóng. Kiểm tra hành vi này từ một trình duyệt hoặc khách hàng đại diện thay vì chỉ dựa vào kiểm tra đơn vị cục bộ hoặc màn hình cấu hình phía máy chủ.
• Bó hàng đợi outbound theo kết nối. Đặt giới hạn tài nguyên hữu hạn và làm cho việc từ chối kết quả thấy được cả cho các nhà điều hành và ứng dụng gọi.
• Phiên bản hợp đồng thông điệp ứng dụng. Bảo tồn đủ danh định để tương quan một giao dịch logic qua khách hàng, biên, ứng dụng, và bất kỳ công nhân bất đồng bộ nào.
• Cung cấp phục hồi trạng thái dựa trên snapshot hoặc cursor. Xem xét lựa chọn sau khi thay đổi hình dạng lưu lượng vì số lượng kết nối, kích thước tải trọng, và tần suất thông điệp có thể thay đổi thiết kế đúng.
• Xả nước và quan sát các kết nối trong quá trình triển khai. Giữ cho đường dẫn dự phòng có thể quan sát và được kiểm tra để khả năng tương thích không phụ thuộc vào một đường dẫn cũ mà đã ngừng hoạt động một cách lặng lẽ.

Kết luận

WebSocket là hai chiều. Khách hàng và máy chủ có thể gửi độc lập sau khi bắt tay. Ứng dụng định nghĩa hợp đồng riêng của chúng. Khung giao thức không tạo ra các chủ đề, lệnh, quyền hoặc phát lại. Áp dụng hai sự thật đó với các giới hạn rõ ràng, trạng thái có thể quan sát, và một đường dẫn dự phòng được kiểm tra bởi các khách hàng tiêu biểu chứ không phải giả định từ cấu hình.

Tài liệu tham khảo

• Tài liệu trình duyệt Scrapeless Scraping
• Tổng quan về sản phẩm trình duyệt Scrapeless Scraping
• Hướng dẫn thu thập khung WebSocket Scrapeless