聊天中的 Flash 插座答案

【问题标题】：Flash sockets in chat聊天中的 Flash 插座
【发布时间】：2011-10-14 17:42:58
【问题描述】：

我听说很多人在聊天和其他长轮询应用程序中使用 Flash 套接字。

为什么在这些场景中使用闪存？

【问题讨论】：

【解决方案1】：

性能，因为 Flash 为开发者提供了Sockets。使用 Sockets，您可以打开连接并保持打开状态，直到客户端离开应用程序。当服务器中有新信息时，它会将数据写入通信通道，客户端会自动读取它。无需拉取，无需连接开销，无需额外数据（例如 HTTP 协议标头）。

网络延迟和带宽将限制您的服务器可以发送的数据量。它还将限制您的客户端可以读取的数据量。关于服务器，资源量（通常是 RAM 内存）限制了您允许保持的活动连接（同时打开）的数量。

当 HTTP 用于聊天（或其他长轮询）应用程序时，通信是无状态的，这意味着应用程序必须在每次必须交换数据时打开与服务器的新连接。您可以使用persistent connection (Keep-Alive) 来重用现有连接，但根据超时时间，它会损害服务器性能：

高超时值：使用单个连接交换更多数据，但它会占用多个服务器进程或线程太长时间。服务器将同时支持更少的用户。
低超时值：服务器进程被快速释放以服务另一个请求，因为它们更早地断开了您的连接，但是如果超时太低，您最终将无法重用连接，这每次您必须交换数据时都会导致新的连接。非常糟糕。

此外，HTTP 协议不是为实时通信而设计的。它需要基于文本的标头，在通信时会浪费大量的字节。我写了一个 article 比较 Smartfox 服务器的不同通信协议，我注意到在基于文本的协议（XML、JSON）中，标题（和补充）代表了我的消息大小的 50-75%案子;尽管消息“纯”数据非常小（28 字节），但它给出了标头开销的概念。

如果您在整个通信时间内保持通道打开并以二进制形式交换数据，则可以避免连接开销并可以调整消息以实现高吞吐量。

注意：今天您可以使用WebSockets 来实现过去只能通过 Flash 通信才能实现的结果。例如，Socket.io 使用 javascript 在每个浏览器上启用实时连接；在后台，它使用 WebSockets（如果可用）、Flash、AJAX 或浏览器支持的其他技术进行通信。

【讨论】：

我打算为赏金写自己的答案，但你已经很好地覆盖了 Dovyski！我想澄清一下，您对资源需求的假设取决于服务器软件的具体实现。例如WebSync 通过良好的服务器编程来降低资源需求，从而减少所需的线程数和内存量。在当今的浏览器和设备世界中，您需要一个具有多种蒸汽方法的抽象层以实现兼容性。您的第一段和最后一段与问题最相关。
谢谢你，本斯韦恩！我完全同意你对我的资源假设的看法（这很天真）。我只是想就基于 HTTP 的长轮询应用中的资源/性能之间的关系给出一个直截了当的想法。

【解决方案2】：

允许纯 TCP 连接的 API 并非普遍适用于 JavaScript（即 WebSocket API）。有些浏览器还没有。当您说长轮询时，您可能是指用于通过 HTTP 模仿普通 TCP 的技术（一种荒谬:)）。这是一个 HTTP 请求，需要大量时间才能发送，但是以块的形式发送的。这种技术是对 HTTP 的误用，但仍然很受欢迎，因为我们在 Web 开发方面的选择有限。

当然，您可以使用任何其他浏览器插件或任何其他为聊天程序实现 TCP 的独立应用程序。

您当然可以设计一个在 HTTP 上运行的聊天程序，但由于 HTTP 的无状态特性，它会使会话维护任务变得更加困难和效率低下（因为您需要一遍又一遍地发送会话信息每次请求时再次）。

最后，几种流行的 IM 格式（例如 Jabber）需要 TCP 连接。 Jabber 还要求您对内容进行 Base64 编码（但是很愚蠢，这是一种很多人使用的格式......）并使用一些加密算法进行身份验证。 Flash 在处理二进制数据时比 JavaScript 更快/更容易在那里实现加密算法。

【讨论】：