为何curl请求总是延时5s

引言：本文描述了我对于"为何请求总是延时5s"问题的分析、解决过程.

1. 初识

最近公司项目遇到一个比较奇怪的问题，现象是在我们的系统（centos6）中发的请求包，总是需要延时5s才能成功. 一想到超时，第一感觉应该就是网络差，于是通过curl www.baidu.com验证，发现也是延时5s才返回，因此第一个结论：网络差

为了进一步确认，尝试在同一网络下其他PC机（Windows）上访问百度网页，发现比较快，并确定不是缓存，于是就有了第一个疑问，"为什么相同网络下不同PC访问百度的时间差别这么大？"

2. 误打误撞

针对第一个疑问，对比了PC机的网络配置，是完全一样的，这就无法解释了。就在没有方向的时候，尝试用IP访问，curl 163.177.151.109，发现速度很快，突然想到我们的请求也是使用域名. 于是自然就转向了DNS，是不是DNS解析慢，于是尝试更换了几个DNS（114.114.114.114、8.8.8.8），可是发现问题依旧.

3. DNS充电

既然问题已经定位在与DNS有关，于是我查阅了资料，了解了DNS的工作流程，如下：

递归查询 - A找B要东西；B发现自己没有，B找C要；C给B；B再给A
迭代查询 - A找B要东西；B发现自己没有于是告知A，C有；A找C要，C给A

递归查询一般用于本地DNS服务器，迭代查询用于DNS服务器之间

言归正传，于是我使用nslook www.baidu.com发现可以快速返回，因此猜测DNS可以正常获取

4. 再抓包

为了找出原因，我使出了杀手锏，用tcpdump抓包，tcpdump -nn host 114.114.114.114

<pre>
00:27:09.459055 IP 192.168.1.88.49776 > 114.114.114.114.53: 33750+ A? www.baidu.com. (31)
00:27:09.459067 IP 192.168.1.88.49776 > 114.114.114.114.53: 46955+ AAAA? www.baidu.com. (31)
00:27:09.482865 IP 114.114.114.114.53 > 192.168.1.88.49776: 33750 3/0/0 CNAME www.a.shifen.com., A 14.215.177.37, A 14.215.177.38 (90)
00:27:14.459055 IP 192.168.1.88.49776 > 114.114.114.114.53: 33750+ A? www.baidu.com. (31)
00:27:14.482865 IP 114.114.114.114.53 > 192.168.1.88.49776: 33750 3/0/0 CNAME www.a.shifen.com., A 14.215.177.37, A 14.215.177.38 (90)
00:27:14.459067 IP 192.168.1.88.49776 > 114.114.114.114.53: 46955+ AAAA? www.baidu.com. (31)
00:27:14.482898 IP 114.114.114.114.53 > 192.168.1.88.49776: 46955 1/1/0 CNAME www.a.shifen.com. (115)
</pre>
发现客户端发起A、AAAA的查询，但服务端只回了A，没有回AAAA，于是客户端等待超时后，继续单条单条查询，成功返回. 为了对比，我们再正常PC上也抓包，结果如下：

因此初步断定，是由于无法获取到ipv6地址导致延时，于是通过curl -4 www.baidu.com发现确实没有延时. 可是为什么会获取不到ipv6呢，单条发送是可以正常返回，于是猜到可能是防火墙再搞鬼. 这其中正好发现了这篇《centos 6中single-request-reopen参数说明》文章

image

5. 结论

综上所述，最终原因出在了防火墙上，但目前防火墙配置不在我们这边，暂时还无法得知，但应该基本可以确定是防火墙搞的鬼，具体的解决方案在/etc/resolv.conf添加以下参数options single-request-reopen

6. 总结

以上是描述了我对"为何请求总是延时5s"问题的追踪过程，从中学到了DNS解析流程、dig命令，可谓甚丰.