WebRTC vs Websockets: Nếu WebRTC có thể làm Video, Audio và Dữ liệu, tại sao tôi cần Websockets? [đóng cửa]

Vì vậy, tôi đang tìm cách xây dựng một ứng dụng trò chuyện cho phép video, âm thanh và văn bản. Tôi đã dành một chút thời gian nghiên cứu về Websockets và WebRTC để quyết định sử dụng cái nào. Vì có rất nhiều ứng dụng video và âm thanh với WebRTC, điều này nghe có vẻ là một lựa chọn hợp lý, nhưng có những điều khác tôi nên xem xét? Hãy chia sẻ những suy nghĩ của bạn.

Những thứ như:

• Do WebRTC mới chỉ có sẵn trên một số trình duyệt, trong khi WebSockets dường như có nhiều trình duyệt hơn.

• Khả năng mở rộng - Websockets sử dụng máy chủ cho phiên và WebRTC dường như là p2p.

• Ghép kênh / nhiều phòng chat - Được sử dụng trong Google+ Hangouts và tôi vẫn đang xem các ứng dụng demo về cách triển khai.

• Máy chủ - Websockets cần RedisSessionStore hoặc RabbitMQ để mở rộng trên nhiều máy.

WebRTC được thiết kế để truyền thông hiệu suất cao, chất lượng cao của video, âm thanh và dữ liệu tùy ý. Nói cách khác, cho các ứng dụng chính xác như những gì bạn mô tả.

Các ứng dụng WebRTC cần một dịch vụ thông qua đó chúng có thể trao đổi siêu dữ liệu mạng và phương tiện, một quá trình được gọi là báo hiệu. Tuy nhiên, một khi tín hiệu đã diễn ra, video / âm thanh / dữ liệu được truyền trực tiếp giữa các máy khách, tránh chi phí hiệu năng truyền phát qua máy chủ trung gian.

Mặt khác, WebSocket được thiết kế để liên lạc hai chiều giữa máy khách và máy chủ. Có thể truyền phát âm thanh và video qua WebSocket (xem tại đây ví dụ ), nhưng công nghệ và API vốn không được thiết kế để phát trực tuyến hiệu quả, mạnh mẽ theo cách WebRTC.

Như các câu trả lời khác đã nói, WebSocket có thể được sử dụng để báo hiệu.

Tôi duy trì một danh sách các tài nguyên WebRTC : khuyên bạn nên bắt đầu bằng cách xem bản trình bày Google I / O 2013 về WebRTC.

WebSockets:

• Đã phê chuẩn tiêu chuẩn IETF (6455) với sự hỗ trợ trên tất cả các trình duyệt hiện đại và thậm chí các trình duyệt cũ sử dụng polyfill web-socket-js.

• Sử dụng bắt tay tương thích HTTP và các cổng mặc định giúp sử dụng dễ dàng hơn nhiều với cơ sở hạ tầng tường lửa, proxy và máy chủ web hiện có.

• API trình duyệt đơn giản hơn nhiều. Về cơ bản một constructor với một vài cuộc gọi lại.

• Máy khách / trình duyệt đến máy chủ duy nhất.

• Chỉ hỗ trợ vận chuyển theo thứ tự đáng tin cậy vì được xây dựng trên TCP. Điều này có nghĩa là giọt gói có thể trì hoãn tất cả các gói tiếp theo.

WebRTC:

• Mới bắt đầu được Chrome và Firefox hỗ trợ. MS đã đề xuất một biến thể không tương thích. Thành phần DataChannel chưa tương thích giữa Firefox và Chrome.

• WebRTC là trình duyệt đến trình duyệt trong hoàn cảnh lý tưởng nhưng thậm chí sau đó hầu như luôn yêu cầu máy chủ báo hiệu để thiết lập các kết nối. Các giải pháp máy chủ báo hiệu phổ biến nhất hiện nay sử dụng WebSockets.

