试图尽可能最好的，我可以TCP套接字和WebSocket的之间的差异理解，我已经发现了很多有用的信息，这些问题中：，一个更多的时间
等等...
在我的调查，我通过这句话继续wikipedia：
的WebSocket从TCP不同之处在于它使信息流，而不是字节
流我不能完全肯定这意味着什么究竟。你的解释是什么？
当您使用正常的TCP套接字从缓冲区发送字节时，send函数将返回发送缓冲区的字节数。如果它是一个非阻塞套接字或非阻塞发送，那么发送的字节数可能小于缓冲区的大小。如果它是阻塞套接字或阻塞发送，则返回的数字将与缓冲区的大小相匹配，但呼叫可能会阻塞。使用WebSocket，传递给send方法的数据总是作为一个整体“消息”发送，或者根本不发送。此外，浏览器WebSocket实现不会阻止发送呼叫。
但是在接收方面有更重要的差异。当接收方在TCP套接字上执行recv（或读取）时，不能保证返回的字节数对应于发送方的单个发送（或写入）。它可能是相同的，它可能更少（或者为零），甚至可能更多（在这种情况下，会收到来自多个发送/写入的字节）。使用WebSockets，消息的接收是事件驱动的（通常您会注册一个消息处理程序例程），并且事件中的数据始终是对方发送的完整消息。
请注意，您可以使用TCP套接字进行基于消息的通信，但是您需要一些额外的图层/封装，将消息边界数据添加到消息中，以便可以从消息中重新组合消息。实际上，WebSockets建立在普通的TCP套接字上，并使用包含每个帧大小的帧头，并指出哪些帧是消息的一部分。 WebSocket API将TCP数据块重新组装成框架，在每个消息调用一次消息事件处理程序之前，将这些框架组装成消息。
WebSocket基本上是一个面向消息的应用协议（参考ISO/OSI网络堆栈），其中使用TCP作为传输层。
WebSocket协议背后的思想包括重用客户端和服务器之间建立的TCP连接。在HTTP握手之后，客户端和服务器通过交换WebSocket信封开始说出WebSocket协议。 HTTP握手用于克服提供某些服务的客户端和服务器之间的任何障碍（例如防火墙）（通常任何人都可以从任何地方访问端口80）。客户端和服务器可以随时切换说HTTP，使用相同的TCP连接（永远不会释放）。
幕后WebSocket重建一致的信封/消息中的TCP帧。全双工信道用于由服务器推以异步方式对客户端的更新：通道是开放的，客户端可以调用任何期货/回调/承诺来管理任何异步的WebSocket收到的消息。简而言之，WebSocket是一个基于TCP（可靠传输层，基于每帧）构建的高级协议（如HTTP本身），使得可以使用JS客户端构建有效的实时应用程序（以前的Comet和使用长轮询技术从服务器中提取更新）。
我认为你的维基百科的句子有点误导。从我刚刚从链接中读取的内容看起来好像WebSockets只是用于非HTTP流量的HTTP TCP连接。 IE，你可以通过TCP连接与服务器进行协商，通过它的端口80来使用套接字来进行VPN类型的通信等。所以websocket只会是一个非http http插座？ Spitballing ...不知道它们是什么意思的“消息”，而不是维基百科摘录中的字节。 – 0xhughes