最新消息:雨落星辰是一个专注网站SEO优化、网站SEO诊断、搜索引擎研究、网络营销推广、网站策划运营及站长类的自媒体原创博客

如何优化nginx三次握手时间

网站源码admin2浏览0评论

如何优化nginx三次握手时间

序言

在http的场景中,三次握手必不可少,在不同的场景中有不同的优化方法,在追求性能的时候,优化是一件比较难得事,而且可能毫无价值。

既然你不听劝,那就打到你听为止。

优化nginx三次握手

1 背景

当nginx作为反向代理的时候,客户端去连接nginx,那么就会进行三次握手,这个时间大概是1.5个RTT的时间,而在互联网时代,现在基本上都是https,而https大概需要2个RTT的时间,从而建连之后,大概就需要3.5个RTT时间。

如果你做的是跨云跨洋的场景,每次的RTT需要170ms的时候,就会感觉很痛苦了,因为这些握手的时间好长。例如从国内去访问海外的aws云,那么这个耗时大概就要500ms了。

2 初始架构

在一般的概念之中,数据链路走的代理越少越好,从而就会产生一种架构,dns解析直接到aws的nginx上,从而只有一层代理,这样访问的性能最快。

但是这就会碰到上面的背景问题,初始化的连接耗时很高。

看到这种情况之后,你会怎么来优化这个性能,如果你要看到对应的耗时,可以通过浏览器访问的时候,按F12查看连接的耗时,发现大概在500ms。

3 优化架构

跨洋的时候建连耗时比较高,那么就采用另外一种架构,使用双层的nginx嵌套结构,在国内阿里云这边也使用一组nginx,将dns解析放到国内阿里云这边,而这组nginx将反代到跨洋的nginx中,从而让三次握手的时间放在国内,从而能大大减少建连的时间,那么就直接能从500ms降低到100ms,为什么会效果这么明显?

一般的人都会很好奇,用一个nginx就可以了,你还用两个,累不累,是不是有点反直觉,总会觉得经过2层代理的性能肯定没有经过1层代理的性能高?

但是细细一想,国内的连接的时候,每次都是十几ms,那么即使3.5个RTT,也就100ms,而在进行代理的时候,虽然国内的nginx到跨洋的nginx之间的耗时高,但是只要开启了upstream的长连接,那么就必然大大减少这种耗时的情况,长连接不但能减少耗时,而且拥塞窗口也可以一直保持满载的状态,从而性能大大提升。

为什么用2组nginx比1组nginx好?这就是长连接的好处。

4 优化后架构出现的问题

在使用优化后的架构跑了几天之后,发现502的数量大大增加,从修改了架构之后就出现了,而出现502的时候,基本上都是连接被上游断开,也就是海外的nginx将客户端的连接直接断开。

当时看了一下国内的报错,有upstream 过早的关闭连接的报错,或者是connection reset by peer。嵌套nginx的时候出现报错,其实也是长连接带来的问题,因为nginx有两个长连接,一个长连接是针对客户端的,这个keepalive_timeout的时间一般是60秒,默认值,而对于nginx连接池来说,一般设置为3分钟,从而就会导致第一个nginx认为没有超时,但是第二个nginx认为空闲超时到了60秒,就关闭了连接。

这个时候的解决方案就是将第一组nginx的upstream超时时间修改为50秒,从而确保第一组的连接不会被第二组的nginx进行关闭。

你以为这就完了吗?发现并没有减少502的情况,从而我们在第一组nginx上进行抓包,看看长连接到底多久被关闭,然而并没有抓到是因为超时时间关闭了连接,而是第二组nginx直接发送了reset包,直接关闭了连接。

看到这就感觉很烦了,突然就reset干啥,从而直接在第二组nginx上进行抓包,发现的确是nginx进行reset的,而且对于第二组后端的连接也同时发送了FIN包,而且在这个时间段内,很多的reset包,仔细一看,感觉是所有的长连接全部断开。

到第二组nginx查看一下错误日志,日志很多,很烦,看到里面很多各种缓存的数据,qps也不少,然后不停的过滤日志,突然看到一条日志,worker process exited,也就是说,worker进程出现了oom,直接被杀死,从而也就找到了原因,发送reset包的原因是因为worker进程占用的内存太大,直接被oom kill。

最终解决方案,就是将第二组nginx的内存进行扩容,扩容之后观察了几天,502的告警就没有了。

嵌套代理,对于长连接来说,有点麻烦,因为一层nginx的时间好配置,而对于2层,3层代理来说,每一层都要考虑对应长连接参数,客户端的一定小于服务端的长连接时间,毕竟对于nginx来说,这个长连接是没有探活数据包的。就像数据库的连接池,最好开启探活包,否则也会出现这样,突然这个连接就被中断了。

风言风语

用多层代理,有的时候也要看场景,是否要用,为了解决什么问题,是否能更好的优化性能?

本来挺喜欢风的,后来太忙了,忙忘了。

优化性能,其实非常耗费时间,就像这种性能优化加上解决问题的时间,来来回回一周了,还要观察,还要运气好,刚好能抓到那个包,否则就只能干瞪眼。

总是听到人谈价值,但是每个人都想着去汇报价值,实际的事情就没人做了,脏活累活是出不了成绩的,卷就能有价值?可能也是毫无价值。。。。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。原始发表:2025-04-25,如有侵权请联系 cloudcommunity@tencent 删除连接性能优化nginx代理

与本文相关的文章

发布评论

评论列表(0)

  1. 暂无评论