浅谈基于HTTP的长连接原理及应用

摘　要：基于HTTP的长连接，是一种通过长轮询方式实现“服务器推”的技术，它弥补了HTTP简单的请求应答模式的不足，极大地增强了程序的实时性和交互性。本文从其产生背景、实现原理、程序设计等方面进行了简要介绍，并且通过一个实际案例阐述了该技术的应用方法。

关键词：HTTP；B/S；长连接；轮询；长轮询；服务器推
　　基于HTTP的长连接（长轮询 long-polling）技术是在传统的HTTP请求应答原理基础上，通过适当变通，从而实现“服务器推”效果的一种解决方案，它的出现满足了在Web开发中日益提高的实时性和交互性的需求。本文将浅析该技术的实现原理和应用方法。
1. 产生的原因和背景
1.1. HTTP的请求应答模式
　　在互联网诞生初期，HTTP协议主要被设计用于分布式超媒体信息资源的定位和获取，它是建立在一种非常简单的通讯模型基础之上的，客户端（通常是浏览器）为得到服务器上的资源而向服务器发出一个请求，服务器则返回一个与请求的资源相对应的应答，这种简捷、快速的方式有利于节省网络带宽资源和减轻服务器负载。
1.2. HTTP机制的不足
　　HTTP是一种无状态的协议，无状态是指协议对于事务处理没有记忆能力，也就是服务器不保存客户端的任何信息和连接状态，每次请求都必须由客户端发起，服务器不能主动向客户端推送信息。
　　随着互联网的飞速发展和普及，越来越多传统的应用软件向B/S转型，例如即时通讯系统、电子行情报价系统、在线游戏等，这类应用的数据更新和传送具有很高的实时性，由于HTTP不提供对“服务器推”的有效支持，我们只能采取客户端定时刷新请求的方式来实现，使实时性大打折扣，如果刷新频率太快，又将给网络带来严重的拥堵和资源浪费。
　　以上分析表明，在B/S开发中实现“服务器推”在现实应用中确实存在很多需求，因为这个原因，目前也出现了很多解决方案，基本可以分为两类：一类是需要在浏览器中安装插件，基于套接口或远程调用的方式；一类是无需安装任何插件的纯浏览器环境下，基于HTTP长连接的方式。本文主要探讨第二种。
2. 实现原理
　　所谓长连接，就是要在客户端与服务器之间创建和保持稳定可靠的连接，其实它是一种很早就存在的技术，但是由于浏览器技术的发展比较缓慢，没有为这种机制的实现提供很好的支持。所以，要达到这种效果，需要客户端和服务器的程序共同配合来完成，通常的做法是，在服务器的程序中加入一个死循环，在循环中监测数据的变动，当发现新数据时，立即将其输出给浏览器并断开连接，浏览器在收到数据后，再次发起请求以进入下一个周期，这就是常说的长轮询（long-polling）方式，如下图所示，它通常包含以下几个关键过程：



　　
　　 图1：长连接原理图
2.1. 轮询的建立
　　建立轮询的过程很简单，浏览器发起请求后进入循环等待状态，此时由于服务器还未做出应答，所以HTTP也一直处于连接状态中。
2.2. 数据的推送
　　在循环过程中，服务器程序对数据变动进行监控，如发现更新，将该信息输出给浏览器，随即断开连接，完成应答过程，实现“服务器推”。
2.3. 轮询的终止
　　轮询可能在以下3种情况时终止：
2.3.1. 有新数据推送
　　当循环过程中服务器向浏览器推送信息后，应该主动结束程序运行从而让连接断开，这样浏览器才能及时收到数据。
2.3.2. 没有新数据推送
　　循环不能一直持续下去，应该设定一个最长时限，避免WEB服务器超时（Timeout），若一直没有新信息，服务器应主动向浏览器发送本次轮询无新信息的正常响应，并断开连接，这也被称为“心跳”信息。
2.3.3. 网络故障或异常
　　由于网络故障等因素造成的请求超时或出错也可能导致轮询的意外中断，此时浏览器将收到错误信息。
2.4. 轮询的重建
　　浏览器收到回复并进行相应处理后，应马上重新发起请求，开始一个新的轮询周期。
3. 程序设计
3.1. 客户端
　　在纯浏览器的情况下，可以采用JAVASCRIPT等前端脚本语言进行客户端的开发，为了让长连接的建立和等待过程不影响程序其他部分的正常运行，一般选择AJAX异步调用的方式，由AJAX向服务器建立长连接通道，等待应答，在收到回复后，将数据交给相应的函数处理。
3.2. 服务器端
    与普通WEB动态网站开发不同的是，要在程序中加入 while (1){…} 构建出死循环，在循环体内进行数据监测和跳出条件控制，下面给出一段用PHP编写的示例代码供参考：


   
