Kết nối WebSocket hoạt động như thế nào?

Trình duyệt Agent Scrapeless cung cấp một kết nối WebSocket để điều khiển một trình duyệt đám mây thông qua Giao thức Chrome DevTools.

Kết nối WebSocket hoạt động như thế nào?

Một kết nối WebSocket thiết lập một kênh liên tục mà qua đó máy khách và máy chủ có thể gửi thông điệp theo cả hai chiều. Sau cái bắt tay mở đầu, các bên ngang hàng trao đổi dữ liệu được đóng khung thay vì gửi một yêu cầu HTTP riêng cho mỗi thông điệp của ứng dụng. Kết nối vẫn hữu ích cho đến khi nó đóng lại, gặp lỗi hoặc không còn phục vụ mục đích của ứng dụng nữa.

WebSocket xác định hành vi truyền tải, chứ không phải ý nghĩa nghiệp vụ của từng thông điệp. Một dịch vụ chat, một nguồn cấp dữ liệu thị trường, và một endpoint điều khiển trình duyệt đều có thể sử dụng WebSocket trong khi sử dụng các giao thức ứng dụng không liên quan. Kết nối thành công chỉ thiết lập kênh truyền; nó không chứng minh rằng ứng dụng đã được xác thực, đã đăng ký đúng dữ liệu, hoặc đã xử lý một thao tác.

Điều Gì Xảy Ra Trong Quá Trình Bắt Tay Mở Đầu?

Bắt tay mở đầu thương lượng một kết nối WebSocket giữa các bên ngang hàng. Trong dạng HTTP/1.1 phổ biến, phía khách gửi một yêu cầu HTTP yêu cầu nâng cấp kết nối, và một phản hồi thành công từ máy chủ sẽ chuyển đổi giao thức. Đặc tả giao thức WebSocket xác định cái bắt tay đó và các quy tắc đóng khung tiếp theo.

Client bao gồm các header riêng của giao thức, và server trả về một giá trị chấp nhận được suy ra. Những giá trị này xác nhận rằng cả hai phía đều hiểu bắt tay WebSocket. Chúng không phải là thông tin xác thực tài khoản, và chúng không xác thực người dùng hoặc cấp quyền truy cập vào dữ liệu ứng dụng được bảo vệ.

Một URL WebSocket bảo mật sử dụng scheme wss để kết nối được bảo vệ bởi TLS. Việc xác thực chứng chỉ và danh tính máy chủ dự kiến vẫn rất quan trọng. Mã hóa bảo vệ lưu lượng trong quá trình truyền; nó không quyết định người dùng nào được phép đăng ký vào một chủ đề riêng tư.

Mẫu nâng cấp HTTP/1.1 không phải là phương thức khởi động duy nhất có thể sử dụng. Khởi động WebSocket qua HTTP/2 sử dụng CONNECT mở rộng. Khi chẩn đoán hạ tầng, hãy xác định đường truyền thực tế thay vì giả định mọi phiên WebSocket xuất hiện như một lần chuyển đổi giao thức HTTP/1.1.

Các Khung Khác Gì So Với Các Tin Nhắn?

Một khung là một đơn vị giao thức chứa điều khiển hoặc dữ liệu, trong khi một thông điệp là một tải trọng ứng dụng được lắp ráp từ các khung dữ liệu. Một thông điệp không bị phân mảnh vừa trong một khung. Một thông điệp bị phân mảnh sử dụng nhiều khung. Các ứng dụng kiểm tra lưu lượng cần biết liệu một công cụ báo cáo các khung thô hay các thông điệp hoàn chỉnh.

Các tin nhắn văn bản chứa văn bản được diễn giải theo các quy tắc văn bản của giao thức. Các tin nhắn nhị phân chứa các byte do ứng dụng định nghĩa. Một đối tượng JSON là một dạng tải trọng văn bản có thể có, nhưng WebSocket không yêu cầu JSON. Một tin nhắn nhị phân có thể chứa dữ liệu ứng dụng đã được nén hoặc mã hóa cần một bộ giải mã riêng.

Các khung từ client đến server được che mặt (masked), trong khi các khung từ server đến client thì không được che mặt theo giao thức cơ bản. Che mặt là một yêu cầu của giao thức để bảo vệ hành vi của hạ tầng; nó không phải là mã hóa. TLS vẫn là cơ chế liên quan để đảm bảo tính bảo mật trong quá trình truyền dữ liệu.

