来谈谈Server Push吧

zhuam在那个简要分析DWR的帖子中谈到叻server push：

http://forum.iteye.com/viewtopic.php?t=19004

并且给出叻一个链接：

http://groups.google.com/group/xmpp/browse_thread/thread/c3c07438a2eccaf5/71170c6b3cf97180#71170c6b3cf97180

其中谈到叻GTalk web。我本人既没用过gmail也没哟用过gtalk，但是server push这个话题引起叻我狠大兴趣，特此新开一贴，想跟大家讨论讨论。

我们都知道，涉及到网络双方通讯的程序，必然会有一个server一个client。从谁是消息的发起者这个角度看，通讯模型分为server-push和client-pull两种。

server-push的好处是及时性好，所以大量被应用在要求及时性的软件上，比如IM、网游、IRC聊天等。而client-pull的好处是对服务器压力小，所有TCP/IP连接都是短暂的，服务规模大，所以大量被应用在大流量应用上，如WEB、Email。

本来呢，server-push和client-pull是井水不凡河水，两者共同生存于网络世界相安无事。突然有一天，有好事者试图将server-push概念引入WEB应用中，于是引发叻一系列的讨论。以下我们只讨论WEB。

在我的记忆力，最初的server-push应用是IE4.0的“频道”，这是典型的信息推送。后来被证明这个东西是失败的，具体失败原因似乎有狠多，不想多说，只说一点，那就是不太符合用户习惯。

在这之后，聊天室狠流行，于是狠多人都在研究怎么能让聊天室最快地做到消息刷新实时性。在这里，分为两派，一派是继续走client-pull概念，方法就是用一个iframe定时去刷服务器上的数据，只不过刷新的间隔狠短（1秒-5秒左右），靠服务器网络的快速响应达到接近实时。而另外一派，就是走server-push概念，方法就是用户连上网后，连接不断，就好像你下载一个狠大的文件一样，永远都下载不完，服务器总有新东西冒出来。在这之后，这个方法被证明为是理论上可行的，也是我们能想到的在web上实现server-push的唯一方法。

用简单的jsp代码模拟一下，大概就是这样：

<%
int i = 1;
while(i>0); {
	out.println(i);;
	out.println("<br/>");;
	out.flush();;

	try {
	    Thread.currentThread();.sleep(500*i);;
	} catch (InterruptedException e); {
	    e.printStackTrace();;
	}

	++i;
	if(i>10); i = 1;
}
%>

但是这样做之后，有一个非常重要的问题，那就是如果用户狠多，每个人连上来都是一个长连接，服务器会吃不消。我们知道，一般的服务器，操作系统内核最多只支持65535个socket，实际上受限于网络带宽、CPU内存以及I/O等处理能力，最多最多大概也就1-2万个socket能够同时处理。这一点，跟网络游戏狠像。好一点的网游，一台服务器能够接受4000个以上的连接同时处理，已经是狠不错叻。

对于中小规模的WEB而言，没什么大不了的。但是，我们做个比方，假设一台服务器，没有server-push这样的东西，它每秒钟能够接收5000个请求，那么10秒钟之内，就能接收50000个请求。在极端情况下，我们假设所有这些请求都来自不同的人，那么我们就可以大概地说，这台服务器能撑住5万个人去浏览页面，没什么大问题。但是如果是server-push，假如有3000个人在长连接上，基本上就没有余量给其它人叻。再加上WEB应用本身又要去不断地刷新后台数据，所以整个应用给人的表现就是非常吃服务器资源。

后来聊天室不火叻，server-push概念就慢慢被人们淡忘叻。可以说，不论是applet、ActiveX还是上面的那种不间断HTTP连接，都无法使服务器达到传统client-pull的那种服务规模。

直到现在，google的出现，或者具体点说，gtalk的出现，又将server-push这个概念拉回叻人们的视野中。我不知道是不是google解决叻服务规模的问题，所以才敢大胆地在gtalk上应用server-push，或者是不是google实现叻某种用户与用户之间建立P2P连接的方法，才能让gtalk的响应如此之快？

大家讨论讨论

google的服务器太多了，而且在服务器分布式处理方面非常领先，所以才敢这么干。

我最近用  JSP、JS ＋ Smack + DWR 实现了一个基于Jabber 的Web Chat ，后来就在想那个地方有问题，Web Page不断的通过定时刷新来获取Message总是感觉很猥琐，且效率也不会很高，这不想到了Server Push 技术。

我实现 Java Server Push 就是通过延长HTTP Request 连接，让他变成一个持久的Socket 连接，这样的缺点是会占用过多的端口，但不要忘了 Jabber 就是采用TCP 连接，我也只不过是自己实现一个特殊的HTTP SERVER 来伪装Request 让他变成持久的 Connection 又未尝不好。

AJAX 、Server Push 这在我看来 Server Push 更好，因为Ajax 的Web Chat 我已经实现，我这两天也是在询问自己不用Server Push 的理由。

最后就是MSN 也是TCP 连接啊，通常一台机器我们能支持1w -1.8w的连接处理， 只是我们需要对Server 端做集群，我已经实现了一个JbossCache 方案的Server 集群.

