WebSocket là gì?

Trình duyệt Agent không lướt bỏ cung cấp một kết nối WebSocket cho điều khiển trình duyệt từ xa được hỗ trợ thông qua Giao thức DevTools của Chrome.

WebSocket là một giao thức để trao đổi thông điệp hai chiều qua một kết nối lâu dài. Một khách hàng mở kết nối thông qua một lần bắt tay, và sau đó cả khách hàng và máy chủ có thể gửi thông điệp độc lập. Mô hình đó phù hợp với bảng điều khiển trực tiếp, giao diện hợp tác, và các phiên điều khiển trình duyệt cần lệnh và sự kiện liên tục. Nó khác với việc gửi lại các yêu cầu HTTP riêng lẻ để hỏi xem có điều gì thay đổi không.

Kết nối mở là một phương tiện, không phải là một lời hứa về ý nghĩa của từng thông điệp. Các ứng dụng phải xác định loại thông điệp, xác thực, kỳ vọng về thứ tự, và cách xử lý một kết nối đóng. Hướng dẫn này giải thích ranh giới giao thức và các quyết định thiết kế vẫn còn phía trên nó.

Lần bắt tay mở

Một kết nối WebSocket bắt đầu với một lần bắt tay liên quan đến HTTP. Khách hàng yêu cầu nâng cấp giao tiếp, và máy chủ có thể chấp nhận hoặc từ chối yêu cầu đó. Giao thức chỉ định WebSocket định nghĩa lần bắt tay và việc đóng khung thông điệp. Sau một lần bắt tay thành công, các bên trao đổi các khung WebSocket thay vì các thân phản hồi HTTP thông thường cho mỗi thông điệp.

Các sơ đồ URL ws và wss quen thuộc xác định các kết nối WebSocket không bảo mật và được bảo vệ bằng TLS. Đối với một dịch vụ từ xa mang theo thông tin xác thực hoặc dữ liệu ứng dụng, hãy sử dụng dạng bảo mật khi nhà cung cấp ghi tài liệu về nó. Đường đi chính xác và các tham số truy vấn thuộc về hợp đồng dịch vụ; một khách hàng WebSocket chung không thể đoán được các thông điệp mà một điểm cuối cụ thể chấp nhận.

Yêu cầu mở có thể bao gồm một giá trị Origin từ trình duyệt, và máy chủ nên đánh giá xem nguồn đó có chấp nhận được cho trường hợp sử dụng của nó hay không. Bảo mật WebSocket không giống với CORS của trình duyệt. Việc ủy quyền ứng dụng vẫn phải được thực thi. Một lần bắt tay giao thức thành công chỉ thiết lập một kênh; nó không cấp quyền cho mọi thông điệp được gửi qua nó.

Thông điệp, Khung và Tình trạng Kết nối

WebSocket truyền tải các thông điệp có thể là văn bản hoặc nhị phân. Một thông điệp có thể được truyền bởi một hoặc nhiều khung, và các khung điều khiển giao thức hỗ trợ các chức năng như đóng và giữ cho kết nối khỏe mạnh. Hướng dẫn API WebSocket MDN giới thiệu giao diện trình duyệt để mở kết nối và nhận thông điệp.

Ứng dụng quyết định ý nghĩa của thông điệp văn bản. Một cập nhật cổ phiếu có thể là JSON với một ký hiệu và giá cả; một giao thức điều khiển trình duyệt có thể mang một định danh lệnh và tên sự kiện. Phân tích định dạng thông điệp và áp dụng nó vào trạng thái ứng dụng là các nhiệm vụ tách biệt với việc duy trì socket. Xác thực từng thông điệp đến trước khi nó cập nhật biểu đồ hoặc kích hoạt một hành động.

Một kết nối có thể đóng bình thường hoặc bất ngờ. Một khách hàng cần biết liệu lệnh cuối cùng của mình có được xác nhận hay không, liệu nó có bỏ lỡ các cập nhật hay không, và tình trạng mà một phiên sau đó nên bắt đầu từ đâu. Một số ứng dụng cung cấp số thứ tự hoặc bức ảnh chụp nhanh để trả lời những câu hỏi đó. Nếu không có thiết kế ở cấp ứng dụng như vậy, một kết nối mở vẫn có thể cung cấp một cái nhìn không đầy đủ về thế giới.

