如何实现Http长连接？
Kermit
如题。 项目的业务上需要建立一个长Http连接，客户端采用了Http标准协议
的格式，测试过程中可以接到一个标准的WebServer上。
但现在的问题是GET上去后，拿回的报文是Connection: close的，服务器发送
这个报文后，就进入TIME_WAIT状态，无法保持长连接。
虽然自己实现一个WebServer可以解决此问题，但我不知还有没有什么变通的
方法(亦或Http标准已经支持到，如Keep-Alive头)，来使用一个已有的服务器(如
apache thttp等)完成这个工作？TCP连接要一直保持，直到任意一方关闭为止。
我在Google过，有方案说服务器cgi可以不退出，每隔5s左右发送一个数据给
客户端，搜到的其他方案也都是说要建立一个类似的推送周期告诉双方还在连接。
但是我没有在RFC相关标准中找到论据来支持这一方案，不知大家都怎么做的。
HTTP协议中说得很清楚，Http连接可以是长连接的，所以我觉得肯定有可行的方案
来做。
Thanks
B.R
Kermit
feiyd..
Connection
：keep-alive 呢？
Shell Xu
如果去掉程序只能执行一定的时间这个限制，你可以发起一个请求，然后让服务器端程序长期不返回，或者慢慢返回，从而达到服务器到客户端的半工长连接的目的。客户端到服务器端的长连接意义并不大，我没有仔细研究。
如果要服务器和客户端能够即时交互的长连接，像CONNECT代理那样子的。我所知的方法里面貌似只有自己写http服务器了。
另外，长连接和Connection: close没有关系，和这个有关系的是Http/1.1中定义的pipeline行为。即使返回后断开，长连接依然能够达到他的目的。而pipeline则是发起多个请求，服务器依次处理返回。
我觉得你可能混淆了pipeline和长连接，不知道是不是搞错的人是我。
无能者无所求，饱食而遨游，泛若不系之舟
blog: http://shell909090.com/blog/
twitter: http://twitter.com/shell909090
Kermit
> http协议可以做长连接，不代表服务器实现支持。现在多数服务器是基于
> request-response模式的。就是在一定时间内接收完整的请求，然后交给某个程
> 序处理。程序也只能执行一定的时间，然后返回全部数据。这样的服务器不利于
> 实现长连接。
其实需要长连接的最核心的问题有两个：
1.服务器需要维护客户端的认证状态，每次连接后服务器都会对客户端用密钥进行
认证，并保持其状态直到连接断开。
2.服务器以后可能会要即时通知客户端执行某些任务。这个我目前在标准Html中还
没有看到有这方面的规定，因为Html中所有任务都是由客户端主动发起请求，服务
器“被动"地通过cgi返回一些具体任务指令(通过JSP等)。
要是短连接能够解决以上两个问题，我觉得我也就不必一定要找个长连接了。
要是实在不行，可能也只能按照你说的，完全实现一个HttpServer了，所幸这个工
作量貌似并不大，我看thttp的代码量也只有6k余行。
> 如果去掉程序只能执行一定的时间这个限制，你可以发起一个请求，然后让服务
> 器端程序长期不返回，或者慢慢返回，从而达到服务器到客户端的半工长连接的
> 目的。客户端到服务器端的长连接意义并不大，我没有仔细研究。
> 如果要服务器和客户端能够即时交互的长连接，像CONNECT代理那样子的。我所
> 知的方法里面貌似只有自己写http服务器了。
> 另外，长连接和Connection: close没有关系，和这个有关系的是Http/1.1中定
> 义的pipeline行为。即使返回后断开，长连接依然能够达到他的目的。而
> pipeline则是发起多个请求，服务器依次处理返回。
>
> 我觉得你可能混淆了pipeline和长连接，不知道是不是搞错的人是我。
这个我需要再check一下，文档中这么写的：
8.1 Persistent Connections
。。。。。。
Persistent HTTP connections have a number of advantages:
……
- HTTP requests and responses can be pipelined on a connection.
Pipelining allows a client to make multiple requests without
waiting for each response, allowing a single TCP connection to
be used much more efficiently, with much lower elapsed time.
……
所以我当时的理解是pipeline是长连接后才有的一个特性，再学习一下……
B.R
Kermit
以上。
B.R
Kermit
小马xiaoma
在 2011年5月10日 下午5:27，Kermit <kermi...@gmail.com> 写道：
stephen leung
Shell Xu
机械唯物主义 : linjunhalida
至于实现一个http服务器, 个人觉得风险大了些, 并且这样的需求其实是很常见的不是特殊的需求, 不需要客制化一个东西出来吧.
看看websocket之类保持一个连接的方案吧, 我也没有用过, 只是前段时间听说的.
2011/5/10 Shell Xu <shell...@gmail.com>:
> 恩，那就是了，你说的长连接和我们平时说的不是一个概念。
Shell Xu
Meteor
Chaos Eternal
2011/5/10 Shell Xu <shell...@gmail.com>:
Shell Xu
另外没看到SSL啊。
Chaos Eternal
Shell Xu
我所知的squid不经过设定好像是不行的。
Kermit
> 恩，那就是了，你说的长连接和我们平时说的不是一个概念。
> 我们平时说，使用长连接能OOXX的时候，说的其实不是真的RFC2616中持久化连
> 接的概念。那个概念和pipeline是差不多的。我们说的长连接是解决服务器通知
> 客户端的问题的。
> 例如，当年我们做聊天室的时候，怎么解决客户什么时候刷新的内容出来呢？我
> 当年很山寨的，用了五秒刷一次的方案。消耗大不说，而且即使这聊天室一个钟
> 头就说了三句话，只要有20个人连接上去，基本服务器就满载了——这个不随着压
> 力而变化的。
恩，应该是我的理解不到位，我理解的“长连接“是指一个永久性的TCP链接。
> 现在的长连接概念，是指，客户申请服务器新内容的时候，服务器并不立刻返回
> 有内容和没有内容，而是保持这个http请求处于不回应状态至少五分钟以上。当
> 有新内容的时候，再返回。于是，当聊天室里面有人说话的时候，http请求才返
> 回，从而大大节约资源。
> 比较有名的用法，就是SNS里面，你长期在线，但是又有即时短消息功能。用定
> 时刷压力太大，刷的时间慢又不及时，正适合用长连接。
> 实现这种长连接，关键是你的脚本需要保持不响应状态五分钟而不被干掉导致连
> 接关闭。具体做法每个服务器各自不同，你可以查查看。
> 当然，更复杂的长连接可以在请求未结束时就开始响应（CGI规范说明不可
> 以），从而在客户端继续向服务器传输数据的时候，服务器响应。能实现这种东
> 西，我就有把握把https封装到http协议里面跑代理。不过很遗憾的，我测试了
> 我的空间，确定，使用CGI接口的程序一概无法做到这点。
恩，这个提示对我很重要，因为我还以为可以使用CGI做个不返回结果的循环就能
做到呢。另外，我想请问一下，这个“CGI规范说明“在哪个文档可以看到？ 是
RFC3875吗？
<snip>
> 其实需要长连接的最核心的问题有两个：
>
> 1.服务器需要维护客户端的认证状态，每次连接后服务器都会对客户端
> 用密钥进行
> 认证，并保持其状态直到连接断开。
> 2.服务器以后可能会要即时通知客户端执行某些任务。这个我目前在标
> 准Html中还
> 没有看到有这方面的规定，因为Html中所有任务都是由客户端主动发起
> 请求，服务
> 器“被动"地通过cgi返回一些具体任务指令(通过JSP等)。
根据以上讨论，我觉得要维护一个永久性连接还是有一定工作量。如果对于上
述需求，我不用满足2，而只满足1，用短连接报文推送方式，并采用标准
WebServer来实现，应该比较简单。
但这里有一个安全性问题，我不知到能否得到保障：
从应用层面上看，每个使用浏览器的用户都需要进行一个双向认证(浏览器和
服务器彼此对方合法)。这种情况下，在每个用户的使用过程中，服务器都需要维
护这个用户连接的信息。我现在不知到使用什么方法能够保证这个过程是安全的，
也就是防止非法的浏览器客户端在此过程中访问服务器数据。因为IP和Mac地址都
可伪造出来。 我原本以为只要使用一个永久性的TCP连接，就可以自动维护这样一
个连接的状态。
<snip>
B.R
Kermit
Jun....@emc.com
最简单的，用 HTTP AUTH BASIC，每次都要发用户名密码上来；
复杂点的， 用HTTP AUTH DIGEST
再复杂点的，用SESSION
再复杂点，用HTTPS，用客户端证书
更复杂点，你自己实现安全机制。
从HTTP协议的角度，长连接或者你理解的持久连接都是不可信任的，你必须采用以上办法之一保证安全。
________________________________________
From: sh...@googlegroups.com [sh...@googlegroups.com] On Behalf Of Kermit [kermi...@gmail.com]
Sent: Wednesday, May 11, 2011 9:27 AM
To: sh...@googlegroups.com
Subject: Re: [shlug] 如何实现Http长连接？
Shell Xu
On Tue, 2011-05-10 at 21:03 +0800, Shell Xu wrote:恩，应该是我的理解不到位，我理解的“长连接“是指一个永久性的TCP链接。
> 恩，那就是了，你说的长连接和我们平时说的不是一个概念。
> 我们平时说，使用长连接能OOXX的时候，说的其实不是真的RFC2616中持久化连
> 接的概念。那个概念和pipeline是差不多的。我们说的长连接是解决服务器通知
> 客户端的问题的。
> 例如，当年我们做聊天室的时候，怎么解决客户什么时候刷新的内容出来呢？我
> 当年很山寨的，用了五秒刷一次的方案。消耗大不说，而且即使这聊天室一个钟
> 头就说了三句话，只要有20个人连接上去，基本服务器就满载了——这个不随着压
> 力而变化的。
http是一种无状态协议，就是说，同一个session的请求，和这些请求是否在同一个tcp连接中没有关系。
> 现在的长连接概念，是指，客户申请服务器新内容的时候，服务器并不立刻返回
> 有内容和没有内容，而是保持这个http请求处于不回应状态至少五分钟以上。当
> 有新内容的时候，再返回。于是，当聊天室里面有人说话的时候，http请求才返
> 回，从而大大节约资源。恩，这个提示对我很重要，因为我还以为可以使用CGI做个不返回结果的循环就能
> 比较有名的用法，就是SNS里面，你长期在线，但是又有即时短消息功能。用定
> 时刷压力太大，刷的时间慢又不及时，正适合用长连接。
> 实现这种长连接，关键是你的脚本需要保持不响应状态五分钟而不被干掉导致连
> 接关闭。具体做法每个服务器各自不同，你可以查查看。
> 当然，更复杂的长连接可以在请求未结束时就开始响应（CGI规范说明不可
> 以），从而在客户端继续向服务器传输数据的时候，服务器响应。能实现这种东
> 西，我就有把握把https封装到http协议里面跑代理。不过很遗憾的，我测试了
> 我的空间，确定，使用CGI接口的程序一概无法做到这点。
做到呢。另外，我想请问一下，这个“CGI规范说明“在哪个文档可以看到？ 是
RFC3875吗？
CGI不返回结果的却有希望做到，不过仅限于服务器向客户端push数据的用法，双方同时交互数据是没戏了。而且你必须要自行保证CGI不被杀掉。很多服务器到一定时间会自动去杀CGI，然后返回500的。
恩，是RFC3875，我查了一下，规范说明的是可以。那不可以应该是我测试下来的结果，反正结论是论证我的设计是不可行的，杯具。
<snip>
> 其实需要长连接的最核心的问题有两个：
>
> 1.服务器需要维护客户端的认证状态，每次连接后服务器都会对客户端
> 用密钥进行
> 认证，并保持其状态直到连接断开。
> 2.服务器以后可能会要即时通知客户端执行某些任务。这个我目前在标
> 准Html中还
> 没有看到有这方面的规定，因为Html中所有任务都是由客户端主动发起
> 请求，服务根据以上讨论，我觉得要维护一个永久性连接还是有一定工作量。如果对于上
> 器“被动"地通过cgi返回一些具体任务指令(通过JSP等)。
述需求，我不用满足2，而只满足1，用短连接报文推送方式，并采用标准
WebServer来实现，应该比较简单。
但这里有一个安全性问题，我不知到能否得到保障：
从应用层面上看，每个使用浏览器的用户都需要进行一个双向认证(浏览器和
服务器彼此对方合法)。这种情况下，在每个用户的使用过程中，服务器都需要维
护这个用户连接的信息。我现在不知到使用什么方法能够保证这个过程是安全的，
也就是防止非法的浏览器客户端在此过程中访问服务器数据。因为IP和Mac地址都
可伪造出来。 我原本以为只要使用一个永久性的TCP连接，就可以自动维护这样一
个连接的状态。
我觉得，你的思路根本错了，http是一种无状态协议。也就是说，即使是持久化连接，也不能在tcp连接层级上保持状态。另外，要实行man in middle攻击完全没必要另行发起一个tcp socket。正确的双方互相严格确认对方身份（尤其是客户端验证服务器身份）的方法是SSL/TLS。http basic auth可能会被man in middle钓鱼的，因为无法确认服务器身份。我记得有个东西叫做客户端证书，可以用来做服务器端认证客户端身份。
比较完美的方法是，自建一个root ca，然后服务器和客户端加入信任。然后用这个ca分别给服务器和客户端签出证书。在SSL握手的时候分别验证对方证书。这个过程在逻辑上是安全的。唯一的问题是——我不知道怎么玩。我玩过ca给nginx签服务器端证书的单向认证，也玩过openvpn的互相认证，可是还没玩过http server的互相认证呢。
<snip>
B.R
Kermit
Zoom.Quiet
Comet：基于 HTTP 长连接的“服务器推”技术
http://www.ibm.com/developerworks/cn/web/wa-lo-comet/
Ajax/Comet實作聊天室心得 » 程式設計 遇上 小提琴
http://blog.ez2learn.com/2010/04/11/ajax-comet-chatroom/
js的comet各个浏览器封装lib--七夜的开源研究
http://www.cellphp.com/article-read-javascript-23-simplecomet-comet-javascript-php.html
只是,现在话说,已经推荐用 node.js 进行所谓长连接的服务架构了:
译言网 | Is node.js best for Comet?
http://article.yeeyan.org/view/91891/162689
有趣的Comet技术选择，论 Is node.js best for Comet? – 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
http://sunxiunan.com/?p=1768
node.js国内外资料集锦(2011.02.09更新)
http://cnodejs.org/blog/?p=104
...
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
哲: http://www.zeuux.org/home/zoomquiet
豆: http://www.douban.com/group/zoomquiet
书: http://code.google.com/p/openbookproject
营: http://code.google.com/p/kcpycamp/wiki/PythoniCamp
Zhenhua Zhang
http://xmpp.org/extensions/xep-0124.html
Compatible with constrained runtime environments* (e.g., mobile and
browser-based clients).
Compatible with proxies that buffer partial HTTP responses.
Efficient through proxies that limit the duration of HTTP responses.
Fully compatible with HTTP/1.0.
Compatible with restricted network connections (e.g., firewalls,
proxies, and gateways).
Fault tolerant (e.g., session recovers after an underlying TCP
connection breaks at any stage during an HTTP request).
Extensible.
Consume significantly less bandwidth than polling-based protocols.
Significantly more responsive (lower latency) than polling-based protocols.
Support for polling (for clients that are limited to a single HTTP
connection at a time).
In-order delivery of data.
Guard against unauthorized users injecting HTTP requests into a session.
Protect against denial of service attacks.
Multiplexing of data streams.
...
Each block of data pushed by the connection manager is a complete HTTP
response. So, unlike the Comet technique, the BOSH technique works
through intermediate proxies that buffer partial HTTP responses. It is
also fully compliant with HTTP/1.0 -- which does not provide for
chunked transfer encoding.
在 2011年5月11日 上午10:10，Zoom.Quiet <zoom....@gmail.com> 写道：
> 是也乎,是也乎,http 长连接,本身就是个翻译误导,其实是合理利用 http 协议,进行貌似的长连接...
> Comet：基于 HTTP 长连接的"服务器推"技术
> http://www.ibm.com/developerworks/cn/web/wa-lo-comet/
> Ajax/Comet實作聊天室心得 >> 程式設計 遇上 小提琴
> http://blog.ez2learn.com/2010/04/11/ajax-comet-chatroom/
> js的comet各个浏览器封装lib--七夜的开源研究
> http://www.cellphp.com/article-read-javascript-23-simplecomet-comet-javascript-php.html
>
> 只是,现在话说,已经推荐用 node.js 进行所谓长连接的服务架构了:
> 译言网 | Is node.js best for Comet?
> http://article.yeeyan.org/view/91891/162689
> 有趣的Comet技术选择，论 Is node.js best for Comet? - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
> http://sunxiunan.com/?p=1768
> node.js国内外资料集锦(2011.02.09更新)
> http://cnodejs.org/blog/?p=104
>
>
> 在 2011年5月11日 上午10:03，Shell Xu <shell...@gmail.com> 写道：
>>
>>
>> 在 2011年5月11日 上午9:27，Kermit <kermi...@gmail.com>写道：
>>>
>>> On Tue, 2011-05-10 at 21:03 +0800, Shell Xu wrote:
>>> > 恩，那就是了，你说的长连接和我们平时说的不是一个概念。
>>> > 我们平时说，使用长连接能OOXX的时候，说的其实不是真的RFC2616中持久化连
>>> > 接的概念。那个概念和pipeline是差不多的。我们说的长连接是解决服务器通知
>>> > 客户端的问题的。
>>> > 例如，当年我们做聊天室的时候，怎么解决客户什么时候刷新的内容出来呢？我
>>> > 当年很山寨的，用了五秒刷一次的方案。消耗大不说，而且即使这聊天室一个钟
>>> > 头就说了三句话，只要有20个人连接上去，基本服务器就满载了----这个不随着压
>> ca，然后服务器和客户端加入信任。然后用这个ca分别给服务器和客户端签出证书。在SSL握手的时候分别验证对方证书。这个过程在逻辑上是安全的。唯一的问题是----我不知道怎么玩。我玩过ca给nginx签服务器端证书的单向认证，也玩过openvpn的互相认证，可是还没玩过http
Kermit
> 我觉得，你的思路根本错了，http是一种无状态协议。也就是说，即使是持久化
> 连接，也不能在tcp连接层级上保持状态。另外，要实行man in middle攻击完全
> 没必要另行发起一个tcp socket。正确的双方互相严格确认对方身份（尤其是客
> 户端验证服务器身份）的方法是SSL/TLS。http basic auth可能会被man in
> middle钓鱼的，因为无法确认服务器身份。我记得有个东西叫做客户端证书，可
> 以用来做服务器端认证客户端身份。
> 比较完美的方法是，自建一个root ca，然后服务器和客户端加入信任。然后用
> 这个ca分别给服务器和客户端签出证书。在SSL握手的时候分别验证对方证书。
> 这个过程在逻辑上是安全的。唯一的问题是——我不知道怎么玩。我玩过ca给
> nginx签服务器端证书的单向认证，也玩过openvpn的互相认证，可是还没玩过
> http server的互相认证呢。
恩，这几天一直在讨论实现方式，https方案也列入研究范围内；同时，对于我提
问的长连接，也有使用session方面的提议，使用短报文方式推送Html文件，用
HTTP中的session来支持会话场景维护，达到在应用层开来是一个连接的效果，我
现在就在研究这个东西。
另外，还想问个问题，要在常用的WebServer里面给HTTP层通讯加一个扩展的头
部，在不修改服务器源代码的层次上方便做到不？
比如说，在一个扩展的HTTP头部中加入一个Custom-Secret头，并根据实际情况填
写其值返回给浏览器。至于怎么解析则是浏览器的事了。
Thanks
B.R
Kermit
单琪玮
如果楼主说的是这种情况的话，那这种应用应该是很普遍的吧。楼主做的程序应该只要像那些浏览器一样在请求的头上加一个session的ID就可以了吧。服务器那头也用对应的ID保存相关的信息。