某某茶叶有限公司欢迎您!
金沙棋牌在线 > Web前端 > 判断Keep-Alive模式的HTTP请求的结束的实现代码金沙棋牌在线

判断Keep-Alive模式的HTTP请求的结束的实现代码金沙棋牌在线

时间:2019-12-29 06:38

HTTP Keep-Alive模式

2015/12/01 · HTML5 · 1 评论 · HTTP

原文出处: 吴秦   

故事发生在10月份的一次面试经历中,本来我不想说出来丢人显眼,但是为了警醒自己和告诫后人,我决定写成博文发出来。因为在面试过程中,我讲在2009年写过QQ农场助手,在这期间深入学习了HTTP协议,而且在2010-05-18写了博文:HTTP协议及其POST与GET操作差异 & C#中如何使用POST、GET等。面试官说既然我熟悉HTTP协议,就问“当HTTP采用keepalive模式,当客户端向服务器发生请求之后,客户端如何判断服务器的数据已经发生完成?”

说实话,当时我懵了,一直没有关注过keepalive模式。我只知道:HTTP协议中客户端发送一个小请求,服务器响应以所期望的信息(例如一个html文件或一副gif图像)。服务器通常在发送回所请求的数据之后就关闭连接。这样客户端读数据时会返回EOF(-1),就知道数据已经接收完全了。我就这样被面试官判了死刑!!!说我完全停留在表面,没有深入(当时真的很受打击,一直自认为技术还不错!)。我当时真的很想找各种借口:

  • 之前没有用到HTTP的keepalive模式,所以没有深入
  • 好久没有用HTTP协议,细节忘了
  • 实习的东西跟HTTP协议没有关系,用得少了就忘了
  • 。。。。。。

觉得各种解释都是那么苍白无力!我再次感叹书到用时方恨少,也感叹一个人的时间是多么的有限(曾一度想成为一个IT专业全才),根本没有精力面面俱到,而且当没有真正使用一个东西的时候,往往会忽略掉很多细节。朋友如果你也答不上来,请认真细看下文,不要怀着浮躁了的心,说不定下次就有人问你这个问题。

在使用短连接方式时,每个HTTP请求对应一个TCP连接,请求完成后连接立即断开,服务器返回EOF。所以根据EOF就可判断一次请求的结束,下面的代码(PHP)很常见:

http1.1版本之前 许多浏览器和服务器扩展了持久连接

所以根据EOF就可判断一次请求的结束,下面的代码很常见: 复制代码 代码如下: // $fp是由fsockopen()产生的句柄 while { echo fgets; } (注:短连接模式是在头部用”Connection: close”标示,长连接用”Connection: keep-alive”标示。目前HTTP/1.0默认使用短连接,HTTP/1.1默认使用长连接。) 而长连接模式的HTTP在发送完数据后服务器并不断开连接,而是留着下一次HTTP请求时使用,所以长连接的好处是显而易见的,通过共用一个TCP连接来节省以后请求时建立/断开连接的开销。而EOF是直到这个TCP连接结束时才会被发送,所以我们就不能使用上面的办法来判断一次HTTP请求的结束了。这也是使用长连接时都会遇到的一个问题。目前判断的方法主要有两种: 根据头中的Content-Length字段。这个字段标明了正文的长度,我们可以以接收完指定长度的字符为判断结束的依据。 在没有Content-Length时,根据Transfer-Encoding。有些时候服务器无法确定正文的大小,因为正文可能是动态产生的,所以就不会提供Content-Length了,而是采用chunk编码来一块一块地发送正文。每个chunk块由头部和正文两部分组成,头部中由一个16进制数字指定了正文的长度;最后由一个长度为0的chunk块来表示整个HTTP正文的结束。 下面我用PHP实现了有Content-Length时的判断方式: 1. 获得Content-Length值 复制代码 代码如下: $length = 0; $line = ''; while { $line = fgets; if === 'Content-Length:') { $length = intval; } } 2. 获得正文 复制代码 代码如下: $sum = 0; while { $line = fgets; $sum += strlen; echo $line; }

1、什么是Keep-Alive模式?

我们知道HTTP协议采用“请求-应答”模式,当使用普通模式,即非KeepAlive模式时,每个请求/应答客户和服务器都要新建一个连接,完成之后立即断开连接(HTTP协议为无连接的协议);当使用Keep-Alive模式(又称持久连接、连接重用)时,Keep-Alive功能使客户端到服务器端的连接持续有效,当出现对服务器的后继请求时,Keep-Alive功能避免了建立或者重新建立连接。

