尚:

Ratified IETF standard (6455) with support across all modern browsers and even legacy browsers using web-socket-js polyfill. Uses HTTP compatible handshake and default ports making it much easier to use with existing firewall, proxy and web server infrastructure. Much simpler browser API. Basically one constructor with a couple of callbacks. Client/browser to server only. Only supports reliable, in-order transport because it is built On TCP. This means packet drops can delay all subsequent packets.

WebRTC:

Just beginning to be supported by Chrome and Firefox. MS has proposed an incompatible variant. The DataChannel component is not yet compatible between Firefox and Chrome. WebRTC is browser to browser in ideal circumstances but even then almost always requires a signaling server to setup the connections. The most common signaling server solutions right now use WebSockets. Transport layer is configurable with application able to choose if connection is in-order and/or reliable. Complex and multilayered browser API. There are JS libs to provide a simpler API but these are young and rapidly changing (just like WebRTC itself).

WebRTC是专为高性能、高质量的视频、音频和任意数据通信而设计的。换句话说，就像你描述的那样。

WebRTC应用程序需要一种服务，通过它可以交换网络和媒体元数据，这个过程被称为信令。然而，一旦信号发生，视频/音频/数据直接在客户端之间流媒体，避免了通过中间服务器流媒体的性能成本。

另一方面，WebSocket是为客户端和服务器端的双向通信而设计的。在WebSocket上传输音频和视频是可能的(参见这里的例子)，但是该技术和api并不是像WebRTC那样为高效、健壮的流媒体而设计的。

正如其他回复所说，WebSocket可以用于发送信号。

我维护了一个WebRTC资源列表:强烈建议你从2013谷歌关于WebRTC的I/O演示开始。

尚:

Ratified IETF standard (6455) with support across all modern browsers and even legacy browsers using web-socket-js polyfill. Uses HTTP compatible handshake and default ports making it much easier to use with existing firewall, proxy and web server infrastructure. Much simpler browser API. Basically one constructor with a couple of callbacks. Client/browser to server only. Only supports reliable, in-order transport because it is built On TCP. This means packet drops can delay all subsequent packets.

WebRTC:

Just beginning to be supported by Chrome and Firefox. MS has proposed an incompatible variant. The DataChannel component is not yet compatible between Firefox and Chrome. WebRTC is browser to browser in ideal circumstances but even then almost always requires a signaling server to setup the connections. The most common signaling server solutions right now use WebSockets. Transport layer is configurable with application able to choose if connection is in-order and/or reliable. Complex and multilayered browser API. There are JS libs to provide a simpler API but these are young and rapidly changing (just like WebRTC itself).

Websocket和WebRTC可以一起使用，Websocket是WebRTC的信号通道，而WebRTC是视频/音频/文本通道，WebRTC也可以在UDP中也可以在TURN中继中，TURN中继支持TCP HTTP也可以在HTTPS中。 许多项目同时使用Websocket和WebRTC。

webRTC还是websockets?为什么不两者都用呢?

当构建视频/音频/文本聊天时，webRTC绝对是一个很好的选择，因为它使用点对点技术，一旦连接启动并运行，您不需要通过服务器传递通信(除非使用TURN)。

当建立webRTC通信时，你必须涉及到某种信号机制。Websockets可能是一个很好的选择，但webRTC是去的视频/音频/文本信息的方式。聊天室是在信令方面完成的。

但是，正如你提到的，并不是每个浏览器都支持webRTC，所以websockets有时可以成为这些浏览器的一个很好的后备。

比较websocket和webrtc是不公平的。

Websocket是基于TCP之上的。与tcp不同的是，websocket可以通过报文头信息来检测报文的边界。

通常，webrtc使用websocket。webrtc的信令没有定义，这取决于服务提供者想要使用哪种类型的信令。它可以是SIP、HTTP、JSON或任何文本/二进制消息。

信令消息可以使用websocket发送/接收。