Trong những tình huống, AJAX sẽ bỏ phiếu dài / ngắn trên HTML5 WebSockets?


306

Tôi đang xây dựng một ứng dụng trò chuyện nhỏ cho bạn bè, nhưng không chắc chắn về cách lấy thông tin kịp thời mà không thủ công hoặc thô sơ như buộc phải làm mới trang.

Hiện tại, tôi đang thực hiện điều này bằng cách sử dụng AJAX đơn giản, nhưng điều này có nhược điểm là thường xuyên truy cập máy chủ khi hết thời gian ngắn.

Trong nghiên cứu bỏ phiếu dài / ngắn, tôi đã chạy trên HTML5 WebSockets. Điều này có vẻ dễ thực hiện, nhưng tôi không chắc có một số nhược điểm tiềm ẩn. Ví dụ: tôi nghĩ WebSockets chỉ được hỗ trợ bởi một số trình duyệt nhất định. Có những bất lợi nào khác đối với WebSockets mà tôi nên biết không?

Vì có vẻ như cả hai công nghệ đều làm điều tương tự, trong các loại kịch bản nào người ta sẽ thích sử dụng cái này hơn cái kia? Cụ thể hơn, HTML5 WebSockets có khiến AJAX bỏ phiếu dài / ngắn không, hoặc có lý do thuyết phục nào để thích AJAX hơn WebSockets không?

Câu trả lời:


508

WebSockets chắc chắn là tương lai.

Bỏ phiếu dài là một cách giải quyết bẩn để ngăn tạo kết nối cho mỗi yêu cầu như AJAX - nhưng bỏ phiếu dài đã được tạo khi WebSockets không tồn tại. Bây giờ do WebSockets, bỏ phiếu dài sẽ biến mất.

WebRTC cho phép giao tiếp ngang hàng.

Tôi khuyên bạn nên học WebSockets .

So sánh:

các kỹ thuật truyền thông khác nhau trên web

  • AJAX - requestresponse. Tạo kết nối đến máy chủ, gửi các tiêu đề yêu cầu với dữ liệu tùy chọn, nhận phản hồi từ máy chủ và đóng kết nối. Được hỗ trợ trong tất cả các trình duyệt chính.

  • Thăm dò ý kiến ​​dài - requestwaitresponse. Tạo kết nối đến máy chủ giống như AJAX, nhưng vẫn duy trì kết nối duy trì mở trong một thời gian (mặc dù không lâu). Trong khi kết nối, máy khách mở có thể nhận dữ liệu từ máy chủ. Máy khách phải kết nối lại định kỳ sau khi kết nối bị đóng, do hết thời gian hoặc eof dữ liệu. Về phía máy chủ, nó vẫn được xử lý như một yêu cầu HTTP, giống như AJAX, ngoại trừ câu trả lời theo yêu cầu sẽ xảy ra ngay bây giờ hoặc một lúc nào đó trong tương lai, được xác định bởi logic ứng dụng. biểu đồ hỗ trợ (đầy đủ) | wikipedia

  • WebSockets - clientserver. Tạo kết nối TCP đến máy chủ và giữ cho nó mở miễn là cần thiết. Máy chủ hoặc máy khách có thể dễ dàng đóng kết nối. Máy khách trải qua quá trình bắt tay tương thích HTTP. Nếu thành công, máy chủ và máy khách có thể trao đổi dữ liệu theo cả hai hướng bất cứ lúc nào. Sẽ hiệu quả nếu ứng dụng yêu cầu trao đổi dữ liệu thường xuyên theo cả hai cách. WebSockets có khung dữ liệu bao gồm mặt nạ cho mỗi tin nhắn được gửi từ máy khách đến máy chủ, vì vậy dữ liệu được mã hóa đơn giản. biểu đồ hỗ trợ (rất tốt) | wikipedia

  • WebRTC - peerpeer. Vận chuyển để thiết lập giao tiếp giữa các máy khách và không liên quan đến vận chuyển, do đó, nó có thể sử dụng UDP, TCP hoặc các lớp trừu tượng hơn. Điều này thường được sử dụng để truyền dữ liệu âm lượng lớn, chẳng hạn như truyền phát video / âm thanh, trong đó độ tin cậy là thứ yếu và một vài khung hình hoặc giảm tiến trình chất lượng có thể được hy sinh theo thời gian đáp ứng và, ít nhất là, một số truyền dữ liệu. Cả hai bên (đồng nghiệp) có thể đẩy dữ liệu cho nhau một cách độc lập. Mặc dù nó có thể được sử dụng hoàn toàn độc lập với bất kỳ máy chủ tập trung nào, nhưng nó vẫn yêu cầu một số cách trao đổi dữ liệu endPoints, trong đó, trong hầu hết các trường hợp, các nhà phát triển vẫn sử dụng máy chủ tập trung để "liên kết" các đồng nghiệp. Điều này chỉ được yêu cầu để trao đổi dữ liệu cần thiết để thiết lập kết nối, sau đó không yêu cầu máy chủ tập trung. biểu đồ hỗ trợ (trung bình) | wikipedia

  • Sự kiện gửi máy chủ - clientserver. Khách hàng thiết lập kết nối liên tục và lâu dài với máy chủ. Chỉ có máy chủ có thể gửi dữ liệu cho khách hàng. Nếu khách hàng muốn gửi dữ liệu đến máy chủ, nó sẽ yêu cầu sử dụng công nghệ / giao thức khác để làm như vậy. Giao thức này tương thích HTTP và đơn giản để thực hiện trong hầu hết các nền tảng phía máy chủ. Đây là một giao thức thích hợp hơn được sử dụng thay vì Long Polling. biểu đồ hỗ trợ (tốt, ngoại trừ IE) | wikipedia

