你的位置: 首页 调试,问题分析

DNS优先查询ipv6地址导致curl延时

2016-03-29 16:09:15

起因

昨天有大活动,服务器进行扩容,跑的新封装的docker镜像,系统ubuntu14,发现用curl调用微信支付接口出现延时。能正确返回结果,但一般有三秒以上的延时。由于线上服务在跑,没有机会详细调试,于是先忽略之。

复现

今天在本地复现,一个简单的tcp连接,没有其他业务操作,时间花了3+,肯定哪里出了问题:

Machine generated alternative text: 2016/03/29  2016/03/29  2016/03/29  2016/03/29  2ø16/ø3/2g  go run main. go  48 4  10.  •08:44 1  • 48  remote ip:  lae. 2e7.69. lei : 443

12之间花了4秒,代码只有golangdial函数,测试完整代码如下:

package main

import (

    "net"

    "fmt"

    "log"

)

 

func main() {

    log.Println(1);

    conn,err:=net.Dial("tcp","api.mch.weixin.qq.com:443")

    log.Println(2);

    if err!=nil {

        fmt.Printf("error: %v",err);

    }

    log.Println(3);

   

   conn.Write([]byte("hello"));

   log.Printf("remote ip: %s",conn.RemoteAddr().String())

       

   log.Println(4);

   

}

反馈给微信技术

联系到昨天在阿里云的服务器上的现象,怀疑是不是微信支付服务器出现网络问题,于是发封邮件反馈之,不料马上被呛了回来,我只能说:从来没有见过如此理直气壮让我滚回去查代码的客服:

Machine generated alternative text: Re: api.mch.weixin.qq.com 连 接 出 现 数 秒 延 时 (Internet mail)  wepayTS ( 微 信 支 付 技 术 支 持 ) to 宁 克 凡  检 查 你 自 己 的 服 务 器 哦 。  we payTS ( 微 信 支 付 技 术 支 持 )

相比而言阿里的同学还是好多了,发工单基本能回,不是他们问题也能帮忙协助分析,给些建议。

继续分析

对这样的回复我只能表示无语,不过也只能无奈的继续分析,本来准备抓包把结果丢他们糊他们一脸,结果却发现了一些有意思的事情:

Machine generated alternative text: Spanning-t ree-( fo r...  223.6.6.6  192. 168.29. 107  54. 187. 165. 177  52.72.21.113  Apple_ed : Of: 11  TendaTec 00: 18: 90  223.6.6.6  192. 168.29.  192. 168.29. 107  5 14.  192. 168.29. 107  .qq. co  192. 168.29. 107  192. 168.29. 107  .qq.com  192. 168.29. 107  qq.com  6 14:11:26.362347  7 14:11:26.886616  8 155791  9 14:11:27. 155792  0 14:11:28.935354  2 14:11:29.653388  4 14:11:29.663853  27 • 9UUU45  TendaTec 18:90  192. 168.29. 107  223.6.6.6  192. 168.29. 107  192. 168.29. 107  TendaTec 00: 18: 90  Apple_ed : Of: 11  192. 168.29. 107  54. 187.165. 177  52.72.21. 113  TendaTec 18:SO  192. 168.29. 107  192. 168.29. 107  52.72.21. 113  192. 168.29. 109  fe8Ø: :8db: 3061: die...  STP  DNS  DNS  TCP  TCP  ARP  ARP  DNS  TCP  TCP  STP  TCP  DNS  TCP  MDNS  MDNS  DNS  DNS  DNS  DNS  81  135  54  54  42  4  66  52  54  74  66  136  74  74  74  74  Standard uer A  a i. mch.weixin.  . com  Standard query response  øx3420 A api.mch.weixin.qq. com CNAME forward.qq.c  55240 443 LACK] seq=l Ack=l Win=4Ø96 Len=Ø  55238 443 LACK] seq=l  Ack=l Win=4Ø96 Len=Ø  Who has 192.168.29.107?  Tell 192.168.29.1  Standard query Ox49f7 AAAA forward.qq.com  „—ueq=l Ack=2 Win=86 Len=Ø TSv  [TCP ACKed unseen segment] 443  -4 55238 LACK] Seq=l Ack=2 Win=79 Len=Ø TSv  Spanning—t to r...  52.72.21.113  223.6.6.6  192.168.29.107  224.ø.ø.251  ffØ2:  223.5.5.5  Cont. Root -  - Cost =  55239 443 LACK] seq=l Ack=l Win=4Ø96 Len=Ø  Standard query Ox49f7 AAAA forward.qq.com  — Øxbuu2  [TCP ACKed unseen segment] 443  -4 55239 LACK] seq=l Ack=2 Win=9Ø Len=Ø TSv  Standard  an ar  Standa rd  Standard  Standar  Standa rd  query  query  query  uer  query  query  response ØXØØØØ TXT, cache flush OPT  response x  cac e  us  223.  6.6.6  223.  6.6.6  223.5.5.5  response Ox49f7 Server failure  Øx49f7 AAAA forward.  . com  response Øx49f7 Server fai ure  response Ox49f7 Server failure  AAAA  AAAA  AAAA  forwa rd  forwar  forwa rd.

先查询A记录,然后被cname然后查询AAAA记录,AAAA记录就是ipv6版本的A记录,结果dns服务器返回了查询失败,几个来回几秒的时间就过去了。然后ipv6地址解析失败,继续解析ipv4的地址,能正常解析,访问了。

所以延时的原因应该就清楚了,curl先去解析ipv6的记录,然后再解析ipv4的记录,这样出现了延时

疑问

为什么同样是ubuntu14,我们其他的服务器没有出现,单单docker里面每次都延时?

:其他服务器默认开启了nscd,缓存了dns查询记录,不会每次查询,所以对业务的影响就很小了。

 

如何解决

优先方案是开nscd缓存服务,因为不只是解析ipv6的问题,频繁解析dns有很大的时间开销。

然后换个好点的dns,优先ipv6策略越来越多的被使用,为什么影响还不大,因为即使是dns查询失败也可以很快时间的返回,试验过好几个dns,有的dnsAAAA记录即使没有,但是返回时间很短,阿里的dns就卡了数秒,可能跟dns策略有关系。

修改系统配置可能有用,有搜到/etc/gai.conf,但是试验是没效果的,有兴趣的可以研究下。参考:https://community.rackspace.com/products/f/25/t/5110

最次是写host文件,紧急情况下可以用,但一定只能作为临时救急手段。


©翟四岚 1989-2089