AJAX与Server Push并不冲突。只是一旦应用变为Server Push后，它就与传统C/S模型比较接近叻，对服务器的要求会更高。

你说的JbossCache方案的Server集群是什么意思？能详细说说吗？

其实我的意思是说TCP 的连接，对我当前的 Jabber Server 来说是没有问题的，因为我们也已经用 JbossCache 做了Server 端的集群， B/S or C/S 对我来说我从来都不关心，我关心的是能否达到我的要求，专业上的术语又何必在乎哩！

希望大家都谈论一些关于 Server push 的缺点.. 谢谢！

我觉得用户数压力不在协议栈的连接数限制， 而在于虚拟机（应用）本身的效率和资源消耗。

另外Server push也并不一定非用TCP吧？ UDP有何不妥？只是需要开发客户端插件。

觉得大家讨论问题过于理论化，喜欢讨论一个很大的数字，但实际需求大吗？ 看看如此火爆的网游，有几个服务器端配置很惊人的？试过一个传奇旧版本服务器，也就是一台Win2000机器，内存加到2G，支持到上千客户端没有问题，大家的项目有很多大过这个需求数目的吗？

除叻tcp连接数的限制，那就是只能被动地收，主动发还是需要建立新的连接。



两者都是瓶颈，但是就虚拟机本身效率来说，SOCKET数的限制是硬的。这个问题在没有server-push的情况下没有体现，但是对于一个用户数狠多的网站，加入server-push后，实际上就相当于资源被挤占叻（因为连接不断），所以可同时提供服务的用户量就少叻狠多。



我上面说叻，只讨论WEB下的Server-push。不然普通的客户端还server-push啥。



你做一个网站，然后跟人说，我这个网站是server-push的，狠酷，但是只能支撑几千个用户访问。。。

不知道你做过网游行业没有。我告诉你，支持网游的网站都是重负载的，一秒钟内的请求少说有1万个。最恐怖的就是游戏全区停机维护的时候，那个时候，所有玩家都突然玩不了游戏，全部都去网站上看发生叻什么事。。。这个并发量，你想像一下吧。

年前试过一下IBM WorkPlace，找了个合作伙伴过来装，当然，机器很烂，Dell的两路志强1.8G，把内存加到4G。装起来之后让他们做一下压力测试，就是测它缺省的网站，那哥们找了个测试工具，象录制宏一样点了一些页面，只用一台单机测。觉得很奇怪，那个数字小到不太让人相信，拐点大概在200个并发左右，250时的响应时间不少于30s。晕倒啊，请教一下到底怎么回事啊这是，是不是测得太业余啊？ 应该的数值在多少？

后来听合作伙伴TCL集团内部也用着呢，两台RS6000，注册用户2万左右吧，我问日常并发多少，说才几十，而且说目前正在做tuning，解决性能问题。咣当！就把我吓跑了，至今觉得这些大公司都在忽悠人。

是不是我错了？请高手门用劲批！

楼上，你们卖的系统并发数给客户是多少？说来听下？

我说网游正是想说那么重的负载连接数都没有用完，瓶颈不在协议栈嘛，你告诉我的和这个观点有矛盾吗？ 各位DX，你们经常做的项目单台在线用户超过1000的有多少？

我们不卖系统，自己开发自己用。

我觉得你没理解我本文的意思。你所说的并发，前提是什么？是客户连上来，请求处理，然后连接断开！但是web-based server-push是什么？是客户连上来，不管有没有请求，连接一直不断，而且还在不断地轮番查询用户是否有新的数据。这对服务器的要求是非常高的，否则撑不了稍微大一点的并发量。

举个例子，一台机器，平时在使用中状态的TCP连接就有6000个以上，但是好在请求处理之后这些旧的连接会断开，新的连接会继续得到请求。但是如果是server-push呢？旧的连接不断，新的又来，最终要么是机器撑不住，要么是协议栈不够用。

网游为什么负载连接数没有用完？那是因为数据传输量太大，机器本身和后台数据库都撑不住。但是基于WEB的server-push，平时大部分时间是没有数据量的（想象一下数据库连接池保持的数据库连接）。所以这个时候需要的不是别的，就是机器，机器越多，越能支撑更多的用户，根本原因就是协议栈本身的限制。

我们可以试想一下这样的情况，如果本身操作系统对socket数没有限制，那么我们就可以肆无忌惮地压榨一台机器，让它接受更多的长连接，不用担心任何问题。也许这需要一个测试，我也只是提出一种可能性，那就是我们发现机器本身可以承受狠多连接，但是协议栈却把这种能力限制了。当然了，也有可能我说的这种情况不存在，即一般的服务器不可能达到把协议栈用完了的能力。

楼上的兄弟似乎不是搞互联网行业的吧？看你张口闭口都是“卖系统”、“做项目”的。

Hay hongliang !

我不知道您有没有写过Server 端Socket 程序，对于单台 Socket 连接的极限数那是我们无法更改的，作为 Server ，持久网络连接的确是很耗系统资源，但通常我们说他很耗资源那也包括了 Thread 内处理，不光说网络层的处理。

Server push  只是将 传统的B/S  转为 C/S ，作为我这样的特殊C/S系统来说，难道就因为保持了Tcp 连接，这就是个错误！