今天在使用 php 的 curl 函数时,发现需要等待大概 5 秒才能得到结果,实在是太慢了。而同样一个 url 使用浏览器访问,则立刻可以获得页面。后来又发现,即使不用 php,使用 Linux 下的原生命令 wget 去获取网页,也很慢。这真是太奇怪了,看上去不是程序的原因,而是网络设置的问题了。
执行 wget 时可以明显看到,阻塞发生在 DNS 域名解析的部分。
$ wget www.myproject.com
--2012-06-18 12:17:30-- http://www.myproject.com/
Resolving www.myproject.com... # 此处停滞约 5 秒
192.168.1.187
Connecting to www.myproject.com|192.168.1.187|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: index.html?
[ ] 5,200 --.-K/s in 0s
2012-06-18 12:17:35 (264 MB/s) - index.html saved [5200]
我使用的是开发环境,域名解析到一个内部 IP 上。奇怪的是,我使用 ping www.myproject.com 却很快可以获得 IP 地址并返回 ICMP 报文。为什么 wget 的 DNS 解析会这么慢呢?www.2cto.com
Google 到 StackOverflow 上面也有很多人提这个问题,有说是 reverse DNS 反向域名解析的问题,有说要在 host 文件中添加那个域名……都无法解决我的问题。百思不得其解之际,突然想到上周是 IPv6 日,我们运维发过一封邮件说公司网络已经全部 enable IPv6 了。会不会是这个原因呢?按照这个线索去查,果然,豁然开朗了。
$ wget -4 www.myproject.com
瞬间就返回了结果。看来是运维没有帮我们为这个域名绑定一个 IPv6 的地址,整个网络升级后,默认会优先解析 IPv6,在那个 domain 没有 IPv6 的情况下,会等待 IPv6 解析失败 timeout 之后才按以前的正常流程去找 IPv4。
对于 PHP curl 来讲,只需要加上下面一句即可解决延迟问题:
curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );
现在很多服务器都开启了 IPv6 却没有路由,无法真正工作,反而导致一些不可预料的问题。深切地体会到 IPv6 路漫漫啊……