这几天业务和web在线聊天搭上了一点关系,就简单了解了一下web在线聊天
在线聊天需要时时通信,而http又是短连接,
首先想到的是ajax脉动请求
这里问题就出现了!如果访问量一旦提高起来,那么服务器的承载就会加速增长。
比如:如果要好的体验那么脉动频越小越好(一般大于1秒),控制在5秒是比较合理的!
但是这样就是一个客户端每5秒就会向服务器发起请求。这样的话会消耗很多的服务器资源。想一想1000人同时在线,服务器会是什么样的结果。
于是我又想啊,有没有其他的办法哪?
想了想,似乎可以建立长连接,来解决这个问题
我们看看http协议:
HTTP是无状态的
也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话
HTTP1.1和HTTP1.0相比较而言,最大的区别就是增加了持久连接支持(貌似最新的http1.0 可以显示的指定 keep-alive),但还是无状态的,或者说是不可以信任的。
如果浏览器或者服务器在其头信息加入了这行代码
Connection:keep-alive
TCP连接在发送后将仍然保持打开状态,于是,浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了带宽。
当然这个长连接也是有限制的!这个取决于客户端浏览器和web服务器keep-alive较低的值。如:客户端的超时值是两分钟,而Web 服务器的超时值是一分钟,则最大超时值是一分钟。
总结下来,这样似乎长连接比短连接更适合用于实现web在线聊天。
第一:长连接的聊天是实时,不存在脉动的说法。用户体验过可定最好。
第二:服务器可以主动向客户端浏————览器推送消息。而这一点是短连接的天生缺陷。
但事实是这样的吗?
我们回归短连接的本质:浏览器采用短连接的方式最重要的原因是节省服务器带宽资源,因为它的基本思想是,客户需要什么我给什么,客户什么时候需要,我什么时候给,而不用保持连接,消耗资源。
所以,再以1000人同时在线为例。使用短连接这样的人数其实很少,对服务器资源占用也少,因为这1000人中正在使用服务器资源(连接中)的人少。服务器只需要几十个或者一两百个线程就可以完成这样的负荷。
但是如果是长连接,那么1000人在线,我就得开1000个线程(应为你的为每个在线人保持连接),可以想象这是什么概念。
所以说长连接有着资源消耗严重的问题。
所以具体采用那种方式,或者两中方式都采用,这个就要根据自己业务需求来定了。
最后,这个纯是个人浅见。欢迎各位程序猿拍砖。