1 5 6 7 8 9 上一个 下一个 229 回复 最新回复: Jan 8, 2018 5:50 PM hitjackma 转至原始发贴 RSS
  • 90. Re: 网络基本功系列:细说网络那些事儿(11月3日更新)
    xixihaha

    能否详细举例讲一讲?最好能结合实际,比如,杭州某用户访问百度北京机房的www.baidu.com,是怎么路由器的?

  • 91. Re: 网络基本功系列:细说网络那些事儿(11月3日更新)
    xixihaha

    这两天学习了一下OSPF网络。

    讲述OSPF优点时,其中有一句“将某一区域网络拓扑变化的影响限制在该区域内,不会影响到整个OSPF网络”。

    通过OSPF中area的概念,使区域内的路由信息数据就不会有那么多了?可以这样解释吗?

  • 92. Re: 网络基本功系列:细说网络那些事儿(11月3日更新)
    Zhang,Jiawen

    网络基本功(十四):细说诊断工具ping

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

    介绍

     

    ping的工作原理很简单,一台网络设备发送请求等待另一网络设备的回复,并记录下发送时间。接收到回复之后,就可以计算报文传输时间了。只要接收到回复就表示连接是正常的。耗费的时间喻示了路径长度。重复请求响应的一致性也表明了连接质量的可靠性。因此,ping回答了两个基本的问题:是否有连接?连接的质量如何?本文主要讨论这两个问题。


    更多信息

     

    正常的ping操作主要是两个特定的ICMP消息,ECHO_REQUESTECHO_REPLY。理论上,所有TCP/IP网络设备都应当通过返回报文来响应ECHO_REQUEST,但实际上并不总是如此。

     

    ping的解析:

     

    大多数操作系统版本,会一直发送ECHO_REQUESTs,直到中断为止。例如:

    bsd1# ping www.bay.com

    PING www.bay.com (204.80.244.66): 56 data bytes

    64 bytes from 204.80.244.66: icmp_seq=0 ttl=112 time=180.974 ms

    64 bytes from 204.80.244.66: icmp_seq=1 ttl=112 time=189.810 ms

    64 bytes from 204.80.244.66: icmp_seq=2 ttl=112 time=167.653 ms

    ^C

    --- www.bay.com ping statistics ---

    3 packets transmitted, 3 packets received, 0% packet loss

    round-trip min/avg/max/stddev = 167.653/179.479/189.810/9.107 ms

    bsd1#

    这一过程被Ctrl-C中断,此时打印出汇总统计。

    上述结果中,针对每一个报文的回复给出了报文大小,来源,ICMP sequence numberTTL值,以及往返时间。其中,sequence number和往返时间对于评估基本连接状况来说是最有用的信息。


    当发送一个ECHO_REQUEST时,将发送时间记录在报文里,并复制到远端主机相应的ECHO_REPLY报文中。当接收到ECHO_REPLY时,通过比较当前时间与报文时间计算出耗费时间。如果没有收到符合该sequence number的报文,则认为该报文丢失。耗费时间长短以及变化范围取决于中间链路数量,速度,以及链路拥塞情况。


    什么值是合理的呢?这一值高度取决于网络以及网络质量。如果是在LAN网络环境下,响应时间还是很快的,通常在十几毫秒范围之内。如果连接到外网则该值会显著增加。如果是远程站点,可能会耗时上百毫秒。


    你也可以用ping来粗略计算连接的吞吐量。在外网上发送两个不同大小的报文,通过-s选项来完成。时间长度的差别会反映大报文中额外数据所耗费的时间。例如,假设ping 100字节耗费30msping 1100字节耗费60ms,因此,往返额外花费30ms单程额外花费15ms,多发送1000字节或8000比特。吞吐量近似为每15ms 8000比特或540000bps。两个测量值之间的差异用来扣除开销。当然这一估算是非常粗略的,没有考虑到路径上其他数据流的情况,也没有考虑路径上所有链路的情况。


    TTL貌似可以估算一条路径上的跳数,但是这有一些问题。当发送报文时,TTL字段先被初始化接着经过路径上每个路由器都要递减。如果达到0,报文就被丢弃了。从而对所有报文生命周期有一定限制。因而在路由回环的过程中,报文不会无期限存在于网络上。不幸的是,TTL字段可能会,也可能不会被远端设备重置,如果重置,也没有一致性。因此,要使用TTL字段估算路径中的跳数需要知道详细的系统信息。


    通常一串稳定的回复意味着健康的连接。如果报文丢失或丢弃,可以在sequence number中看到跳数,以及丢失报文的编号。偶尔丢失一个报文不表示真的有什么问题。特别是跨越多台路由器或拥塞网络时。一个序列中的一个报文丢失或耗费明显更长时间是很正常的,这是因为路径中各条链路需对第一个报文做ARP解析。在ARP数据保存之后,后续报文就不会有这种开销。但是,如果丢失报文比例较大,则有可能路径上有问题。


    某些情况下会收到ICMP错误消息。通常来自路由器,这里面包含很有用的信息。例如,下例中,设备尝试访问一个不存在的网络上的设备:

    bsd1# ping 172.16.4.1

    PING 172.16.4.1 (172.16.4.1): 56 data bytes

    36 bytes from 172.16.2.1: Destination Host Unreachable

    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

    4  5  00 5400 5031   0 0000  fe  01 0e49 172.16.2.13  172.16.4.1

     

    36 bytes from 172.16.2.1: Destination Host Unreachable

    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

    4  5  00 5400 5034   0 0000  fe  01 0e46 172.16.2.13  172.16.4.1

     

    ^C

    --- 172.16.4.1 ping statistics ---

    2 packets transmitted, 0 packets received, 100% packet loss


    由于路由器没有到达该网络的路径,所以返回ICMP DESTINATION_HOST_UNREACHABLE信息。通常如果问题发生在运行ping命令的设备上,则会收到Destination Host Unreachable告警或 Destination Network Unreachable告警。如果问题发生在转发报文的设备上,则只会收到一条Destination Host Unreachable

     

    下例中,尝试向一台已配置拒绝从源设备接收数据流的路由器发送数据:

    bsd1# ping 172.16.3.10

    PING 172.16.3.10 (172.16.3.10): 56 data bytes

    36 bytes from 172.16.2.1: Communication prohibited by filter

    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

    4  5  00 5400 5618   0 0000  ff  01 0859 172.16.2.13  172.16.3.10

     

    36 bytes from 172.16.2.1: Communication prohibited by filter

    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

    4  5  00 5400 561b   0 0000  ff  01 0856 172.16.2.13  172.16.3.10

     

    ^C

    --- 172.16.3.10 ping statistics ---

    2 packets transmitted, 0 packets received, 100% packet loss


    被过滤条件阻止的告警信息表明报文被丢弃。但也有可能过滤条件不显示该告警。

     

    下例中,

    bsd1# ping 172.16.3.10

    PING 172.16.3.10 (172.16.3.10): 56 data bytes

    ^C

    --- 172.16.3.10 ping statistics ---

    6 packets transmitted, 0 packets received, 100% packet loss


    路由器上使用同样的过滤条件,但应用于离开网络的数据流,而不作用于inbound数据流。因此,没有消息发送。这时,ping就无法告诉你为什么报文没有收到回复。

     

    ping的选项:

     

    一些选项控制发送报文的速率和数量,-c选项允许用户指定发送报文的数量。例如,ping –c10会发送10个报文然后停止。这一命令在脚本中很有用处。

    命令-f-l用于将报文泛洪到网络上。-f选项表明报文发送速率与接收主机能够处理速率相同。这一参数可用于链路压力测试或接口性能比较。

    -l选项用于计数,尽可能快的发送该数量报文,然后恢复正常。该命令用于测试处理泛洪的能力,需要root权限执行。

    -i选项用于用户在两个连续报文之间指定等待秒数。该命令对于将报文间隔开或用在脚本中非常有用。正常情况下,偶然的ping包对数据流的影响是很小的。但重复报文或报文泛洪影响就很大了。因此,使用以上选项时需谨慎。

    -n选项将输出限制为数字形式,这在碰见DNS问题时很有用。-v显示更详尽输出,较少输出为-q-Q

    -s选项指定发送数据的大小。但如果设置的太小,小于8,则报文中就没有空间留给时间戳了。设置报文大小能诊断有路径MTU(Maximum Transmission Unit)设置或分段而导致的问题。如果不使用该选项,ping默认是64字节。

     

     

    参考

     

    Network Troubleshooting Tools

     

     

     

     

                 

  • 93. Re: 网络基本功系列:细说网络那些事儿(11月10日更新)
    Zhang,Jiawen

    网络基本功(十五):细说网络性能监测与实例(上)

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

    介绍

     

    网络路径性能检测主要包括三方面的内容:带宽测量能够获知网络的硬件特性,如网络的最大容量,吞吐量测量能够获得网络实际可提供的最大容量,数据流测量能够了解真实占用的网络容量。

    本文介绍在评估网络性能是否合理时,需要收集的数据及收集方式。涉及工具包括:ping, pathchar, bing, ttcp, netperf, iperf, netstat


    更多信息

     

    带宽测量:

     

    ping

    ping这一工具返回的时间,虽然通常被描述为传输延时,实际上是发送,传输,队列延时之和。上一节中,我们通过ping来粗略计算带宽。这一过程可通过如下方式改进:首先计算链路近端的路径行为,然后计算远端路径,然后用两者差异来估算链路带宽。

    image002.png

    这一过程需要四次使用ping。首先,用两个不同大小报文ping近端链路。减掉传输大报文中额外数据的传输时间以外,时间差可估算传输以及队列延时。接下来,用同样两个报文ping远端链路。再次用大报文和小报文的时间差来估算开销。最后,用两次差值的差值就是在最后一段链路中传输额外数据的时间值。这是一个往返时间,除以2就是额外数据在单向链路传输所用时间。带宽则是额外数据总量除以单向传输时间。

    下表是第二跳和第三跳的时间值,报文大小为1001100字节。

    image003.png

    下表显示了带宽计算结果,用time difference除以2,用8000bit除以这个值,再乘1000(毫秒转换为秒)。结果是bps转换为Mbps

    image004.png

     

    pathchar

     

    将上述过程自动话完成的一个工具是pathcharpathchar在路径的一端即能检测各链路的带宽。方法与之前描述的ping相类似,但是pathchar使用各种大小不一的报文。如下例所示:

    bsd1# pathchar 165.166.0.2

    pathchar to 165.166.0.2 (165.166.0.2)

    mtu limited to 1500 bytes at local host

    doing 32 probes at each of 45 sizes (64 to 1500 by 32)

    0 205.153.60.247 (205.153.60.247)

    |   4.3 Mb/s,   1.55 ms (5.88 ms)

    1 cisco (205.153.60.2)

    |   1.5 Mb/s,   -144 us (13.5 ms)

    2 165.166.36.17 (165.166.36.17)

    |    10 Mb/s,   242 us (15.2 ms)

    3 e0.r01.ia-gnwd.Infoave.Net (165.166.36.33)

    |   1.2 Mb/s,   3.86 ms (32.7 ms)

    4 165.166.125.165 (165.166.125.165)

    |   ?? b/s,   2.56 ms (37.7 ms)

    5 165.166.125.106 (165.166.125.106)

    |    45 Mb/s,   1.85 ms (41.6 ms),  +q 3.20 ms (18.1 KB) *4

    6 atm1-0-5.r01.ncchrl.infoave.net (165.166.126.1)

    |    17 Mb/s,   0.94 ms (44.3 ms),  +q 5.83 ms (12.1 KB) *2

    7 h10-1-0.r01.ia-chrl.infoave.net (165.166.125.33)

    |   ?? b/s,   89 us (44.3 ms),  1% dropped

    8 dns1.InfoAve.Net (165.166.0.2)

    8 hops, rtt 21.9 ms (44.3 ms), bottleneck 1.2 Mb/s, pipe 10372 bytes

    pathchar的运行过程中,首先显示的信息描述探测如何进行。从第三行输出开始,可看到pathchar使用从641500字节的45中不同大小报文。对于每一跳使用32种不同报文组合进行测试。因此,共8跳生成了11520个测试报文加上相应回复信息。

    显示中给出了带宽和延时。pathchar也包括了队列延时信息(如本例中56)。如上述信息,pathchar并不总是能成功估算出带宽(如链路47)或是延时(如链路1)。

    pathchar运行过程中,每发送一个报文就启动一次倒计时:显示内容如下所示:

    1:  31   288   0       3

    1指示跳数并且随着路径上后续跳数而增加。下一个数字是倒计时值,给出这一链路剩余的探测组数。第三个值是当前发送报文大小。第二个和第三个值改变都非常迅速。倒数第二个值是目前为止丢弃报文数,最后一个是该链路的平均往返时间。

    当一条的探测完成时,这一行内容被带宽,传输延时,往返时间所取代。pathchar使用观测到的最小延时来改进带宽估算值。

     

    bing

     

    pathchar的一个替代工具是bingpathchar估算的是一条路径上各链路的带宽,而bing用来测量点到点的带宽。通常,如果你不知道路径上的各条链路,需要首先执行traceroute命令。之后可以运行bing来指定链路的近端和远端。下例显示了第三跳的带宽:

    bsd1# bing -e10 -c1 205.153.60.2 165.166.36.17

    BING    205.153.60.2 (205.153.60.2) and 165.166.36.17 (165.166.36.17)

            44 and 108 data bytes

    1024 bits in 0.835ms: 1226347bps, 0.000815ms per bit

    1024 bits in 0.671ms: 1526080bps, 0.000655ms per bit

    1024 bits in 0.664ms: 1542169bps, 0.000648ms per bit

    1024 bits in 0.658ms: 1556231bps, 0.000643ms per bit

    1024 bits in 0.627ms: 1633174bps, 0.000612ms per bit

    1024 bits in 0.682ms: 1501466bps, 0.000666ms per bit

    1024 bits in 0.685ms: 1494891bps, 0.000669ms per bit

    1024 bits in 0.605ms: 1692562bps, 0.000591ms per bit

    1024 bits in 0.618ms: 1656958bps, 0.000604ms per bit

     

    --- 205.153.60.2 statistics ---

    bytes   out    in   dup  loss   rtt (ms): min       avg       max

       44    10    10          0%           3.385     3.421     3.551

      108    10    10          0%           3.638     3.684     3.762

     

    --- 165.166.36.17 statistics ---

    bytes   out    in   dup  loss   rtt (ms): min       avg       max

       44    10    10          0%           3.926     3.986     4.050

      108    10    10          0%           4.797     4.918     4.986

     

    --- estimated link characteristics ---

    estimated throughput 1656958bps

    minimum delay per packet 0.116ms (192 bits)

     

    average statistics (experimental) :

    packet loss: small 0%, big 0%, total 0%

    average throughput 1528358bps

    average delay per packet 0.140ms (232 bits)

    weighted average throughput 1528358bps

    resetting after 10 samples.

    输出从地址和报文大小信息开始,之后是探测pair。接下来,返回往返时间和丢失数据。最后,返回一些吞吐量的估测值。

     

    吞吐量测量:

     

    吞吐量不够的原因不仅在于硬件不足,还有可能是网络设计架构的问题。例如,广播域设置得太大,则即使硬件够磅也会造成问题。解决方案是重构网络,在充分理解数据流模式后,将这类域隔离开或是分段。

    吞吐量通常是测量大块数据传输延时来完成的。通常需要在链路各端运行软件。一般这类软件运行在应用层,所以它不仅测量网络也测量了软硬件。

    一个比较简单粗放的方式是用FTP。用FTP来传输一份文件并且看一下它report的数据。需要将结果转换成比特率,例如,这是文件传输的最后一行:

    1294522 bytes received in 1.44 secs (8.8e+02 Kbytes/sec)

    1,294,522字节乘8转换成bit之后再除以时间1.44秒。 结果为7,191,789 bps

    这种方法的不足在于磁盘访问时间可能对结果造成影响。如果需要提高精度则需要使用一些工具。

    ttcp

    运行这一程序首先需要在远端设备运行server,通常用-r-s选项。之后运行client,用-t-s选项,以及主机名或地址。数据从client端发送至server端,测量性能之后,在各端返回结果,之后终止client端和server端。例如,server端如下所示:

    bsd2# ttcp -r -s

    ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp

    ttcp-r: socket

    ttcp-r: accept from 205.153.60.247

    ttcp-r: 16777216 bytes in 18.35 real seconds = 892.71 KB/sec +++

    ttcp-r: 11483 I/O calls, msec/call = 1.64, calls/sec = 625.67

    ttcp-r: 0.0user 0.9sys 0:18real 5% 15i+291d 176maxrss 0+2pf 11478+28csw

    client端如下所示:

    bsd1# ttcp -t -s 205.153.63.239

    ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 205.153.63.239

    ttcp-t: socket

    ttcp-t: connect

    ttcp-t: 16777216 bytes in 18.34 real seconds = 893.26 KB/sec +++

    ttcp-t: 2048 I/O calls, msec/call = 9.17, calls/sec = 111.66

    ttcp-t: 0.0user 0.5sys 0:18real 2% 16i+305d 176maxrss 0+2pf 3397+7csw

    该程序报告中显示了信息传输总量,标识了连接的建立,并且给出了结果,包括raw datathroughputI/O call信息,执行时间。最有用的信息应该是transfer rate892.71 KB/sec (or 893.26 KB/sec)

    这一数据反映了数据的传输速率,而不是链路的容量。将这一数据转化成带宽可能是有问题的,因为实际上传输了比这一值更多的比特数。这一程序显示18.35秒传送了16,777,216字节,但是这仅仅是数据。以太网报文封装还包括TCPIP,以太网报文头,估算容量时,需要把这些值加上去。

    吞吐量低通常意味着拥塞,但也并不总是如此。吞吐量也会取决于配置问题,如连接的TCP窗口大小。如果窗口大小不足,会严重影响到性能。

    (未完待续)

    参考

     

    Network Troubleshooting Tools

     

     

                 

  • 94. Re: 网络基本功系列:细说网络那些事儿(11月24日更新)
    ճС��

    我对网络数据传输知识非常感兴趣,但是自己这方面的知识储备太少,您写的网络基本功系列非常棒,但是自己能明白的还是太少,能不能推荐几本入门级别的网络数据传输书籍?还有以后有关于这方面的问题如何像您请教?谢谢!

  • 95. Re: 网络基本功系列:细说网络那些事儿(11月24日更新)
    Zhang,Jiawen

    谢谢。其实前五章着重写的就是报文在网络中传播的详细过程,文章看着长内容是比较基本的,基本上没什么复杂的难点。之前也有网友让推荐书,介绍的是英文的看起来有点费劲,我稍后归纳整理一些中文书籍在这个帖子里推荐给大家。

  • 96. Re: 网络基本功系列:细说网络那些事儿(11月24日更新)
    ճС��

    期待您的推荐!

  • 97. Re: 网络基本功系列:细说网络那些事儿(11月24日更新)
    Zhang,Jiawen

    网络基本功(十六):细说网络性能监测与实例(下)

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

     

    介绍

     

    网络问题中,性能问题是最复杂的问题之一,解决这样的问题能够透彻的了解整个网络的结构。但通过合适的吞吐量和数据流测试工具,能够帮你快速找到问题所在。本文承接上文,阐述netperfnetstat的用法。


    更多信息

     

    吞吐量测量:

    (承接上文)

    netperf

    该程序是由HP创造,该程序免费可用,运行于一些Unix平台,有支持文档,也被移植到Windows平台。虽然不像ttcp那样无处不在,但它的测试范围更加广泛。

    ttcp不同,客户端和服务器端是分开的程序。服务器端是netserver,能够单独启动,或通过inetd启动。客户端是netperf。下例中,服务器和客户端启动于同一台机器:

    bsd1# netserver

    Starting netserver at port 12865

    bsd1# netperf

    TCP STREAM TEST to localhost : histogram

    Recv   Send    Send

    Socket Socket  Message  Elapsed

    Size   Size    Size     Time     Throughput

    bytes  bytes   bytes    secs.    10^6bits/sec

     

    16384  16384  16384    10.00     326.10

    测试的是loop-back接口,报告显示吞吐量为326Mbps

     

    下例中,netserver启动于主机:

    bsd1# netserver

    Starting netserver at port 12865

    netperf加上-H选项指定服务器地址:

    bsd2# netperf -H 205.153.60.247

    TCP STREAM TEST to 205.153.60.247 : histogram

    Recv   Send    Send

    Socket Socket  Message  Elapsed

    Size   Size    Size     Time     Throughput

    bytes  bytes   bytes    secs.    10^6bits/sec

     

    16384  16384  16384    10.01       6.86

    大致与ttcp所得出的吞吐量相同。netperf还进行了一些额外的测试。以下测试中,还计算了连接的transaction rate

    bsd2# netperf -H 205.153.60.247 -tTCP_RR

    TCP REQUEST/RESPONSE TEST to 205.153.60.247 : histogram

    Local /Remote

    Socket Size   Request  Resp.   Elapsed  Trans.

    Send   Recv   Size     Size    Time     Rate

    bytes  Bytes  bytes    bytes   secs.    per sec

     

    16384  16384  1        1       10.00     655.84

    16384  16384

    该程序包含一些测试脚本。也可以使用netperf做各种流测试。

     

    iperf

    如果ttcpnetperf都不符合你的要求,那么可以考虑iperfiperf也可以用于测试UDP带宽,丢失率,和抖动。Java前端让该工具便于使用。该工具同样移植入windows

    下例是运行iperf服务器端:

    bsd2# iperf -s -p3000

    ------------------------------------------------------------

    Server listening on TCP port 3000

    TCP window size: 16.0 KByte (default)

    ------------------------------------------------------------

    [  4] local 172.16.2.236 port 3000 connected with 205.153.63.30 port 1133

    [ ID] Interval       Transfer     Bandwidth

    [  4]  0.0-10.0 sec   5.6 MBytes   4.5 Mbits/sec

    ^C

    下例是在windows运行客户端:

    C:\>iperf -c205.153.60.236

    -p3000

    ------------------------------------------------------------

    Client connecting to 205.153.60.236, TCP port 3000

    TCP window size:  8.0 KByte (default)

    ------------------------------------------------------------

    [ 28] local 205.153.63.30 port 1133 connected with 205.153.60.236 port 3000

    [ ID] Interval       Transfer     Bandwidth

    [ 28]  0.0-10.0 sec   5.6 MBytes   4.5 Mbits/sec

     

    注意使用Ctrl-C来终止服务器端。在TCP模式下,iperf相当于ttcp,所以它可盈用户客户端或服务器。

    在研究TCP窗口是否足够大时,使用iperf特别方便。-w选项设置socket buffer大小。对于TCP来说,这就是窗口大小。通过-w选项,用户可以单步调试各种窗口大小来看它们是怎样影响吞吐量的。

     

    其他工具

    你也许想要考虑一些相关或类似的工具。treno使用的方法类似于traceroute来计算块容量,路径MTU,以及最小RTP。如下例所示:

    bsd2# treno 205.153.63.30

    MTU=8166  MTU=4352  MTU=2002  MTU=1492 ..........

    Replies were from sloan.lander.edu [205.153.63.30]

        Average rate: 3868.14 kbp/s (3380 pkts in + 42 lost = 1.2%) in 10.07 s

    Equilibrium rate:      0 kbp/s (0 pkts in + 0 lost =   0%) in    0 s

    Path properties: min RTT was  13.58 ms, path MTU was 1440 bytes

    XXX Calibration checks are still under construction, use –v

     

    通常来说,netperfiperftreno提供更加丰富的feature,但ttcp更加容易找到。

     

     

    通过netstat进行流量测量:

    在理想的网络环境下,如果把overhead算在内,吞吐量是很接近于带宽的。但是吞吐量往往低于期望值,这种情况下,你会想要知道差异在哪。如之前所提到的,可能与硬件或软件相关。但通常是由于网络上其他数据流的影响。如果你无法确定原因,下一步就是查看你网络上的数据流。

    有三种基本方法可供采用。第一,最快的方法是使用如netstat这样的工具来查看链路行为。或通过抓包来查看数据流。最后,可使用基于SNMP的工具如ntop

    要得到网络上数据流的快照,使用-i选项。举例来说:

    bsd2# netstat -i

    Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

    lp0*  1500  <Link>                               0     0        0     0     0

    ep0   1500  <Link>      00.60.97.06.22.22 13971293     0  1223799     1     0

    ep0   1500  205.153.63    bsd2            13971293     0  1223799     1     0

    tun0* 1500  <Link>                               0     0        0     0     0

    sl0*  552   <Link>                               0     0        0     0     0

    ppp0* 1500  <Link>                               0     0        0     0     0

    lo0   16384 <Link>                             234     0      234     0     0

    lo0   16384 127           localhost            234     0      234     0     0

    输出显示了自上一次重启以来,各接口所处理的报文数量。在本例中,接口ep0收到13,971,293个没有差错(Ierrs)的报文(Ipkts),发送了1,223,799 个报文(Opkts),有1个差错,没有冲突(Coll)。少量错误通常并不是造成告警的原因,但各错误所占比例应当是维持在较低水平,应该明显低于报文总量的0.1%。冲突可以稍微高一些,但应当少于数据流总量的10%。冲突数量仅包括那些影响接口的。较高数量的冲突喻示着网络负载较高,用户应当考虑分段。冲突只出现在特定媒介上。

     

    如果你只想要单一接口的输出,可以通过-I选项指定,如:

    bsd2# netstat -Iep0

    Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

    ep0   1500  <Link>      00.60.97.06.22.22 13971838     0  1223818     1     0

    ep0   1500  205.153.63    bsd2            13971838     0  1223818     1     0

    随着实现的不同,输出可能看起来有些差异,但基本信息是一样的。例如,Linux平台的输出:

    lnx1# netstat -i

    Kernel Interface table

    Iface   MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg

    eth0   1500   0  7366003      0      0      0    93092      0      0      0 BMRU

    eth1   1500   0   289211      0      0      0    18581      0      0      0 BRU

    lo     3924   0      123      0      0      0      123      0      0      0 LRU

    如上例所示,Linux将丢失报文拆成三个目录:errors, drops,以及overruns

    不方便的是,netstat的返回值是系统自上一次重启之后的累计值。我们真正关心的是这些数值最近是怎样变化的,因为问题是在发展的,在它增长到足以显现问题之前会花费相当长的时间。

     

    有时你会对系统做一些压力测试来看错误是否增加,可以使用ping–I选项或spray命令。

    首先,运行netstat来得到当前值:

    bsd2# netstat -Iep0

    Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

    ep0   1500  <Link>      00.60.97.06.22.22 13978296     0  1228137     1     0

    ep0   1500  205.153.63    bsd2            13978296     0  1228137     1     0

     

    接下来,发送大量报文到目的地址。本例中,发送了1000UDP报文:

    bsd1# spray -c1000 205.153.63.239

    sending 1000 packets of lnth 86 to 205.153.63.239 ...

            in 0.09 seconds elapsed time

            464 packets (46.40%) dropped

    Sent:   11267 packets/sec, 946.3K bytes/sec

    Rcvd:   6039 packets/sec, 507.2K bytes/sec

    注意到该测试超出了网络容量,因为464个报文被丢弃了。这可能意味着网络拥塞。更加可能的是,主机正在尝试与一个慢速设备通信。当spray在相反方向运行时,没有报文丢弃。

    最后,回到netstat来看看是否存在问题:

    bsd2# netstat -Iep0

    Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

    ep0   1500  <Link>      00.60.97.06.22.22 13978964     0  1228156     1     0

    ep0   1500  205.153.63    bsd2            13978964     0  1228156     1     0

    本例显示没有问题。

     

    如果显示有问题,可以通过-s选项来得到。输出数据量可能有点吓人,但可以提供丰富的信息。信息按照协议和错误类型来分段,如bad checksum或报文头不完整。

     

    在某些系统上,两次-s选项显示非零值的总和,如下所示:

    bsd2# netstat -s -s

    ip:

            255 total packets received

            255 packets for this host

            114 packets sent from this host

    icmp:

            ICMP address mask responses are disabled

    igmp:

    tcp:

            107 packets sent

                    81 data packets (8272 bytes)

                    26 ack-only packets (25 delayed)

            140 packets received

                    77 acks (for 8271 bytes)

                    86 packets (153 bytes) received in-sequence

            1 connection accept

            1 connection established (including accepts)

            77 segments updated rtt (of 78 attempts)

            2 correct ACK header predictions

            62 correct data packet header predictions

    udp:

            115 datagrams received

            108 broadcast/multicast datagrams dropped due to no socket

            7 delivered

            7 datagrams output

    通过-p选项显示某一协议的汇总信息,下例显示TCP非零值的统计信息:

    bsd2# netstat -p tcp -s -s

    tcp:

            147 packets sent

                    121 data packets (10513 bytes)

                    26 ack-only packets (25 delayed)

            205 packets received

                    116 acks (for 10512 bytes)

                    122 packets (191 bytes) received in-sequence

            1 connection accept

            1 connection established (including accepts)

            116 segments updated rtt (of 117 attempts)

            2 correct ACK header predictions

            88 correct data packet header predictions

    解释这一结果是需要一些经验的。一开始可以从大量错误信息开始看起。接下来,识别错误类型。通常,input error是由于硬件故障应期的。 Output error是由本地主机的问题造成。Data corruption,例如错误校验和,通常产生于服务器。冲突往往意味着网络拥塞。当然,这只是一般情况。

     

     

     

    参考

     

    Network Troubleshooting Tools

     

     

     

     

     

                 

  • 98. Re: 网络基本功系列:细说网络那些事儿(12月1日更新)
    Zhang,Jiawen

    刚看到点击量破了个整数,谢谢大家来看这个帖子。欢迎大家在帖子里留言讨论,我会尽力回复~

  • 99. Re: 网络基本功系列:细说网络那些事儿(11月24日更新)
    Zhang,Jiawen

    《计算机网络》 谢希仁编著。计算机的专业课本。

    《TCP/IP 详解 卷一 》可以对网络中常用的协议有透彻地了解。

    另外,思科的CCNA交换与路由也是相当不错的书。

  • 100. Re: 网络基本功系列:细说网络那些事儿(12月1日更新)
    NaNi_Z

    好久没来已经更新了这么多,要恶补一下了

    感谢分享~

  • 101. Re: 网络基本功系列:细说网络那些事儿(12月1日更新)
    Zhang,Jiawen

    好久没见~有问题欢迎讨论~

  • 102. Re: 网络基本功系列:细说网络那些事儿(12月1日更新)
    kinolucky163

    你好,有个问题想咨询一下。

    当局域网内的机器访问外网的一个servcie时,从ip数据包的角度来看的话

     

    发送时是没问题的,数据包先到网关,再到service, 想问一下,service收到数据包时,里面的源ip是谁的ip?(应该是网关的吧)

     

    再就是service返回数据包时,是如何正确回给局域网内的那台机器的?ip层没有会话的概念,是如何保证了这种会话的。是不是网关保证了这种会话,如果是,是如何实现的?有没有相关的参考资料

     

    谢谢!

  • 103. Re: 网络基本功系列:细说网络那些事儿(12月1日更新)
    Zhang,Jiawen

    当局域网内的机器访问外网的一个servcie时,从ip数据包的角度来看的话

     

    发送时是没问题的,数据包先到网关,再到service, 想问一下,service收到数据包时,里面的源ip是谁的ip?

    在报文从原设备传输至目的设备的过程中,三层IP地址不会改变。但是,每一跳随着报文在路由器中被解封装和重新封装,二层数据链路地址都会改变。所以,源IP是局域网机器的IP。

    再就是service返回数据包时,是如何正确回给局域网内的那台机器的?ip层没有会话的概念,是如何保证了这种会话的。

    “如何正确回给局域网的机器”这个问题有点含糊,我理解这个问题和会话层应该是两个概念。能具体说一下吗?

  • 104. Re: 网络基本功系列:细说网络那些事儿(12月1日更新)
    xidianlz

    一般局域网的ip都是私有ip,在公网是找不到的,主要借助的是网关上的nat技术找到局域网的那台机器吧。

1 5 6 7 8 9 上一个 下一个