TCP套接字和Web套接字之间的差异,再一次

Pie*_*rOz 137 sockets tcp websocket

为了尽可能地了解TCP套接字和websocket之间的差异,我已经在这些问题中找到了很多有用的信息:

等等...

在我的调查中,我在维基百科上看了这句话:

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

我不完全确定它究竟意味着什么.你有什么解释?

kan*_*aka 193

当您从具有正常TCP套接字的缓冲区发送字节时,send函数返回已发送的缓冲区的字节数.如果它是非阻塞套接字或非阻塞发送,则发送的字节数可能小于缓冲区的大小.如果是阻塞套接字或阻塞发送,则返回的数字将与缓冲区的大小匹配,但调用可能会阻塞.使用WebSockets,传递给send方法的数据总是作为整个"消息"发送或根本不发送.此外,浏览器WebSocket实现不会阻止发送调用.

但是接收方面存在更重要的差异.当接收器在TCP套接字上执行recv(或读取)时,无法保证返回的字节数对应于发送方的单个发送(或写入).它可能是相同的,它可能更少(或为零)甚至可能更多(在这种情况下,来自多个发送/写入的字节被接收).使用WebSockets,消息的接收是事件驱动的(通常是注册消息处理程序例程),事件中的数据始终是另一方发送的整个消息.

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

  • @kanaka是这个主题的专家,根据维基百科的政策,专家不应该编辑主题文章:"利益冲突"(COI)政策.我也在那里被烧了.忘记维基百科. (9认同)
  • @MarcCasavant你问这个问题的方式似乎暗示WebSockets是开销的,没有充分的理由存在.我会翻阅它并说WebSockets是TCP的封装,它为浏览器带来了类似TCP的功能和性能,而不使用插件,也没有放弃来之不易的浏览器安全最佳实践(如CORS).在握手之后,额外分层的开销非常轻(小帧的2字节标题). (9认同)
  • @oberstet这是对[实际政策]的错误陈述(http://en.wikipedia.org/wiki/Wikipedia:Expert_editors)。你所说的是荒谬的。它的真正含义是:“告诫专家编辑,如果编辑涉及专家自己的研究,著作或发现的文章,可能会引起潜在的利益冲突。” (4认同)
  • 那么Web套接字只是普通tcp套接字和Web浏览器之间的一个额外层? (3认同)
  • @EJP 是的,这很荒谬。这是我的经验,该政策如何在“实践”中展开。正如实际读者所承认的那样,“政策警察”出现并删除了有价值的信息。请参阅 http://en.wikipedia.org/wiki/Talk:Comparison_of_WebSocket_implementations 和 http://en.wikipedia.org/wiki/User_talk:Oberstet#Conflict_of_Interest_on_WebSockets_comparison (2认同)

Pao*_*sca 131

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

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

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

简而言之,WebSocket是一种基于TCP(可靠传输层,基于每帧)构建的高级协议(如HTTP本身),可以使用JS客户端构建有效的实时应用程序(以前的Comet和长轮询技术)用于在实现WebSocket之前从服务器提取更新.请参阅Stackoverflow帖子:websockets与基于回合的游戏服务器的长轮询之间的差异).

  • 不知何故,这比外行的回答更好,这解释了一个外行人。 (6认同)