云网络运维常用命令工具

一、网络常见排障命令工具

1.1 ping命令

ping 命令是基于 ICMP 协议来工作的，ICMP全称为 Internet 控制报文协议（Internet Control Message Protocol）。ping 命令会发送一份ICMP回显请求报文给目标主机，并等待目标主机返回ICMP回显应答。因为ICMP协议会要求目标主机在收到消息之后，必须返回ICMP应答消息给源主机，如果源主机在一定时间内收到了目标主机的应答，则表明两台主机之间网络是可达的。除了监测是否可达以外，还可以利用应答时间和发起时间之间的差值，计算出数据包的延迟耗时。

1.1.1 ping 用法说明

1.1.2 Ping常用参数

1.1.3 ping场景测试

使用awk可以让ping命令记录时间：

ping www.aliyun.com | awk '{ print $0"\t" strftime("%Y-%m-%d %H:%M:%S",systime()) } '

1.1.4 失败排障

1.2 traceroute命令

通过traceroute我们可以知道信息从你的计算机到互联网另一端的主机是走的什么路径。当然每次数据包由某一同样的出发点（source）到达某一同样的目的地(destination)走的路径可能会不一样，但基本上来说大部分时候所走的路由是相同的。linux系统中，我们称之为traceroute,在Windows中为tracert。

1.2.1 traceroute 用法说明

Usage:

traceroute [ -46dFITnreAUDV ] [ -f first_ttl ] [ -g gate,... ] [ -i device ] [ -m max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l flow_label ] [ -w waittime ] [ -q nqueries ] [ -s src_addr ] [ -z sendwait ] [ --fwmark=num ] host [ packetlen ]

1.2.2 traceroute 常用参数

1.2.3 traceroute 场景测试

有时我们traceroute 一台主机时，会看到有一些行是以星号表示的。出现这样的情况，可能是防火墙封掉了ICMP的返回信息或者ICMP选择性回应策略，所以我们得不到什么相关的数据包返回数据。具体看是否有故障，可以通过观察后面的跳数是否正常回显；

另外，traceroute尽可能收集双向，因为有时候单向可能不丢包，反向会丢包；另外双向信息才能完全确认数据包所走的来回路径；

1.3 mtr命令

MTR 通过更大的采样来跟踪路由，就像 traceroute + ping 命令的组合;相比之下，诸如 traceroute 和 MTR 之类的工具会以递增增加的 TTL 发送 ICMP 数据包，以便查看数据包在源和目的地之间进行的路由或一系列跳数。 TTL 或生存时间控制数据包在“死亡”并返回主机之前将产生多少“跳”。通过发送一系列数据包，使它们在一跳之后死亡并返回，然后两个，然后三个，客户端机器能够组合在因特网上的主机之间的流量所占用的路由。

1.3.1 mtr 用法说明

1.3.2 mtr 常用参数

3.3.3 mtr 场景测试

mtr 111.62.76.149

第一列：显示IP

第二列： 丢包率；

第三列： snt : 每秒发送数据包的数量，默认值是10

第四列： 显示最近一次的返回时延

第五列： 发送ping包的平均时延

第六列： 时延最短时间

第七列： 最长时延

第八列： 标准偏差

默认情况下是使用ICMP报文探测，不过可以指定TCP或者UDP协议以及端口；新版本的MTR现在能够在TCP模式下以指定的TCP端口运行。在某些情况下，网络劣化只会影响某些端口，或者路由器上错误配置的防火墙规则可能会阻塞一定的协议。在某个端口上运行MTR可能会显示丢包，默认的ICMP报告可能没有。因此，有时候我们可以更细化到端口用UDP或者TCP去看客户反馈的丢包情况。

mtr --tcp --port 80 111.62.76.149 tcp延迟会比默认icmp大50ms左右；

（1）验证数据包丢失

如果您在任何特定跳点看到一定百分比的丢失，这可能表明该特定路由器存在问题。然而，一些服务提供商通常的做法是限制 MTR 使用的ICMP流量。这实际上没有损失可以给出丢包的错觉。要确定您看到的损失是真实的还是由于速率限制，请查看随后的一跳，如果该跳丢包率是0.0％，那么您可以确定您看到 ICMP 速率限制，而不是实际丢包。如上图的7、8跳。