Ưu điểm:

Ưu điểm chính của phía máy chủ WebSockets , đó không phải là yêu cầu HTTP (sau khi bắt tay), mà là một giao thức truyền thông dựa trên thông điệp thích hợp. Điều này cho phép bạn đạt được lợi thế lớn về hiệu suất và kiến ​​trúc . Ví dụ: trong node.js, bạn có thể chia sẻ cùng một bộ nhớ cho các kết nối ổ cắm khác nhau, để chúng có thể truy cập từng biến được chia sẻ. Do đó, bạn không cần sử dụng cơ sở dữ liệu làm điểm trao đổi ở giữa (như với AJAX hoặc Bỏ phiếu dài với một ngôn ngữ như PHP). Bạn có thể lưu trữ dữ liệu trong RAM hoặc thậm chí xuất bản lại giữa các ổ cắm ngay lập tức.

Cân nhắc về Bảo mật

Mọi người thường quan tâm đến tính bảo mật của WebSockets. Thực tế là nó tạo ra rất ít sự khác biệt hoặc thậm chí đặt WebSockets là lựa chọn tốt hơn. Trước hết, với AJAX, có cơ hội MITM cao hơn , vì mỗi yêu cầu là một kết nối TCP mới đang đi qua cơ sở hạ tầng internet. Với WebSockets, một khi được kết nối, việc chặn giữa chừng sẽ khó khăn hơn rất nhiều, với việc che dấu khung được thi hành bổ sung khi dữ liệu được truyền từ máy khách đến máy chủ cũng như nén thêm, đòi hỏi nhiều nỗ lực hơn để thăm dò dữ liệu. Tất cả các giao thức hiện đại đều hỗ trợ cả: HTTP và HTTPS (được mã hóa).

PS

Hãy nhớ rằng WebSockets thường có cách tiếp cận logic rất khác nhau để kết nối mạng , giống như các trò chơi thời gian thực có tất cả thời gian này và không giống như http.


