网络自助诊断2: 实践篇

叁叁肆2018-10-25 12:30

此文已由作者徐城利授权网易云社区发布。

欢迎访问网易云社区,了解更多网易技术产品运营经验。


在上一篇中已经介绍了一些基础的网络知识,而这一篇中我们将对一些实际应用中比较常见的问题进行诊断。

网络不通

网络连通性是平时最基本的问题,也是大部分网络问题中首先需要确认的。 最简单也是每个人都知道的工具ping,虽然这是个很基本的命令,但还是能给我们提供不少有用的信息。

  • Uknown host: 这个错误表示域名解析错误,需要检查DNS配置。

  • Network unreachable: 这个错误表示是二层网络不通,可能没有正确配置网络、网线不对、交换机配置错误等原因。

  • Operation permission denied: 这个错误一般表示包被自己的内核丢掉,需检查本地的防火墙规则,内核是不是有异常,如conntrack表满,arp缓存满,socket内存用尽等。

  • Timeout: 三层不通,一般需要分析整个路由路径。

注意:有些网络设备或服务器禁掉了ICMP,有些设备在处理ICMP和处理转发的性能差很多,因此,ping的结果更多是作为一个参考,而非判断网络连通性和网络状态的绝对标准。

域名解析

当发现域名解析出现问题时,可以先查看系统配置了解当前使用的nameserver,再检查nameserver是否可用,也可以直接通过nslookup或dig等命令查看当前系统的域名解析情况。

~$ nslookup yun.163.comServer:        
 10.180.0.223Address:       
  10.180.0.223#53Non-authoritative answer:Name:   
  yun.163.comAddress: 223.252.208.251

如结果所示:本地用于解析的DNS服务器是10.180.0.223, yun.163.com这个域名指向了223.252.208.251这个IP。 如果系统默认的DNS解析出来的结果不对,也可以指定特定的nameserver,看结果是否一致:

~$ nslookup yun.163.com 114.114.114.114Server:        
 114.114.114.114Address:       
  114.114.114.114#53Non-authoritative answer:Name:  
   yun.163.comAddress: 223.252.208.251

二层问题

如果碰到二层网络不通,可能是本地方的配置问题,也可能是对端的问题,因此需要逐一排除:

  • 使用ip link、ip address、ip route等命令检查本地的设备是否已经正确配置(例如网卡状态为UP、Carrier状态正常、正确配置了IP,到目标地址的路由正确)

  • 测试同个二层网络内的其他IP地址是否可以访问

  • 可以使用arping等工作在更下层的工具,适合IP被防火墙屏蔽等情况

~$ sudo arping -I eth0.100 10.180.0.24ARPING 10.180.0.24 from 10.180.0.86 eth0.100Unicast reply from 10.180.0.24 [34:40:B5:DB:35:B0]  0.658msUnicast reply from 10.180.0.24 [34:40:B5:DB:35:B0]  0.576msUnicast reply from 10.180.0.24 [34:40:B5:DB:35:B0]  0.575msUnicast reply from 10.180.0.24 [34:40:B5:DB:35:B0]  0.588ms

此外,arping还能用于检测是否在冲突IP

~$ sudo arping -D -I eth0.100 10.180.0.24ARPING 10.180.0.24 from 0.0.0.0 eth0.100Unicast reply from 10.180.0.24 [34:40:B5:DB:35:B0]  0.597msSent 1 probes (1 broadcast(s))Received 1 response(s)

及用于更新交换机上或其他服务器上的ARP缓存

~$ sudo arping -U -c3  -I eth0.100 10.180.0.86ARPING 10.180.0.86 from 10.180.0.86 eth0.100Sent 3 probes (3 broadcast(s))
Received 0 response(s)

三层问题

当三层网络不通时,可以按以下步骤来:

  • 同样使用ip addresss和ip route等命令检查本地的IP配置及到目标的路由

  • 根据路由,检查网关是否可达

  • 可以使用mtr、traceroute等工具获取更多的信息