WebSocket khác với việc truy vấn HTTP như thế nào

Với việc truy vấn, một khách hàng gửi các yêu cầu lặp lại để yêu cầu thông tin mới. Một WebSocket giữ cho kênh mở để bất kỳ bên nào cũng có thể gửi một thông điệp khi cần. Điều đó có thể giảm thiểu quá tải của các yêu cầu lặp lại và cải thiện khả năng phản hồi cho dữ liệu thay đổi thường xuyên. Lợi ích phụ thuộc vào mô hình lưu lượng và triển khai; một trang kiểm tra trạng thái một lần mỗi giờ không nhất thiết phải cần một kết nối dài hạn.

HTTP vẫn hữu ích cho việc tạo ra tài nguyên, lấy tài liệu tĩnh và thực hiện các thao tác có yêu cầu và phản hồi rõ ràng. WebSocket hữu ích khi việc trao đổi diễn ra liên tục và cả hai bên cần nói chuyện. Một hệ thống có thể sử dụng cả hai: HTTP để tải trang ban đầu và thiết lập ngữ cảnh, sau đó là một socket cho các cập nhật trực tiếp. Việc chọn một phương tiện không yêu cầu loại bỏ phương tiện còn lại.

Sự kiện do máy chủ gửi cung cấp một mô hình cập nhật trực tiếp khác trong đó máy chủ gửi sự kiện đến một khách hàng qua phản hồi HTTP. Điều đó có thể đơn giản hơn cho các nguồn thông tin một chiều. WebSocket cung cấp các thông điệp hai chiều. So sánh hướng giao tiếp, hỗ trợ trình duyệt, hành vi hạ tầng và phục hồi trạng thái trước khi chọn một phương tiện cho một tính năng mới.

Một WebSocket trong Tự động hóa Trình duyệt

Điều khiển trình duyệt từ xa cần phải gửi lệnh đến một trình duyệt và gửi sự kiện trở lại cho bộ điều khiển. Trình duyệt Agent không lướt bỏ cung cấp một điểm cuối WebSocket bảo mật đã được tài liệu cho việc kết nối thông qua công cụ trình duyệt được hỗ trợ. Hướng dẫn khởi động nhanh Agent Browser giải thích cách thiết lập một phiên. Phương tiện WebSocket là kênh; giao thức điều khiển trình duyệt định nghĩa từ vựng lệnh.

Một trang trong trình duyệt đó có thể mở WebSocket của riêng nó đến một trang web. Đó là một kết nối khác biệt so với kết nối của bộ điều khiển đến Trình duyệt Agent. Nhầm lẫn chúng dẫn đến kết luận sai lầm: quan sát một socket điều khiển trình duyệt không có nghĩa là trang mục tiêu sử dụng các socket trực tiếp, và việc bắt khung của trang mục tiêu không tiết lộ các lệnh bên trong của bộ điều khiển.

Hướng dẫn bắt khung WebSocket liên quan cho thấy cách công cụ trình duyệt có thể quan sát lưu lượng socket do trang tạo ra trong một quy trình làm việc được ủy quyền. Một khung có thể chứa dữ liệu thị trường công khai, thông tin tài khoản cá nhân, hoặc một thông điệp ứng dụng khác. Chỉ kiểm tra dữ liệu trong quyền hạn của nhiệm vụ và tránh ghi lại các mã thông báo hoặc tải cá nhân không cần thiết.

Thách thức Vận hành của Các Kênh Lâu Dài

Một kết nối mở tiêu tốn tài nguyên ở cả hai đầu. Một máy chủ phải quản lý các khách hàng nhàn rỗi và giới hạn lượng dữ liệu chưa gửi mà nó đệm cho một người nhận chậm. Một khách hàng phải quyết định cách hiển thị trạng thái cũ khi các bản cập nhật dừng lại. Giao diện WebSocket của trình duyệt không tự động giải quyết vấn đề áp lực ngược cho mọi mẫu sử dụng, vì vậy các luồng có khối lượng lớn cần thử nghiệm tải rõ ràng và thiết kế xử lý tin nhắn.

