小编先是习惯性的在某中文百科网站上看了WebSocket的介绍，觉得很囧。如果你按照这个答案去参加BAT等互联网公司的前端开发面试，估计会被鄙视。让我们阅读一些英文资料。直接看stackoverflow上的原文，再翻译一下：原文地址：https://stackoverflow.com/que...这个讨论有8万多浏览量。首先，让我们阅读这个有166个赞的答案：当您使用普通TCP套接字从缓冲区发送字节时，发送函数返回已发送缓冲区的字节数。当我们发送一个普通的TCPsocket从内存缓冲区发送一段字节数据时，send系统调用返回实际发送的字节数。如果是非阻塞套接字或非阻塞发送，则发送的字节数可能小于缓冲区的大小。在操作非阻塞套接字时，send返回的发送字节数可能小于buffer中要发送的字节数。如果它是阻塞套接字或阻塞发送，则返回的数字将与缓冲区的大小匹配，但调用可能会阻塞。如果所有发送的数据都发送完，API调用将不会返回。使用WebSockets，传递给send方法的数据总是要么作为整个“消息”发送，要么根本不发送。此外，浏览器WebSocket实现不会阻止发送调用。Websocket和TCPsocket的区别在于，从发送的数据来看，不再是一串字节，而是按照一个完整的“消息体”发送出去。这个“消息体”不能进一步划分。要么全部发送成功，要么根本没有发送。有些情况下会发生部分发送，如TCP套接字非阻塞操作。也就是说，WebSocket中对套接字的操作是非阻塞操作。这种区别在维基百科上也有清楚的解释：Websocket与TCP的不同之处在于它启用消息流而不是字节流让我们看一下接收器之间的区别。原文：但是在事物的接收端有更重要的区别。当接收方在TCP套接字上执行recv（或读取）时，无法保证返回的字节数对应于发送方的单个发送（或写入）。它可能相同，可能更少（或为零），甚至可能更多（在这种情况下，会收到来自多个发送/写入的字节）。使用WebSockets，消息的接收是事件驱动的（您通常注册一个消息处理例程），事件中的数据始终是另一方发送的整个消息。同样，在TCP套接字的情况下，接收方从TCP套接字中读取的字节数不一定等于发送方调用send发送的字节数。那么WebSocket呢？WebSocket的receiver从socket中读取数据，不是像TCPsockets那样直接使用recv/read读取，而是采用了事件驱动的机制。即应用程序注册一个事件处理函数。当websocket发送端发送的数据被接收应用程序从内核缓冲区复制到应用层后已经可用时，应用程序注册的事件处理函数将作为回调被调用。方法被调用。看一个例子：我通过WebSocket发送一条消息“王子熙”：在调试器中看到的字符串作为回调函数的入参注入到函数体中：在Chrome开发者工具中观察到的WebSocket消息体：下次在面试的时候，面试官问到TCP和WebSocketsockets的区别。相信大家应该都能知道如何回答。获取更多Jerry原创文章，请关注公众号“王子熙”：