（2）ICMP速率限制

如上图5、6跳，当丢包到一跳不持续到后续跳数时，丢失是由ICMP限制引起的；

1.4 netstat命令

Netstat 是一款命令行工具，可用于列出系统上所有的网络套接字连接情况，包括 tcp, udp 以及 unix 套接字，另外它还能列出处于监听状态（即等待接入请求）的套接字。

1.4.1 netstat 用法说明

1.4.2 netstat 常用参数

1.4.2 netstat 场景测试

（1）最简单的命令：列出所有当前的连接。使用 -a 选项即可。

netstat -a

（2）只列出监听中的连接

netstat -tnl

注意：不要使用 -a 选项，否则 netstat 会列出所有连接，而不仅仅是监听端口。

（3）查看TCP连接状态（适用于看客户机器连接数情况）

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 或

netstat -n |awk '/^tcp/ {print $NF}'|sort|uniq -c|sort -rn 或

netstat -ant | awk '{print $NF}' | grep -v '[a-z]' | sort | uniq -c

它会显示例如下面的信息：

TIME_WAIT 814

CLOSE_WAIT 1

FIN_WAIT1 1

ESTABLISHED 634

SYN_RECV 2

LAST_ACK 1

常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

看哪些连接了

netstat -na|grep ESTABLISHED | awk '{print $5}'|awk -F: '{print $1}' |sort|uniq -c|sort -r

常见的问题有两个：

1.服务器保持了大量TIME_WAIT状态

2.服务器保持了大量CLOSE_WAIT状态

http://www.cnblogs.com/sunxucool/p/3449068.html

（4）查找请求数前20个IP（常用于查找攻来源）：

netstat -anlp|grep 80|grep tcp|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -nr|head -n20

netstat -ant |awk '/:80/{split($5,ip,":");++A[ip[1]]}END{for(i in A) print A[i],i}' |sort -rn|head -n20

（5）查找较多time_wait连接

netstat -n|grep TIME_WAIT|awk '{print $5}'|sort|uniq -c|sort -rn|head -n20

（6）找查较多的SYN连接

netstat -an | grep SYN | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -nr | more

（7）经典NAT环境时间戳校验导致丢包，TCP队列过满导致丢包等；常常和机器的/var/log/messages错误日志输出的信息一起排障。

netstat -s

AWK教程用法：https://coolshell.cn/articles/9070.html

1.5 tcpdump抓包命令

1.5.1 tcpdump用法说明

Usage: tcpdump [-aAbdDefhHIJKlLnNOpqRStuUvxX] [-B size] [-c count]

[-C file_size] [-E algo:secret] [-F file] [-G seconds]

[-i interface] [-j tstamptype] [-M secret]

[-P in|out|inout]

[-r file] [-s snaplen] [-T type] [-V file] [-w file]

[-W filecount] [-y datalinktype] [-z command]

[-Z user] [expression]

1.5.2 tcpdump常用参数

1.5.3 tcpdump场景测试

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型

(2)-i eth1 : 只抓经过接口eth1的包

(3)-t : 不显示时间戳

(4)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包

(5)-c 100 : 只抓取100个数据包

(6)dst port ! 22 : 不抓取目标端口是22的数据包

(7)src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24

