因此，我正在寻求构建一个允许视频，音频和文本的聊天应用程序。我花了一些时间研究Websockets和WebRTC来决定使用哪个。由于WebRTC有大量的视频和音频应用程序，这听起来像是一个合理的选择，但是我还应该考虑其他事项吗？随时分享您的想法。
像：
由于是新的，因此WebRTC仅在某些浏览器中可用，而WebSockets似乎在更多的浏览器中可用。
可伸缩性-Websockets使用服务器进行会话，而WebRTC似乎是p2p。
多重/多个聊天室-用于Google+环聊中，我仍在查看演示应用程序的实施方法。
服务器-Websockets需要RedisSessionStore或RabbitMQ才能在多台计算机上扩展。
Answers:
WebRTC设计用于视频，音频和任意数据的高性能，高质量通信。换句话说，适用于您所描述的应用程序。
WebRTC应用程序需要一种服务，通过它们可以交换网络和媒体元数据，这一过程称为信令。但是，一旦发生信令，视频/音频/数据将直接在客户端之间进行流传输，从而避免了通过中介服务器进行流传输的性能成本。
另一方面，WebSocket设计用于客户端和服务器之间的双向通信。可以通过WebSocket流传输音频和视频（例如，请参见此处），但是该技术和API并不是为WebRTC那样固有地设计用于高效，强大的流传输。
正如其他答复所说，WebSocket可用于发出信号。
WebSockets：
批准了IETF标准（6455），并支持所有现代浏览器，甚至使用web-socket-js polyfill的旧版浏览器。
使用HTTP兼容的握手和默认端口，可以更轻松地与现有防火墙，代理和Web服务器基础结构一起使用。
更简单的浏览器API。基本上是一个构造函数，带有几个回调。
客户端/浏览器仅适用于服务器。
仅支持可靠的顺序传输，因为它是基于TCP构建的。这意味着数据包丢弃可能会延迟所有后续数据包。
WebRTC：
刚刚开始受到Chrome和Firefox的支持。MS已提出了不兼容的变体。Firefox和Chrome之间的DataChannel组件尚不兼容。
WebRTC在理想情况下是一种浏览器，但即使如此，几乎始终需要信令服务器来建立连接。现在，最常见的信令服务器解决方案使用WebSockets。
传输层是可配置的，应用程序可以选择连接是否有序和/或可靠。
复杂的多层浏览器API。有JS库提供了一个更简单的API，但是这些库还很年轻并且正在快速变化（就像WebRTC本身一样）。
Websocket使用TCP协议。
WebRTC主要是UDP。
因此，使用WebRTC代替Websocket的主要原因是延迟。使用websocket流，您将获得高延迟或低延迟的断断续续的播放。使用WebRTC，您可以实现低延迟和流畅的播放，这对于VoIP通信至关重要。
只需尝试以2％的网络损耗测试这些技术。您将在Websocket流中看到高延迟。
webRTC还是websockets？为什么不同时使用它们。
建立视频/音频/文本聊天时，webRTC绝对是一个不错的选择，因为它使用对等技术，并且一旦建立并运行连接，就无需通过服务器传递通信（除非使用TURN）。
设置webRTC通信时，您必须涉及某种信令机制。Websocket在这里可能是一个不错的选择，但是webRTC是获取视频/音频/文本信息的方法。聊天室在信令中完成。
但是，正如您提到的，并非所有浏览器都支持webRTC，因此websocket有时对于这些浏览器来说是一个很好的后备。
安全是您错过的一方面。
使用Websockets，数据必须通过中央Web服务器传输，该服务器通常可以查看所有流量并可以访问它。
使用WebRTC，数据是端到端加密的，并且不会通过服务器传递（除非有时需要TURN服务器，但它们无法访问转发的邮件正文）。
根据您的应用程序，这可能会或可能不会影响。
如果您要发送大量数据，则由于webRTC的P2P架构而节省云带宽成本可能也值得考虑。
Webrtc是对等连接的一部分。众所周知，在创建对等连接之前，需要进行握手过程才能建立对等连接。Websocket在握手过程中扮演着重要的角色。