http协议的keepalive属性

    君子予以义，小人予以利。

    踩到了一坨屎，你是把鞋子洗洗继续穿？还是把鞋子扔了？还是把脚砍了？

    在使用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负载不均衡。。。。

    很多时候，你会碰到各种挑战，有的时候是人的挑战，有的时候技术的挑战，当蒙着眼睛走路的时候，问题不会消失，当闭着眼睛看人的时候，这个人可能会消失，一个环境。

    当你不去看一个问题产生的本质原因的时候，其实也能解决问题，所谓的知其然不知其所以然。要想看本质原因，会花费大量的时间，而且需要关注各种各样的细节问题。不想keepalive了，想close了。。。

    解决了，那就算了吧，何必浪费时间。。。emmm，maybe。。。