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