前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >http协议的keepalive属性

http协议的keepalive属性

作者头像
SRE运维实践
发布2019-07-08 14:50:15
1.1K0
发布2019-07-08 14:50:15
举报
文章被收录于专栏:SRE运维实践

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-05-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SRE运维实践 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
负载均衡
负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档