mtr集成了traceroute和ping的功能,是一个比较方便的诊断辅助工具,Windows下也有port实现,如WinMtr

~$ mtr -c4 -r 114.114.114.114HOST: 10-180-0-86                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 115.236.124.1             25.0%     4    3.8   3.0   0.3   4.7   2.3
  2.|-- ???                       100.0     4    0.0   0.0   0.0   0.0   0.0
  3.|-- 61.164.31.49               0.0%     4    3.2   1.4   0.7   3.2   1.2
  4.|-- 61.164.29.9               25.0%     4    1.6   1.3   1.2   1.6   0.3
  5.|-- 202.97.84.74               0.0%     4    8.4   6.5   5.4   8.4   1.3
  6.|-- 218.2.182.74               0.0%     4    9.3   9.5   7.7  10.6   1.3
  7.|-- 58.213.224.170             0.0%     4    7.2   7.4   7.2   8.0   0.4
  8.|-- public1.114dns.com         0.0%     4    8.4   8.5   8.4   8.5   0.0

如图所示,mtr基本列出了整个网络路径上每一跳的丢包率、RTT等信息,类似于用traceroute获取转发路径上的每一跳,并逐一去ping的效果。 大家可能注意到上面的结果中,中间节点的丢包率反而被后面的高,这也是之前提到的,网络设备在处理ICMP的性能不等同于处理转发的性能,有些甚至完全禁用了ICMP。因此traceroute等工具支持多种网络协议,可以配合使用,Windows下的tracert只支持单协议。

~$ sudo traceroute -I 114.114.114.114
traceroute to 114.114.114.114 (114.114.114.114), 30 hops max, 60 byte packets
 1  115.236.124.1 (115.236.124.1)  0.337 ms  0.374 ms  0.439 ms
 2  * * *
 3  61.164.31.49 (61.164.31.49)  1.019 ms  1.036 ms  1.059 ms
 4  * * *
 5  202.97.84.74 (202.97.84.74)  8.278 ms  8.312 ms  8.305 ms
 6  218.2.182.74 (218.2.182.74)  11.171 ms  9.872 ms  9.841 ms
 7  58.213.224.170 (58.213.224.170)  7.328 ms  7.749 ms  8.156 ms
 8  public1.114dns.com (114.114.114.114)  8.357 ms  8.426 ms  8.425 ms

~$ sudo traceroute -T 114.114.114.114
traceroute to 114.114.114.114 (114.114.114.114), 30 hops max, 60 byte packets
 1  115.236.124.1 (115.236.124.1)  0.361 ms  0.406 ms  0.464 ms
 2  * * *
 3  * * 61.164.31.29 (61.164.31.29)  4.580 ms
 4  * * 61.164.31.229 (61.164.31.229)  3.135 ms
 5  202.97.41.249 (202.97.41.249)  9.948 ms 202.97.68.237 (202.97.68.237)  10.384 ms 202.97.84.74 (202.97.84.74)  6.072 ms
 6  218.2.134.74 (218.2.134.74)  7.191 ms 218.2.182.34 (218.2.182.34)  9.558 ms 221.231.191.170 (221.231.191.170)  10.637 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *

如图,使用不同协议的结果是不同的。

如果整个网络路径上所有或部分节点可控,也可以使用抓包的方式来缩小查找的范围(网络抓包分析的相关内容将在后续文章讨论)。

应用无法访问

当碰到服务无法访问时,也可以根据返回的错误进行初步判断,各个错误对应的诊断过程完全是不同的。

Connection Refused

当看到这个错误时,首先表示网络连通性没有问题,一般是服务没有监听:

  • 检查要访问的目标地址是否正确,如写错IP、域名解析错误、连错端口等

  • 检查服务是否监听了正确的地址,例如一些应用只监听了127.0.0.1,就无法被远程访问。这些信息都可以通过上篇文章提过的ss或netstate等命令获取

Timeout