Các khung điều khiển bao gồm ping, pong và close. Chúng phục vụ cho việc quản lý kết nối hơn là dữ liệu nghiệp vụ thông thường. Một trường JSON có giá trị là “ping” là một quy ước của ứng dụng và không nên tự động được xem là tương đương với một khung ping của giao thức.

API của trình duyệt phơi bày một kết nối như thế nào?

API WebSocket của trình duyệt cung cấp trạng thái kết nối và các sự kiện cho việc mở kết nối, nhận tin nhắn, lỗi và đóng kết nối. Mã của ứng dụng phải đợi cho đến khi kênh được mở trước khi gửi dữ liệu thông thường. Một đối tượng đã được tạo không phải là bằng chứng rằng máy chủ đã chấp nhận kết nối.

The tiêu chuẩn API WebSocket của trình duyệt xác định các thuộc tính như readyState và bufferedAmount. Thuộc tính sau mô tả dữ liệu ứng dụng đang được xếp hàng để gửi và chưa được truyền tại thời điểm quan sát được chỉ định. Đây không phải là sự xác nhận rằng ứng dụng phía xa đã xử lý những byte đó.

Trình tạo (constructor) trình duyệt thông thường không cung cấp tùy chọn chung cho các header yêu cầu tùy ý. Lựa chọn cơ chế xác thực phải phù hợp với luồng trình duyệt và cách triển khai mà máy chủ hỗ trợ. Tránh sao chép cấu hình header của thư viện phía máy chủ sang mã chạy trong trình duyệt và cho rằng cùng một giao diện tồn tại.

Đăng ký các trình lắng nghe trước khi ứng dụng bắt đầu hoạt động mà bạn cần quan sát. Một trang có thể mở socket sớm trong quá trình điều hướng. Gắn trình lắng nghe chỉ sau khi một widget đã được hiển thị và điền dữ liệu có thể khiến bạn bỏ lỡ các thông điệp đã thiết lập trạng thái ban đầu của nó.

Nên Áp Dụng Xác Thực và Phân Quyền Như Thế Nào?

Một dịch vụ WebSocket phải xác định cách một kết nối nhận diện bên gọi và những thao tác mà bên đó được phép thực hiện. Bắt tay (handshake) có thể dựa trên một phiên đã thiết lập, một cơ chế thông tin xác thực được ghi chép, hoặc một trao đổi ứng dụng về sau. Cơ chế đúng phụ thuộc vào dịch vụ và môi trường khách.

Máy chủ nên xác thực chính sách origin dự kiến cho các client là trình duyệt và phân quyền cho các đăng ký hoặc lệnh dưới danh tính đã được xác thực. Thông tin origin hữu ích như một ranh giới cho trình duyệt, nhưng nó không thay thế cho kiểm tra danh tính đối với các client tùy ý.

Thông tin xác thực được nhúng trong URL kết nối vẫn là dữ liệu nhạy cảm. Chúng có thể xuất hiện trong log, dấu vết gỡ lỗi, ảnh chụp màn hình và thông báo lỗi được sao chép. Hãy che mờ chúng trước khi chia sẻ. Kênh truyền mã hóa của kết nối không ngăn được việc lộ lọt thông qua chính cơ chế ghi log của ứng dụng.

Quyền truy cập có thể thay đổi khi một kênh vẫn đang mở. Giao thức ứng dụng cần có chính sách cho quyền bị thu hồi, thông tin xác thực hết hạn và các đăng ký không còn được phép. Việc giữ cho kết nối TCP luôn sống không nên tự nó cấp quyền truy cập vô thời hạn.

Điều Gì Xảy Ra Khi Bên Nhận Chậm Hơn Bên Gửi?

Một bên nhận chậm tạo ra áp lực về đệm (buffering) và điều khiển luồng. Ứng dụng cần có giới hạn cho dữ liệu xếp hàng, khối lượng xử lý và thông điệp được giữ lại. Một kênh tồn tại lâu dài có thể tích lũy nhiều công việc hơn so với mô hình yêu cầu theo trang nếu bản cập nhật đến nhanh hơn khả năng xử lý.

Hãy chọn chính sách quá tải dựa trên ý nghĩa của dữ liệu. Một màn hình trạng thái trực tiếp có thể chỉ giữ trạng thái mới nhất cho một khóa. Một luồng sự kiện kiểm toán có thể yêu cầu lưu trữ bền vững trước khi xác nhận là đã chấp nhận. Việc bỏ qua trạng thái trung gian và bỏ qua sự kiện nghiệp vụ là hai quyết định khác nhau.