• Lớp vận chuyển có thể cấu hình với ứng dụng có thể chọn nếu kết nối theo thứ tự và / hoặc đáng tin cậy.

• API trình duyệt phức tạp và nhiều lớp. Có các lib lib để cung cấp API đơn giản hơn nhưng chúng rất trẻ và thay đổi nhanh chóng (giống như chính WebRTC).

Websockets sử dụng giao thức TCP.

WebRTC chủ yếu là UDP.

Do đó, lý do chính của việc sử dụng WebRTC thay vì Websocket là độ trễ. Với phát trực tuyến websocket, bạn sẽ có độ trễ cao hoặc phát lại bị giật với độ trễ thấp. Với WebRTC, bạn có thể đạt được độ trễ thấp và phát lại mượt mà, đây là công cụ quan trọng để liên lạc VoIP.

Chỉ cần thử kiểm tra các công nghệ này với mất mạng, tức là 2%. Bạn sẽ thấy độ trễ cao trong luồng Websocket.

webRTC hay websockets? Tại sao không sử dụng cả hai.

Khi xây dựng trò chuyện video / âm thanh / văn bản, webRTC chắc chắn là một lựa chọn tốt vì nó sử dụng công nghệ ngang hàng và một khi kết nối được bật và chạy, bạn không cần truyền thông qua máy chủ (trừ khi sử dụng TURN).

Khi thiết lập giao tiếp webRTC, bạn phải sử dụng một số loại cơ chế báo hiệu. Websockets có thể là một lựa chọn tốt ở đây, nhưng webRTC là cách để tìm thông tin video / âm thanh / văn bản. Phòng trò chuyện được thực hiện trong các tín hiệu.

Nhưng, như bạn đã đề cập, không phải mọi trình duyệt đều hỗ trợ webRTC, do đó, websockets đôi khi có thể là một dự phòng tốt cho các trình duyệt đó.

So sánh websocket và webrtc là không công bằng.

Websocket dựa trên TCP. Ranh giới của gói có thể được phát hiện từ thông tin tiêu đề của gói websocket không giống như tcp.

Thông thường, webrtc sử dụng websocket. Tín hiệu cho webrtc không được xác định, tùy thuộc vào nhà cung cấp dịch vụ loại tín hiệu nào anh ta muốn sử dụng. Nó có thể là SIP, HTTP, JSON hoặc bất kỳ tin nhắn văn bản / nhị phân nào.

Các tin nhắn báo hiệu có thể được gửi / nhận bằng websocket.

Bảo mật là một khía cạnh bạn đã bỏ lỡ.

Với Websockets, dữ liệu phải đi qua một máy chủ web trung tâm thường thấy tất cả lưu lượng truy cập và có thể truy cập nó.

Với WebRTC, dữ liệu được mã hóa nối đầu và không đi qua máy chủ (ngoại trừ đôi khi cần có máy chủ TURN, nhưng họ không có quyền truy cập vào nội dung thư mà họ chuyển tiếp).

Tùy thuộc vào ứng dụng của bạn, điều này có thể hoặc không quan trọng.

Nếu bạn đang gửi một lượng lớn dữ liệu, việc tiết kiệm chi phí băng thông đám mây do kiến ​​trúc P2P của webRTC cũng có thể đáng xem xét.

Webrtc là một phần của kết nối ngang hàng. Chúng ta đều biết rằng trước khi tạo kết nối ngang hàng, nó đòi hỏi quá trình bắt tay để thiết lập kết nối ngang hàng. Và websockets đóng vai trò của quá trình bắt tay.

Websocket và WebRTC có thể được sử dụng cùng nhau, Websocket là kênh tín hiệu của WebRTC và webrtc là kênh video / âm thanh / văn bản, WebRTC cũng có thể trong UDP cũng trong chuyển tiếp TURN, chuyển tiếp TURN hỗ trợ TCP HTTP cũng HTTPS. Nhiều dự án sử dụng Websocket và WebRTC cùng nhau.