Android 浏览器的替代服务器推送/ Comet 实现而不发送 4KB 消息？
我正在开发一个 Web 应用程序，它使用 Comet Hidden iFrame 技术将数据从服务器推送到移动浏览器。
在 Mobile Safari 上一切正常，但在 Android 上则要痛苦得多。似乎需要从服务器发送 4 KB 消息才能考虑该消息。这适用于每条消息，而不仅仅是第一条消息。
有些人尝试使用 XMLHttpRequest 流实现 Comet，但遇到了相同的 4KB 问题 (http://code.google.com/p/android/issues/detail?id=13044)
有没有人设法在 Android 浏览器上实现 Comet 技术，而不需要将消息填充到 4KB ？
在 Android 2.1,2.2 上测试，
即使在 Android 4.0 版本上似乎也不支持服务器发送的事件 http://caniuse.com/eventsource
对于 websocket 相同 http://caniuse.com/websockets
谢谢
-seb
I am developing a web application that uses Comet Hidden iFrame technique to push data from server to mobile browser.
Everything works fine on Mobile Safari but Android is a lot more painful. It seems to require 4 KB messages to be sent from the server in order the message to be taken in account. This is for each messages not only the first one.
Some people tried implementing Comet using XMLHttpRequest streaming but have the same 4KB issues (http://code.google.com/p/android/issues/detail?id=13044)
Has anyone managed to implement Comet techniques on Android browser without requiring to pad the messages to 4KB ?
Tested on Android 2.1,2.2
Server sent event seems not to be supported even on version Android 4.0
http://caniuse.com/eventsource
Same for websocket
http://caniuse.com/websockets
thanks
-seb
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不确定它是否可以作为您眼前问题的答案，但一般建议是使用面向未来的技术，该技术可以回退到相当好的 polyfill。
对于您的具体问题，我相信 WebSockets 是最好的技术，与 WebSocket 服务器（node.js、Kaazing）相结合，并具有良好的后备选项。我更熟悉 Kaazing：它在不兼容 WebSocket 的浏览器上提供的性能几乎与本机 WebSocket 性能相同。
有关 WebSocket 模拟的更多信息，您可能会发现这篇文章对 WebSocket 模拟很有用。
Not sure if it qualifies as an answer to your immediate problem, but the general recommendation is to use a future-proof technique that falls back to a reasonably good polyfill.
For your specific issue, I believe WebSockets is the best technology, in combination with a WebSocket server (node.js, Kaazing), with good fallback options. I'm more familiar with Kaazing: it provides virtually the same performance on non-WebSocket-compliant browsers as the native WebSocket performance.
For more on WebSocket emulation, you may find this post useful on WebSocket emulation.
这个 4KB 缓冲区问题已经存在很长时间了，并且在桌面浏览器以及 Android Internet.app（我不知道）上仍然存在这种情况。
解决方案是通过初始连接发送 4KB 块。在这种情况下，HTTP Streaming 是比 HTTP 长轮询。通过流式传输，您可以在新数据可用时保持连接打开，这与关闭然后重新打开连接的长轮询不同。这种技术意味着，不幸的是，最初存在 4KB 的无用数据块，但除此之外的所有数据都是实际数据（可用）。我花了好几个小时来摆弄这个缓冲区大小，有时不同的网络浏览器之间的缓冲区大小不一致。
但是，有些公司（例如 Caplin Systems）在其企业级应用程序中使用 HTTP 流，这些应用程序被众多金融机构使用，所以可以让它持续良好地工作。
这种情况发生的可能性极小。 WebSockets（正如 @Peter Moskovits 所指出的）是未来跨浏览器实现这种双向通信（目前重点是推送）的方式。对于 Android 来说，这确实意味着用户还需要在其设备上安装 Flash，以便互联网应用程序支持 Flash 回退技术，这是因为 Android 目前本身并不支持 WebSockets。
This 4KB buffer problem has been around for a long time and is still the case on desktop browsers as well as Android Internet.app (which I didn't know about).
The solution is to send a 4KB chunk with the initial connection. And this is one scenario where HTTP Streaming is a better solution than HTTP Long-Polling. With streaming you keep the connection open when new data is available, unlike Long-Polling where you close and then re-open a connection. This technique means that there is an initial unfortunate 4KB chunk of useless data but all data beyond that is actual data (usable). I've spent hours of my life messing with this buffer size and it's sometimes inconsistent between web browsers.
But, there are companies such as Caplin Systems who use HTTP Streaming in their enterprise level applications, used by numerous financial institutions, so it is possible to get this working consistently well.
It's highly unlikely that this will ever happen. And WebSockets (as pointed out by @Peter Moskovits) are the way that this bi-directional communication (with an emphasis on push at the moment) will be achieved cross-browser in the future. For Android this does mean that the user would also need Flash installed on their device for the Internet application to support the Flash fallback technique which will be required since Android, for the moment, does not natively support WebSockets.
在 Android 上，使用浏览器和 rgd。 WebSockets：
Firefox Mobile 已支持（包括最终版 RFC6455）
内置浏览器不支持 WS（直至 Android 4，包括 Android 4）< /p>
Chrome for Mobile（完整 RFC6455）.. 仅适用于Android 4
On Android, and with browsers, and rgd. WebSockets:
Firefox Mobile has support (incl. final RFC6455)
builtin browser has no support for WS whatsoever (up to and incl. Android 4)
Chrome for Mobile (full RFC6455) .. only avail for Android 4