TCP套接字和web套接字之间的差异，再重复一次[重复]

Question

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

• WebSocket与纯TCP的根本区别

等等

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

WebSocket与TCP的不同之处在于它支持消息流而不是字节流

我不完全确定这到底是什么意思。你的解读是什么？

Answer 1

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

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

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

简而言之，WebSocket是一个建立在TCP（可靠的传输层，基于每帧）上的高级协议（像HTTP本身），它使得使用JS客户端构建有效的实时应用程序成为可能（以前的Comet和长html" target="_blank">轮询技术用于从实现WebSocket之前的服务器。请参阅Stackoverflow文章：基于回合的游戏服务器的webSocket和长轮询之间的差异）。

Answer 2

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

但在事情的接受方面还有更重要的区别。当接收器在TCP套接字上执行recv（或read）时，无法保证返回的字节数对应于发送方的一次发送（或写入）。它可能是相同的，可能更少（或零），甚至更多（在这种情况下，从多个发送/写入接收字节）。对于WebSocket，消息的接收者是事件驱动的（通常注册消息处理程序例程），事件中的数据始终是另一方发送的整个消息。

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