一、问题背景

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

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

二、问题现象

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

三、问题排查

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

• 接口是简单的GET请求返回base64解码后的字符串，没有做任何特殊处理。
• 排查controller层发现无特殊的aop耗时逻辑。
• 在本地电脑上使用Postman模拟请求，无论是公司内网或者外网调用接口响应时间都很快，均在200ms内响应。

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

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

3.临时解决方案

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

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

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

4.排查网络链路问题

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

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

使用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部分参数对应关系

4.2观察服务入口流量

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

tcpdump命令

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

4.3观察外网调用方发起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结果。

4.4验证问题

对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地址直接请求。