15
Nó không phải là về khả năng tương thích nó tự. Quan trọng nhất là nó sắp sửa suy nghĩ lại về cách thức giao tiếp đang diễn ra. Vì API RESTful hoạt động với mẫu Yêu cầu> Phản hồi, giao tiếp hai chiều ở đây sẽ là vô nghĩa. Vì vậy, cố gắng sử dụng WebSockets để truy vấn API RESTful - là một nỗ lực hơi kỳ lạ và hoàn toàn không thể thấy bất kỳ lợi ích nào của nó. Nếu bạn cần dữ liệu từ API RESTful nhưng theo cách thức thời gian thực, thì bạn tạo api WebSockets để đẩy dữ liệu sẽ hoạt động với giao tiếp hai chiều như WebSockets. Bạn đang cố gắng so sánh mọi thứ theo góc độ mà chúng không thể so sánh được :)
moka

2
Xin chào @pithhelmet, tất cả phụ thuộc vào phần mềm phía máy chủ (ngôn ngữ / công nghệ). WebSocket là lớp trên TCP và có nhiều cách để thực hiện luồng TCP. Các máy chủ web hiện đại sử dụng kiến ​​trúc dựa trên sự kiện và rất hiệu quả với nhóm luồng. Bạn đang sử dụng công nghệ nào? Node.js sử dụng các sự kiện đằng sau hậu trường cho IO và sự kiện với một luồng trong ngữ cảnh thực thi, vì vậy nó rất hiệu quả. Sử dụng luồng cho mỗi kết nối - rất kém hiệu quả về RAM (1mb + trên mỗi luồng) cũng như CPU, vì các luồng đó sẽ chỉ nhàn rỗi hoặc tệ hơn - vòng lặp kiểm tra dữ liệu vô hạn.
moka

4
Bỏ phiếu dài không phải là một cách giải quyết bẩn thỉu và nó khác với webSocket. Hai cái này có nghĩa là được sử dụng trong kịch bản khác nhau.
bagz_man

5
@bagz_man Long Polling là việc sử dụng công nghệ "hacky" để đạt được kết quả mà công nghệ không cho phép theo định nghĩa và không có sự thay thế tiêu chuẩn có sẵn. Lý do Long Polling tồn tại chính xác là thực tế mà WS đã không, Kỳ.
moka

4
@moka: Cấp miễn phí của Cloudflare sẽ hấp thụ một cuộc tấn công 400 + Gbps được duy trì. Ví của bạn có thể hấp thụ hóa đơn AWS không? Ngoài ra AWS và Cloudflare có quan điểm trái ngược khi giải quyết các khiếu nại chống lại nguồn gốc của bạn. Đó chỉ là một cái gì đó để ghi nhớ miễn là chúng ta đang thảo luận về sự đánh đổi. :)
danneu

11

Một công nghệ tranh chấp mà bạn đã bỏ qua là Nguồn Sự kiện / Sự kiện do Máy chủ gửi. Long-Polling, Websockets, Server-Sent Events (SSE) và Comet là gì? có một cuộc thảo luận tốt về tất cả những điều này. Hãy nhớ rằng một số trong số này dễ dàng hơn những thứ khác để tích hợp với phía máy chủ.


Trong số tất cả những điều này, bạn muốn đề nghị xem xét điều gì?
một

Tôi đã thành công với việc bỏ phiếu dài, mẹo duy nhất (cho nó và các công nghệ khác) là không buộc một luồng máy chủ. Nếu bạn không sử dụng mã máy chủ không đồng bộ, nó sẽ không mở rộng.
bmm6o

1
@somdow Maksims-Mihejevs đã trả lời câu hỏi của bạn độc đáo trong hai đoạn đầu câu trả lời của anh ấy. Sử dụng ổ cắm web.
Jeff Sheffield

7

Đối với các ứng dụng trò chuyện hoặc bất kỳ ứng dụng nào liên tục trò chuyện với máy chủ, WebSocketslà lựa chọn tốt nhất. Tuy nhiên, bạn chỉ có thể sử dụng WebSocketsvới một máy chủ hỗ trợ chúng, do đó có thể hạn chế khả năng sử dụng chúng nếu bạn không thể cài đặt các thư viện cần thiết. Trong trường hợp đó, bạn sẽ cần sử dụng Long Pollingđể có được chức năng tương tự.