(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析；

1.5.4 tcpdump循环抓包

有时候需要等问题复现，但是抓包又不能一直进行，担心抓包量大消耗磁盘，可以采用循环抓包；主要是合理使用-C和-W的参数。

tcpdump -i xxx -C 500 -W 16 -Z root -w /data/xxxx.cap

-C后面就是每次抓的大小500M，这个根据咱们的盘大小定，-W就是循环抓16次；后续也就是抓8G后；会重新覆盖抓。

1.5.4 wireshark常见提示分析

不管是tcpdump抓的包还是wireshark抓的包,都可以在wireshark中看，也不用担心自己看不懂，我们只需要学会简单看就好了，不要畏难。学习分析抓包前，先要了解https工作原理和TCP三次握手机制：

http://www.cnblogs.com/ttltry-air/archive/2012/08/20/2647898.html

（1）【Packet size limited during capture】

当你看到这个提示，说明被标记的那个包没有抓全。以图1的4号包为例，它全长有171字节，但只有前96个字节被抓到了，因此Wireshark给了此提示。

这种情况一般是由抓包方式引起的。在有些操作系统中，tcpdump默认只抓每个帧的前96个字节，我们可以用“-s”参数来指定想要抓到的字节数，比如下面这条命令可以抓到1000字节。

（2）【TCP Previous segment not captured】

在TCP传输过程中，同一台主机发出的数据段应该是连续的，即后一个包的Seq号等于前一个包的Seq Len（三次握手和四次挥手是例外）。如果Wireshark发现后一个包的Seq号大于前一个包的Seq Len，就知道中间缺失了一段数据。假如缺失的那段数据在整个网络包中都找不到（即排除了乱序），就会提示［TCP Previous segment not captured］。比如在图2这个例子中，6号包的Seq号1449大于5号包的Seq Len=1 0=1，说明中间有个携带1448字节的包没被抓到，它就是“Seq=1, Len=1448”。

网络包没被抓到还分两种情况：一种是真的丢了；另一种是实际上没有丢，但被抓包工具漏掉了。在Wireshark中如何区分这两种情况呢？只要看对方回复的确认（Ack）就行了。如果该确认包含了没抓到的那个包，那就是抓包工具漏掉而已，否则就是真的丢了。

顺便分析一下上图这个网络包，它是HTTPS传输异常时在客户端抓的。因为“Len: 667”的小包（即6号包）可以送达，但“Len: 1448”的大包却丢了，说明路径上可能有个网络设备的MTU比较小，会丢弃大包。后来的解决方式证实了这个猜测，只要把整个网络路径的MTU保持一致，问题就消失了。

（3）【TCP ACKed unseen segment】

当Wireshark发现被Ack的那个包没被抓到，就会提示 [TCP ACKed unseen segment］。这可能是最常见的Wireshark提示了，幸好它几乎是永远可以忽略的。以下图为例，32号包的Seq Len=6889+1448=8337，说明服务器发出的下一个包应该是Seq=8337。而我们看到的却是35号包的Seq=11233，这意味着8337～11232这段数据没有被抓到。这段数据本应该出现在34号之前，所以Wireshark提示了[TCP ACKed unseen segment]。

（4）【TCP Out-of-Order】

在TCP传输过程中（不包括三次握手和四次挥手），同一台主机发出的数据包应该是连续的，即后一个包的Seq号等于前一个包的Seq Len。也可以说，后一个包的Seq会大于或等于前一个包的Seq。当Wireshark发现后一个包的Seq号小于前一个包的Seq Len时，就会认为是乱序了，因此提示 [TCP Out-of-Order] 。如图4所示，3362号包的Seq=2685642小于3360号包的Seq=2712622，所以就是乱序。

小跨度的乱序影响不大，比如原本顺序为1、2、3、4、5号包被打乱成2、1、3、4、5就没事。但跨度大的乱序却可能触发快速重传，比如打乱成2、3、4、5、1时，就会触发足够多的Dup ACK，从而导致1号包的重传。

（5）【TCP Dup ACK】

当乱序或者丢包发生时，接收方会收到一些Seq号比期望值大的包。它每收到一个这种包就会Ack一次期望的Seq值，以此方式来提醒发送方，于是就产生了一些重复的Ack。Wireshark会在这种重复的Ack上标记[TCP Dup ACK] 。

以下图为例，服务器收到的7号包为“Seq=29303, Len=1460”，所以它期望下一个包应该是Seq Len=29303+1460=30763，没想到实际收到的却是8号包Seq=32223，说明Seq=30763那个包可能丢失了。因此服务器立即在9号包发了Ack=30763，表示“我要的是Seq=30763”。由于接下来服务器收到的10号、12号、14号也都是大于Seq=30763的，因此它每收到一个就回复一次Ack=30763，从图中可见Wireshark在这些回复上都标记了[TCP Dup ACK]。

（6）【TCP Fast Retransmission】

当发送方收到3个或以上[TCP Dup ACK]，就意识到之前发的包可能丢了，于是快速重传它（这是RFC的规定）。以下图为例，客户端收到了4个Ack=991851，于是在1177号包重传了Seq=991851。

（7）【TCP Retransmission】

如果一个包真的丢了，又没有后续包可以在接收方触发[Dup Ack]，就不会快速重传。这种情况下发送方只好等到超时了再重传，此类重传包就会被Wireshark标上[TCP Retransmission]。以图7为例，客户端发了原始包（包号1053）之后，一直等不到相应的Ack，于是只能在100多毫秒之后重传了（包号1225）。

（8）【Time-to-live exceeded (Fragment reassembly time exceeded)】ICMP的报错有好多种，大都不难理解，所以我们只举其中的一种为例。 [Fragment reassembly time exceeded]表示这个包的发送方之前收到了一些分片，但是由于某些原因迟迟无法组装起来。比如在图12中，由于上海发往北京的一些包被分片传输，且有一部分在路上丢失了，所以北京方无法组装起来，便只好用这个ICMP报错告知上海方。

1.6 netcat（UDP）命令

对于TCP端口，如上一般用telnet检测。对于UDP端口，一般稍微复杂点：

因为UDP协议是无连接的，不需要握手建立连接，数据发送后，server端也不会返回确认信息。

一般可以使用netcat检测，这个命令被誉为是网络中的“瑞士军刀”，功能非常强大，测试udp只是其中的一个功能变通。

1.6.1 netcat用法说明

nc的作用也非常多：

（1）实现任意TCP/UDP端口的侦听，nc可以作为server以TCP或UDP方式侦听指定端口；

（2）端口的扫描，nc可以作为client发起TCP或UDP连接；

（3）机器之间传输文件；

（4）机器之间网络测速 ；

1.6.2 netcat常用参数

1.6.3 netcat场景测试

UDP端口连通性测试：

在目标机器监听UDP端口port1, 在客户端机器向目标机器port1端口发送UDP数据报，看能否发送成功。发送成功，则表示可连通。

例如：

A机器上运行(服务器端)：

nc -ul 1080

或：netcat -ul -p 1080

使用udp模式监听1080 端口

B机器上运行（客户端）：

nc -u x.x.x.x 1080（x.x.x.x为A机器地址）

或：netcat -u x.x.x.x 1080

使用udp模式向该ip的1080端口发送信息。

效果如图，B输入内容，会收到相应内容，以此就可以测试该端口的udp连接是否通常。

B机器上抓包可以发现有B机器向A机器发包，但是因为UDP协议是无连接的，不需要握手建立连接，数据发送后，server端也不会返回确认信息；所以这里抓包不会看到回包。

1.7 Curl（CDN常用命令）

1.7.1 curl用法说明

linux中测试网络的访问工具 无论是cdn也好，测试服务器返回是否正常也好，都是可以直接使用curl来进行多功能测试。

1.7.2 curl常用参数

1.7.3 curl场景测试

1、验证某节点ip缓存情况

[root@VM_27_201_centos ~]# curl -I 'http://app613.imgcache.xxx.com/app613/frontend_swf/version.js' -x 106.74.23.144:80

HTTP/1.1 200 OK

Server: NWS_TCloud_S1

Connection: keep-alive

Date: Sun, 03 Jul 2016 08:50:34 GMT

Cache-Control: max-age=6000

Expires: Sun, 03 Jul 2016 10:30:34 GMT

Last-Modified: Thu, 30 Jun 2016 09:12:30 GMT

Content-Type: application/x-javascript; charset=utf-8

Content-Length: 69

X-Cache-Lookup: Hit From Disktank

PS: 其中的-x绑定代理服务器ip的用法，类似于wget中的：

# wget -e http-proxy=119.97.137.178 http://sdxxx.cloudcdn.net/test008/6wireshark-win64-1.2.9.exe

2、指定某节点https请求

如果是http可以直接 -x 14.204.144.142:80

https需要 --resolve mc.qcloudimg.com:443:14.204.144.142 即--resolve host:端口:ip

curl -vo /dev/null 'https://mc.qcloudimg.com/static/img/ae4bfa87aae5714c1c74dd9e134f5a29/image.png' --resolve mc.qcloudimg.com:443:14.204.144.142

3、验证referer头部白名单是否生效场景

使用-H 来添加自定义的头部，模拟特殊条件下源站/cdn节点对特性是否支持，结果返回是否符合预期。下面的这个例子，就是用来验证在控制台上添加了referer白名单后，模拟该referer头部返回是否符合预期。

[root@VM_27_201_centos ~]# curl -I 'http://res2.xxxxx.com/' -x 106.74.23.144:80 -H"referer:http://*.yqh5.cn"

HTTP/1.1 200 OK

Server: NWS_TCloud_S1

Connection: keep-alive

Date: Sun, 03 Jul 2016 08:59:50 GMT

Cache-Control: max-age=31536000

Expires: Mon, 03 Jul 2017 08:59:50 GMT

Last-Modified: Tue, 12 Apr 2016 01:59:32 GMT

Content-Type: text/html

Content-Length: 612

X-Cache-Lookup: Hit From Disktank

Access-Control-Allow-Origin: *

Content-Disposition: inline; filename=""

Accept-Ranges: bytes

4、验证节点/源站对分片的支持情况

[root@VM_27_201_centos ~]# curl -Iv 'http://update01.xxxx-cloud.com/pup/8S70_E6200_V016.002.230_9.zip' -x 106.74.23.144:80 -H'range:bytes=0-1000'

About to connect() to proxy 106.74.23.144 port 80 (#0)* Trying 106.74.23.144... connected* Connected to 106.74.23.144 (106.74.23.144) port 80 (#0)> HEAD http://update01.skyworth-cloud.com/pup/8S70_E6200_V016.002.230_9.zip HTTP/1.1> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2> Host: update01.skyworth-cloud.com> Accept: */*

> Proxy-Connection: Keep-Alive

> range:bytes=0-1000

>

< HTTP/1.1 206 Partial Content

HTTP/1.1 206 Partial Content

< Server: nws_ocmid_hy

Server: nws_ocmid_hy

< Connection: close

Connection: close

< Date: Sun, 03 Jul 2016 09:02:24 GMT

Date: Sun, 03 Jul 2016 09:02:24 GMT

< Cache-Control: max-age=600

Cache-Control: max-age=600

< Expires: Sun, 03 Jul 2016 09:12:24 GMT

Expires: Sun, 03 Jul 2016 09:12:24 GMT

< Last-Modified: Mon, 23 May 2016 20:10:06 GMT

Last-Modified: Mon, 23 May 2016 20:10:06 GMT

< Content-Range: bytes 0-1000/437405243

Content-Range: bytes 0-1000/437405243

< Content-Type: application/octet-stream

Content-Type: application/octet-stream

< Content-Length: 1001

Content-Length: 1001

< X-Daa-Tunnel: hop_count=2

X-Daa-Tunnel: hop_count=2

< X-Cache-Lookup: Hit From Disktank Upstream

X-Cache-Lookup: Hit From Disktank Upstream

< X-Cache-Lookup: Hit From Disktank

X-Cache-Lookup: Hit From Disktank

< X-Daa-Tunnel: hop_count=2

X-Daa-Tunnel: hop_count=2

< X-Cache-Lookup: Hit From Inner Cluster

X-Cache-Lookup: Hit From Inner Cluster

备注上面的

curl -Iv 'http://update01.xxx-cloud.com/pup/8S70_E6200_V016.002.230_9.zip' -x 106.74.23.144:80 -H'range:bytes=0-1000'

也可以写成

curl -Iv 'http://update01.xxx-cloud.com/pup/8S70_E6200_V016.002.230_9.zip' -x 106.74.23.144:80 -r 0-1000

5、验证文件在节点和源站上大小是否一致（通过md5判断）

[root@VM_27_201_centos ~]# curl -o pic1 'http://as.xxx.com/show/visitor/4a2d8aae508506ef0150a6fcebbf2f53' -x 106.74.23.144:80

%Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed100 10126 100 10126 0 0 40629 0 --:--:-- --:--:-- --:--:-- 54149

[root@VM_27_201_centos ~]# md5sum pic1

4b7671dbe1a634541726bd9473d14dcc pic1

[root@VM_27_201_centos ~]# curl -o pic2 'http://as.xxx.com/show/visitor/4a2d8aae508506ef0150a6fcebbf2f53' -x 115.159.20.55:80

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed100 10126 100 10126 0 0 4629k 0 --:--:-- --:--:-- --:--:-- 9888k

[root@VM_27_201_centos ~]# md5sum pic2

4b7671dbe1a634541726bd9473d14dcc

备注：上面的-o 代表把文件下载到指定的路径下，-x代表使用指定的ip或者域名作为代理。

6、模拟https访问验证https证书

[root@VM_117_214_centos ~]# curl -sv 'https://xxx.qcloud.com/static/img/57c45bb3997a277e5996dcf13314b365/user-40.png' -o /dev/null -k

About to connect() to mccdn.qcloud.com port 443 (#0)* Trying 113.207.16.63... connected* Connected to mccdn.qcloud.com (113.207.16.63) port 443 (#0)* Initializing NSS with certpath: sql:/etc/pki/nssdb* warning: ignoring value of ssl.verifyhost* skipping SSL peer certificate verification* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA* Server certificate:* subject: CN=*.qcloud.com,OU=R&D,O=Shenzhen Tencent Computer Systems Company Limited,L=shenzhen,ST=guangdong,C=CN* start date: May 25 00:00:00 2016 GMT* expire date: Jul 24 23:59:59 2019 GMT* common name: *.qcloud.com* issuer: CN=Symantec Class 3 Secure Server CA - G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US> GET /static/img/57c45bb3997a277e5996dcf13314b365/user-40.png HTTP/1.1> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2> Host: mccdn.qcloud.com> Accept: */*

>

< HTTP/1.1 200 OK

< Server: nnws/1.7.3.8

< Date: Sat, 20 Aug 2016 12:43:55 GMT

< Content-Type: image/png

< Content-Length: 3558

< Connection: keep-alive

< Cache-Control: max-age=2592000

< Expires: Mon, 19 Sep 2016 12:43:54 GMT

< Last-Modified: Wed, 25 May 2016 08:06:29 GMT

< X-Cache-Lookup: Hit From Disktank

<

{ [data not shown]

* Connection #0 to host mccdn.qcloud.com left intact

* Closing connection #0

7、curl中绑定host测试方法

等同于在windows中绑定host进行测试

[root@VM_230113centos ~]# curl -I -H 'host:7u2q8y.com3.z0.glb.xxxcdn.com' http://xxx.com.z0.glb.xxxdns.com/M-_WoLgVqduR7VFfrhnmWwL8YgA=/luI-lideKDodDAYi55H6D2HV6HcO/000000.ts

HTTP/1.1 200 OK

Server: nginx/1.4.4

Date: Sat, 02 Jan 2016 11:39:23 GMT

Content-Type: video/mp2t

Content-Length: 673416

Connection: keep-alive

Accept-Ranges: bytes

Access-Control-Allow-Origin: *

Access-Control-Max-Age: 2592000

Cache-Control: public, max-age=31536000

Content-Disposition: inline; filename="000000.ts"

Content-Transfer-Encoding: binary

Etag: "Fs–ekImTQ2ZMjO_MdTeTN0Yew_5"

Last-Modified: Sun, 22 Nov 2015 06:28:55 GMT

X-Log: mc.g;IO:1

X-Reqid: iToAAMIdW1cTmSUU

X-Qiniu-Zone: 0

[root@VM_230113centos ~]# curl -I -H 'host:7u2q8y.com3.z0.glb.xxxcdn.com' http://211.161.127.147/M-_WoLgVqduR7VFfrhnmWwL8YgA=/luI-lideKDodDAYi55H6D2HV6HcO/000000.ts

HTTP/1.1 200 OK

Server: NWS_Appimg_HY

Connection: keep-alive

Date: Sat, 02 Jan 2016 11:45:50 GMT

Cache-Control: max-age=31536000

Expires: Sun, 01 Jan 2017 11:45:50 GMT

Last-Modified: Sun, 22 Nov 2015 06:28:55 GMT

Content-Type: video/mp2t

Content-Length: 673416

X-Cache-Lookup: Hit From Disktank

Access-Control-Allow-Origin: *

Accept-Ranges: bytes

Etag: "Fs–ekImTQ2ZMjO_MdTeTN0Yew_5"

X-ReqId: ATUAABGu8oBVjyUU

Content-Disposition: inline; filename="000000.ts"

其中：

• 7u2q8y.com3.z0.glb.qiniucdn.com 为用户的域名
• src.com.z0.glb.qiniudns.com 为源站或者回源host地址，也可以为ip地址形式
• 211.161.127.147 为域名接入cdn之后解析到的cdn节点ip地址

通过验证源站url和cdn节点ip地址后的curl反馈可以判断出到底是源站有问题，还是cdn节点有问题

8、验证TCP握手和ssl握手的延时

curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://www.alipay.com

9、使用curl抓取返回时间

判断网页访问各耗时时间

curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" http://www.itts-union.com

This command will output this:

[root@VM_117_214_centos ~]# curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" http://www.itts-union.com/1326.html

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed100 74470 0 74470 0 0 52368 0 --:--:-- 0:00:01 --:--:-- 116k

Connect: 0.799 TTFB: 1.309 Total time: 1.422

10、查询各个阶段的耗时时间

-w 可以指定特殊文件 也可以指定耗时**%{time_namelookup}**

[root@VM_49_231_centos ~]# curl -Iv "http://img.yxp01.com/images/20/2017/07/VXunsmRXXU355lC5lM8xc5sXmFNfus.jpg?v=4" -x 119.6.229.37:80 -so /dev/null -w "@curl-time"

需要先创建一个文件curl-time：

[root@VM_49_231_centos ~]# cat curl-time

Time-DNS-lookup: %{time_namelookup}s\n

Time-TCP-connect: %{time_connect}s\n

Time-SSL-connect: %{time_appconnect}s\n

Time-redirect: %{time_redirect}s\n

Time-Pre-transfer: %{time_pretransfer}s\n

Time-First-transfer: %{time_starttransfer}s\n

----------\n

Time-total: %{time_total}s\n

11、-L实现301或者302的跳转

12、缓存文件建立时间Pragma: X-Get-Last-Update-Info

13、查看cdn节点回源的链路：x_upstream_info=on

curl -o 100 "http://res.hoisin.xxxtv.com/video/20150731164143_960.ts?x_upstream_info=on" -x 61.140.13.201:80 -H "Pragma: X-Get-Last-Update-Info" -v

[root@sheazhang ~]# curl -o /dev/null -v "http://zl.winyp.cn/test.jpg?x_upstream_info=on"

> GET /test.jpg?x_upstream_info=on HTTP/1.1

> User-Agent: curl/7.29.0

> Host: zl.winyp.cn

> Accept: */*

>

< HTTP/1.1 200 OK

< Server: NWS_TCloud_S1

< Connection: keep-alive

< Date: Tue, 01 Jan 2019 02:46:29 GMT

< Cache-Control: max-age=600

< Expires: Tue, 01 Jan 2019 02:56:29 GMT

< Last-Modified: Thu, 22 Jun 2017 18:27:09 GMT

< Content-Type: image/jpeg

< Content-Length: 201557

< X-NWS-LOG-UUID: 4243021142118093756 4c4df2ad367f7a7282b8c634e5bb5346

< Access-Control-Allow-Origin: *

< X-Daa-Tunnel: hop_count=3

< X-Cache-Lookup: Hit From Upstream 125.39.46.83, cost 33 ms

< X-Upstream-Info: l2.cloudhy.tcdn.qq.com

< X-Cache-Lookup: Hit From Disktank3

< Accept-Ranges: bytes

< X-Cache-Lookup: Hit From Inner Cluster

14、指定访问的来源客户端ua

-A 'ua'

[root@sheaBJ ~]# curl -Iv "http://www.xxx.com/ckkhj/index.shtml" -x 1.xxx:80 -A 'Smartphone'

About to connect() to proxy 1.180.204.168 port 80 (#0)* Trying 1.180.204.168...* Connected to 1.180.204.168 (1.180.204.168) port 80 (#0)> HEAD http://www.dongao.com/ckkhj/index.shtml HTTP/1.1> User-Agent: Smartphone> Host: www.dongao.com> Accept: */*

> Proxy-Connection: Keep-Alive

>

< HTTP/1.1 301 Moved Permanently

HTTP/1.1 301 Moved Permanently

< Server: NWS_TCloud_S1

Server: NWS_TCloud_S1

< Connection: keep-alive

Connection: keep-alive

< Date: Fri, 08 Mar 2019 03:51:38 GMT

Date: Fri, 08 Mar 2019 03:51:38 GMT

< Content-Length: 39

Content-Length: 39

< Location: http://m.dongao.com/ckkhj/index.shtml

Location: http://m.dongao.com/ckkhj/index.shtml

<

* Excess found in a non pipelined read: excess = 39 url = /ckkhj/index.shtml (zero-length body)

* Connection #0 to host 1.180.204.168 left intact39 url = /ckkhj/index.shtml (zero-length body)

Conection #0 to host 1.180.204.168 left intact

15、curl常用头部集合

-H 'Accept-Encoding:gzip' 测试压缩

-L 实现301或者302的跳转

-H 'Pragma: X-Get-Last-Update-Info' 缓存文件建立时间

-H 'x_upstream_info=on' cdn节点回源的链路

-H 'host:7u2q8y.com3.z0.glb.qiniucdn.com' 绑定hosts

-H 'range:bytes=0-1000' 或 -r 0-0 测试分片支持

-H "referer:http://*.yqh5.cn" 验证reffer头部

-d "x=123" 模拟post请求

-H "Origin:http://sheazhang.winyp.cn/" 验证跨域的来源情况，其中O大写

-w "@curl-time" 各个阶段的耗时时间

16、httpstat的脚本-time

参考链接：

https://github.com/reorx/httpstat

17、测试源站是否吐出304的情况

-H 'If-Modified-Since:xxx'

[root@VM_14_42_centos ~]# curl -o 1 -v "http://j.xxx.cc/daobo/js/fabric.js" -x 139.xxx.204:80 -H 'If-Modified-Since: Mon, 23 Apr 2018 03:38:55 GMT'

About to connect() to proxy 139.199.214.204 port 80 (#0)* Trying 139.xxx...% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 139.199.214.204 (139.199.214.204) port 80 (#0)> GET http://j.xxx.cc/daobo/js/fabric.js HTTP/1.1> User-Agent: curl/7.29.0> Host: xxx> Accept: */*

> Proxy-Connection: Keep-Alive

> If-Modified-Since: Mon, 23 Apr 2018 03:38:55 GMT

>

< HTTP/1.1 304 Not Modified

< Server: nginx/1.14.2

< Date: Mon, 15 Apr 2019 07:40:50 GMT

< Connection: keep-alive

< Last-Modified: Mon, 23 Apr 2018 03:38:55 GMT

< ETag: "5add554f-da835"

< Access-Control-Allow-Origin: *

<

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

• Connection #0 to host 139.199.214.204 left intact

二、 网络常用的拨测工具

2.1ipipnet

查询地址归属、ping、traceroute都非常有用;

https://tools.ipip.net/traceroute.php

2.2ping.pe

包含了ping、端口探测、dig解析；

2.3查询IP地址归属

https://www.ipip.net/ip.html

http://m.ip138.com/ （有时候不太准）

https://whatismyipaddress.com/ip-lookup

https://www.whois365.com/tw/ip/

2.4华佗分析系统

上报本机ip及外网网络质量，用于排除是否是客户本身网络质量异常；另外华佗里面也有安卓的手机抓包工具。

https://huatuo.qq.com/

2.5DNS解析工具My Dig Tool

http://q.talebook.org/mdig/

查询域名对应的所有A记录，基于Edns探测各个地区运营商的解析情况