所以我想建立一个聊天应用程序，将允许视频，音频和文本。我花了一些时间研究Websockets和WebRTC来决定使用哪个。既然有很多WebRTC的视频和音频应用程序，这听起来是一个合理的选择，但我还应该考虑其他事情吗? 欢迎分享你的想法。
喜欢的东西:
由于WebRTC是新的，它只在一些浏览器上可用，而WebSockets似乎在更多的浏览器中可用。 可伸缩性——Websockets使用服务器进行会话，WebRTC似乎是p2p的。 多路/多聊天室-用于谷歌+ Hangouts，我仍然在查看如何实现的演示应用程序。 服务器- Websockets需要RedisSessionStore或RabbitMQ来跨多台机器扩展。
当前回答
Webrtc是点对点连接的一部分。 我们都知道，在创建点对点连接之前，需要握手过程来建立点对点连接。 而websockets则扮演握手过程的角色。
其他回答
Websockets使用TCP协议。
WebRTC主要是UDP。
因此，使用WebRTC而不是Websocket的主要原因是延迟。 使用websocket流，你会有高延迟或低延迟的震荡回放。使用WebRTC，您可以实现低延迟和流畅的回放，这对VoIP通信至关重要。
试着在网络损耗(即2%)的情况下测试这些技术。您将看到Websocket流中的高延迟。
安全性是你错过的一个方面。
使用Websockets，数据必须通过一个中央网络服务器，该服务器通常可以看到所有流量并可以访问它。
使用WebRTC，数据是端到端加密的，不通过服务器(除非有时需要TURN服务器，但它们无法访问它们转发的消息体)。
这取决于您的应用程序，也可能无关紧要。
如果你要发送大量的数据，由于webRTC的P2P架构节省的云带宽成本可能也值得考虑。
WebRTC是专为高性能、高质量的视频、音频和任意数据通信而设计的。换句话说，就像你描述的那样。
WebRTC应用程序需要一种服务，通过它可以交换网络和媒体元数据，这个过程被称为信令。然而，一旦信号发生，视频/音频/数据直接在客户端之间流媒体，避免了通过中间服务器流媒体的性能成本。
另一方面，WebSocket是为客户端和服务器端的双向通信而设计的。在WebSocket上传输音频和视频是可能的(参见这里的例子)，但是该技术和api并不是像WebRTC那样为高效、健壮的流媒体而设计的。
正如其他回复所说，WebSocket可以用于发送信号。
我维护了一个WebRTC资源列表:强烈建议你从2013谷歌关于WebRTC的I/O演示开始。
webRTC还是websockets?为什么不两者都用呢?
当构建视频/音频/文本聊天时，webRTC绝对是一个很好的选择，因为它使用点对点技术，一旦连接启动并运行，您不需要通过服务器传递通信(除非使用TURN)。
当建立webRTC通信时，你必须涉及到某种信号机制。Websockets可能是一个很好的选择，但webRTC是去的视频/音频/文本信息的方式。聊天室是在信令方面完成的。
但是，正如你提到的，并不是每个浏览器都支持webRTC，所以websockets有时可以成为这些浏览器的一个很好的后备。
比较websocket和webrtc是不公平的。
Websocket是基于TCP之上的。与tcp不同的是，websocket可以通过报文头信息来检测报文的边界。
通常，webrtc使用websocket。webrtc的信令没有定义，这取决于服务提供者想要使用哪种类型的信令。它可以是SIP、HTTP、JSON或任何文本/二进制消息。
信令消息可以使用websocket发送/接收。