金沙棋牌在线 1

http 1.0中默认是关闭的,需要在http头加入”Connection: Keep-Alive”,才能启用Keep-Alive;http 1.1中默认启用Keep-Alive,如果加入”Connection: close “,才关闭。目前大部分浏览器都是用http1.1协议,也就是说默认都会发起Keep-Alive的连接请求了,所以是否能完成一个完整的Keep-Alive连接就看服务器设置情况。

// $fp是由fsockopen()产生的句柄

使用 Connection:Keep-Alive 的首部来操作 tcp 的持久连接

2、启用Keep-Alive的优点

从上面的分析来看,启用Keep-Alive模式肯定更高效,性能更高。因为避免了建立/释放连接的开销。下面是RFC 2616上的总结:

    1. By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
    2. 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.
    3. Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.
    4. Latency on subsequent requests is reduced since there is no time spent in TCP’s connection opening handshake.
    5. HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using     future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old   semantics after an error is reported.

RFC 2616(P47)还指出:单用户客户端与任何服务器或代理之间的连接数不应该超过2个。一个代理与其它服务器或代码之间应该使用超过2 * N的活跃并发连接。这是为了提高HTTP响应时间,避免拥塞(冗余的连接并不能代码执行性能的提升)。

while(!feof($fp)) {

实现HTTP/1.0 keep-alive连接的客户端可以通过包含Connection: Keep-Alive首部请求将一条连接保持在打开状态。如果服务器愿意为下一条请求将连接保持在打开状态,就在响应中包含相同的首部(参见图4-14)。如果响应中没有Connection: Keep-Alive首部,客户端就认为服务器不支持keep-alive,会在发回响应报文之后关闭连接。

3、回到我们的问题(即如何判断消息内容/长度的大小?)

Keep-Alive模式,客户端如何判断请求所得到的响应数据已经接收完成(或者说如何知道服务器已经发生完了数据)?我们已经知道了,Keep-Alive模式发送玩数据HTTP服务器不会自动断开连接,所有不能再使用返回EOF(-1)来判断(当然你一定要这样使用也没有办法,可以想象那效率是何等的低)!下面我介绍两种来判断方法。

echo fgets($fp);

金沙棋牌在线 2

3.1、使用消息首部字段Conent-Length

故名思意,Conent-Length表示实体内容长度,客户端(服务器)可以根据这个值来判断数据是否接收完成。但是如果消息中没有Conent-Length,那该如何来判断呢?又在什么情况下会没有Conent-Length呢?请继续往下看……

}

HTTP/1.0 keep-alive事务首部的握手过程

3.2、使用消息首部字段Transfer-Encoding

当客户端向服务器请求一个静态页面或者一张图片时,服务器可以很清楚的知道内容大小,然后通过Content-length消息首部字段告诉客户端需要接收多少数据。但是如果是动态页面等时,服务器是不可能预先知道内容大小,这时就可以使用Transfer-Encoding:chunk模式来传输数据了。即如果要一边产生数据,一边发给客户端,服务器就需要使用”Transfer-Encoding: chunked”这样的方式来代替Content-Length。

chunk编码将数据分成一块一块的发生。Chunked编码将使用若干个Chunk串连而成,由一个标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分,头部内容指定正文的字符总数(十六进制的数字)和数量单位(一般不写),正文部分就是指定长度的实际内容,两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容,是一些附加的Header信息(通常可以直接忽略)。

Chunk编码的格式如下:

Chunked-Body = *chunk
“0” CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF

hex-no-zero = <HEX excluding “0”>

