聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

一次ipv6地址查询导致网络请求耗时问题的分析解决

2022-01-06 10:45 浏览: 2874174 次 我要评论(0 条) 字号:

「 关注“石杉的架构笔记”,大厂架构经验倾囊相授 

“从零开始带你成为JVM实战高手” 免费加餐啦!

点击查看 专栏目录


【文章作者/来源】学多两年Java就去送外卖/https://sourl.cn/b5H59i


问题背景




两个月前的一个版本需要对接腾讯会议相关接口,需要接收腾讯会议事件变更回调,腾讯会议通过webhook的形式发送http请求到我们的测试环境服务中,暂且称之为A服务,假设域名为a.test.abc.com

在保存接口配置的时候,腾讯会议对接口url进行可用性的校验,3秒内进行响应,并正确返回即可进行配置。


问题现象




在配置的过程中出现了异常提示,无法正常保存配置,反复操作十几次后,才正常保存成功一次(具体原因可参考文末第五节)。如图所示:


问题排查




排查接口是否存在复杂逻辑

  • 接口是简单的GET请求返回base64解码后的字符串,没有做任何特殊处理。

  • 排查controller层发现无特殊的aop耗时逻辑。

  • 在本地电脑上使用Postman模拟请求,无论是公司内网或者外网调用接口响应时间都很快,均在200ms内响应。

与相关方收集接口请求数据

与腾讯会议后端负责人沟通,腾讯后端负责人排查日志发现,腾讯会议后端发起http调用A服务测试环境url超时

临时解决方案

为了避免影响送测,我们临时在线上阿里云服务上的某个服务做了一层请求中转,让腾讯云把请求打到了线上服务,线上服务通过okhttp发起第二次http请求转发到测试服务中。

经过这层中转临时解决了问题,实现了业务正常回调。

可是对于测试环境来说,阿里云线上的服务器一样是外网环境,为什么我们的服务调用测试环境没有问题,而腾讯的服务调用就超时呢?文末第五节有谈到问题解析

排查网络链路问题

排查链路问题之前,尝试用自己的服务器和线上服务器部署了简单的web服务,提供回调接口,均可正常配置。基本可以确定腾讯会议服务访问A服务测试环境存在耗时问题。

模拟外网请求测试环境接口,查看耗时

使用curl模拟外网请求测试环境接口,打印各个环节耗时:

  • 选择阿里云多台容器测试:

  • 使用腾讯云服务器测试:

可以发现,在域名查找(time_namelookup)这个环节耗费了绝大部分时间。

而tcp连接、http请求响应、数据传输的环节耗时非常低,均在200ms左右。

curl代码示例

curl -w "time_namelookup:%{time_namelookup}ntime_connect:%{time_connect}ntime_pretransfer:%{time_pretransfer}ntime_starttransfer:%{time_starttransfer}ntime_total:%{time_total}n" -o /dev/null -s -L  "https://a.test.abc.com/server-main/api/v1/meeting/disable/callback?check_str=xxx(此处填上url)"

curl部分参数对应关系

参数描述
time_total总时间,按秒计。精确到小数点后三位
time_namelookupDNS解析时间,从请求开始到DNS解析完毕所用时间
time_connect连接时间,从开始到建立TCP连接完成所用时间,包括DNS解析时间(得到连接时间=time_connect-time_namelookup)
time_appconnect连接建立完成时间,如SSL/SSH等建立连接或者完成三次握手时间
time_pretransfer从开始到准备传输的时间
time_redirect重定向时间,包括到最后一次传输前的几次重定向的DNS解析,连接,预传输,传输时间
time_starttransfer开始传输时间。在client发出请求之后,Web 服务器返回数据的第一个字节所用的时间

观察服务入口流量

使用tcpdump对A服务流量入口进行抓包操作,将日志dump到本地,使用wireshark进行分析可以发现。从建立TCP连接开始到发起http请求,耗时确实很低,与上面打印的时间相符

tcpdump命令

tcpdump -i eth0 -s 0 -w tcp.pcap

观察外网调用方发起http请求的流量详情

依然通过tcpdump进行抓包和分析,可以发现,仅使用0.3ms,dns服务器就已经返回了域名对应的ip地址。但是完成这步操作之后,客户端没有开始建立tcp连接,而是继续查找AAAA a.test.abc.com的操作,而这一步耗时长达5秒多,完全符合4.1中的耗时情况。

此处query AAAA的操作为查找ipv6地址,每一次curl请求都发出了两次DNS  query,一个是A记录,另外一个是AAAA记录,也就是同时请求了IPV4和IPV6地址。IPV4很快就返回了结果,而IPV6则常常耗时长达5秒(IPV6请求会被forward到upstream的DNS),且最终返回NXDomain无IP结果。

验证问题

对curl请求加上-4参数,直接使用Ipv4地址进行请求,验证是否是ipv6地址查询耗时导致。确实非常快得到了响应。至此,问题已经被验证。


解决方案




带着问题和数据包,向运维求助。最终由运维的同事针对*.test.abc.com的泛cname做ipv6的假响应配置,即不做任何处理,直接返回NXDomain。问题得到解决。


过程遇到的其他问题




1.阿里云线上环境请求测试环境也存在耗时的情况,那为什么在临时解决方案中使用了中转服务可以正常使用呢?

定位okhttp的源码可以发现,okhttp会解析http请求url的域名,在域名第一次请求获取ip的时候,将域名和ip进行一一对应的缓存,并且这个缓存操作与操作系统级别的dns缓存不同,是没有过期时间的

所以可能会存在第一次请求的时候耗时较长的情况。但是经过第一次请求后,后面发起的http请求都是直接用ip地址进行请求,无需再次解析。

代码位置:java.net.InetAddress#getAllByName0(java.lang.String, java.net.InetAddress, boolean)

2.腾讯会议服务多次保存只有少数次可以成功

猜测依然是与上面一样存在ip缓存的机制,由于现在绝大部分web服务都是分布式地部署多台容器,多次http请求中,只要有两次走到了同一台机器上,即可使用组件缓存的ip地址直接请求。

-------------  END  -------------

欢迎小伙伴们加入后端技术交流圈,一个大牛云集的技术交流和面经分享社群。
扫描下方二维码,暗号:加群


点个在看你最好看



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复