long polling与polling概述服务端推送技术应用越来越普遍，应用范围也越来越宽广，技术解决方案也越来越成熟且丰富。很多sns网站的chat功能就有用到了long polling技术。比如fackebook, kaixin001。
long polling原理其实很简单，也很讨巧。与polling相比，long polling客户端也许不会马上收到来自服务端的响应，需要等待一些时间(直到有新消息，或者连接timeout了等等)。同样的，客户端也不再需要定时向服务发送请求了，而是直到收到服务端响应之后，或者连接丢失之后，客户端接着马上请求客户端。这里，我打个比方，传统的polling一般是由c向s询问:”有我的信件吗？”。s接到询问之后，会立即查询，并且把查询结果告诉c，不管有没有c的信件，要码回复:”嗯，你有x封信。”，要码回复:”没，没有你的信”.而long polling更像是这样，c向s发出询问:”有我的信件吗？”，s开始查询，如果有则回复c:”嗯，有你x封信”。如果没有，则不作任何回复，而是让c等着，自己一遍一遍地查询是否有订阅者的信。换句话说：当s收到c的查询请求之后，polling则只查询一次，并且把查询结果告诉c;而long polling收到请求之后，则会一遍一遍地查询，直到有消息才会响应c，不然一直hold client。
long polling相较传统的polling而言，最大的实惠在于：减少了请求次数。举个例子，假定一个用户每2小时内，有可能收到2条新消息。如果采用传通的polling方式，每30秒发向服务端发送一次查询请求的话。则在这2小时内，服务器需要处理240(60*60*2/30)次请求，其中至少有238次请求是没有实际意义的。试想，如果是10000的并发量的话，这种浪费是很惊人的。相较而方，long polling没有那么浪费服务器资源来处理这些没有实际意义的请求。
polling传统的polling实现方式比较单一，由客户端javascript脚本定时发送http请求。服务端脚本如下:
上面是一个传统polling简单的服务端脚本。很简单，收到客户端请求后，服务端马上执行脚本查询，并且立即响应客户端。客户端等待的时间很短，客户端唯一要做的事情就是定时向服务端发出查询请求。下面是请求时，通过tcpdump抓到的包:
1>17:49:03.533760 ip 192.168.0.98.4383 > devhome.http: s 3235664319:3235664319(0) win 65535 2>17:49:03.534336 ip devhome.http > 192.168.0.98.4383: s 2018732723:2018732723(0) ack 3235664320 win 5840 3>17:49:03.533841 ip 192.168.0.98.4383 > devhome.http: . ack 1 win 655354>17:49:03.534404 ip 192.168.0.98.4383 > devhome.http: p 1:781(780) ack 1 win 655355>17:49:03.534416 ip devhome.http > 192.168.0.98.4383: . ack 781 win 70206>17:49:03.535033 ip devhome.http > 192.168.0.98.4383: p 1:369(368) ack 781 win 70207>17:49:03.535110 ip devhome.http > 192.168.0.98.4383: f 369:369(0) ack 781 win 70208>17:49:03.535263 ip 192.168.0.98.4383 > devhome.http: . ack 370 win 651679>17:49:03.536105 ip 192.168.0.98.4383 > devhome.http: f 781:781(0) ack 370 win 6516710>17:49:03.536111 ip devhome.http > 192.168.0.98.4383: . ack 782 win 7020
第1、2、3行，tcp三次握手，建立连接。
第4行，由192.168.0.98向服务端devhome发送httpd请求。
第5行，由服务端devhome确认收到了来自客户端192.168.0.98的http请求。
第6行，服务器响devhom响应客户端192.168.0.98刚才发的httpd请求。注意:特别注意一下第一列时间截，http请求与http响应的时间间隔很短，才0.001s
第7、8、9、10共4行，tcp四次挥手，断开连接。由服务端主动断开连接。
long pollinglong polling较之polling稍微有些不一样，long polling持续执行，以此延迟对客户端的响应。请查看代码:
'info' , 'c' => $msg)); flush(); exit(0); } usleep(3000000);}echo json_encode(array('t' => 'refresh', 'c' => 3000));flush();?>
上面是long polling服务端代码。语意也很明了，如果有$msg，则会马上响应客户端请求，并且关闭该tcp连接。如果在$timeout之内，没有$msg，则会让客户端一直保持该tcp连接，不中断(关闭)。直到超过了$timeout(具体时间主要取决于$timeout * $usleep_time)，服务端会要求客户端重新请求(重新建立tcp连接)，同时关闭当前tcp连接。下面是通过 tcpdump抓到的包:
1>18:39:46.449563 ip 192.168.0.98.4407 > devhome.http: s 174149200:174149200(0) win 65535 2>18:39:46.449587 ip devhome.http > 192.168.0.98.4407: s 938669730:938669730(0) ack 174149201 win 5840 3>18:39:46.449692 ip 192.168.0.98.4407 > devhome.http: . ack 1 win 655354>18:39:46.450308 ip 192.168.0.98.4407 > devhome.http: p 1:793(792) ack 1 win 655355>18:39:46.450320 ip devhome.http > 192.168.0.98.4407: . ack 793 win 71286>18:42:46.521749 ip devhome.http > 192.168.0.98.4407: p 1:377(376) ack 793 win 71287>18:42:46.521825 ip devhome.http > 192.168.0.98.4407: p 377:412(35) ack 793 win 71288>18:42:46.521859 ip devhome.http > 192.168.0.98.4407: f 412:412(0) ack 793 win 71289>18:42:46.521997 ip 192.168.0.98.4407 > devhome.http: . ack 412 win 6512410>18:42:46.522021 ip 192.168.0.98.4407 > devhome.http: . ack 413 win 6512411>18:42:46.522965 ip 192.168.0.98.4407 > devhome.http: f 793:793(0) ack 413 win 6512412>18:42:46.522970 ip devhome.http > 192.168.0.98.4407: . ack 794 win 7128
第1、2、3行，tcp三次握手，建立连接。
第4行，由192.168.0.98向服务端192.168.0.6发送http请求。
第5行，由192.168.0.6确认收到192.168.0.98刚刚发送的请求。
第6、7行，服务器host_6响应3分钟前客户端192.168.0.98发出的http请求。注意，第一列的时间截，第5行与第6行之差为3分钟。这与服务端脚本，客户端监控是相呼应的。
最后4行，tcp四次挥手，断开连接，同样由服务端devhome发起。
由上图可见(httpwatch绘制),正好验证了，响应客户端host_98的http请求，在3分钟之后。这也说明了，long polling与polling的区别在于，客户端有可能需要等待更长时间才能收到服务端的响应。