Websockets. Mất internet, tin nhắn giữ chân, kiến ​​trúc ứng dụng, v.v.

Question

Vâng, có rất nhiều thông tin về websockets. Bản thân công nghệ là tuyệt vời, không có nghi ngờ gì trong thực tế này. Và trước khi tôi bắt đầu sử dụng chúng trong ứng dụng của tôi, tôi chỉ muốn cộng đồng trả lời những câu hỏi sau:

"... để duy trì sự hiện diện, ứng dụng có thể gửi tin nhắn còn sống trên WebSocket để ngăn chặn nó bị đóng do một thời gian chờ nhàn rỗi ... "

" ... lý tưởng một phiên bản tương lai của WebSocket sẽ hỗ trợ phát hiện hết giờ, vì vậy nó có thể cho ứng dụng biết thời gian lưu giữ tin nhắn ... "

1. Điều này giống như deja vu. Trước đó chúng tôi đã phải thăm dò ý kiến ​​máy chủ một lần một% period_time% để có được thông tin cập nhật cần thiết. Với websockets, chúng ta phải thăm dò ý kiến ​​máy chủ websocket một lần một% period_time% với tin nhắn giữ lại để đảm bảo kết nối internet vẫn còn hoạt động/máy chủ websocket vẫn hoạt động. Lợi nhuận là gì?

   Và một điều khác liên quan đến những thư còn sống này. Giao thức Websocket có lợi thế là sử dụng ít lưu lượng hơn HTTP (S). Nếu chúng tôi gửi tin nhắn tiếp tục, có vẻ như lợi thế giao thông sẽ biến mất. Hoặc có thể không?

2. Tôi nên xử lý mất internet trong ứng dụng của mình như thế nào nếu tôi sử dụng ổ cắm web? Tôi có nghĩa là tình hình thực sự khi kết nối internet đột nhiên bị mất (tôi có nghĩa là không có "navigator.offline" sự kiện đã xảy ra). Tôi có nên sử dụng một số loại chức năng setTimeout để tìm kiếm các tin nhắn còn sống hay không hoặc có cách nào tốt hơn để xử lý tình huống này không?

3. REST cung cấp cho chúng tôi sự hiểu biết rõ ràng về cách ứng dụng hoạt động và cách các yêu cầu sẽ như thế nào. Cách tốt nhất để làm điều này trong các ứng dụng hỗ trợ websocket là gì? Tôi có nên có (nói) các thông điệp được mã hóa JSON với trường request.action không? Và ứng dụng sẽ thực hiện các yêu cầu PUT như thế nào? Có các tài nguyên URL trong mô hình REST để xử lý việc này, vì vậy tôi có nên sử dụng sự kết hợp của các phương pháp này hoặc có thể có sự đơn giản hơn không?

Answer 1

Tôi nghĩ rằng hầu hết các câu hỏi của bạn có thể được làm rõ bằng cách hiểu mục đích thực sự của WebSockets. WebSockets không được thiết kế chủ yếu để thay thế bất kỳ thứ gì đã sẵn sàng và hoạt động tốt. Ví dụ, nó không được thiết kế để trở thành một phiên bản AJAX có chi phí thấp. Mục đích là để cung cấp một chiều hai chiều, độ trễ thấp, song công toàn bộ, kênh giao tiếp giữa trình duyệt và máy chủ. Mục đích thực sự của nó là kích hoạt một miền ứng dụng web mới hoặc cải tiến các ứng dụng hiện tại đang lạm dụng HTTP để đạt được giao tiếp hai chiều.

Với ý nghĩ đó cho tôi nhận xét về điểm đạn của bạn:

1. Mục đích của kỳ WebSockets ping/tin nhắn pong là hai lần: để giữ kênh khỏi bị đóng cửa do thời gian chờ TCP và nhiều hơn nữa nhanh chóng phát hiện khi kênh bị đóng (đây là một điểm yếu trong lịch sử của TCP). Mục đích của việc bỏ phiếu HTTP/AJAX là nhận được thực tế rằng HTTP không phải là hai chiều (nghĩa là các cuộc thăm dò của khách hàng để cung cấp cho máy chủ cơ hội gửi dữ liệu trở lại). Các khung ping/pong WebSocket thường dài 2 byte. Việc kiểm tra HTTP/AJAX yêu cầu tiêu đề đầy đủ, cookie, v.v. có thể dễ dàng tổng trên một kilobyte cho mỗi yêu cầu/phản hồi. Ngay cả khi bạn gửi một ping/pong 10 lần một giây trên WebSockets bạn vẫn không thể thậm chí so sánh với chi phí của HTTP/AJAX bỏ phiếu mỗi 2 giây.Tuy nhiên, lưu ý rằng các ứng dụng không có khả năng gửi tin nhắn ping/pong. Đây là giữa trình duyệt và máy chủ.

2. Nếu bạn mất kết nối Internet, bạn sẽ nhận được sự kiện onclose. Nếu trình duyệt của bạn không thực hiện các tin nhắn ping/pong cho bạn thì bạn có thể không nhận được thông báo onclose cho đến khi bạn cố gửi tin nhắn sau khi kết nối mạng bị ngắt.

3. Tôi sẽ không thay thế dịch vụ RESTful đang hoạt động bằng WebSockets. Bạn sẽ làm rất nhiều công việc lập bản đồ cho rất ít lợi ích (một lần nữa, WebSockets không được thiết kế để thay thế những gì đã hoạt động tốt). Tôi có thể hình dung các tình huống mà bạn có thể kết hợp cả hai: REST cho chuyển giao trạng thái, WebSockets cho thông báo sự kiện. Ví dụ. máy chủ gửi một thông báo WebSocket cho biết "một cái gì đó thay đổi" mà gây ra các khách hàng để làm một yêu cầu REST để tìm ra sự thay đổi.

Cập nhật:

Làm rõ: bạn có thể làm REST của hơn WebSockets nhưng đó là một không phù hợp trong triết học. REST là một kiểu kiến ​​trúc không có ý kiến ​​về hệ thống truyền tải cơ bản. Nó là một kiến ​​trúc bị hạn chế: "client-server", "stateless", "cacheable", "layered system", "code on demand" và "uniform interface". WebSockets bị ràng buộc bởi không ai trong số đó; nó là một hệ thống truyền tải thông điệp chung. Bạn có thể hạn chế WebSockets để được RESTful nhưng không làm điều đó cho đến khi bạn hiểu cả REST và WebSockets một cách mật thiết và có thể xác định khi nào nó đúng.

Answer 2

"Vui lòng ngừng nói những từ phổ biến và cho biết có bao nhiêu trường hợp thực tế sử dụng ổ cắm web trong ứng dụng sẵn sàng sản xuất bạn có biết ngoại trừ cuộc trò chuyện và ứng dụng trao đổi không?"

Tôi đã sử dụng ổ cắm web để hỗ trợ nhiều người chơi trong trò chơi hành động tàu không gian. Websockets là một công nghệ thực sự tuyệt vời, nhưng tôi cũng thấy nó khó chịu không thể đoán trước - đó có lẽ chỉ là tôi là một người mới và mắc phải một số sai lầm. Nếu tôi có nhiều lỗi phát sinh, tôi có thể đã đặt một liên kết, nhưng nó bị treo quá nhiều, vì vậy tôi không có nó trên một máy chủ trực tiếp vào lúc này.

Tôi cho rằng điều đó sẽ đủ điều kiện nó như là một ứng dụng không sẵn sàng sản xuất, nhưng về mặt giả thuyết tôi không thấy lý do tại sao một người khác có nhiều kinh nghiệm sẽ không làm tốt điều đó.