今天在使用 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 解析會這麼慢呢?

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 路漫漫啊……