chunk-size = hex-no-zero *HEX
chunk-ext = *( “;” chunk-ext-name [ “=” chunk-ext-value ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)

footer = *entity-header

即Chunk编码由四部分组成:1、0至多个chunk块,2、“0” CRLF,3、footer,4、CRLF.而每个chunk块由:chunk-size、chunk-ext(可选)、CRLF、chunk-data、CRLF组成。

(注:短连接模式是在头部用”Connection: close”标示,长连接用”Connection: keep-alive”标示。目前HTTP/1.0默认使用短连接,HTTP/1.1默认使用长连接。)

Keep-Alive 选项

当使用Connection: Keep-Alive 首部时可以附加一个 Keep-Alive首部来调节 keep-alive 的行为

timeout max 都是响应首部发出的 分别表示 服务器希望将连接保持在活跃状态的时间和服务器希望为多少个事务保持此连接的活跃状态,它们都是一个估计值并不是一个承诺值。

此外还可以添加任意未经处理的形如 name[=value]的属性 主要用于诊断和调试

Connection: Keep-Alive

Keep-Alive: max=5, timeout=120

上面的例子表示服务器最多还会为另外5个事务保持连接的活跃状态或者将空闲状态的活跃连接保持两分钟

4、消息长度的总结

其实,上面2中方法都可以归纳为是如何判断http消息的大小、消息的数量。RFC 2616对消息的长度总结如下:一个消息的transfer-length(传输长度)是指消息中的message-body(消息体)的长度。当应用了transfer-coding(传输编码),每个消息中的message-body(消息体)的长度(transfer-length)由以下几种情况决定(优先级由高到低):

  • 任何不含有消息体的消息(如1XXX、204、304等响应消息和任何头(HEAD,首部)请求的响应消息),总是由一个空行(CLRF)结束。
  • 如果出现了Transfer-Encoding头字段 并且值为非“identity”,那么transfer-length由“chunked” 传输编码定义,除非消息由于关闭连接而终止。
  • 如果出现了Content-Length头字段,它的值表示entity-length(实体长度)和transfer-length(传输长度)。如果这两个长度的大小不一样(i.e.设置了Transfer-Encoding头字段),那么将不能发送Content-Length头字段。并且如果同时收到了Transfer-Encoding字段和Content-Length头字段,那么必须忽略Content-Length字段。
  • 如果消息使用媒体类型“multipart/byteranges”,并且transfer-length 没有另外指定,那么这种自定界(self-delimiting)媒体类型定义transfer-length 。除非发送者知道接收者能够解析该类型,否则不能使用该类型。
  • 由服务器关闭连接确定消息长度。(注意:关闭连接不能用于确定请求消息的结束,因为服务器不能再发响应消息给客户端了。)

为了兼容HTTP/1.0应用程序,HTTP/1.1的请求消息体中必须包含一个合法的Content-Length头字段,除非知道服务器兼容HTTP/1.1。一个请求包含消息体,并且Content-Length字段没有给定,如果不能判断消息的长度,服务器应该用用400 (bad request) 来响应;或者服务器坚持希望收到一个合法的Content-Length字段,用 411 (length required)来响应。

所有HTTP/1.1的接收者应用程序必须接受“chunked” transfer-coding (传输编码),因此当不能事先知道消息的长度,允许使用这种机制来传输消息。消息不应该够同时包含 Content-Length头字段和non-identity transfer-coding。如果一个消息同时包含non-identity transfer-coding和Content-Length ,必须忽略Content-Length 。

而长连接(也称持久连接)模式的HTTP在发送完数据后服务器并不断开连接,而是留着下一次HTTP请求时使用,所以长连接的好处是显而易见的,通过共用一个TCP连接来节省以后请求时建立/断开连接的开销。而EOF是直到这个TCP连接结束(超时或出错)时才会被发送,所以我们就不能使用上面的办法来判断一次HTTP请求的结束了。这也是使用长连接时都会遇到的一个问题。目前判断的方法主要有两种:

Keep-Alive连接的限制和规则

  1. http/1.0 中keep-alive不是默认使用的 客户端必须发送一个带有 Connection:Keep-Alive 的请求首部的请求来激活 keep-alive 连接

  2. Connection:Keep-Alive 首部必须跟随所有希望保持持久连接的报文一起发送:

如果客户端没有发送Connection:Keep-Alive 服务器将会在请求之后关闭连接

如何客户端发现在响应中没有Connection:Keep-Alive首部,则可以知道服务器在发出响应之后会关闭连接

3. 保持持久连接报文实体必须要有正确Content-Length,这样事务处理才能正确的检测出一条报文的结束和另一条报文的结束。

4. 代理和网关必须执行Connection首部的规则。代理或网关必须在将报文转发出去或将其高速缓存之前,删除在Connection首部中命名的所有首部字段以及Connection首部自身。严格来说,不应该与无法确定是否支持Con-nection首部的代理服务器建立keep-alive连接,以防止出现哑代理问题。