用于实时聊天应用程序的 HTML5 Websockets?

2021-12-25 00:00:00 websocket chat php html

我们计划使用 Websockets 技术制作一个基于 HTML5 的聊天应用程序.

We were planning to make an HTML5 based chat app using the Websockets technology.

所以我的问题是:

  1. 截至今天，哪些浏览器本身支持 Websockets?

如果浏览器不支持它，什么是可能的优雅回退?

有没有可以提供帮助的 polyfill?

问候，

推荐答案

目前有哪些浏览器原生支持 Websocket?

Which are the browsers that support Websockets natively currently as of today?

正如之前的答案所指出的那样.

As pointed out in previous answers.

见:

  • http://caniuse.com/websockets
  • http://html5please.com/#Websockets

如果浏览器不支持它，什么是可能的优雅回退?

If a browser does not support it, what is a possible graceful fallback?

如果您的实时网络服务器仅支持 WebSockets，那么下一个最佳选择是使用 web-socket-js 它是一个基于 Flash 的 polyfill，它创建了一个 WebSocket 对象，该对象以与原生 WebSocket 对象相同的方式进行交互.

If your realtime web server only supports WebSockets then the next best option is to use web-socket-js it's a Flash-based polyfill which creates a WebSocket object which an be interacted with in the same ways as the native WebSocket object.

其他回退 - 需要由您的实时网络服务器支持并由它提供的 JavaScript 客户端库管理 - 是从最好到最坏的顺序:

Additional fallbacks - which need to be supported by your realtime web server and managed by the JavaScript client library it provides - are, ordered best to worst:

  1. EventSource - 来自服务器 -> 客户端的单个流连接.可以使用第二个 HTTP 请求实现双向通信.
  2. HTTP 流 - 使用两个连接来模拟双向连接.消息通过持久的流"连接服务器推送" -> 客户端
  3. HTTP 长轮询 - 也使用两个连接.但是，服务器 -> 客户端已打开，一直保持到新消息可用或发生超时.然后关闭它，如果设置了任何数据，它会在响应中传递.
  4. 标准 HTTP 轮询 - 效率低得多，而且可能会浪费大量请求.但是，如果您的应用程序提供的更新没有那么频繁地发生，并且数据在轮询请求之间的时间是否过时"也无关紧要，那么这可能是一个可以接受的解决方案.这里没有推".
  1. EventSource - A single streaming connection from server -> client. Bi-directional communication can be achieved using a second HTTP request.
  2. HTTP Streaming - uses two connections to simulate bi-directional connectivity. Messages are 'pushed' over a persistent 'streaming' connection server -> client
  3. HTTP Long-Polling - also uses two connections. However, the server -> client is opened, held until either a new message is available or a timeout occurs. It's then closed and if any data has been set it is delivered in the response.
  4. Standard HTTP polling - much less efficient and due to the large amount of potentially wasted requests. However, if the updates your app delivers don't happen all that frequently and it doesn't matter if data is 'out of date' for the time between polling requests, then this may be an acceptable solution. There is no 'push' here.

选项 1. 和 2. 可以通过多种不同的方式实现，具体取决于网络浏览器.这就是使他们成为黑客"的原因.我们现在有用于双向通信的 WebSocket 和 EventSource(服务器发送的事件)，它与 HTTP Streaming 非常相似，并且具有支持自动重新连接的额外好处.

Options 1. and 2. can be achieved in numerous different ways depending on the web browser. This is what makes them 'hacks'. We now have WebSocket for bi-directional communication and EventSource (server-sent events) which is very similar to HTTP Streaming with the added benefit of it supporting auto-reconnection.

是否有 polyfill 可以提供帮助?

Is there a polyfill that can help?

是的，请参阅前面提到的 web-socket-js.

Yes, see web-socket-js as previously mentioned.

对于 PHP，您的最佳选择是 Ratchet.它不在 Apache 中运行，因此不会受到相同的限制 - 它没有考虑到请求/响应范式.

For PHP your best choice is Ratchet. It doesn't run within Apache so it doesn't suffer from the same limitations - it wasn't built with the Request/Response paradigm in mind.

我现在看到的最常用的解决方案是:

The most commonly used solutions I see right now are:

  • Faye - node.js 和 ruby​​
  • socket.io - node.js 和适用于各种其他语言的端口
  • SockJS - erlang、node.js、ruby
  • SignalR - .NET
  • XSockets - .NET
  • Faye - node.js and ruby
  • socket.io - node.js and ports available for various other languages
  • SockJS - erlang, node.js, ruby
  • SignalR - .NET
  • XSockets - .NET

对于其他选项 - 包括托管服务，如 Pusher(我在撰写本文时为其工作) - 看看这个 实时网络技术指南，我正在维护(并接受对其的贡献).

For other options - including hosted services like Pusher (who I work for at the time of writing) - take a look at this realtime web tech guide which I'm maintaining (and accepting contributions towards).

相关文章