Một số câu trả lời tuyệt vời từ những người khác bao gồm rất nhiều cơ sở. Đây là một chút bổ sung.
Ưu điểm duy nhất của WebSockets so với các plugin như Java Applets, Flash hoặc Silverlight là WebSockets được tích hợp sẵn trong trình duyệt và không dựa vào plugin.
Nếu điều này có nghĩa là bạn có thể sử dụng Java Applet, Flash hoặc Silverlight để thiết lập kết nối socket thì có, điều đó là có thể. Tuy nhiên, bạn không thấy điều đó được triển khai trong thế giới thực quá thường xuyên vì những hạn chế.
Ví dụ, người trung gian có thể và thực hiện việc tắt lưu lượng truy cập đó. Tiêu chuẩn WebSocket được thiết kế để tương thích với cơ sở hạ tầng HTTP hiện có và do đó ít bị can thiệp bởi các trung gian như tường lửa và proxy.
Hơn nữa, WebSocket có thể sử dụng cổng 80 và 443 mà không yêu cầu cổng chuyên dụng, một lần nữa nhờ thiết kế giao thức tương thích nhất có thể với cơ sở hạ tầng HTTP hiện có.
Các lựa chọn thay thế socket đó (Java, Flash và Silverlight) khó sử dụng một cách an toàn trong kiến trúc nguồn gốc chéo. Vì vậy, mọi người thường cố gắng sử dụng chúng có nguồn gốc chéo sẽ chịu đựng được những bất an hơn là cố gắng thực hiện nó một cách an toàn.
Chúng cũng có thể yêu cầu mở thêm các cổng "không chuẩn" (điều mà quản trị viên không thích làm) hoặc các tệp chính sách cần được quản lý.
Nói tóm lại, việc sử dụng Java, Flash hoặc Silverlight cho kết nối socket có vấn đề đến mức bạn không thấy nó được triển khai trong các kiến trúc nghiêm túc quá thường xuyên. Flash và Java đã có khả năng này trong ít nhất 10 năm, nhưng nó vẫn chưa phổ biến.
Tiêu chuẩn WebSocket đã có thể bắt đầu với một cách tiếp cận mới, lưu ý đến những hạn chế đó và hy vọng đã học được một số bài học từ chúng.
Một số triển khai WebSocket sử dụng Flash (hoặc có thể là Silverlight và / hoặc Java) làm dự phòng khi không thể thiết lập kết nối WebSocket (chẳng hạn như khi chạy trong trình duyệt cũ hoặc khi một bên trung gian can thiệp).
Mặc dù một số loại chiến lược dự phòng cho những tình huống đó là thông minh, thậm chí cần thiết, nhưng hầu hết những chiến lược sử dụng Flash et al sẽ mắc phải những nhược điểm được mô tả ở trên. Không nhất thiết phải như vậy - có những cách giải quyết để đạt được các kết nối có khả năng đa nguồn an toàn bằng cách sử dụng Flash, Silverlight, v.v. - nhưng hầu hết các triển khai sẽ không làm được điều đó vì nó không dễ dàng.
Ví dụ: nếu bạn dựa vào WebSocket cho kết nối nhiều nguồn gốc, điều đó sẽ hoạt động tốt. Nhưng nếu sau đó bạn chạy trong một trình duyệt cũ hoặc tường lửa / proxy bị can thiệp và dựa vào Flash, chẳng hạn như dự phòng của bạn, bạn sẽ thấy khó thực hiện cùng một kết nối nguồn gốc chéo đó. Tất nhiên, trừ khi bạn không quan tâm đến bảo mật.
Điều đó có nghĩa là rất khó để có một kiến trúc thống nhất duy nhất hoạt động cho các kết nối gốc và không phải bản địa, trừ khi bạn đã chuẩn bị sẵn sàng để thực hiện khá nhiều công việc hoặc đi với một khuôn khổ đã hoạt động tốt. Trong một kiến trúc lý tưởng, bạn sẽ không nhận thấy các kết nối có phải là bản địa hay không; cài đặt bảo mật của bạn sẽ hoạt động trong cả hai trường hợp; cài đặt phân cụm của bạn sẽ vẫn hoạt động; kế hoạch năng lực của bạn sẽ vẫn được giữ; và như thế.
Ưu điểm duy nhất của WebSockets so với truyền trực tuyến http là bạn không phải nỗ lực để "hiểu" và phân tích cú pháp dữ liệu nhận được.
Nó không đơn giản như mở một luồng HTTP và ngồi lại khi dữ liệu của bạn chảy trong vài phút, hàng giờ hoặc lâu hơn. Các khách hàng khác nhau hành xử khác nhau và bạn phải quản lý điều đó. Ví dụ: một số máy khách sẽ đệm dữ liệu và không phát hành nó vào ứng dụng cho đến khi đạt đến một số ngưỡng. Thậm chí tệ hơn, một số sẽ không chuyển dữ liệu vào ứng dụng cho đến khi kết nối bị đóng.
Vì vậy, nếu bạn đang gửi nhiều thư cho ứng dụng khách, có thể ứng dụng khách sẽ không nhận được dữ liệu cho đến khi nhận được 50 thư có giá trị dữ liệu. Đó không phải là thời gian thực.
Mặc dù phát trực tuyến HTTP có thể là một giải pháp thay thế khả thi khi không có WebSocket, nhưng nó không phải là thuốc chữa bách bệnh. Nó cần có sự hiểu biết tốt để hoạt động một cách hiệu quả trong vùng đất xấu của Web trong điều kiện thực tế.
Có sự khác biệt đáng kể nào khác mà tôi đang thiếu không?
Còn một điều nữa mà chưa ai nói đến nên mình sẽ đưa ra.
Giao thức WebSocket được thiết kế để trở thành một lớp truyền tải cho các giao thức cấp cao hơn. Mặc dù bạn có thể gửi tin nhắn JSON hoặc những gì không trực tiếp qua kết nối WebSocket, nó cũng có thể mang các giao thức tiêu chuẩn hoặc tùy chỉnh.
Ví dụ: bạn có thể thực hiện AMQP hoặc XMPP qua WebSocket, như mọi người đã làm. Vì vậy, một khách hàng có thể nhận được tin nhắn từ một nhà môi giới AMQP như thể nó được kết nối trực tiếp với chính nhà môi giới đó (và trong một số trường hợp là như vậy).
Hoặc nếu bạn có một máy chủ hiện có với một số giao thức tùy chỉnh, bạn có thể vận chuyển nó qua WebSocket, do đó mở rộng máy chủ back-end đó lên Web. Thông thường, một ứng dụng hiện có đã bị khóa trong doanh nghiệp có thể mở rộng phạm vi tiếp cận của nó bằng cách sử dụng WebSocket mà không cần phải thay đổi bất kỳ cơ sở hạ tầng back-end nào.
(Đương nhiên, bạn muốn có thể thực hiện tất cả những điều đó một cách an toàn, vì vậy hãy kiểm tra với nhà cung cấp hoặc nhà cung cấp WebSocket.)
Một số người đã gọi WebSocket là TCP cho Web. Bởi vì giống như TCP vận chuyển các giao thức cấp cao hơn, WebSocket cũng vậy, nhưng theo cách tương thích với cơ sở hạ tầng Web.
Vì vậy, mặc dù luôn có thể gửi các thông báo JSON (hoặc bất kỳ thứ gì) trực tiếp qua WebSocket, nhưng người ta cũng nên xem xét các giao thức hiện có. Bởi vì đối với nhiều thứ bạn muốn làm, có thể có một giao thức đã được nghĩ ra để làm điều đó.
Tôi xin lỗi nếu tôi đang hỏi lại hoặc kết hợp nhiều câu hỏi đã có trên SO thành một câu hỏi duy nhất, nhưng tôi chỉ muốn hiểu rõ hơn về tất cả thông tin có trên SO và web liên quan đến những khái niệm này.
Đây là một câu hỏi tuyệt vời và tất cả các câu trả lời đều rất giàu thông tin!