sockets - TCP sockets和web sockets的区别，再来一次

Question

为了尽可能地理解 TCP socket 和 websocket 之间的区别，我已经在这些问题中找到了很多有用的信息：

• websockets和纯TCP的根本区别
• 如何从 Web 浏览器（客户端）建立 TCP Socket 连接？

等等...

在我的调查中，我在维基百科上浏览了这句话：

Websocket 与 TCP 的不同之处在于它启用消息流而不是字节流

我不完全确定它的确切含义。你的解释是什么？

Answer 1

当您使用普通 TCP 套接字从缓冲区发送字节时，send 函数返回已发送的缓冲区字节数。如果是非阻塞套接字或非阻塞发送，则发送的字节数可能小于缓冲区的大小。如果是阻塞套接字或阻塞发送，则返回的数字将匹配缓冲区的大小，但调用可能会阻塞。使用 WebSockets，传递给 send 方法的数据总是要么作为一个完整的“消息”发送，要么根本不发送。此外，浏览器 WebSocket 实现不会阻塞发送调用。

但在事物的接收方面还有更重要的区别。当接收方在 TCP 套接字上执行recv（或read）时，不能保证返回的字节数对应于发送方的单个发送（或写入）。它可能相同，可能更少（或零），甚至可能更多（在这种情况下，接收来自多个发送/写入的字节）。使用 WebSockets，消息的接收者是事件驱动的（你通常注册一个消息处理程序），事件中的数据总是对方发送的整个消息。

请注意，您可以使用 TCP 套接字进行基于消息的通信，但您需要一些额外的层/封装，将帧/消息边界数据添加到消息中，以便可以从片段中重新组装原始消息。事实上，WebSockets 建立在普通 TCP 套接字之上，并使用帧头，其中包含每个帧的大小并指示哪些帧是消息的一部分。WebSocket API 将 TCP 数据块重新组装成帧，这些帧在每条消息调用一次消息事件处理程序之前组装成消息。

Answer 2

WebSocket 基本上是一个应用程序协议（参考 ISO/OSI 网络堆栈），面向消息，它利用 TCP作为传输层。

WebSocket 协议背后的想法包括重用客户端和服务器之间已建立的 TCP 连接。在 HTTP 握手之后，客户端和服务器通过交换 WebSocket 信封开始使用 WebSocket 协议。HTTP 握手用于克服客户端和提供某些服务的服务器之间的任何障碍（例如防火墙）（通常任何人都可以从任何地方访问端口 80）。客户端和服务器可以在任何时候切换使用相同的 TCP 连接（永远不会释放）。

在幕后 WebSocket 在一致的信封/消息中重建 TCP 帧。服务器使用全双工通道以异步方式向客户端推送更新：通道是打开的，客户端可以调用任何期货/回调/承诺来管理任何异步 WebSocket 接收到的消息。

简而言之，WebSocket 是建立在 TCP（可靠传输层，基于每帧）之上的高级协议（如 HTTP 本身），可以使用 JS 客户端（以前的 Comet 和长轮询技术）构建有效的实时应用程序用于在 WebSockets 实施之前从服务器中提取更新。请参阅 Stackoverflow 帖子： Websockets 之间的差异和基于回合的游戏服务器的长轮询）。