首先申明标题党!
前几天,有一张图片访问404(从第三方站点拉去),后来查到原因是下载超过5s(wget带了超时参数--timeout=5),所以下载失败。但是直接访问原图又是非常快,基本感觉不到延时。开始怀疑是服务器网络原因,用host获取该域名的ip地址,无法ping通。
初步结论是:网络原因,无法ping通
服务器可能会设置禁ping,于是我就用wget不带超时下载了一次,发现确实可以下载,只是耗时非常严重,如图:
花了20s,才将此图完整下下来。换成curl来下载此图,结果如图:
结果就很明显,curl仅用1s的时间下载此图,而wget却用了20s才做完相同的事儿。我这并不是说curl的性能优于wget啊,换成其他网站url,时间消耗就差不多。那到底是什么原因才导致了如此巨大的差异了,勾起了我的好奇心。
用strace、tcpdump分别跟踪了wget和curl,摘取了相对核心的地方来做分析。
wget的strace结果
由于strace的内容比较多比较杂,为了方便分析摘出了比较核心的几处
- 11:52:37.877356 execve("/usr/bin/wget", ["wget", "http://newpic.jxnews.com.cn/0/11"], [/* 30 vars */]) = 0
- 11:52:37.899984 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
- 11:52:37.900043 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.55.21.254")}, 28) = 0
- 11:52:37.900114 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
- 11:52:37.900165 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
- 11:52:37.900215 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
- 11:52:37.900284 sendto(3, "\353J\1\0\0\1\0\0\0\0\0\0\6newpic\6jxnews\3com\2c"..., 38, MSG_NOSIGNAL, NULL, 0) = 38
- 11:52:37.900773 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 (Timeout)
- 11:52:47.900462 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
- 11:52:47.900529 sendto(3, "\353J\1\0\0\1\0\0\0\0\0\0\6newpic\6jxnews\3com\2c"..., 38, MSG_NOSIGNAL, NULL, 0) = 38
- 11:52:47.900606 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 (Timeout)
- 11:52:57.900996 close(3) = 0
- 11:52:57.901134 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
- 11:52:57.901192 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.55.21.254")}, 28) = 0
- 11:52:57.901270 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
- 11:52:57.901322 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
- 11:52:57.901374 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
- 11:52:57.901436 sendto(3, "c\237\1\0\0\1\0\0\0\0\0\0\6newpic\6jxnews\3com\2c"..., 50, MSG_NOSIGNAL, NULL, 0) = 50
- 11:52:57.901646 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
- 11:52:57.902350 ioctl(3, FIONREAD, [125]) = 0
- 11:52:57.902421 recvfrom(3, "c\237\201\203\0\1\0\0\0\1\0\0\6newpic\6jxnews\3com\2c"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.55.21.254")}, [16]) = 125
- 11:52:57.902516 close(3) = 0
- 11:52:57.902592 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
- 11:52:57.902647 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.55.21.254")}, 28) = 0
- 11:52:57.902707 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
- 11:52:57.902757 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
- 11:52:57.902808 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
- 11:52:57.902881 sendto(3, "\343\25\1\0\0\1\0\0\0\0\0\0\6newpic\6jxnews\3com\2c"..., 38, MSG_NOSIGNAL, NULL, 0) = 38
- 11:52:57.903027 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
- 11:52:57.983323 ioctl(3, FIONREAD, [92]) = 0
- 11:52:57.983394 recvfrom(3, "\343\25\201\200\0\1\0\1\0\2\0\0\6newpic\6jxnews\3com\2c"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.55.21.254")}, [16]) = 92
- 11:52:57.983482 close(3) = 0
- 11:52:57.983584 write(2, "59.52.28.153", 12) = 12
- 11:52:57.983707 write(2, "\n", 1) = 1
- 11:52:57.983825 open("/usr/share/locale/zh.GBK/LC_MESSAGES/wget.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
- 11:52:57.983905 open("/usr/share/locale/zh/LC_MESSAGES/wget.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
- 11:52:57.983979 write(2, "Connecting to newpic.jxnews.com."..., 55) = 55
- 11:52:57.984073 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
- 11:52:57.984139 connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("59.52.28.153")}, 16) = 0
- 11:52:58.045641 write(2, "\322\321\301\254\275\323\241\243\n", 9) = 9
- 11:52:58.045760 select(4, NULL, [3], NULL, {900, 0}) = 1 (out [3], left {900, 0})
- 11:52:58.045832 write(3, "GET /0/11/84/34/11843462_991618."..., 155) = 155
在11:52:37这一刻,执行wget命令。第一个较为重要的动作是做dns解析,向域名服务器10.55.21.254发起了两次数据包的长度是38字节查询请求,得到两次timeout,在11:52:57正式关闭了请求。
系统尝试向dns服务器10.55.21.254发送长度为50字节的数据包的查询请求,并获得返回结果(这里无法知道获知返回结果)。
系统在获得返回结果后,第四次向10.55.21.254发送请求,获得返回结果后,得到url的ip地址,发起了http请求。
通过已经分析,可以得到几个结论:
1、对域名解析方式上的差异导致wget和curl的耗时差别巨大
2、第三次改变数据包的查询,虽然获取得了返回,但并没有获取域名的ip
wget的tcpdump结果
tcpdump的结果图:
相对于strace的日志,tcpdump的就比较干净,为了方便分析,还是摘除了关键部分
- 11:52:37.900351 IP wapcms-169.54429 > dns.domain: 60234+ AAAA? newpic.jxnews.com.cn. (38)
- 11:52:47.900568 IP wapcms-169.54429 > dns.domain: 60234+ AAAA? newpic.jxnews.com.cn. (38)
- 11:52:57.901476 IP wapcms-169.46106 > dns.domain: 25503+ AAAA? newpic.jxnews.com.cn.localdomain. (50)
- 11:52:57.902233 IP dns.domain > wapcms-169.46106: 25503 NXDomain 0/1/0 (125)
- 11:52:57.902924 IP wapcms-169.58634 > dns.domain: 58133+ A? newpic.jxnews.com.cn. (38)
- 11:52:57.983135 IP dns.domain > wapcms-169.58634: 58133 1/2/0 A 59.52.28.153 (92)
很清晰的与strace的结果对应上了,两次38字节的数据包timeout,一次50字节的数据包,获得返回
NXDomain 0/1/0 (125),一次38字节的请求获得域名的ip地址:59.52.28.153
curl的strace结果
- execve("/usr/bin/curl", ["curl", "http://newpic.jxnews.com.cn/0/11", "-o", "1.jpg"], [/* 31 vars */]) = 0
- = 0
- socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
- connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.55.21.254")}, 28) = 0
- fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
- fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
- poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
- sendto(3, "\370T\1\0\0\1\0\0\0\0\0\0\6newpic\6jxnews\3com\2c"..., 38, MSG_NOSIGNAL, NULL, 0) = 38
- poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
- ioctl(3, FIONREAD, [92]) = 0
- recvfrom(3, "\370T\201\200\0\1\0\1\0\2\0\0\6newpic\6jxnews\3com\2c"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.55.21.254")}, [16]) = 92
- close(3)
- = 0
- socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
- fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
- fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
- connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("120.203.216.133")}, 16) = -1 EINPROGRESS (Operation now in progress)
- poll([{fd=3, events=POLLOUT}], 1, 300000) = 1 ([{fd=3, revents=POLLOUT}])
- getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
- sendto(3, "GET /0/11/84/34/11843462_991618."..., 194, MSG_NOSIGNAL, NULL, 0) = 194
很明显的发现,curl通过一次dns查询就获取了url的ip地址,然后就发起http请求。
curl的tcpdump结果
- 15:19:39.744520 IP wapcms-169.48990 > dns.domain: 63572+ A? newpic.jxnews.com.cn. (38)
- 15:19:39.744905 IP wapcms-169.38502 > dns.domain: 13836+ PTR? 254.21.55.10.in-addr.arpa. (43)
- 15:19:39.745626 IP dns.domain > wapcms-169.38502: 13836* 1/1/0 (86)
- 15:19:39.793797 IP dns.domain > wapcms-169.48990: 63572 1/2/0 A 120.203.216.133 (92)
- 15:19:39.793890 IP wapcms-169.31975 > dns.domain: 54867+ PTR? 133.216.203.120.in-addr.arpa. (46)
- 15:19:39.848460 IP dns.domain > wapcms-169.31975: 54867 NXDomain 0/1/0 (102)
从上面基本上可以得到结论,wget与curl在域名解析上有很大的不同。
通过查阅dns协议和tcpdump的输出数据格式得到结论是:
wget兼容IPv6,而curl不兼容,该url的dns解析20s的时间发生在解析IPv6上
引申:
host命令兼容IPv6 dig不兼容 (均为不带任何附加参数)
追加证明:
wget强制使用IPv4进行dns的结果如图:
注:
dns协议见附件,相关附带知识如下:
tcpdupm中dns数据包格式
域名服务请求的格式是
src>dst:idop?flagsqtypeqclassname(len)
h2opolo.1538>helios.domain:3+A?ucbvax.berkeley.edu.(37)
主机h2opolo访问helios上的域名服务,询问和ucbvax.berkeley.edu.关联的地址记录(qtype=A).查询号是 `3'.` +'表明设置了递归请求标志.查询长度是37字节,不包括UDP和IP头.查询操作是普通的Query操作,因此op域可以忽略.如果op设置成其他什么 东西,它应该显示在`3'和`+'之间.类似的,qclass是普通的C_IN类型,也被忽略了.其他类型的qclass应该在`A'后面显示.
Tcpdump 会检查一些不规则情况,相应的结果作为补充域放在方括号内:如果某个查询包含回答,名字服务或管理机构部分,就把ancount,nscount,或 arcount显示成`[na]',`[nn]'或`[nau]',这里的n代表相应的数量.如果在第二和第三字节中,任何一个回答位(AA,RA或 rcode)或任何一个`必须为零'的位被置位,就显示`[b2&3=x]',这里的x是报头第二和第三字节的16进制数.
UDP名字服务回答
名字服务回答的格式是
src>dst:idoprcodeflagsa/n/autypeclassdata(len)
helios.domain>h2opolo.1538:33/3/7A128.32.137.3(273)
helios.domain>h2opolo.1537:2NXDomain*0/1/0(97)
第一个例子里,helios回答了h2opolo发出的标识为3的询问,一共是3个回答记录,3个名字服务记录和7个管理结构记录.第一个回答纪录的类型是 A(地址),数据是internet地址128.32.137.3.回答的全长为273字节,不包括UDP和IP报头.作为A记录的class (C_IN)可以忽略op(询问)和rcode(NoError).
在第二个例子里,helios对标识为2的询问作出域名不存在(NXDomain)的回答,没有回答记录,一个名字服务记录,而且没有管理结构.
`*'表明设置了权威回答(authoritativeanswer).由于没有回答记录,这里就不显示type,class和data.
其他标志字符可以显示为`-'(没有设置递归有效(RA))和`|'(设置消息截短(TC)).如果`问题'部分没有有效的内容,就显示`[nq]'.
注意名字服务的询问和回答一般说来比较大,68字节的snaplen可能无法捕捉到足够的报文内容.如果你的确在研究名字服务的情况,可以使用-s选项增大捕捉缓冲区.`-s128'应该效果不错了.
IPv6的正向解析与反向解析
a. 正向解析
IPv4的地址正向解析的资源记录是“A”记录。IPv6地址的正向解析目前有两种资源记录,即,“AAAA”和“A6”记录。其中, “AAAA”较早提出<4>,它是对“A”记录的简单扩展,由于IP地址由32位扩展到128位,扩大了4倍,所以资源记录由“A”扩大成4 个“A”。“AAAA”用来表示域名和IPv6地址的对应关系,并不支持地址的层次性。
“A6”在RFC2874<5>中提出,它是把一个IPv6地址与多个“A6”记录建立联系,每个“A6”记录都只包含了IPv6地址的一部分,结合后拼装成一个完整的IPv6地址。“A6”记录支持一些“AAAA”所不具备的新特性,如地址聚合,地址更改(Renumber)等。
首先,“A6”记录方式根据TLA、NLA和SLA的分配层次把128位的IPv6的地址分解成为若干级的地址前缀和地址后缀,构成了一个地址链。每个地址前缀和地址后缀都是地址链上的一环,一个完整的地址链就组成一个IPv6地址。这种思想符合IPv6地址的层次结构,从而支持地址聚合。
其次,用户在改变ISP时,要随ISP改变而改变其拥有的IPv6地址。如果手工修改用户子网中所有在DNS中注册的地址,是一件非常繁琐的事情。而在用“A6”记录表示的地址链中,只要改变地址前缀对应的ISP名字即可,可以大大减少DNS中资源记录的修改。并且在地址分配层次中越靠近底层,所需要改动的越少。
b. 反向解析
IPv6反向解析的记录和IPv4一样,是“PTR”,但地址表示形式有两种。一种是用 “.”分隔的半字节16进制数字格式(Nibble Format),低位地址在前,高位地址在后,域后缀是“IP6.INT.”。另一种是二进制串(Bit-string)格式,以“\<”开头, 16进制地址(无分隔符,高位在前,低位在后)居中,地址后加“>”,域后缀是“IP6.ARPA.”。半字节16进制数字格式与“AAAA”对应,是对IPv4的简单扩展。二进制串格式与“A6”记录对应,地址也象“A6”一样,可以分成多级地址链表示,每一级的授权用“DNAME”记录。和 “A6”一样,二进制串格式也支持地址层次特性。
总之,以地址链形式表示的IPv6地址体现了地址的层次性,支持地址聚合和地址更改。但是,由于一次完整的地址解析分成多个步骤进行,需要按照地址的分配层次关系到不同的DNS服务器进行查询。所有的查询都成功才能得到完整的解析结果。这势必会延长解析时间,出错的机会也增加。因此,需要进一步改进DNS地址链功能,提高域名解析的速度才能为用户提供理想的服务。
转载于:https://blog.51cto.com/xdebug/1130815