Giới hạn kích thước thông điệp và xác thực cấu trúc payload trước khi thực hiện xử lý tốn kém. Một bên kết nối vẫn có thể gửi dữ liệu không phù hợp. Tách việc nhận ở tầng mạng khỏi việc phân tích cú pháp, xác thực nghiệp vụ và chấp nhận bền vững để các số liệu mô tả đúng ranh giới cần đo.

Thứ tự cũng cần có phạm vi. Tầng truyền tải cung cấp một kênh có thứ tự, nhưng tính song song trong ứng dụng có thể xử lý thông điệp theo thứ tự khác. Nhiều socket không tự động chia sẻ một thứ tự toàn cục. Nếu thứ tự ảnh hưởng đến ý nghĩa, hãy định nghĩa các định danh hoặc đánh số trình tự trong giao thức ứng dụng.

WebSocket Được Áp Dụng Như Thế Nào Cho Điều Khiển Trình Duyệt Đám Mây?

Điều khiển trình duyệt đám mây sử dụng WebSocket như một kênh cho giao thức tự động hóa trình duyệt. Scrapeless Agent Browser cung cấp một endpoint CDP WebSocket. Các tham số kết nối Agent Browser xác định hợp đồng kết nối cụ thể cho dịch vụ.

Socket điều khiển đó tách biệt với các socket được mở bởi các trang web bên trong trình duyệt. Một trang có thể kết nối đến một nguồn cấp dữ liệu trực tiếp trong khi client tự động hóa giao tiếp với trình duyệt thông qua CDP. Quan sát một kênh không tự động thu thập thông điệp ứng dụng của kênh còn lại.

Ví dụ bắt lưu lượng WebSocket của trình duyệt giải thích sự khác biệt giữa các sự kiện lưu lượng ở cấp trang và việc đo đạc trình duyệt ở cấp thấp hơn. Chỉ áp dụng các kỹ thuật đó cho những nguồn và dữ liệu mà bạn được phép kiểm tra. Một trang hiển thị được không có nghĩa là được phép thu thập mọi luồng riêng tư mà tài khoản có thể truy cập.

Thời lượng phiên và vòng đời kết nối cũng khác nhau. Một dịch vụ trình duyệt có thể đóng phiên theo vòng đời đã được ghi chép ngay cả khi quy trình tự động hóa vẫn mong đợi còn việc phải làm. Hãy lập kế hoạch cho các tác vụ có giới hạn và ghi lại trạng thái ứng dụng cuối cùng đã được chấp nhận. Xem lại Scrapeless pricing khi đánh giá chi phí tài nguyên của việc giữ các phiên trình duyệt luôn mở.

Việc Đóng Kết Nối Khác Gì Với Hoàn Thành Một Tác Vụ?

Một bắt tay đóng kết thúc kênh, trong khi việc hoàn thành tác vụ phụ thuộc vào giao thức ứng dụng. Một lần đóng sạch có thể diễn ra sau một đăng ký đã hoàn tất hoặc một yêu cầu hủy có chủ đích. Một lần đóng bất thường có thể khiến ứng dụng không chắc chắn về những thao tác nào đã được xử lý.

Hãy ghi nhận các xác nhận nghiệp vụ tách biệt khỏi các sự kiện ở tầng truyền tải. Gửi một lệnh không khẳng định rằng hiệu ứng của nó đã được cam kết. Nhận một thông điệp không khẳng định rằng hệ thống lưu trữ của chính bạn đã chấp nhận nó. Các ứng dụng cần tiến trình bền vững nên xác định rõ ràng ranh giới xác nhận và điểm kiểm (checkpoint).

Để minh họa cho việc thu thập telemetry, hãy đặt thời lượng quan sát hoặc giới hạn số thông điệp được chấp nhận trước khi bắt đầu. Khi đạt đến giới hạn đó, hãy dừng đăng ký và đóng kênh theo hành vi mà dịch vụ hỗ trợ. Báo cáo việc thu thập là có giới hạn thay vì tuyên bố rằng nó chứa mọi sự kiện mà nguồn đã từng tạo ra.

Kết Luận

Hãy hiểu quy trình WebSocket theo từng lớp: thiết lập kênh, xác thực giao thức ứng dụng, phân quyền thao tác và ghi nhận tiến trình đã được chấp nhận. Sự tách biệt đó giúp việc phân biệt lỗi kết nối, đăng ký bị thiếu và xử lý hạ nguồn chưa hoàn tất trở nên dễ dàng hơn nhiều.