聊天中的 Flash 套接字
我听说很多人在聊天和其他长轮询应用程序中使用闪存套接字。
为什么在这些场景中要使用Flash？
I hear a lot about people using flash sockets in chat and other long polling apps.
Why is flash used in these scenarios?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
性能，因为 Flash 为开发人员提供了 套接字。使用套接字，您可以打开连接并保持打开状态，直到客户端离开应用程序。当服务器中有新信息时，它将数据写入通信通道，客户端自动读取它。无需拉动，无需连接开销，无需额外数据（例如 HTTP 协议标头）。
网络延迟和带宽将限制您的服务器可以发送的数据量。它还会限制您的客户端可以读取的数据量。对于服务器，资源量（通常是 RAM 内存）限制了您可以保留的活动连接（同时打开）的数量。
当 HTTP 用于聊天（或另一个长轮询）应用程序时，通信是无状态的，这意味着应用程序每次必须交换数据时都必须打开与服务器的新连接。您可以使用持久连接（Keep-Alive）来重用现有连接，但取决于超时，这会损害服务器性能：
高超时值：使用单个连接交换更多数据，但会占用多个服务器进程或线程太长时间。服务器将同时支持更少的用户。
低超时值：服务器进程会快速释放以服务另一个请求，因为它们会提前断开您的连接，但是如果超时太低，您最终将不会重用该连接，这会导致每次必须交换数据时都会建立新的连接。非常糟糕。
此外，HTTP 协议并不是为实时通信而设计的。它需要基于文本的标头，这在通信时会浪费大量的字节。我写了一篇文章比较Smartfox服务器的不同通信协议，我注意到在基于文本的协议中（XML、JSON）在我的例子中，标头（和补充）代表消息大小的50-75%；尽管消息“纯”数据非常小（28 字节），但它给出了标头开销的概念。
如果您在整个通信时间内保持通道打开并以二进制形式交换数据，则可以避免连接开销并可以调整消息以实现巨大的吞吐量。
注意：今天，您可以使用 WebSockets 来实现只能实现的结果过去用Flash通讯。例如，Socket.io 使用 JavaScript 在每个浏览器上实现实时连接；它在底层使用 WebSockets（如果可用）、Flash、AJAX 或浏览器支持的其他技术来进行通信。
Performance, because Flash provides the developer with Sockets. Using Sockets, you can open a connection and keep it open until the client leaves the app. When there is new info in the server, it writes the data in the communication channel and the clients automatically reads it. No pulling, no connection overhead, no extra data needed (HTTP protocol header, for instance).
The network latency and bandwidth will limit the amount of data your server can send. It will also limit the amount of data your client can read. Regarding the server, the amount of resources (generally RAM memory) limits the number of active connections (concurrently open) you are allowed to keep.
When HTTP is used for a chat (or another long polling) app, the communication is stateless, which mean the app must open a new connection with the server every time it has to exchange data. You can use persistent connection (Keep-Alive) to reuse an existing connection, but depending on the timeout, it will hurt server performance:
High timeout value: more data exchanged using a single connection, but it will tie up multiple server processes or threads for too long. The server will support fewer users concurrently.
Low timeout value: server processes are released quickly to serve another request because they drop your connection earlier, however if the timeout is too low you will end up not reusing the connection, which leads to a new connection every time you must exchange data. Very bad.
Additionally the HTTP protocol was not designed for real-time communication. It requires text based headers that will waste a precious amount of bytes when communicating. I wrote an article comparing different communication protocols for Smartfox Server and I noticed that in text based protocols (XML, JSON) the header (and complements) represented 50-75% of the message size in my case; even though the message "pure" data was very small (28 bytes), it gives an idea of header overhead.
If you keep a channel open during the whole communication time and exchange data in binary form, you avoid connection overhead and can tweak the messages to achieve great throughput.
NOTICE: today you can use WebSockets to achieve results that were possible only with Flash communication in the past. Socket.io, for instance, enables realtime connectivity on every browser using javascript; under the hood it uses WebSockets (when available), or Flash, or AJAX or other technique supported by the browser to make the communication.
允许普通 TCP 连接的 API 并不普遍适用于 JavaScript（这些是 WebSocket API）。有些浏览器还没有它们。当您说长轮询时，您可能指的是用于模仿 HTTP 上的普通 TCP 的技术（有点荒谬:)）。这是一个需要花费大量时间来发送的 HTTP 请求，但是以块的形式发送的。这种技术实际上是对 HTTP 的滥用，但仍然很流行，因为在 Web 开发方面我们的替代方案有限。
当然，您可以使用任何其他浏览器插件或任何其他为聊天程序实现 TCP 的独立应用程序。
您当然可以设计一个通过 HTTP 工作的聊天程序，但由于 HTTP 的无状态性质，它会使会话维护等任务变得更加困难且效率较低（因为您需要一遍又一遍地发送会话信息）要求）。
最后，几种流行的 IM 格式（例如 Jabber）需要 TCP 连接。 Jabber 还要求您对内容进行 Base64 编码（无论多么愚蠢，这是很多人使用的格式......）并使用某种加密算法进行身份验证。 Flash 在处理二进制数据时比 JavaScript 更快/在那里更容易实现加密算法。
The API allowing plain TCP connection aren't universally available to JavaScript (those would be WebSocket API). Some browsers don't have them yet. When you say long polling you probably mean the technique used to imitate plain TCP over HTTP (an absurdity of a kind :)). That is an HTTP request that takes enormous time to send, but is being sent in chunks. This technique is rather a misuse of HTTP, but is nevertheless popular because we have limited alternatives when it comes to web development.
Of course you could use any other browser plugin or any other standalone application that implements TCP for a chat program.
You could certainly design a chat program that works over HTTP, but due to the stateless nature of HTTP it would make tasks as session maintenance more difficult and less efficient (as you'd be required to send the session information over and over again with each request).
Finally, several popular IM formats (such as Jabber for example) require TCP connection. Jabber also requires that you Base64-encode the contents (however silly that is, it's a format a lot of people use...) and use some encryption algorithm for authentication. Flash is faster when working with binary data then JavaScript / it's easier to implement encryption algorithm there.