5
WebSockets được hỗ trợ bởi mọi máy chủ ... Bạn chỉ cần cài đặt node.js hoặc một cái gì đó tương tự.
noob

9
Tinh chỉnh một chút để giải thích rằng có bất kỳ máy chủ nào sẽ hỗ trợ WebSockets. Tuy nhiên, nếu bạn đang sử dụng dịch vụ lưu trữ, bạn có thể không sử dụng được chúng.
Brant Olsen

Tôi nhận ra chủ đề này hơi cũ nhưng ... WebSockets có thể không phải là câu trả lời tốt nhất cho tất cả các giao tiếp hai chiều. Gần đây tôi nhận thấy rằng tài liệu hỗ trợ ổ cắm web của Spring 4 cho thấy WebSockets phù hợp hơn cho việc di chuyển một lượng lớn dữ liệu hoặc độ trễ thấp. Nếu những điều đó không được áp dụng hoặc không phải là ưu tiên thì họ tin rằng họ đề nghị sử dụng bỏ phiếu dài. Tôi không biết sự biện minh đầy đủ cho quan điểm này, tôi chỉ hình dung những người mùa xuân biết những gì họ đang nói chung.
Stoney

1
@Stoney ngoài thực tế là bạn sẽ cần thiết lập websocket trên máy chủ (trình xử lý, v.v.) Đơn giản là không có lý do gì để sử dụng bỏ phiếu dài trên websocket. Websocket nhanh hơn nhiều (độ trễ thấp) và cho phép máy chủ "nói chuyện" với khách hàng mà không cần khách hàng yêu cầu. Ngày nay tôi sử dụng signalr (một trong những triển khai tốt nhất của websocket theo quan điểm của tôi - nó chạy trên máy khách và máy chủ và cho phép máy khách gọi các phương thức trên máy chủ và máy chủ trên máy khách như thể không có sự khác biệt) trang web tôi tạo - tải nội dung động, trang không đáy, v.v.
DividedByZero

0

Bỏ phiếu XHR vs SSE vs WebSockets

  • Bỏ phiếu XHR Một yêu cầu được trả lời khi sự kiện xảy ra (có thể ngay lập tức hoặc sau khi trì hoãn). Các yêu cầu tiếp theo sẽ cần phải được thực hiện để nhận thêm các sự kiện.

    Trình duyệt đưa ra yêu cầu không đồng bộ của máy chủ, có thể đợi dữ liệu khả dụng trước khi phản hồi. Phản hồi có thể chứa dữ liệu được mã hóa (thường là XML hoặc JSON) hoặc Javascript được thực hiện bởi máy khách. Khi kết thúc quá trình xử lý phản hồi, trình duyệt tạo và gửi một XHR khác, để chờ sự kiện tiếp theo. Do đó, trình duyệt luôn giữ một yêu cầu nổi bật với máy chủ, để được trả lời khi mỗi sự kiện xảy ra. Wikipedia

  • Sự kiện máy chủ đã gửi Máy khách gửi yêu cầu đến máy chủ. Máy chủ gửi dữ liệu mới đến trang web bất cứ lúc nào.

    Theo truyền thống, một trang web phải gửi yêu cầu đến máy chủ để nhận dữ liệu mới; đó là, trang yêu cầu dữ liệu từ máy chủ. Với các sự kiện do máy chủ gửi, máy chủ có thể gửi dữ liệu mới tới trang web bất cứ lúc nào bằng cách đẩy tin nhắn đến trang web. Những tin nhắn đến này có thể được coi là dữ liệu Sự kiện + trong trang web. Mozilla

  • WebSockets Sau khi bắt tay ban đầu (thông qua giao thức HTTP). Giao tiếp được thực hiện hai chiều bằng giao thức WebSocket.

    Bắt tay bắt đầu với một yêu cầu / phản hồi HTTP, cho phép các máy chủ xử lý các kết nối HTTP cũng như các kết nối WebSocket trên cùng một cổng. Khi kết nối được thiết lập, giao tiếp sẽ chuyển sang giao thức nhị phân hai chiều không phù hợp với giao thức HTTP. Wikipedia

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.