未解决
此帖子已超过 5 年
1.2K 消息
31
507253
网络基本功系列：细说网络那些事儿(3月26日更新)
网络基本功（一）：细说网络传输
转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese
介绍
常言道：欲练神功，必先练好基本功。之前做了一个关于IP路由，默认网关和掩码的问答贴，做完这个帖子觉得如果对网络知识点做一个系统的阐述，应该会很有帮助。
本系列文章着重于讲解网络管理实际应用中常常涉及的重要知识点，尽量以实用为主。准备写的几个章节暂时有（可能会有增减）：
- 网络传输
- 交换机
- VLAN与Trunk
- 路由(上)
- 路由(下)
- 链路聚合
- IP地址与子网
- NAT原理与配置
- ICMP与ARP
- TCP滑动窗口
- TCP重传
- TCP确认机制
- TCP窗口调整与流控
- Wireshark抓包实例诊断TCP连接问题 (精)
- Wireshark抓包实例诊断TCP重传 (精)
- Wireshark抓包实例诊断TCP重复ACK与乱序 （精）
- Wireshark抓包实例诊断TCP窗口与reset （精）
- Wireshark抓包实例诊断HTTP问题 （精）
- Wireshark抓包实例诊断数据库问题
- HTTP(上)
- HTTP(下)
- DNS（上） （NEW)
- 细说Linux网络配置（上）
- 细说Linux网络配置（下）
- 常用诊断工具：ping
- 网络性能监测与实例（上）
- 网络性能监测与实例（下）
- tcpdump的妙用 (上)
- tcpdump的妙用（下）
更多信息
首先来看一个例子：
示例：网络服务器向客户端传送数据的过程:
在详细阐述网络传输过程之前，先来看一个最常见的例子，下图显示了一个网络服务器向客户端传送数据的完整过程：
1. 需要传送的数据是网络服务器的HTML页面。
2. 应用协议HTTP报文头添加到HTML数据之前。报文头信息包括：服务器所使用的HTTP版本，以及表明它包含发给网络客户端信息的状态编码。
3. HTTP应用层协议将HTML格式的网页数据发送给传输层。TCP传输层用于管理网络服务器和客户端之间的会话。
4. IP信息添加到TCP信息之前。IP指定适当的源和目的IP地址。这些信息就构成了IP报文。
5. 以太网协议添加到IP报文的两端之后，就形成了数据链路帧。上述帧发送至通向网络客户端的路径上的最近一个路由器。路由器移除以太网信息，观察IP报文，判定最佳路径，将报文插入一个新的帧，并发送至目标路径上下一个相邻路由器。每一个路由器在转发之前都移除并添加新的数据链路层信息。
6. 数据通过互联网络传输，互联网络包含媒介和中间设备。
7. 客户端接收到包含数据的数据链路帧，处理各层协议头，之后以添加时相反的顺序移除协议头。首先处理并移除以太网信息，之后是IP协议信息，接下来TCP信息，最后是HTTP信息。
8. 之后，将网页信息传递给客户端网页浏览器软件。
数据封装:
消息要在网络中传输，必须对它进行编码，以特定的格式进行封装，同时需要适当地封装以足够的控制和地址信息，以使它能够从发送方移动到接收方。
消息大小
理论上，视频或邮件信息是能够以大块非中断型流从网络源地址传送到目的地址，但这也意味着同一时刻同一网络其他设备就无法收发消息。这种大型数据流会造成显著延时。并且，如果传输过程中连接断开，整个数据流都会丢失需要全部重传。因此更好的方法是将数据流分割（segmentation）为较小的，便于管理的片段，能够带来两点好处：
· 发送较小片段，网络上同时可有多个会话交错进行。这种在网络上将不同会话片段交错进行的过程称为多路传输（multiplexing）。
· 分割可提高网络通讯的可靠性。各消息片段从源地址到目的地址无需经过相同路径，如果一条路径被堵塞或断开，其余消息可从替换路径到达目的地址。如果部分消息到不了目的地址，那只需重传丢失部分。
通过对片段打上标签的方式来保证顺序以及在接收时重组。
协议数据单元（Protocol Data Unit, PDU）
应用层数据在传输过程中沿着协议栈传递，每一层协议都会向其中添加信息。这就是封装的过程。
数据片段在各层网络结构中采用的形式就称为协议数据单元（PDU）。封装过程中，下一层对从上一层收到的PDU进行封装。在处理的每一个阶段PDU都有不同的名字来反应它的功能。
PDU按照TCP/IP协议的命名规范：
· 数据（Data）：应用层PDU的常用术语
· 分段（Segment）：传输层PDU
· 帧（Frame）：网络层PDU
· 比特（Bits）：在介质上物理传输数据所使用的PDU。
封装
封装是指在传输之前为数据添加额外的协议头信息的过程。在绝大多数数据通信过程中，源数据在传输前都会封装以数层协议。在网络上发送消息时，主机上的协议栈从上至下进行操作。
以网络服务器为例，HTTP应用层协议发送HTML格式网页数据到传输层，应用层数据被分成TCP分段。各TCP分段被打上标签，称为头（header），表明接收方哪一个进程应当接收此消息。同时也包含使得接收方能够按照原有的格式来重组数据的信息。
传输层将网页HTML数据封装成分段并发送至网络层，执行IP层协议。整个TCP分段封装成IP报文，也就是再添上IP头标签。IP头包括源和目的IP地址，以及发送报文到目的地址所必须的信息。
之后，IP报文发送到接入层，封装以帧头和帧尾。每个帧头都包含源和目的物理地址。物理地址唯一指定了本地网络上的设备。帧尾包含差错校正信息。最后，由服务器网卡将比特编码传输给介质。
解封装
接收主机以相反的方式进行操作称为解封装。解封装是接收设备移除一层或多层协议头的过程。数据在协议栈中向上移动直到终端应用层伴随着解封装。
访问本地资源：
访问本地网络资源需要两种类型的地址：网络层地址和数据链路层地址。网络层和数据链路层负责将数据从发送设备传输至接收设备。两层协议都有源和目的地址，但两种地址的目的不同。
示例：客户端PC1与FTP在同一IP网络的通信
网络地址
网络层地址或IP地址包含两个部分：网络前缀和主机。路由器使用网络前缀部分将报文转发给适当的网络。最后一个路由器使用主机部分将报文发送给目标设备。同一本地网络中，网络前缀部分是相同的，只有主机设备地址部分不同。
源IP地址：发送设备，即客户端PC1的IP地址：192.168.1.110
目的IP地址：接收设备，即FTP服务器：192.168.1.9
数据链路地址
数据链路地址的目的是在同一网络中将数据链路帧从一个网络接口发送至另一个网络接口。以太网LAN和无线网LAN是两种不同物理介质的网络示例，分别有自己的数据链路协议。
当IP报文的发送方和接收方位于同一网络，数据链路帧直接发送到接收设备。以太网上数据链路地址就是以太网MAC地址。MAC地址是物理植入网卡的48比特地址。
源MAC地址：发送IP报文的PC1以太网卡MAC地址，AA-AA-AA-AA-AA-AA。
目的MAC地址：当发送设备与接收设备位于同一网络，即为接收设备的数据链路地址。本例中，FTP MAC地址：CC-CC-CC-CC-CC-CC。
源和目的MAC地址添加到以太网帧中。
MAC与IP地址
发送方必须知道接收方的物理和逻辑地址。发送方主机能够以多种方式学习到接收方的IP地址：比如域名系统（Domain Name System, DNS），或通过应用手动输入，如用户指定FTP地址。
以太网MAC地址是怎么识别的呢？发送方主机使用地址解析协议（Address Resolution Protocol, ARP）以检测本地网络的所有MAC地址。如下图所示，发送主机在整个LAN发送ARP请求消息，这是一条广播消息。ARP请求包含目标设备的IP地址，LAN上的每一个设备都会检查该ARP请求，看看是否包含它自身的IP地址。只有符合该IP地址的设备才会发送ARP响应。ARP响应包含ARP请求中IP地址相对应的MAC地址。
访问远程资源：
默认网关
当主机发送消息到远端网络，必须使用路由器，也称为默认网关。默认网关就是位于发送主机同一网络上的路由器的接口IP地址。有一点很重要：本地网络上的所有主机都能够配置自己的默认网关地址。如果该主机的TCP/IP设置中没有配置默认网关地址，或指定了错误的默认网关地址，则远端网络消息无法被送达。
如下图所示，LAN上的主机PC 1使用IP地址为192.168.1.1的R1作为默认网关，如果PDU的目的地址位于另一个网络，则主机将PDU发送至路由器上的默认网关。
与远端网络设备通讯
下图显示了客户端主机PC 1与远端IP网络服务器进行通讯的网络层地址与数据链路层地址：
网络地址
当报文的发送方与接收方位于不同网络，源和目的IP地址将会代表不同网络上的主机。
源IP地址：发送设备即客户端主机PC 1的IP地址：192.168.1.110。
目的IP地址：接收设备即网络服务器的IP地址：172.16.1.99。
数据链路地址
当报文的发送方与接收方位于不同网络，以太网数据链路帧无法直接被发送到目的主机。以太网帧必须先发送给路由器或默认网关。本例中，默认网关是R1，R1的接口IP地址与PC 1属于同一网络，因此PC 1能够直接达到路由器。
源MAC地址：发送设备即PC 1的MAC地址，PC1的以太网接口MAC地址为：AA-AA-AA-AA-AA-AA。
目的MAC地址：当报文的发送方与接收方位于不同网络，这一值为路由器或默认网关的以太网MAC地址。本例中，即R1的以太网接口MAC地址，即：11-11-11-11-11-11。
IP报文封装成的以太网帧先被传输至R1，R1再转发给目的地址即网络服务器。R1可以转发给另一个路由器，如果目的服务器所在网路连接至R1，则直接发送给服务器。
发送设备如何确定路由器的MAC地址？每一个设备通过自己的TCP/IP设置中的默认网关地址得知路由器的IP地址。之后，它通过ARP来得知默认网关的MAC地址，该MAC地址随后添加到帧中。
xixihaha
3 消息
0
2014年11月9日 00:00
这两天学习了一下OSPF网络。
讲述OSPF优点时，其中有一句“将某一区域网络拓扑变化的影响限制在该区域内，不会影响到整个OSPF网络”。
通过OSPF中area的概念，使区域内的路由信息数据就不会有那么多了？可以这样解释吗？
Zhang_Jiawen
1.2K 消息
0
2014年11月9日 16:00
网络基本功（十四）：细说诊断工具ping
转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese![image001.gif]()
介绍
ping的工作原理很简单，一台网络设备发送请求等待另一网络设备的回复，并记录下发送时间。接收到回复之后，就可以计算报文传输时间了。只要接收到回复就表示连接是正常的。耗费的时间喻示了路径长度。重复请求响应的一致性也表明了连接质量的可靠性。因此，ping回答了两个基本的问题：是否有连接？连接的质量如何？本文主要讨论这两个问题。
更多信息
正常的ping操作主要是两个特定的ICMP消息，ECHO_REQUEST和ECHO_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 number，TTL值，以及往返时间。其中，sequence number和往返时间对于评估基本连接状况来说是最有用的信息。
当发送一个ECHO_REQUEST时，将发送时间记录在报文里，并复制到远端主机相应的ECHO_REPLY报文中。当接收到ECHO_REPLY时，通过比较当前时间与报文时间计算出耗费时间。如果没有收到符合该sequence number的报文，则认为该报文丢失。耗费时间长短以及变化范围取决于中间链路数量，速度，以及链路拥塞情况。
什么值是合理的呢？这一值高度取决于网络以及网络质量。如果是在LAN网络环境下，响应时间还是很快的，通常在十几毫秒范围之内。如果连接到外网则该值会显著增加。如果是远程站点，可能会耗时上百毫秒。
你也可以用ping来粗略计算连接的吞吐量。在外网上发送两个不同大小的报文，通过-s选项来完成。时间长度的差别会反映大报文中额外数据所耗费的时间。例如，假设ping 100字节耗费30ms而ping 1100字节耗费60ms，因此，往返额外花费30ms单程额外花费15ms，多发送1000字节或8000比特。吞吐量近似为每15ms 8000比特或540，000bps。两个测量值之间的差异用来扣除开销。当然这一估算是非常粗略的，没有考虑到路径上其他数据流的情况，也没有考虑路径上所有链路的情况。
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
Zhang_Jiawen
1.2K 消息
0
2014年11月23日 18:00
网络基本功（十五）：细说网络性能监测与实例（上）
转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese![image001.gif]()
介绍
网络路径性能检测主要包括三方面的内容：带宽测量能够获知网络的硬件特性，如网络的最大容量，吞吐量测量能够获得网络实际可提供的最大容量，数据流测量能够了解真实占用的网络容量。
本文介绍在评估网络性能是否合理时，需要收集的数据及收集方式。涉及工具包括：ping, pathchar, bing, ttcp, netperf, iperf, netstat。
更多信息
带宽测量:
ping
ping这一工具返回的时间，虽然通常被描述为传输延时，实际上是发送，传输，队列延时之和。上一节中，我们通过ping来粗略计算带宽。这一过程可通过如下方式改进：首先计算链路近端的路径行为，然后计算远端路径，然后用两者差异来估算链路带宽。
这一过程需要四次使用ping。首先，用两个不同大小报文ping近端链路。减掉传输大报文中额外数据的传输时间以外，时间差可估算传输以及队列延时。接下来，用同样两个报文ping远端链路。再次用大报文和小报文的时间差来估算开销。最后，用两次差值的差值就是在最后一段链路中传输额外数据的时间值。这是一个往返时间，除以2就是额外数据在单向链路传输所用时间。带宽则是额外数据总量除以单向传输时间。
下表是第二跳和第三跳的时间值，报文大小为100和1100字节。
下表显示了带宽计算结果，用time difference除以2，用8000bit除以这个值，再乘1000（毫秒转换为秒）。结果是bps转换为Mbps。
pathchar
将上述过程自动话完成的一个工具是pathchar。pathchar在路径的一端即能检测各链路的带宽。方法与之前描述的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使用从64到1500字节的45中不同大小报文。对于每一跳使用32种不同报文组合进行测试。因此，共8跳生成了11，520个测试报文加上相应回复信息。
显示中给出了带宽和延时。pathchar也包括了队列延时信息（如本例中5和6）。如上述信息，pathchar并不总是能成功估算出带宽（如链路4和7）或是延时（如链路1）。
在pathchar运行过程中，每发送一个报文就启动一次倒计时：显示内容如下所示：
1: 31 288 0 3
1指示跳数并且随着路径上后续跳数而增加。下一个数字是倒计时值，给出这一链路剩余的探测组数。第三个值是当前发送报文大小。第二个和第三个值改变都非常迅速。倒数第二个值是目前为止丢弃报文数，最后一个是该链路的平均往返时间。
当一条的探测完成时，这一行内容被带宽，传输延时，往返时间所取代。pathchar使用观测到的最小延时来改进带宽估算值。
bing
pathchar的一个替代工具是bing。pathchar估算的是一条路径上各链路的带宽，而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 data，throughput，I/O call信息，执行时间。最有用的信息应该是transfer rate，892.71 KB/sec (or 893.26 KB/sec)。
这一数据反映了数据的传输速率，而不是链路的容量。将这一数据转化成带宽可能是有问题的，因为实际上传输了比这一值更多的比特数。这一程序显示18.35秒传送了16,777,216字节，但是这仅仅是数据。以太网报文封装还包括TCP，IP，以太网报文头，估算容量时，需要把这些值加上去。
吞吐量低通常意味着拥塞，但也并不总是如此。吞吐量也会取决于配置问题，如连接的TCP窗口大小。如果窗口大小不足，会严重影响到性能。
（未完待续）
参考
Network Troubleshooting Tools
ճС__
2 消息
0
2014年11月25日 14:00
我对网络数据传输知识非常感兴趣，但是自己这方面的知识储备太少，您写的网络基本功系列非常棒，但是自己能明白的还是太少，能不能推荐几本入门级别的网络数据传输书籍？还有以后有关于这方面的问题如何像您请教？谢谢！
Zhang_Jiawen
1.2K 消息
2
2014年11月26日 17:00
谢谢。其实前五章着重写的就是报文在网络中传播的详细过程，文章看着长内容是比较基本的，基本上没什么复杂的难点。之前也有网友让推荐书，介绍的是英文的看起来有点费劲，我稍后归纳整理一些中文书籍在这个帖子里推荐给大家。
ճС__
2 消息
0
2014年11月28日 16:00
期待您的推荐！
Zhang_Jiawen
1.2K 消息
0
2014年11月30日 17:00
网络基本功（十六）：细说网络性能监测与实例（下）
转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese![image001.gif]()
介绍
网络问题中，性能问题是最复杂的问题之一，解决这样的问题能够透彻的了解整个网络的结构。但通过合适的吞吐量和数据流测试工具，能够帮你快速找到问题所在。本文承接上文，阐述netperf和netstat的用法。
更多信息
吞吐量测量:
(承接上文)
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
如果ttcp和netperf都不符合你的要求，那么可以考虑iperf。iperf也可以用于测试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
通常来说，netperf，iperf和treno提供更加丰富的feature，但ttcp更加容易找到。
通过netstat进行流量测量:
在理想的网络环境下，如果把overhead算在内，吞吐量是很接近于带宽的。但是吞吐量往往低于期望值，这种情况下，你会想要知道差异在哪。如之前所提到的，可能与硬件或软件相关。但通常是由于网络上其他数据流的影响。如果你无法确定原因，下一步就是查看你网络上的数据流。
有三种基本方法可供采用。第一，最快的方法是使用如netstat这样的工具来查看链路行为。或通过抓包来查看数据流。最后，可使用基于SNMP的工具如ntop。
要得到网络上数据流的快照，使用-i选项。举例来说：
bsd2# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lp0* 1500 0 0 0 0 0
ep0 1500 00.60.97.06.22.22 13971293 0 1223799 1 0
ep0 1500 205.153.63 bsd2 13971293 0 1223799 1 0
tun0* 1500 0 0 0 0 0
sl0* 552 0 0 0 0 0
ppp0* 1500 0 0 0 0 0
lo0 16384 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 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 00.60.97.06.22.22 13978296 0 1228137 1 0
ep0 1500 205.153.63 bsd2 13978296 0 1228137 1 0
接下来，发送大量报文到目的地址。本例中，发送了1000个UDP报文：
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 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
Zhang_Jiawen
1.2K 消息
1
2014年11月30日 17:00
刚看到点击量破了个整数，谢谢大家来看这个帖子。欢迎大家在帖子里留言讨论，我会尽力回复～
Zhang_Jiawen
1.2K 消息
0
2014年11月30日 23:00
《计算机网络》 谢希仁编著。计算机的专业课本。
《TCP/IP 详解 卷一 》可以对网络中常用的协议有透彻地了解。
另外，思科的CCNA交换与路由也是相当不错的书。
NaNi_Z
13 消息
0
2014年12月1日 00:00
好久没来已经更新了这么多，要恶补一下了
感谢分享~
Zhang_Jiawen
1.2K 消息
0
2014年12月1日 00:00
好久没见～有问题欢迎讨论～
kinolucky163
9 消息
0
2014年12月3日 22:00
你好，有个问题想咨询一下。
当局域网内的机器访问外网的一个servcie时，从ip数据包的角度来看的话
发送时是没问题的，数据包先到网关，再到service, 想问一下，service收到数据包时，里面的源ip是谁的ip?(应该是网关的吧）
再就是service返回数据包时，是如何正确回给局域网内的那台机器的？ip层没有会话的概念，是如何保证了这种会话的。是不是网关保证了这种会话，如果是，是如何实现的？有没有相关的参考资料
谢谢！
Zhang_Jiawen
1.2K 消息
0
2014年12月4日 00:00
在报文从原设备传输至目的设备的过程中，三层IP地址不会改变。但是，每一跳随着报文在路由器中被解封装和重新封装，二层数据链路地址都会改变。所以，源IP是局域网机器的IP。
“如何正确回给局域网的机器”这个问题有点含糊，我理解这个问题和会话层应该是两个概念。能具体说一下吗？
xidianlz
6 消息
0
2014年12月4日 01:00
一般局域网的ip都是私有ip，在公网是找不到的，主要借助的是网关上的nat技术找到局域网的那台机器吧。
kinolucky163
9 消息
0
2014年12月4日 01:00
好的，明白了。
谢谢了！同时谢谢两位的解答！