Flash中的WebSocket与原始TCP套接字

什么WebSocket添加到原始TCP连接？ 我为什么要使用WebSocket

我想听听正反两方面的意见，比如：

• 好：WebSocket添加了一些有用的东西，比如自动重新连接、会话ID等
• 坏：WebSocket会增加很多开销

---

我只有Flash客户端，不需要支持Javascript客户端。

您不能在浏览器中从web应用程序执行原始套接字。即使来自Flash的“原始”套接字连接也不是真正的原始连接，因为您必须响应策略文件请求才能获得安全性（WebSocket握手的部分原因）

在初始WebSocket握手之后，WebSocket消息每帧有两个字节的帧开销（Hixie-*有“\x00…\xff”，HyBi-07有两个字节的头），因此与常规套接字相比，开销可以忽略不计

WebSocket握手是一种HTTP兼容的升级请求，因此很容易将WebSocket支持集成到现有的web服务器中，并使用现有的web端口（80/443），这意味着WebSocket连接也可以更容易地集成到现有的防火墙规则中

与HTTP兼容的握手还意味着现有的HTTP身份验证机制可以透明地与WebSocket一起工作。此外，WebSocket可以通过现有的web代理进行代理，而只需很少或不需要修改

在WebSockets协议修订版（HyBi-07）的下一个版本中，他们的目标是防止行为不端的web中介使用有效负载数据的客户端到服务器XOR屏蔽

WebSocket中没有定义自动重新连接、会话ID等内容，尽管在WebSocket上构建的一些Javascript框架有这样的功能。如果您是从Flash应用程序中使用WebSocket，那么您需要进行自己的会话管理，或者将现有会话管理库转换为使用WebSocket而不是Flash Socket（这种转换非常简单）

更新：

以下几个链接可能对您或在此处登陆的其他人有用：

• ：用于Flash应用程序的WebSockets客户端库
• ：WebSockets fallback/polyfill在Flash中为Javascript应用程序实现（将WebSockets支持添加到使用Flash但不使用原生WebSockets的浏览器）

---

关于开销，最小为2字节，但通常更多。从客户端到服务器，掩码需要额外4个字节。当数据长度超过126字节时，还必须为uint添加另外4个字节作为长度。因此，通常要发送大约10字节的数据开销。但更重要的是，要处理这个报头，并在服务器端对每条消息进行去屏蔽，所以要使用更多的CPU来处理数据。同样，如果您创建了从数据直接到二进制的良好序列化，那么它将比使用utf8消息（例如JSON）要好得多。对于flash使用raw.Maksims，HyBi工作组非常有意地选择了屏蔽客户端->服务器流量的机制。由于掩码包含在帧中，因此没有要记住的状态，并且运行的4字节异或是跨批次或架构的最快（也是最有效）的流操作。还需要注意的是，服务器->客户机流量永远不会被屏蔽，大数据通常是服务器->客户机。此外，126->65535字节帧有2个字节的额外字节，而不是4个字节的额外字节。超过65535是8个额外字节。这种标头开销不会造成可测量的现实世界差异。那么，“每项新技术都会带来一系列新的问题。对于WebSocket来说，这是与代理服务器的兼容性，代理服务器在大多数公司网络中调解HTTP连接。WebSocket协议使用HTTP升级系统（通常用于HTTP/SSL）将HTTP连接“升级”到WebSocket连接。某些代理服务器不喜欢这种情况，会断开连接。因此，即使给定的客户端使用WebSocket协议，也可能无法建立连接。”-关于Windows 8/Server 2012的要求如何：>>链接到>>@Triynko，您链接到的html5rocks文章已经有3年了。提到的问题是错误，大多数问题已经或将在不久的将来得到修复。此外，Flash TCP套接字的策略请求也存在类似问题，并且由于Flash是错误的，因此不太可能得到解决大多数开发人员都认为这是遗留问题。就IIS Express对WebSocket的支持而言，这很有意思，但这并不妨碍您运行专用WebSocket服务器，因此实际情况与Flash TCP套接字（在大多数情况下，您都会运行专用服务器）没有什么不同。有关此主题的好信息：