客户端通过脚本和服务器保持请求，每次请求刷新一个时间，服务器检查这个时间，如果发现时间超过预定，则可以判断该客户端浏览器已关闭。然后对进行相应得操作。如果你想知道是那个客户端浏览器关闭，可以把会话绑定到轮询对象中。长连接不是所有服务器都支持得，这种方式，比你的现实多了。
我的个人看法。
我首先同意这几种做法，它们也能实现这个需求，他们都通过客户端的轮询，更新服务器的最后访问时间，让服务器检测超时。我来谈谈我对这2种做法的理解

1 服务器端如何进行超时判断，启动一个后台线程进行定时轮询？循环检查每个session是否超过了间隔？
2 如果用线程，那么服务器端判断的间隔或者周期是多少，1秒，10秒，20秒..
3 如果大家都用10秒间隔，客户也能承受这个间隔，我们来看结果
  1) 我还不知道哪个服务器不支持长连接，如果你下载100G的文件，难道不行吗？中间非得断开n次？
  2) 你的每个客户端需要在10秒之内，发出新的请求，让服务器进行响应，我的则不需要
  3) 轮询操作要注意并发问题，也就是同步访问问题，你的数据得保存在application或者其它自定义全局数据结构里面，而多线程不存在这个问题
  4) 轮询属于单线程，统一处理，而长连接为多线程
  5) 客户端每次请求刷新后断开连接，可以减少占用服务器的连接数，提高并发数，但相对增加了每次请求的负担。
4 关键区别：如果要求在0.1秒内必须做出精确反应，发现连接断开要马上进行处理，我想我的多线程方案会更有效，因为浏览器很难在那么短的时间内发出10次请求的。而长连接则只需要减少发送数据的间隔就可以。

 

总结：
需求决定应用。
系统要求的判断超时的时间越短，长连接的方案优势越大，时间越长，轮询的可用性越强。具体需要根据应用做抉择。
对于一般的B/S判断，大部分聊天室和在线人数统计都是临行轮询操作的。一个人离开聊天室，不会立即更新在线列表，但IM程序(QQ/MSN)等则会相对非常精确的更新。

如果需要精确判断，我想长连接是我能想到的解决方案之一；另一个就是客户端插件，比如applet,Flash，ActiveX等使用socket进行了，不过机制和长连接没有区别。
两点小建议

1。 做到0.1反应可以，但做到0.1秒“精确”反应不行。TCP协议虽然是长连接，但没规定CS中一端掉线时，另一端迅速可知（否则也不会有后来TCP不太标准的“心跳”协议），这关乎中间网络硬件的支持。现实中也是如此。 当然，我不知道版主这篇文章的可能还有上文，所以不知这系统准备运行在什么网上。

2。 文章既然提到“前面页面”。看来这个系统就不应该是QQ或游戏服务器了，后台很可能就是运行一个普通的WEB服务器，IIS或APACHE。。它们的设计目标明确，所以都会有最大连接数限制。表面上，数千人同时在线，没关系，由于采用短连接，同一时间的并发数通常够用。但如果就算客户不活动，连接也要保持，那这个数目就很快有个死限了。
就算游戏或IM工具，典型如QQ，也不敢用TCP来长连接服务器。

所以我的总结是，如果准备做一个最多就1，2百人左右同时上线（而不是同时活动），那可以采用楼主的方法。如果人数一涨，则包括flash, activeX, socket ...统统不可能用长连接，宁可用UDP去碰。