有人称做“服务器推”

主要是用在TCP上的，因为TCP的握手机制什么的

以FTP举例

S 在21端口等待C 发起连接，C以>1024的某个随机port 连接S ，S与C 之间建立control ，S与C协商 transport 事宜，传输的时候有主动模式和passive 模式。A模式下，C告诉S，我的某个port 打开等待你来连接；但是在中间经过FW的时候，FW是不允许inside 向outside 未知port 发起连接的，所以出现了P模式，P模式下，S告诉C（control连接）我的20打开，你要拿就过来，于是C与S建立transport连接。但是传输完了，是要关闭连接的，这时候长连接就上场了。


在FW的需求上建立长连接一般是控制这个socket（IP+port）的timeout ，这个“长”就是时间的长短，FW（juniper 为例）socket 超时为30min，万一juniper 上配置了NAT，问题就出现了！而现实中大量的NAT是配置在FW上的（哎~），当FW把NAT timeout掉了，rotary会从pool中拿个IP出来（极有可能不是上一个IP），放到新的nat table，这时原来的流量又来了，socket还是原来那个，于是FW丢弃这个包，于是访问失败。（这个例子里面还有dns存在，可能比较难理解）另一种情况，防火墙干掉了这个socket ，在某些S-C的情况下会显示掉线。重新建立短连接，虽然可以，但是会造成防火墙的负担，处理效率也较低。


称为服务器推也是长连接的一种。利用websocket 或者java的功能实现的较多，类似于触发式组播，客户端加组，S主动下发流量到C。C直到不需要的时候，才向S发送第四次TCP握手，关闭连接。实现的时候需要保活机制。


总之，自我感觉在FW上的长连接就是设置timeout 时间非常大，http长连接则是协议上的一种技术实现。