5.nginx的keepalive和pipe

image

小张当上了村里的邮差，每日带着村民的信件到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，但是内部已然是一个一个处理，但是减少了处理完第一个请求，等待第二个请求的时间）