小张当上了村里的邮差,每日带着村民的信件到nginx帝国,傍晚带着大量的回信回到村子。小张去了师傅家里,师傅听了小张讲述的已经逐渐熟悉了的server_name匹配顺序和规则,又从房间拿出了一些新的工具牌。nginx协议http 1.0和http 1.1是支持长连接的。http基于tcp协议之下,一次请求,需要建立tcp链接,而tcp链接是需要三次握手进行确定,结束请求需要四次交互。这种方式nginx需要耗费资源,时间开销都会影响整体速度。
而如果知道请求头和响应体的长度,我们是可以在在一个链接上执行多个请求。如post请求,我们在请求头上加上请求体body的大小用content-length表示,否则返回400错误。请求体是确定的,响应体中body的长度:
1.http 1.0中响应头中有content-length头,就是响应体body的长度,取出对应的长度的数据就可以结束了。如果nginx的响应头没有给出content-length头信息,那么就一直接受数据,等待nginx自动结束。
2.http 1.1中响应头中的transfer-encoding为chunked传输,代表流式输出,body体被分为几个块,每块的开始都会标注当前块的长度,body不需要指定长度。非chunked传输时,有content-length头信息,则接受对应长度的数据,没有则等待nginx传输结束自动结束掉请求。
除了上面两种不知道响应体长度的,body的长度是可以知道的。这时候,我可以在请求头中增加connection信息,当对应的值为keepalive时,代表为长连接,nginx在输出响应体之后,并不关闭连接,而是等待下一次的请求。http 1.0中connection的值默认为cloes,而http 1.1默认keep-alive。
小张拿着师傅给的工具牌,有了这keepalive,将信件归类之后,速度就快多了。
老王:当然,你速度也要快,nginx看到keep-alive之后,不会马上关闭连接,但是也不可能一直等待。nginx设置了keepalive链接属性和一个keepalive_timeout等待时间,超出这个时间,nginx还没有收到请求,就会关掉链接。keepalive_timeout也可以配置为0,这样表示nginx不接受长连接,无论请求头是否添加了keepalive属性。(如果有大量的请求,开启长连接,nginx可以减少大量的tine-wait)。
小张:那这个pipe有什么用呢?
老王:这是http 1.1的属性,pipeline是基于长连接的,目的是用一个链接做多次请求。对于keepalive,多个请求中第二个请求必须等待第一个请求结束,pipeline可以在第一个请求没有结束就发起第二个请求。(nginx支持pipeline,但是内部已然是一个一个处理,但是减少了处理完第一个请求,等待第二个请求的时间)