Nginx对长连接的处理及HTTP协议中body长度的确定
2017-02-24 17:03
225 查看
长连接
背景: http请求是基于TCP协议之上的,那么,当客户端在发起请求前,需要先与服务端建立TCP连接,而每一次的TCP连接是需要三次握手来确定的,如果客户端与服务端之间网络差一点,这三次交互消费的时间会比较多,而且三次交互也会带来网络流量。当然,当连接断开后,也会有四次的交互,当然对用户体验来说就不友好了。定义: 而http请求是请求应答式的,如果我们能知道每个请求头与响应体的长度,那么我们是可以在一个连接上面执行多个请求的,这就是所谓的长连接。
前提: 先确定请求头与响应体的长度。
①对于请求头:
a、如果当前请求需要有body,如POST请求,那么nginx就需要客户端在请求头中指定content-length来表明body的长度。
b、如果请求头不需要body,遇到两个连续回车时,即可确定请求头结束。
②对于应答体:
a、对于http1.0协议来说,如果响应头中有content-length头,则以content-length的长度就可以知道body的长度了,客户端在接收body时,就可以依照这个长度来接收数据,接收完后,就表示这个请求完成了。而如果没有content-length头,则客户端会一直接收数据,直到服务端主动断开连接,才表示body接收完了。
b、而对于http1.1协议来说,如果响应头中的Transfer-encoding为chunked传输,则表示body是流式输出,body会被分成多个块,每块的开始会标识出当前块的长度,此时,body不需要通过长度来指定。如果是非chunked传输,而且有content-length,则按照content-length来接收数据。否则,如果是非chunked,并且没有content-length,则客户端接收数据,直到服务端主动断开连接。
Nginx的处理:从上面看,我们可以看到,除了http1.0不带content-length以及http1.1非chunked不带content-length外,body的长度是可知的。此时,当服务端在输出完body之后,会可以考虑使用长连接。能否使用长连接,也是有条件限制的。如果客户端的请求头中的connection为close,则表示客户端需要关掉长连接,如果为keep-alive,则客户端需要打开长连接,如果客户端的请求中没有connection这个头,那么根据协议,如果是http1.0,则默认为close,如果是http1.1,则默认为keep-alive。如果结果为keepalive,那么,nginx在输出完响应体后,会设置当前连接的keepalive属性,然后等待客户端下一次请求。当然,nginx不可能一直等待下去,如果客户端一直不发数据过来,岂不是一直占用这个连接?所以当nginx设置了keepalive等待下一次的请求时,同时也会设置一个最大等待时间,这个时间是通过选项keepalive_timeout来配置的,如果配置为0,则表示关掉keepalive,此时,http版本无论是1.1还是1.0,客户端的connection不管是close还是keepalive,都会强制为close。
使用场景如果服务端最后的决定是keepalive打开,那么在响应的http头里面,也会包含有connection头域,其值是”Keep-Alive”,否则就是”Close”。如果connection值为close,那么在nginx响应完数据后,会主动关掉连接。所以,对于请求量比较大的nginx来说,关掉keepalive最后会产生比较多的time-wait状态的socket。一般来说,当客户端的一次访问,需要多次访问同一个server时,打开keepalive的优势非常大,比如图片服务器,通常一个网页会包含很多个图片。打开keepalive也会大量减少time-wait的数量。
下面解释一下time-wait状态的socket:
tcp状态机:
根据上图【tcp状态机】:
解释一下TIME_WAIT状态,主动调用close()的一方在发送FIN报文之后进入FIN_WAIT_1状态,如果收到了对方回复的ACK报文并且也收到了对方发来的FIN报文之后就会进入TIME_WAIT状态。
停留在TIME_WAIT状态的时间为2MSL,MSL是maximum segment lifetime,BSD实现中的数值为30秒。IP头里面有TTL,MSL就是TTL为255级时报文也不会超过的最大生存时间。
需要TIME_WAIT的原因一是因为回复给对方FIN的ACK报文可能会丢失,从而使得对方再一次发送FIN报文,若是TCP连接马上退至CLOSED状态,对于第二次到来的FIN就会发送RST报文。
第二个原因是让TCP链接expire掉,因为网络上可能还有残留的旧的TCP链接的数据,这些数据都要作废,2个MSL是因为有两个方向的数据作废时间,在TIME_WAIT结束以前,旧的TCP占用的端口号不能使用。
pipe
在http1.1中,引入了一种新的特性,即pipeline。那么什么是pipeline呢?pipeline其实就是流水线作业,它可以看作为keepalive的一种升华,因为pipeline也是基于长连接的,目的就是利用一个连接做多次请求。如果客户端要提交多个请求,对于keepalive来说,那么第二个请求,必须要等到第一个请求的响应接收完全后,才能发起,这和TCP的停止等待协议是一样的,得到两个响应的时间至少为2*RTT。而对pipeline来说,客户端不必等到第一个请求处理完后,就可以马上发起第二个请求。得到两个响应的时间可能能够达到1*RTT。
nginx是直接支持pipeline的,但是,nginx对pipeline中的多个请求的处理却不是并行的,依然是一个请求接一个请求的处理,只是在处理第一个请求的时候,客户端就可以发起第二个请求。这样,nginx利用pipeline减少了处理完一个请求后,等待第二个请求的请求头数据的时间。其实nginx的做法很简单,前面说到,nginx在读取数据时,会将读取的数据放到一个buffer里面,所以,如果nginx在处理完前一个请求后,如果发现buffer里面还有数据,就认为剩下的数据是下一个请求的开始,然后就接下来处理下一个请求,否则就设置keepalive。
相关文章推荐
- Url请求长度HTTP协议不对URI的长度作事先的限制,服务器必须能够处理任何他们提供资源的URI,并且应该能够处理无限长度的URIs,这种无效长度的URL可能会在客户端以基于GET方式的请求时产生。
- 【nginx】App打点场景下,用nginx的log捕获http协议的$request_body的正确方法
- BT源代码学习心得(七):跟踪服务器(Tracker)的代码分析(HTTP协议处理对象)
- 基础连接已经关闭: 该服务器提交了 HTTP 协议冲突?
- http协议中,url最大长度是多少?
- java中处理http连接超时的方法
- HTTP协议之长连接与短连接
- java中处理http连接超时
- web面试中,遇到无数次的问题“无状态的HTTP协议如何提供有状态的连接”?
- HTTP协议建立连接的方式
- HTTP协议--处理状态和返回状态码含义
- 网络篇——七层协议、四层协议、TCP、HTTP、SOCKET、长短连接
- HTTP 协议概要(一) 非持久连接
- HTTP/1.1 协议 8-10 持久连接( Persistent Connections)
- Getting error "No subject alternative names" when doing secure URL connection(针对处理https连接的安全异常)(转:http://www.coderanch.com/t/134
- BT源代码学习心得(七):跟踪服务器(Tracker)的代码分析(HTTP协议处理对象)
- java中处理http连接超时
- BT源代码学习心得(七):跟踪服务器(Tracker)的代码分析(HTTP协议处理对象) -- 转贴自 wolfenstein (NeverSayNever)
- HTTP协议之处理Cookie