现在在做一个聊天室的应用,本来想和网页版qq一样,发送信息不需要速度限制,后来考虑到根本不行。

人家腾讯的是什么服务器啊,我自己的是什么渣渣服务器啊…大量并发的时候,肯定各种问题,所以必须限制信息发送频率。

怎么实现?(其实应该前后端均实现限制,但是暂时只做前端限制)

一、流程实现

首先提供一个前端限制的思路:

这里只是用js做了限制,还是有局限性的。

(1)刷新客户端可绕过

因为是纯客户端去验证发送速度,如果你刷新页面,js就会重新加载,变量将会重置,这个时候你又可以随意发送了。一旦到限制,你就刷新页面,再次发送,再次刷新页面…

这个东西写个脚本随便都可以实现…有个很严重的问题,就是如果有这种家伙,页面的聊天内容就会疯狂刷新,严重影响正常用户的聊天。而且服务器负担过重的问题还是没有解决…

(2)内容长度限制

这个问题是偶然发现的。不知道qq有没有限制一次发送内容长度,就算你发送速度慢,但是你发送的内容多(而且无意义),还是会严重影响聊天。

置于这个东西,实现就更加简单了…也是会严重影响服务器性能…

(3)如何解决以上问题?(可能性探讨)

1.聊天室的局限性

首先,聊天室这个东西始终还是比较落后的产物。因为现在的通信基本上都是qq那种形式,单对单和单对群…

如果有这种搞破坏的人,首先可以通过踢人的方式来解决,就是把这个判断的过程交给了用户去处理,有效解决了服务器的负担。

2.服务端限制

那么如果非要用技术手段在服务器端解决这种问题(靠),那么该怎么办?

刚才说了,把参数校验放在客户端是不行的,所以我们就把参数放在服务端。

3.记录

首先是把发送次数也放到服务端记录,然后进行按时清零操作,如果次数超过限制,那么当用户发送时,ajax回显显示次数超过,禁止发送,直到惩罚时间超过,然后解禁,才能再次发送信息。

这种方法基本上可以实现我们的需要,不需要数据库,只需要考虑服务器端对发送次数的统计(累加),发送次数和惩罚的清空,还有不同情况下采取的操作就可以了(次数没超过限制?那么通过if判断正常发送信息次数超过限制?通不过if判断进入禁止发送模式)

问题是:其实还是加重了服务器的负担。而且不好做限制。

假如服务器做限制你2秒只能发10条,那么我写个脚本只发9条不就好了吗…所以这个限制存在争议。

限制条数多了起不到限制的效果,限制条数少了可能影响正常用户的使用…

惩罚时间也有争议,首先不能一视同仁,发的多的基本上可以认为是脚本和攻击性行为,应当给予长时间惩罚。而一般情况下,用户输入过快,则应该给予很低的惩罚(5秒左右?有待商榷)。

但是这个规则是可以被识破的,脚本依然可以是伪装成用户发送的频率。这个方法毛病实在是太多了,而且复杂程度超乎想象,多到不应该去使用。

4.监测行为

加强一下,检测的不是发送次数,而是发送行为。

  1. 首先重复内容比较可疑,你需要弄一个算法去检测小范围变动的内容。
  2. 关键字也可疑,你需要一个算法去干预部分关键字。
  3. 那种压线式的长期保持同一频率发送的也可疑,你需要一个算法去检测这种频率接近的发送行为。
  4. ………….

首先这种方法是可行的,问题是难度大,你有这么多种行为可以检测,等你发明了一系列牛逼算法去规范限制用户行为,你早就把你的聊天项目从聊天室无限制性改成qq式的用户自己干预型了…

其次,这么多算法将给服务器带来巨大压力。你永远找不到一个又快又强大耗费资源又小的算法,你只能在众多限制中去寻找一个平衡点,让这个算法可以接受。

最后,因为复杂所以慢,容易影响用户体验。

(4)我的一些暂时性的解决方案

关于字数限制问题,可以通过size()等方法去获取内容的长度,然后直接在客户端就加上限制,当然服务端也要加上相关限制,超过长度(明显的攻击行为)就弃置请求,次数多了就ban账号。

但是,必须考虑到极端情况。如果用户想要转发一篇文章,刚好就超过了这个限制,那么这个请求是不是就发不出去了?

如果用户又不知道存在字数限制,文章又发不出去,他会怎么做?

是尝试去删减字数吗?不是,如果是我,我就会换用qq来发。你满足不了我的需求,我就走人(更何况这个需求本就应该实现,这么简单)。

实际上,我们要考虑的就是找这个平衡点。内容设置较大将影响服务器性能,影响正常用户的聊天。内容设置较小将影响正常用户的某些功能。

以上各种各样的问题,难以全部通过服务器去解决。所以我们需要更换聊天模式,更换软件的功能,把限制权交给用户,将用户变成上帝,让他们去做判断。

你是在攻击我,你影响了我的功能,我就删了你。你要骚扰我,我就把你拉黑。

这样问题就被转化成比较可以接受的状态了。(也就变成了山寨版的qq了)

二、总结一下

所以说,这种无限制的聊天室成本太高,要出大问题。只有qq式的聊天模式才有出路。

我目前只是实现了聊天室,就遇到了各种麻烦的问题,从根本上来说就是设计的太差了,从根本上就出了问题。

幸好这只是一个练手的项目,如果真的当成产品去实现,就亏大了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注