连接超时的情况更加复杂点,不过也有一定的检查步骤:

  • 先通过ping等方式检查目标地址是否可达,如不可达则参考前面网络连通性的诊断方法。

  • 如果是TCP应用,通过telnet等检查指定端口是否可以建立TCP连接,如果无法连接,重点检查服务端是否有防火墙规则之类的限制。

  • 如果可以telnet,但还是无法建立连接,一般涉及到了具体的应用实现,这时就要靠抓包、日志等方法结合应用实现、协议实现等业务知识来进行分析,已经超出这篇文章的范畴了。

socket异常

当服务器碰到无法建立新连接等问题时,关注下socket的统计信息有时能发现一些有用的线索:

~$ sudo ss -s
Total: 138 (kernel 206)
TCP:   24 (estab 4, closed 5, orphaned 0, synrecv 0, timewait 3/0), ports 18

Transport Total     IP        IPv6
*         206       -         -
RAW       0         0         0
UDP       14        11        3
TCP       19        13        6
INET      33        24        9
FRAG      0         0         0

如果看到大量的synrecv、timewait、close-wait、orphaned等,就值得关注:

  • 大量的syn_recv:应用已经无法接收新的请求,有可能是应用服务本身问题,也有可能是被类似syn flood攻击。

  • 大量的close_wait: 如果系统上出现大量的这种状态,一般是应用程序的bug,没有正确处理远端的断开连接请求。

  • 大量的time_wait: 在访问量比较大的应用服务器上一定量的time_wait是正常的,但如果一直往上增加,可能是有客户端不断的新建、断开连接,可以通过设置内核参数,减小time_wait时间,或允许重用。

在分析socket问题时,熟悉TCP各个状态之类的转换非常重要,网上也有很多图例可以参考。

应用程序性能问题

有些用户碰到性能问题时,直接说:“我们的并发数上不去,一定是你们网络的问题,得给我解决!” 碰到这样的用户,有时确实也令人无奈。何不在把责任撇清前先自己先做一个初步的分析呢? 假设服务器A(10.0.1.2)上一个应用调用了服务器B(10.0.1.3)上的另外一个服务(端口8080),在A中发现调用B的服务时并发数不够,那怎么才能知道是应用程序本身的问题,还是底层网络的问题呢?其实在前一篇已经提到过。

在A和B上检查socket的状态

A:~$ sudo ss state established dst :8080
Netid  Recv-Q Send-Q        Local Address:Port            Peer Address:Port
DIAG answers 22
tcp    0      0                  10.0.1.2:46728               10.0.1.3:8080

B:~$ sudo ss state established dst 10.0.1.2 and src :8080
Netid  Recv-Q Send-Q        Local Address:Port            Peer Address:Port
DIAG answers 22
tcp    0      0                  10.0.1.3:8080               10.0.1.2:46728

我们可以通过两端socket收发队列中的数据进行判断:

  • 当A的Send-Q中数据堆积而B的Recv-Q中数据为0时,一般是A-B之间的网络问题

  • 当A的Send-Q和B的Recv-Q中的数据同时累积时,一般是B服务的性能问题

  • 当A的Recv-Q中数据堆积时,一般是A本身的性能问题

  • 如果所有的队列都为0,那还是表示网络没有成为瓶颈

如果确定是网络问题,再进一步对整个网络路径进行排查,如某个节点上带宽用完、CPU耗尽、丢包等。

总结

这一篇文章中,我们总结了一些常见的网络问题及诊断方法。通过这些方法基本上可以排除不少日常的网络问题,当然,网络本身牵涉到不少复杂的情况,有时无法只通过一些简单的工具就能了解所有的情况,必须要求我们对网络上的包的内容进行分析,这将是我们下一篇的内容,敬请关注。



网易云免费体验馆,0成本体验20+款云产品! 

更多网易技术、产品、运营经验分享请点击




相关文章:
【推荐】 测试角度的并发和幂等问题总结
【推荐】 聊一聊数据分析师这个职业
【推荐】 分布式存储系统可靠性系列一:如何估算