HTML5简单聊天室
我想做的是一个简单的 HTML5 聊天室，没什么花哨的，一旦有人说了什么，它就会将其发送给当前连接到服务器的每个人，仅此而已。没有存储，没有什么复杂的。不过，它必须灵活，我的网站应该能够根据需要自动创建单独的聊天室。我看过很多演示和示例，但它们都要求我安装 node.js 或类似的需要终端访问的东西（我没有）。我目前正在其中一个免费网站主机上运行，它为您提供 ftp 客户端、mysql 数据库、一些 php 支持，仅此而已。有什么办法可以做到这一点吗？或者也许我遗漏了一些东西，有没有办法在此类服务器上安装软件包？也许有人知道一种获得终端访问权限的方法？任何形式的帮助将不胜感激，谢谢。
What I would like to do is a simple HTML5 chatroom, nothing fancy, once someone says something it sends it out to everyone currently connected to the server and that's it. No storage, nothing complex. It would have to be flexible, though, my site should be able to automatically create separate chatrooms as they're needed. I've seen a lot of demos and examples but all of them require me to install node.js or something similar that requires terminal access (which I do not have). I'm currently running on one of those free website hosts, that give you an ftp client, a mysql database, some php support and that's it. Is there any way of doing this? Or perhaps I'm missing something, is there a way to install packages on these kind of servers? Perhaps someone knows a way to obtain terminal access? Any kind of help would be greatly appreciated, thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
去过那里做过那件事。做到正确并不是一件小事。
我认为您必须做出一个重要的决定：您希望聊天真正是即时的，还是可以延迟 2 秒直到每个人都看到新消息。
如果延迟没问题，您实际上可以每 2 秒轮询一次服务器以查看是否有新消息可用。没有人喜欢拖延，但根据你想做什么，这可能并没有那么糟糕。然后，服务器将检查每个请求的数据库/文件并返回更新。这是一个非常简单的解决方案并且有效。 （如果您认为每 2 秒轮询一次会浪费资源并对服务器造成不必要的负载……请继续阅读，替代方案可能会更糟。）
完全即时的聊天要求服务器可以立即向客户端发送新数据，而无需等待客户索取。 HTTP 本身并不支持此功能，如果您不想使用任何 Flash/Java，我知道执行此操作的唯一方法是使用 comet 请求。这些请求（通常是 AJAX）会故意在服务器上挂起一段时间，然后在需要发送到客户端的新数据可用时或发生超时时精确返回。每次 comet 请求返回时，客户端都会处理数据并立即发出另一个 comet 请求，该请求将再次挂起，直到有新数据可用。我相信每个纯 HTML/JS 聊天网站都是这样做的（Omegle、Facebook 等）。
现在，这是简单的部分。但是如何在服务器上实现这一点呢？让我们看一下这种情况：您有 10 个用户在聊天，这意味着 10 个客户端每个客户端都有一个挂起的 comet 请求等待新数据。其中一名用户在聊天中写入了一些内容，这会导致向服务器发出额外的请求来发布文本。如何使服务器上 PHP 脚本的这一次执行导致其他 10 次执行停止等待并返回新数据？ （您可以用 Perl 或任何其他东西来代替 PHP。）您将需要一些允许多个脚本执行相互通信的东西。 （或者 PHP 代码本身可能每秒轮询数据库，但这又会带来延迟。）在这些脚本语言中，任何形式的进程间通信 (IPC) 都是困难的，尤其是您不知道该脚本的模型类型是什么。 Web 服务器用来执行它们。例如，Apache 可以为每个请求分配一个进程，或者为每个请求分配一个线程，或者两者的混合。但也许你的主机使用的是IIS，或者其他什么，所以在这种情况下很难进行IPC。我最终做的是用 PHP 创建一个自己的始终运行的服务器组件，其任务是在 PHP 脚本的不同执行之间传递消息。是的，这需要 shell 访问权限。所有 PHP 执行都将通过套接字连接到该服务器组件，并且可以传递消息。虽然很难做到正确，但最终效果很好。
不幸的是，comet 请求可能会非常浪费内存和 CPU 周期。我的 Apache 服务器有一个每个 PHP 执行一个进程的模型。因此，当聊天中有 100 人时，这意味着任何时候都有 100 个待处理的 comet 请求，这意味着有 100 个 Apache 进程正在运行。即使新的 Apache 进程仅使用 10MB，总计也将达到 1GB！这是大量的内存，而这些进程只是在等待某些事情发生。这段聊天非常消耗内存。此外，这样的聊天确实会产生大量请求：每当有人在聊天中说些什么时，所有 100 个请求都会返回，之后您将立即收到 100 个新请求。聊天中的用户数量增加一倍通常意味着请求数量增加四倍。你真的希望这一切变得敏捷。 Apache 在处理这个问题上并不总是那么有效。有一些网络服务器软件专门针对 comet 请求进行了调整，并且可以很好地扩展，但这又需要比您拥有更多的服务器访问权限。
因此，为了完整起见，我的故事到此结束：与此同时，我放弃了所有 PHP 并完全重写了聊天内容。在我看来，Apache 和 PHP 都非常不适合这种任务。现在有一个 Java 服务器组件集成了高效的多线程 HTTP 服务器。我对它进行了压力测试，它的表现非常好：连接 500 个垃圾邮件客户端时，CPU 使用率不会超过 15%，内存使用率保持在 150MB。这比我预期的要好得多。与 Apache/PHP 相比，它的响应能力也提高了很多。最终结果可以在 http://www.dark-chat.info/ 查看目前由于各种原因有些死了。随着我有更多的时间，这种情况有望改变。
好吧，我知道这对您没有多大帮助，因为您受到托管提供商的很大限制。如果没有 shell 访问权限，您能做的就只有这么多了。如果您可以接受 2 秒的延迟（或设为 1 秒），并且您不希望同时有超过 20 个用户，那么您实际上可以直接进行轮询。有一些方法可以对此进行优化，例如，活跃用户可以获得 1 秒的民意调查，而那些很少写东西的用户可以获得 5 秒的民意调查。
也就是说，也许您也可以寻找某种托管解决方案。我确信您可以通过 iframe 嵌入一些聊天内容。
好吧，这比我想要的要长得多。但我希望它能帮助一些人。 :)
Been there done that. It's not trivial to get right.
I think there's one important decision that you have to make: Do you want the chat to be really instantaneous, or is it ok to get like 2 second delays until everyone sees new messages.
If delays are ok, you could really just poll the server every 2 seconds to see if new messages are available. Nobody likes delays, but depending on what you want to do, it might not be all that bad. The server would then check a database/file on every request and return updates. It's a very simple solution and it works. (And if you think polling every 2 seconds is wasting resources and an unnecessary load on the server... read on, the alternative might be worse.)
A fully instantaneous chat requires that the server can immediately send new data to the clients, without waiting for the clients to ask for it. HTTP does not natively support this and if you don't want to use any Flash/Java, the only way I know to do this is using comet requests. These are requests (usually AJAX) that will deliberately hang for a while on the server and will then return precisely at the moment when new data is available that needs to be sent to the client, or when a timeout occurs. Every time a comet request returns, the client processes the data and immediately makes another comet request that will again hang until new data is available. I believe every chat website in pure HTML/JS does it this way (Omegle, Facebook, many others).
Now, this was the easy part. But how do you implement this on the server? Let's look at this situation: You have 10 users in the chat, that means 10 clients that will each have a hanging comet request that waits for new data. One of the users writes something into the chat and that causes an additional request to the server to post the text. How do you make this one execution of a PHP script on the server cause the other 10 executions to stop waiting and return the new data? (You can substitue PHP with Perl, or anything.) You will need something that allows several executions of scripts to talk to each other. (Or the PHP code could itself be polling a database every second, but that again introduces delays.) Any form of inter-process communication (IPC) is difficult in those scripting languages, especially that you don't know what kind of model the web server uses to execute them. Apache for example can have a process for each request, or a thread for each request, or a mix of both. But maybe your hosting uses IIS, or something else, so it's difficult to do IPC in this situation. What I ended up doing was to create an own server component in PHP that was running all the time, its task was to pass messages between different executions of PHP scripts. And yes, this requires shell access. All PHP executions would connect to that server component via sockets and messages could be passed around. It was tricky to get right, but at the end it worked quite well.
Unfortunately, comet requests can be very wasteful with memory and CPU cycles. My Apache server had a process-per-PHP-execution model. So when there were 100 people in the chat, that meant there were 100 pending comet requests at any time, meaning there were 100 Apache processes running. And even if a fresh Apache process uses only 10MB, that makes a total of 1GB! That's a lot of memory and those processes were nothing but waiting for something to happen. The chat was an incredible memory hog. Also, such a chat generates really a lot of requests: Every time someone says something in the chat, all 100 requests return and you will get 100 new requests right after that. Twice as many users in the chat usually means four times as many requests. And you'd really want this to be snappy. Apache wasn't always so efficient in handling this. There is some web server software around that is specially tuned toward comet requests and that will scale very well, but that again requires more access to the server than you have.
So for completeness, here's the end of my story: In the meantime I ditched all the PHP and entirely rewrote the chat. In my opinion, Apache as well as PHP is highly unsuitable for this kind of task. There's now a single Java server component that integrates an efficient multi-threaded HTTP server. I have stress tested it and it behaves very well: With 500 spamming clients connected, CPU usage doesn't go over 15% and memory usage stays at 150MB. That's much better than I ever expected. Its responsiveness has improved a lot too, compared to Apache/PHP. The end result can be viewed at http://www.dark-chat.info/ Although the chat is currently somewhat dead for various reasons. That will hopefully change as I get more time for it.
Well, I know this isn't helping you much at all, since you're quite restricted by your hosting provider. And without shell access, there's really only so much you can do. If you're ok with a 2 second delay (or make it 1 second) and you don't expect more than 20 users at the same time, you could really just go with the polling. There are ways to optimize this a bit, for example, active users can get 1 second polls and those that rarely write something get 5 second polls.
That said, maybe you could also look around for some sort of hosted solution. I'm sure there are chats around that you can embed via iframes.
Ok, this got much longer than I wanted to. But I hope it helps some people. :)
无需使用任何插件（Flash、Java 等）即可实现聊天的唯一方法是 WebSocket。 （在特定时间间隔连接服务器以检查新消息是实现此目的的一种方法，但我认为它太“肮脏”...）但是，我认为 Web 托管站点可能不提供 WebSocket 服务器。我建议您通过使用 Java/Flash 进行连接来制作 IRC 客户端。如果你想使用HTML/JS来制作UI，请在Flash中使用
ExternalInterface或在Java中使用JSObject来实现插件和JS之间的通信。The only way you can implement chatting without using any plugins (Flash, Java, ...) is WebSocket. (Connecting server for a specific interval to check a new message is a way to implement this, but I think it's too 'dirty'...) However, I think the web hosting site might not provide WebSocket server. I suggest you to make a IRC client by doing connection using Java/Flash. If you want to use HTML/JS to make UI, use
ExternalInterfacein Flash orJSObjectin Java to communicate between plugin and JS.我不能说太多，但目前经常使用的技术是 彗星。
在 Comet 中，您向服务器打开一个请求（例如，使用 AJAX 之类的东西），但不关闭它。您只需将其保持打开状态，但仅在需要时将数据从服务器发送到客户端。这项技术还需要一些特殊的服务器，但我想如果你谷歌一下，你肯定会找到一种用 PHP 实现 Comet 的方法（但我认为 Python 对于这样的事情会更好）......
希望这个给你一些想法，如何解决你的问题:)
I can't say much about it, but the a currently often used technology for things like this is comet.
In Comet you open a request to the server (eg. with something like AJAX), but you don't close it. You just keep it open, but you only send data from the server to the client if needed. This technology also needs some special servers for that, but I think if you Google a bit around you'll sure find a way to implement Comet with PHP (but I think that Python would be better for something like this)...
Hope this gives you some idea, how to solve your problem :)
HTML 5 有一个很酷的新功能，称为 Web Sockets，它允许客户端和服务器之间真正的双向通信。但是，您不会找到任何便宜的共享托管计划来允许您托管自己的 Web Socket 服务器。
您可以通过“老式”方式来伪造双向通信：使用 AJAX。基本上，客户端 JavaScript 每隔几秒就会向数据库发出一个请求，以检查是否有任何新的聊天消息要显示。发布新消息只需将该消息发布到服务器即可。
Comet 只是一种奇特的（更高效的服务器端）方法来做到这一点。
HTML 5 has a cool new feature called Web Sockets, which allow true two-way communication between the client and the server. However, you won't find any cheap, shared hosting plans that will allow you to host your own Web Socket server.
You can fake the two-way communication, by doing it the "old-fashioned" way: using AJAX. Basically the client side JavaScript makes a request to the database every few seconds to check if there are any new chat messages to display. To post a new message is simply posting that message to the server.
Comet is just a fancy (more efficient, server-side) way to do this.
正如许多人提到的，实现此目的的流行方法是使用 ajax、comet（或其他一些长轮询机制）或 WebSocket。
我的建议是使用 WebSockets，但正如前面提到的，您的主机可能不允许您设置套接字服务器。
如果您遇到这种情况，我建议使用服务器发送事件，另一个 HTML5 解决方案，但已被 WebSockets 掩盖。
它将允许您将事件发送到浏览器，并且仍然可以轻松地在 PHP 中实现。
As many people have mentioned, the popular method to accomplish this is by using ajax, comet (or some other long-polling mechanism), or WebSockets.
My suggestion is to use WebSockets, but as it has been mentioned, your host might not allow you to set up a socket server.
If this is the situation you find yourself in, I recommend the use of Server Sent Events, another HTML5 solution which has been overshadowed by WebSockets.
It will allow you the ability to send events to the browser and still make it easy to implement in PHP.