http协议的keepalive属性

keep-alive

在使用http的时候，有1.0的协议，有1.1的协议，两者最大的区别就是1.0的协议会将connection设置为close，从而是一种短连接的状态，从而每次进行传输数据的时候，都要三次握手，损耗性能，从而在1.1的协议中进行了改进，默认使用的连接保持的属性，从而提高了性能。

背景：在一些特殊的场景中，一旦使用的是1.0的协议，那么就会造成一些业务失败。

长连接短连接傻傻分不清楚，长连接好处那么多，我们就必须使用长连接么，并不一定，在进行健康检查的时候，就需要使用短连接，emmm，看来好像在健康检查的时候使用短连接也是可以的，但是想象一种场景，如果有几万个vip呢，都进行长连接的健康检查，那么就会造成一种情况，所有的请求都在排队等待连接的释放，所以对于大量的vip来说，还是需要使用短连接的方式。

指定使用http 1.0的协议，进行抓包，在不同的机器上进行请求：

在使用curl的时候，-I表示仅返回头文件，-0表示使用http1.0的协议，-H表示带http头属性，抓包结果如下：

当使用http1.0而不带http头呢？

抓包结果如下：

从上面可以看到，nginx偷偷修改了协议，但是在使用属性的时候，依然是根据客户端发送的http头直接进行的转发。

使用默认情况下的发送都是http1.1的协议，如下：

抓包结果如下：

只听说过升协议，从1.0升级到1.1，但是降协议，居然还有这种操作。。。只有你想不到，没有做不到。

转发的时候是否需要使用keep-alive属性，也是一个选择的过程，对于大量的连接来说，还是需要使用close的形式。长连接太多，vip组件无法承担那么大的压力。

对于这种问题如何进行诊断呢？主要就是将请求发送到后端的rs，然后发一个请求到nginx，进行抓包对比，看看哪些地方发生了变化，例如请求的协议，例如请求的属性。在使用浏览器的时候，默认发送的都是1.1协议，但是如果返回来的也是1.1协议，在浏览器的F12中看不出来任何变化，还是需要直接在rs上进行抓包比对。

再说解决方案，当出现问题的时候，有多少种解决方案可选？原则都是优先解决问题。

既然7层的负载均衡搞不定了，那就试试4层，毕竟lvs在使用的时候，单纯作为一个转发器，不会那么复杂。

如何确定是负载均衡的问题，那么也是通过抓包来进行比对。发到负载均衡上，发到后端的rs上。

负载不均衡怎么办？在很多时候，lvs是根据源ip进行会话保持，其实nginx的ip_hash也是这种会话保持，当你最前端的是F5的时候，那么又选择那种负载均衡呢？都会导致后端的rs负载不均衡。。。。