Các phương tiện trung gian có thể ảnh hưởng đến tuổi thọ kết nối. Các máy chủ proxy ngược, cổng và sự thay đổi mạng có thể đóng các kết nối nhàn rỗi hoặc chạy lâu ngay cả khi ứng dụng còn khỏe mạnh. Định nghĩa cách ứng dụng phát hiện sự đóng và khôi phục một cái nhìn chính xác từ một ảnh chụp hoặc con trỏ có thẩm quyền. Đừng giả định rằng một socket mới mở sẽ tiếp tục chuỗi sự kiện chính xác mà cái cũ đã thấy.

Các biện pháp kiểm soát an ninh thuộc về giao thức ứng dụng. Xác thực kết nối hoặc tin nhắn theo hợp đồng dịch vụ, ủy quyền cho mỗi hoạt động nhạy cảm, xác minh kích thước và loại tin nhắn, và đóng phiên khi quyền truy cập kết thúc. The Hướng dẫn máy chủ WebSocket bao gồm các kiểm tra sự bắt tay. Một phương thức truyền tải an toàn bảo vệ dữ liệu trong quá trình truyền; nó không làm cho một tin nhắn không đáng tin cậy an toàn để xử lý.

Khi nào nên chọn WebSocket

Chọn WebSocket khi một trường hợp sử dụng thực sự cần trao đổi hai chiều kịp thời: chỉnh sửa hợp tác, điều khiển tương tác, telemetry trực tiếp, hoặc một phiên trình duyệt từ xa là những ví dụ. Định nghĩa tần suất cập nhật cần thiết, kích thước tin nhắn tối đa và hành vi sau khi mất kết nối. Giao thức sẽ hỗ trợ kênh, nhưng ứng dụng phải định nghĩa tính chính xác.

Đối với các lần đọc thỉnh thoảng, bắt đầu với một hoạt động HTTP bình thường. Nếu ứng dụng chỉ cần cập nhật từ máy chủ đến khách hàng, hãy so sánh với các sự kiện được gửi từ máy chủ. Nếu nó cần lệnh và sự kiện trên cùng một kênh đang diễn ra, WebSocket trở nên hấp dẫn hơn. Đo lường khối lượng công việc đại diện thay vì chọn giao thức chỉ vì một bản demo cảm thấy như đang trực tiếp hơn.

Tài liệu các tin nhắn cẩn thận như một API HTTP. Đặt tên cho từng loại tin nhắn, xác định các trường bắt buộc và chỉ định hành vi lỗi và đóng. Kiểm tra chuỗi dự kiến từ kết nối đến dọn dẹp. Một ứng dụng với giao thức được định nghĩa rõ ràng có thể sử dụng WebSocket một cách hiệu quả; một ứng dụng với các chuyển tiếp trạng thái chưa xác định có thể thất bại mặc dù socket đang hoạt động hoàn hảo.

Một người tiêu thụ dữ liệu trực tiếp cũng cần một ranh giới ảnh chụp rõ ràng. Nếu nó tham gia một luồng sau khi các sự kiện trước đó xảy ra, nó có thể cần một ảnh chụp HTTP ban đầu tiếp theo là các tin nhắn cập nhật ảnh chụp đó. Định nghĩa cách máy khách nhận ra các khoảng trống giữa ảnh chụp và luồng. Nếu không có quy tắc đó, một socket được sắp xếp hoàn hảo vẫn có thể hiển thị số dư tài khoản hoặc số lượng kho không đầy đủ vì máy khách chưa bao giờ biết trạng thái bắt đầu.

Kết luận

WebSocket cung cấp một kênh hai chiều liên tục sau một sự bắt tay mở. Nó rất phù hợp cho các lệnh và sự kiện đang diễn ra, bao gồm điều khiển trình duyệt từ xa, nhưng nó không định nghĩa ý nghĩa tin nhắn của ứng dụng hoặc hành vi khôi phục. Thiết kế những quy tắc đó một cách rõ ràng và xác minh chúng trong các điều kiện kết nối thực tế.