图2：长轮询的PHP实现示例代码
3.3. 需要注意的问题
　　在进行长连接的程序设计时，要注意以下几点：
3.3.1.  服务器程序对轮询的可控性
　　由于轮询是用死循环的方式实现的，所以在算法上要保证程序对何时退出循环有完全的控制能力，避免进入死循环而耗尽服务器资源。
3.3.2. 合理选择“心跳”频率
　　从图1可以看出，长连接必须由客户端不停地进行请求来维持，所以在客户端和服务器间保持正常的“心跳”至为关键，参数POLLING_LIFE应小于WEB服务器的超时时间，一般建议在10～20秒左右。
3.3.3. 网络因素的影响
　　在实际应用时，从服务器做出应答，到下一次循环的建立，是有时间延迟的，延迟时间的长短受网络传输等多种因素影响，在这段时间内，长连接处于暂时断开的空档，如果恰好有数据在这段时间内发生变动，服务器是无法立即进行推送的，所以，在算法设计上要注意解决由于延迟可能造成的数据丢失问题。
3.3.4. 服务器的性能
　　在长连接应用中，服务器与每个客户端实例都保持一个持久的连接，这将消耗大量服务器资源，特别是在一些大型应用系统中更是如此，大量并发的长连接有可能导致新的请求被阻塞甚至系统崩溃，所以，在进行程序设计时应特别注意算法的优化和改进，必要时还需要考虑服务器的负载均衡和集群技术。
4. 测试案例
　　这里选取最为常见的网页聊天室为例，测试以HTTP长连接取代传统定时刷新页面的方式实现即时聊天的效果，测试中采用PHP编程语言。
4.1. 数据结构
　　在数据库中建立一张表 message 用于保存聊天内容，如下图所示：





　　在服务器端程序中声明2个全局变量 UserID和LastMsgID ，分别用于保存当前用户的编号以及该用户最近一次推送的聊天记录编号。
4.2. 测试方法
　　在服务器端实现两个主要接口，分别是：
4.2.1. 发言提交接口
　　调用方式：http://server/chatro ?to={发送对象ID}&msg={内容}
　　该接口接收新的聊天信息，并将其插入表message中，说话者默认为当前用户，即全局变量UserID。
4.2.2. 长连接接口
　　调用方式：
　　该接口实现长轮询，在循环过程中，不断检测表message是否存在属于当前用户的新信息，判断标准是字段TalkTo中包含当前用户的UserID值，且MsgID大于全局变量LastMsgID。若有新信息，将其推送给客户端，并更新LastMsgID的值，结束此次请求，否则，达到循环时限后输出无新信息的应答。客户端在收到新信息后，用前端脚本程序将其显示出来，随即再次调用该接口以进入下一次轮询。
4.3. 测试效果
    经过实测，在网速稳定的情况下，当用户A向B发送一个新信息，B的长连接通道几乎同时收到该信息，达到预期效果。开发一个聊天室系统还有很多细节需要考虑和完善，具体代码这里不再详述。
5. 结束语
基于HTTP的长连接技术，是目前在纯浏览器环境下进行即时交互类应用开发的理想选择，相信随着浏览器的快速发展，将为其提供更好的支持和更广泛的应用。

参考文献：
. 工业控制计算机,2003,16(2):43-44. 本文链接：http://www.qk112.com/lwfw/jsjlw/jsjwl/238254.html