注：本文章为华为HCIA-Datacom学习指南的整理，作者为王达老师，感兴趣的朋友可以去看看
3.1 ICMP
ICMP是TCP/IPv4协议簇中的核心协议之一，也是体系结构中网络层的一个重要协议，用于IP网络设备之间发送控制数据包，传输差错、控制、查询等信息。
3.1.1 ICMP数据包格式
ICMP与IPv4协议同位于网络层，但它的子层次高于IPv4协议，所以ICMP数据包发送时需要经过IPv4协议的封装（如果IPv4数据包中是ICMP消息，则IPv4数据包头中的Protocol字段值为1），到了以太网数据链路层后，还要经过以太网协议封装。其整体封装结构如图3 - 1所示，其中ICMP数据包作为IPv4数据包中的Data部分，包括以下4个字段。
① Type：1 个字节，指示消息类型。目前已定义了 14 种消息类型，其可分为两大类，第一类是取值为 1～127 的差错数据包，第二类是取值为 128 以上的信息数据包。
② Code：1 个字节，指示消息代码，包含了消息类型中的具体参数。
ICMP 定义了多种消息类型，用于诊断网络连接性问题。根据这些消息，源设备可以判断出数据传输失败的原因。例如：目的地址不可达（可能是路由不通，也可能是目的地址输入错误），如果是路由原因，则会返回目的网络不可达消息；如果无法找到目的设备，则会返回目的主机不可达消息；如果网络中发生了环路，导致数据包在网络中循环转发，且最终因 TTL 超时，数据传输不到目的设备，或者因为网络连接性能导致请求消息传输超时，传输不到目的设备，则会返回请求超时消息。
在这些 ICMP 消息中，有些不需要 Code 字段来描述具体类型参数，仅用 Type 字段表示消息类型。比如，ICMP Echo 应答消息仅 Type 字段设置为 0。但有些 ICMP 消息要使用 Type 字段定义消息大类，同时要用 Code 字段表示消息的具体参数。比如，Type 为 3 的消息表示目的不可达，不同的 Code 值又可表示不可达的具体原因，如目的网络不可达（Code=0）、目的主机不可达（Code=1）、协议不可达（Code=2）、目的 TCP/UDP 端口不可达（Code=3）等。主要的 ICMP 消息类型及描述见表 3-1。
表3 - 1 主要的ICMP消息类型及描述
| Type | Code | 描述 |
|---|---|---|
| 0 | 0 | Echo应答 |
| 3 | 0 | 网络不可达 |
| 3 | 1 | 主机不可达 |
| 3 | 2 | 协议不可达 |
| 3 | 3 | TCP/UDP端口不可达 |
| 5 | 0 | ICMP重定向 |
| 8 | 0 | Echo请求 |
③ Checksum：2 个字节，对包括 ICMP 消息内容在内的整个 ICMP 数据包（不包括帧头和 IPv4 数据包头）进行校验，检验 ICMP 数据包在传输过程中是否出现了差错。
④ ICMP 消息内容：包含 32bit 的可变参数，通常设置为 0，但以下情形例外。
· 在 ICMP Redirect（重定向）消息中，这个字段用来指定网关 IPv4 地址，主机根据这个地址将数据包重定向到指定网关。
当路由器检测到一台设备使用了非最优路由时，它会向该设备发送一个 ICMP 重定向报文，请求该设备改变路由。一般，主机错误地配置了网关才会出现这种情况。
如图 3 - 2 所示，主机 A 想要向服务器发送报文，本来应该走 RTA 的转发路径，但由于管理员错误配置了 RTB 作为网关，所以发给服务器的报文转到了 RTB。此时，如果 RTB 启用了 ICMP 重定向功能，会发现报文应该被转发到与源主机在同一网段的另一个网关设备 RTA，因为此转发路径更优，所以 RTB 会向主机 A 发送一个 Redirect 消息，通知主机 A 直接向另一个网关 RTA 发送该报文。主机收到 Redirect 消息后，会向 RTA 发送报文，然后 RTA 会将该报文再转发给服务器。
在Echo请求消息中，这个字段包含Identifier（标识符）和Sequence Number（序列号），源端根据这两个参数将收到的回复消息与本端发送的Echo请求消息进行关联。尤其是当源端向目的端发送了多个Echo请求消息时，需要根据标识符和序列号将Echo请求和应答消息一一对应。
在下面将要介绍的两种ICMP典型应用------Ping和Tracert程序中，源端都是利用ICMP Echo请求消息（Type字段值为8）来发起网络检测的。目的端或ICMP消息数据包中TTL=0时（进行Tracert应用时）会根据请求消息中的源IPv4地址发送一个ICMP Echo 应答消息（Type 字段值为 0）进行应答。
3.1.2 ICMP 的典型应用
ICMP 仅是一个网络层协议，不是一个可直接发送网络测试数据包的应用层协议，但一些基于 ICMP 开发的应用程序可以调用它，用于网络检测，这就是本节所要介绍的两种典型的 ICMP 应用程序------Ping 和 Tracert。Ping 和 Tracert 程序都是采用 UDP 作为传输层协议的，用于诊断源设备和目的设备之间的网络联通性，同时还可以提供其他信息，如数据包往返时间、所经过节点的 IP 地址等。
- Ping 测试
Ping 是基于 ICMP 的一个典型应用层工具软件，使用的是 ICMP 的回显消息（包括 Echo 请求和 Echo 应答），用于检测网络的联通性，同时也能够收集其他相关信息。用户可以在 Ping 命令中指定不同参数，如 ICMP 数据包长度、发送的 ICMP 数据包个数、等待回复应答的超时时间等，设备根据配置的参数来构造并发送 ICMP Echo 请求数据包，进行 Ping 测试。
不仅网络设备支持 Ping 程序，各操作系统也支持，且可支持的参数非常多。但不同设备上的 Ping 命令参数格式不完全一样，但所有参数均必须在目的 IP 地址参数之前指定，如键入 ping 10.1.1.1 -h 128 不正确，键入 ping -h 128 10.1.1.1 才是正确的。图 3-3 是华为设备上的一些主要 Ping 命令参数及说明。
这里要着重说明的是"-h"参数，它是指定发送 ICMP 请求数据包的初始 TTL 值。在华为设备中默认的 TTL 值是 255，Windows 系统默认的 TTL 值是 128。在执行 Ping 操作时，如果能成功 Ping 通，则 ICMP Echo 应答消息中也会显示一个 TTL 值，但此 TTL 值是指剩余的 TTL 大小，即由初始的 TTL 减去 ICMP 请求数据包从源设备到达目的设备所经过的三层设备数（不包括源设备）。图 3 - 4 中显示的 TTL = 253（假设初始 TTL 为默认的 255），因为从源设备到达目的设备（IPv4 地址为 5.5.5.2）的路径中只经过了两台三层设备，即两跳，所以 TTL = 255 - 2 = 253。
另外，在返回的 ICMP Echo 应答消息中，Byte 字段表示发送的 ICMP 请求消息大小。
华为设备默认为56个字节，这是一个比较小的测试包，要测试大包的通信性能，可以通过Ping命令中的 -s 参数把这个测试包改大，最大可为9600个字节。Sequence字段代表所发送的ICMP请求消息的序列号。time字段为对应ICMP请求数据包从发出到接收应答消息整个过程中所消耗的时间。最下面是发送的测试包总数、成功和丢失的测试包数目，以及以上测试的最小耗时、平均耗时和最大耗时，单位为ms（毫秒）。
图3 - 4是成功Ping操作时的消息显示，当然也可能因各种原因Ping不成功，即通常所说的Ping不通，这时返回的消息就有多种了，如请求超时、目的主机不可达等。此时证明源主机与目的主机网络不通，就要检查网络配置了，特别是路由配置。
- Tracert路径跟踪
Tracert是ICMP的另一个典型应用程序，用于根据IPv4数据包包头部中的TTL值来逐跳跟踪ICMP数据包的转发路径。在华为设备中，Tracert命令的主要参数及说明如图3 - 5所示。同样，所有参数均必须在目的IP地址参数之前指定，如键入"tracert 10.1.1.1 - f2"不正确，键入"tracert - f2 10.1.1.1"才是正确的。
在图3 - 5中的参数中，-f是初始TTL值（默认为1），表示第一次发送ICMP测试包（每一次会同时发送多个ICMP测试包，华为设备默认一次发送3个）时的TTL值为1，即只能从源端传输到下一跳设备，再传会超时，会返回ICMP Echo应答消息，以表明数据包到达了对应跳设备。随后，第二次发送ICMP测试包时，TTL值会增加1，即等于2，第三次发送ICMP测试包时，TTL值再增加1，以此类推。最多发送多少次ICMP测试包，一是要看从源端到达目的端所经过的三层设备跳数，二是要看 - m参数（最大TTL）的设备（华为设备的默认值为30）。当从源端到达目的端所经过的跳数小于默认的最大TTL值时，最多只发送对应跳数次ICMP数据包。
另外，在Tracert命令的参数中还有一个 -p 参数，其用来设置执行Tracert应用操作时所需用到的目的UDP端口号（华为设备中默认为33434），一般是30000以上的UDP端口，因为这样的传输层端口通常不被应用程序所使用。这里需要注意，ICMP是网络层的协议，执行Tracert（包括前面的ping）命令返回的消息是由ICMP自己产生的，但Tracert以及Ping，都基于ICMP的应用层程序，所以这些程序发送的测试数据包还是要经过传输层协议封装的，且都是采用UDP进行封装的。
目的端接收到ICMP测试包后还要继续向上层传输，寻找ICMP测试包中目的UDP端口上运行的应用进程，但事实上接收端并没有运行在该目的UDP端口的应用，所以会返回一个"ICMP端口不可达"消息，但此时跟踪网络路径的目的已达到。
图3 - 6是成功执行Tracert操作的示例。返回的ICMP Echo应答消息中的1、2、3是指ICMP测试包从源端到达目的端所经过的第1、2、3跳设备，后面的IPv4地址即为对应跳设备的IPv4地址，后面有3个时间值，是每一跳每次（华为设备中默认为3次）从发送探测ICMP数据包到收到对应返回应答消息整个过程所经过的时间总和。
如果 Tracert 程序执行不成功，也会返回各种类型的错误消息，如请求超时、目的网络（或主机）不可达，或者因网络性能问题，导致一些路径检测出现了时延，这时可能不会在返回消息中显示对应跳设备 IPv4 地址、传输时间等信息，而是一个个"*"号。
我们通过 Tracert 路径跟踪的结果还可发现从源端到达目的端是否存在路由环路，由此可以有针对性地进行网络优化或网络故障排除。
3.1.3 Tracert 的工作原理
如图 3 - 7 所示，假设主机 A 通过 RTA、RTB 和 RTC 路由器可以到达主机 B，在 RTA 上对主机 B 执行 Tracert 命令操作，下面是具体的流程。
①源端（主机A）向目的端（主机B）发送第一个以UDP协议装的ICMP测试包，TTL值为1。第一跳（RTA）收到源端发出的ICMP测试包后，判断出包中的目的IPv4地址不是本机IPv4地址，于是将TTL值减1希望继续向下游设备传输，但此时包中的TTL值等于0，于是丢弃测试包，并向源端发送一个ICMP超时（Time Out）消息（指的是超出了TTL限制，该消息的源IPv4地址是第一跳（主机A的网关IPv4地址1.1.1.1），这样源端就得到了网关RTA的IPv4地址。
② 源端收到RTA的ICMP超时消息后，再次向目的端发送一个以UDP协议装的ICMP测试包，但此时包中的TTL初始值为2。经过第一跳RTA后包中的TTL=1，再向第二跳RTB传输，到了第二跳RTB时，此时包中的TTL=0，又不能再向下传输了，于是时也向源端发送一个ICMP超时消息，这样源端就得到了RTB的地址（10.0.0.2）。
③ 源端收到RTB的ICMP超时消息后，再次向目的端发送一个以UDP协议装的ICMP测试包，但此时包中的TTL初始值为3。经过第一跳RTA后包中的TTL=2，经过第二跳RTB后包中的TTL=1，继续向第三跳RTC传输，此时包中的TTL=0，又不能再向下传输了，于是RTC也向源端发送一个ICMP超时消息，这样源端就得到了RTC的地址（20.0.0.2）。
④ 源端收到RTC的ICMP超时消息后，再次向目的端发送一个以UDP协议装的ICMP测试包，但此时包中的TTL初始值为4，可以直接到达目的端主机B。主机B在收到源端发送的ICMP测试包后，判断出目的IPv4地址是本机IPv4地址，则处理此测试包。根据包中的目的UDP端口号寻找占用此端口号的上层协议，因目的端没有应用程序使用该UDP端口号（因为Tracer并不是一个C/S模式程序，在目的端没有对应的Tracert服务器程序），则向源端返回一个ICMP端口不可达（Destination Unreachable）消息。
⑤ 源端收到主机B发来的ICMP端口不可达消息后，即可判断出ICMP数据包已经到达目的端，则停止Tracert程序，从而得到数据包从源端主机A到目的端主机B所经历的路径为1.1.1.1→10.0.0.2→20.0.0.2→30.0.0.2。
3.2 ARP
ARP是一个必不可少的网络协议。ARP的主要功能有3个方面：①将IP地址解析为MAC地址，用于数据帧的封装；②维护IP地址与MAC地址的映射关系，生成ARP表项，用于指导IP数据包的转发；③实现网段内重复IP地址的检测，即IP地址冲突检测。
在以上ARP的功能中，最重要的是MAC地址解析功能。这是因为一个IP应用层数据在向下传输过程中，不仅要在网络层通过IPv4协议封装其源/目的的IPv4地址，还必须在数据链路层通过以太网协议封装其源/目的的MAC地址，才能形成最终的数据帧进行单播传输。但通常，我们在进行应用操作（如前面介绍的Ping、Tracert）时只会填上目的IPv4地址，却很少填写目的MAC地址，这时就要用ARP通过已知的目的IPv4地址解析出对应的MAC地址，然后进行帧封装。
3.2.1 ARP数据包格式
ARP与IPv4协议、ICMP一样，也位于体系结构中的网络层，但它位于IPv4协议之下的子层，所以ARP数据包无须经过IPv4协议封装，在源端直接向下面的数据链路层传输，即可形成ARP数据帧，其帧格式如图3 - 8所示。ARP数据帧的总长度为46个字节，其中ARP数据包部分仅28个字节，ARP数据包部分各字段的具体说明如下。
① Hardware Type（硬件类型）：2个字节，标识发送方接口硬件类型，以太网接口对应的十六进制值为0x0001。
② Protocol Type（协议类型）：2个字节，标识要查找的MAC地址所映射的地址对应的协议类型，因为是IPv4地址，所以此处对应IPv4协议，对应的十六进制值为0x0800。
③ Hardware Length（硬件地址长度）：1个字节，标识硬件地址长度，以太网MAC地址长度为6个字节，对应的十六进制值为0x0110。
④ Protocol Length（协议地址长度）：1个字节，标识IPv4地址长度，为4个字节，对应的十六进制值为0x0100。
⑤ Operation Code（操作代码）：2个字节，标识ARP数据包类型，请求包为1（0x0001），应答包为2（0x0002）。
⑥ Source Hardware Address（源硬件地址）：6个字节，标识发送ARP数据包的设备接口硬件地址，以太网为MAC地址，与帧头中的"源硬件地址"字段值一样。
⑦ Source Protocol Address（源协议地址）：4个字节，标识发送ARP数据包的设备接口的协议地址，IPv4网络为IPv4地址。
⑧ Destination Hardware Address（目的硬件地址）：6个字节，标识接收方接口硬件地址，以太网为MAC地址，在ARP Request数据包中，该字段值为0，表示任意地址，因为现在不知道MAC地址（在帧头中的目的硬件地址为全1的广播MAC地址），在应答数据包中为真实的接收方设备接口的MAC地址。
⑨ Destination Protocol Address（目的协议地址）：4个字节，标识接收方的协议地址，IPv4网络为IPv4地址。
图3 - 9是一个ARP请求数据帧示例，从中可以看出，以太网帧头部分的目的MAC地址为全1（f是十六进制是的15，代表四个二进制的1）的广播MAC地址，在ARP请求数据包中的目的MAC地址全为0，表示未知。
3.2.2 ARP 映射表项
ARP 除了可以通过已知的目的 IP 地址查找未知的 MAC 地址外，还有一个重要功能，那就是可以自动生成，或者手动静态配置 ARP 表项，将其保存在缓存中。
在发送或转发 IPv4 数据包前，设备会先检查 ARP 缓存，如果存在目的设备 IPv4 地址对应的 ARP 表项，则直接用该表项中的 MAC 地址进行帧封装，然后从缓存表项对应的出接口发送出去。如果设备在 ARP 缓存中找不到对应目的的 IPv4 地址的表项，则要通过发送 ARP 请求来获取表项。如果目标设备位于其他网络，则源设备会在 ARP 缓存表中查找网关的 MAC 地址，然后将数据发送给网关，最后网关再把数据转发给目的设备。
ARP 表项包括动态 ARP 表项和静态 ARP 表项。在设备的 ARP 表项中，多个不同的 IPv4 地址可以与同一个 MAC 地址对应，因为一个接口或一个网卡可以配置多个 IPv4 地址。
① 静态 ARP 表项：由网络管理员手动建立的 IPv4 地址和 MAC 地址之间固定的映射关系。静态 ARP 表项不会被老化，不会被动态 ARP 表项覆盖。
② 动态 ARP 表项：由 ARP 通过自身的学习功能自动生成和维护，可以被老化，可以被新的 ARP 数据包更新，可以被静态 ARP 表项覆盖。
ARP 的学习功能是，当三层接口接收到 IPv4 地址或者 ARP 数据包时，ARP 会学习包中对应源设备的源 IPv4 地址和源 MAC 地址，以及接收数据包的设备接口（或主机网卡），然后在 ARP 缓存中生成对应的动态 ARP 表项。以后其他设备向这个源设备发送数据包时，可依据这个 ARP 表项中映射的接口指导数据包的转发。
动态 ARP 表项的老化参数有老化超时时间（华为设备上默认为 180s）、老化探测次数和老化探测模式。设备上动态 ARP 表项到达老化超时时间后，设备会发送老化探测数据包（也是一种 ARP 请求数据包，但目的 MAC 地址不为 0），如图 3 - 10 所示。如果能收到 ARP 应答数据包，则更新该动态 ARP 表项，本次老化探测结束；如果超过设置的老化探测次数后仍没有收到 ARP 应答数据包，则删除该动态 ARP 表项，本次老化探测结束。
设备发送的老化探测数据包可以是单播数据包，也可以是广播数据包。在默认情况下，设备仅在最后一次发送的ARP老化探测数据包是广播模式，其余均为单播模式。当对端设备MAC地址不变时，可以配置接口以单播模式发送ARP老化探测数据包。当接口Down时设备会立即删除相应的动态ARP表项。
3.2.3 ARP地址解析原理
ARP的MAC地址解析工作是通过ARP请求数据包和应答数据包的交互来完成的。
下面以图3 - 11中主机A要获取位于同IP网段的主机C的MAC地址为例介绍ARP的MAC地址解析原理。假设主机A的ARP缓存中不存在主机C的MAC地址对应的ARP表项，所以主机A不能直接对要发送给主机C的数据进行帧封装，需要先通过ARP获取主机C的MAC地址。具体流程如下。
①主机A发送ARP请求数据包来获取目的主机C的MAC地址。ARP请求数据包封装在以太网帧中，帧头中的源MAC地址为发送端主机A的MAC地址0000 - 0001 - 0001，目的MAC地址为广播地址FF - FF - FF - FF - FF - FF，表示采用广播方式发送。ARP请求数据包中包含源IPv4地址、目的IPv4地址、源MAC地址、目的MAC地址，其中目的MAC地址的值为0，Operation Code字段被设置为Request，其余分别采用对应的地址，如图3 - 12所示。
ARP请求数据包会在整个网段内传播，该网段内所有主机（包括主机B，也包括网关）都会接收到此数据包。但网关将会阻止该数据包发送到其他网络上。其他设备在收到该ARP请求数据包后，都会检查ARP请求数据包中的目的IPv4地址字段与自身的IPv4地址是否匹配。如果不匹配，则该主机将不会应答该ARP请求数据包；如果匹配，则该主机会将ARP请求数据包中的源MAC地址和源IPv4地址信息记录到自己的ARP缓存表中，生成对应的源主机A的ARP表项，然后通过ARP应答数据包进行应答。
②因为主机C的IPv4地址与ARP请求数据包中的目的IPv4地址一致，所以主机C会接收该数据包，同时会向源主机A回应ARP应答数据包。ARP应答数据包中的源IPv4地址是主机C自己的IPv4地址，目的IPv4地址是主机A的IPv4地址，目的MAC地址是主机A的MAC地址，源MAC地址是主机C的MAC地址，同时Operation Code字段被设置为Reply，如图3 - 13所示。ARP应答数据包通过单播传送，不会发送给主机B。
③ 主机A收到主机C的ARP应答数据包后，会检查此ARP应答数据包中目的MAC地址是否与自己的MAC地址匹配。如果匹配，ARP应答数据包中的源MAC地址和源IPv4地址会被记录到主机A的ARP缓存表中，生成主机C的ARP表项。
随后，就可以利用该表项对发送到目的主机C的数据进行帧封装了，然后发送数据。但这样建立的ARP表项是动态的，是有老化期的，如果在老化期内没有得到更新，又得重新通过ARP来获取目的设备的MAC地址，建立新的动态ARP表项。
ARP只能获取到与源设备在同一IP网段的设备的MAC地址，不能直接得到位于不同IP网段中目的设备的MAC地址，因为ARP位于IPv4协议之下，不能封装IPv4协议，所以其广播数据包只能在数据链路层进行广播封装，不能跨IP网段传输。如果想要获得位于不同IP网段目的设备的MAC地址，则只能通过网关一级级代替源设备查找。此时，源设备上最终获得的是网关的MAC地址（以此作为目的的IPv4地址对应的MAC地址）。
【说明】"网关"是网络与网络之间的连接点，用于数据从一个网络转发到另一个网络。
如果源设备与目的设备不在同一IP网段，则数据首先会被转发到网关，然后再由网关转发到目的设备中。网关通常是从源设备所在IP网段转发到目的设备时所经过的第一跳设备接口，即对应第一跳设备连接本网段的一个网络接口，以一个IPv4地址表示。当然，在一个大型的网络中，网关通常不止一个，每两个互联的网络之间至少有一个网关。
3.2.4 ARP代理
如果源设备与目的设备的IPv4地址在同一IP网段，但却在不同的物理网络上，如图3-14所示，且没有配置默认网关，此时通过ARP也是没办法进行目的主机MAC地址解析的，因为广播传输方式的ARP请求数据包是不能跨网段传输的。这时就需要使用另一个ARP功能，即ARP代理（Proxy ARP）。
如果在图3-14中的AR（Aceess Router，接入路由器）上启用了ARP代理功能，那么连接这两个网络的AR就可以自己应答源设备ARP请求数据包，这个过程称作ARP代理。但ARP代理也可应用不同IP网段的目的主机MAC地址解析，只要不配置默认网关，启用路由器设备的ARP代理功能即可。
ARP代理分为路由式ARP代理、VLAN内ARP代理和VLAN间ARP代理，它们各自的适用场景见表3-2。HCIA只需掌握路由式代理ARP原理即可。
路由式ARP代理就是使那些在同一IP网段却不在同一物理网络上的网络设备能够相互通信的一种功能。下面仍以图3 - 14为例进行介绍，假设主机A的MAC地址为0000 - 0001 - 0001，主机B的MAC地址为0000 - 0002 - 0002，AR的MAC地址为0001 - 0002 - 0003。
①当主机A需要与主机B通信时，由于目的IPv4地址与本机的IPv4地址为同一网段（均在10.0.0.0/8网段），因此主机A以广播形式发送一个ARP请求数据包，并以此获取目的主机B的MAC地址。经过数据链路层封装后的ARP请求数据帧的格式如图3 - 15所示。
由于两台主机连接的是不同物理网络（分别为10.1.0.0/16网段和10.2.0.0/16网段），主机B自然接收不到主机A发送的ARP请求数据包，也不会应答。此时如果在AR上启用路由式ARP代理功能，可解决此问题。
② 启用路由式ARP代理功能后，AR在收到主机A发送的ARP请求数据包后查找本地路由表。由于主机B与AR直连，AR上存有主机B的路由表项，所以认为可以直接进行ARP应答（如果与目的主机不是直连的，则AR也不能直接通过一个ARP请求数据包获取到目的主机的MAC地址）。AR使用自己的G0/0/0接口（是主机A的网关，但其实在主机A上并没有配置该网关，一定要注意）的MAC地址给主机A发送ARP应答数据包，ARP应答数据包中的源IPv4地址仍为目的主机B的IPv4地址，具体帧格式如图3 - 16所示。从中可以看出，在ARP应答数据包中，源IPv4地址是主机B的，但源MAC地址却是G0/0/0接口的MAC地址，这就是通常所说的"善意的欺骗"。
③主机A收到AR发给它的ARP应答数据包时，误以为是目的主机B发来的，于是将以G0/0/0接口的MAC地址、主机B的IPv4地址建立一个主机B的ARP表项。对于要发给主机B的数据，主机A采用G0/0/0接口的MAC地址作为目的MAC地址进行封装并发送。此时，AR相当于主机B的代理。
这里还有一个问题，就是源主机A发给目的主机B的数据到了AR后，又需要重新进行帧封装，AR仍然需要知道目的主机B的MAC地址，这时该怎么办呢？其实这很容易，只需要AR在连接目的主机B所在网段发送一条ARP请求数据包来查找主机B 。的MAC地址就行了，这属于正常的ARP地址解析过程。得到了目的主机B的MAC地址后，AR就可以对来自源主机A发往目的主机B的数据重新进行帧封装，以真正的目的主机B的MAC地址作为目的MAC地址，源MAC地址当然是AR的G0/0/1接口的MAC地址，源IPv4地址和目的IPv4地址不变。
3.2.5 免费ARP工作原理
免费ARP数据包有一个最显著的特点，即ARP数据包中的源IPv4地址和目的IPv4地址相同（通常都是发送设备自己的），用来检测网络中的IPv4地址冲突、更新旧的硬件地址信息、防止IPv4地址欺骗。
当一个设备发送了一个免费ARP数据包时，该数据包的源IPv4地址、目的IPv4地址都是这个设备自身的，源MAC地址也是发送设备的MAC地址，但目的MAC地址为全0，即在本地网段中以广播方式发送。
图3 - 17就是一个免费ARP数据包示例。收到免费ARP数据包的设备会学习其中的源IPv4地址和源MAC地址，对本地的ARP表进行更新，以此防止设备的IPv4地址欺骗。
在DHCP应用中，DHCP客户端被分配了IPv4地址或者IPv4地址发生变更后，必须立刻通过广播方式发送免费ARP数据包来检测其所分配的IPv4地址在网络上是否是唯一的，以避免地址冲突。收到广播的免费ARP数据包的设备会比较自己的IPv4地址与包中的目的IPv4地址，如果一致，则会响应，否则不响应。这样一来，如果发送免费ARP数据包的主机收到了一个对应的ARP应答数据包，则认为有其他设备在使用与自己一样的IPv4地址，于是会向DHCP服务器申请新的IPv4地址。如果没有收到与该ARP数据包响应的ARP数据包，则认为网络中没有其他设备使用与自己一样的IPv4地址，从而可以正式使用该IPv4地址了。
另外，当设备接口的协议状态变为Up时，设备会主动对外发送免费ARP数据包，检测网络中可能存在的IPv4地址冲突。如果检测到IPv4地址冲突，设备会周期性地广播发送免费ARP应答数据包，直到冲突解除。
3.3 TCP
TCP位于体系结构的传输层，是一种面向连接的端到端协议，可以为主机提供可靠的的数据传输。
TCP的标识是TCP端口，每个端口与一个应用进程关联。TCP端口分为知名端口（0～1023）和动态端口（1024～6535）两类。知名TCP端口是被一些主要的应用服务[如Web服务分配了80端口，FTP（File Transfer Protocol，文件传输协议）服务分配了20、21两个端口，Telnet服务分配了23端口等]所独占使用的，而动态TCP端口一般不分配给特定的应用服务使用，只要这些端口当前没有被使用，任何应用层服务都可以使用这些TCP端口。
TCP允许一个主机同时运行多个应用进程，实现多个TCP端口与同一个IPv4地址建立关联，以满足一台主机同时进行多种网络应用。每个IPv4地址可以拥有65536个TCP端口，每个TCP端口、源IPv4地址和目的IPv4地址共同唯一地标识一个应用层会话。
3.3.1 TCP的主要特性
TCP具有许多非常重要的特性，具体如下。
（1）面向连接的传输协议
应用程序在使用TCP之前，必须先建立TCP传输连接，传输数据完毕，可释放已建立的TCP传输连接。
（2）仅支持单播传输
每条TCP传输连接只能有两个端点，只支持单播数据传输，不支持组播和广播传输方式。但每台设备可以同时进行多项基于TCP的应用，因为一个IPv4地址可以有最多65536个TCP端口可以使用。
【说明】这里所说的TCP传输连接的"端点"既不是主机，也不是主机的IPv4地址，也不是应用进程，同样不是传输层协议端口，而是套接字（socket）。套接字是IPv4地址和端口号的组合，中间用冒号或逗号分隔，如（192.168.10.80）。每个TCP传输连接有两个端点，也就是有两个套接字，即"源IPv4地址和端口号"组合和"目的IPv4地址和端口号"组合，可表示为{socket1,socket2}或者{(IP1,Port1),(IP2,Port2)}。
（3）提供可靠的交付服务
因为TCP的应用必须先建立TCP连接，有专门的传输通道，所以通过TCP连接传送的数据理论可以无差错、不丢失、不重复，且按时序到达对端。
（4）传输单元为数据段
TCP以"数据段"作为数据传输单元。数据段大小由应用层传送的报文大小和所途经链路的MTU值大小决定，所以每次发送的TCP数据段大小是不固定的。在一个具体的网络中，有一个MSS（Maximum Segment Size，最大数据段大小），最小的TCP数据段仅有20个字节的TCP头部，无数据部分，如建立TCP连接的SYN数据段，用于对所接收的数据段进行确认的ACK数据段等。
（5）支持全双工传输
TCP 允许通信双方的应用程序在任何时候都能发送数据，因为 TCP 连接的两端都设有发送/接收缓存，用来临时存放双向通信的数据。当然 TCP 可以立即发送一个数据段，也可以缓存一段时间，以便再一次性发送更多的数据段。
（6）TCP 连接是基于字节流的，而非报文流TCP是在不保留数据段边界的情况下，以字节流方式进行传输，而不是报文流。
3.3.2 TCP数据段格式
TCP通常使用IPv4协议作为网络层协议，所以TCP数据段在向网络层传输时要封装IPv4协议头部，其基本格式和所包括的字段如图3 - 18所示，各字段说明如下。
① Source Port（源端口）和 Destination Port（目的端口）：分别代表源端和目的端的 TCP 端口号，各占 2 个字节（16bit），用于标识一个具体的应用。每个 TCP 数据段同时包括源端口和目的端口，与 IPv4 协议头部的源 IPv4 地址和目的 IPv4 地址可以唯一确定一个 TCP 连接。
【说明】在 TCP 应用中的服务通常都是 C/S（客户端/服务器）工作模式的，在建立 TCP 连接时，源端（客户端）通常使用的是随机的 1024 以后的非知名端口作为源端口，目的端（服务器）一般是使用由对应服务器指定的端口作为目的端口。知名服务一般默认使用对应的知名 TCP 端口，如 Web 服务器默认使用的是 TCP 80 端口，Telnet 服务器默认使用的是 TCP 23 端口等。
② Sequence Number（序列号）：用于标识从源端发出的 TCP 数据段的序列号，占 4 个字节（32bit）。初始序列号是随机的，可能是 0～4294967295 的任意值。但 TCP 数据段的序列号不是以 1 为增量连续的，因为事实上要对数据段中的 Data 字段的每一个字节进行编号，序列号是指 Data 字段的第一个字节的编号。如一个 TCP 数据段的序列号是 10，而所传输的数据段中的 Data 字段有 22 个字节，则 Data 字段 22 个字节的编号为 10～31，自然下一个数据段的序列号就是 32，可以直接用序列号加上 Data 字段的字节数相加得出，即 10+22=32。
TCP 数据段在传输时，各数据段到达目的端的先后顺序可能发生变化，目的端就可以依据此序列号正确重组数据。
③ Acknowledgement Number（确认号）：4 个字节（32 位），指示本端期望接收对端下一个数据段的序列号，不是代表已经正确接收到的最后一个字节的序列号，是已成功接收的连续数据段中的最大数据段，最后一个数据字节的序号加1。
④ Header Length（头部长度，也称"数据偏移"）：4bit，以4个字节为单位表示TCP头部的长度，用于确定TCP数据段头部的长度，以便在目的端把数据向应用层传输时能准确地去掉TCP头部，仅保留Data字段部分。4个比特所能表示的最大值为15，每个单位为4个字节，即15×4=60，故头部长度最大为60个字节，如果没有Options字段则此字段值为5，20个字节。
⑤ URG（Urgent Pointer Valid，紧急指针有效）：控制位，指示当前数据段中是否有紧急数据，占1bit，置1时表示有紧急数据。紧急数据会放在Data部分最前面。
⑥ ACK（Acknowledgement，确认）：控制位，指示TCP数据段中Acknowledgement Number字段是否有效，占1bit，置1时表示有效。ACK数据段中没有Data部分。
⑦ PSH（Push，推）：控制位，指示接收端是否需要立即把收到的数据段提交给应用进程，占1bit，置1时需要立即向上层提交，不管前面是否还有其他TCP数据段未成功接收，置0时可以先缓存起来，等待前面所有数据段都成功接收后再一起向上层提交。
⑧ RST（Reset，重置）：控制位，用于重置、释放一个已经混乱的传输连接，然后重建新的传输连接，占1bit，置1时释放当前传输连接，然后重新建立新的传输连接，默认置0。RST数据段没有Data部分。
⑨ SYN（Synchronization，同步）：控制位，用来建立TCP连接，占1bit。当SYN=1、ACK=0时为连接建立请求数据段，如果对方同意建立连接，则对方会返回一个SYN=1、ACK=1的连接建立请求和确认数据段。SYN数据段中没有Data部分。
⑩ FIN（Final，最后）：控制位，用于请求释放一个传输连接，占1bit。置1时，表示数据已全部传输完成，发送端没有数据要传输了，请求释放当前连接，但是接收端仍然可继续接收数据。FIN数据段中没有Data部分。
⑪ Window（窗口大小）：2个字节，指示发送此TCP数据段的主机当前可用于存储传入数据段（仅包括数据段的Data部分，去掉了TCP头部，准备要向应用层上传）的字节大小，即发送方当前还可以接收的最大字节数，是对方设置其"发送窗口"大小的依据，用来进行流量控制。由于该字段是16位，所以最大值为65535，即最大的窗口大小为64kB。
⑫ Checksum（校验和）：2个字节，校验整个TCP报文，包括TCP头部和TCP数据，同时在TCP数据段的前面加上12个字节的伪头部。该值由发送端计算和记录并由接收端进行验证。
【说明】TCP伪头部格式如图3 - 19所示，包括了一些网络层和传输层信息（UDP也有这样类似的伪头部，UDP的PID为17，对应十六进制的0x11）。
增加伪头部参加校验和计算，主要是为了多一些检测的参数，可以更准确地反映数据的更改。但伪头部只参与校验和计算，不与TCP数据段一起传输给对方。通过校验和字段进行数据完整性校验的方法如下。
• 将伪头部和TCP数据段（其中"校验和"字段值置0）以16bit为单位从最低位向高位做加法运算。如果尾部数据不足16bit则填充至16bit。
• 计算校验和，把校验的值填充在"校验和"字段。
• 到了接收端后，根据TCP数据段中的真实数据再生成一个TCP伪头部，然后再以相同方法计算校验和（计算时"校验和"字段也置0）。如果计算出来的结果与"校验和"字段值匹配的话，则认为数据段是正确的，将接收，否则表明发生了某种类型的错误，数据段将会被丢弃。
13 Urgent Pointer（紧急指针）：2 个字节，仅当前面的 URG 控制位置 1 时有意 义，指示本数据段中紧急数据中的最后一个字节的序列号，占 16bit。即使当前窗口大小为 0，也是可以发送紧急数据的，因为紧急数据无须缓存。
14 Options（选项）|Padding（填充）：这两个字段可选，可有一个或多个可选项， 最长可达 40 个字节。当没有使用该字段时，TCP 头部的长度为 20 个字节。填充字段仅 当 TCP 头部（包括可选项）的长度不是 4 个字节的整数倍时填充 0，使其达到 4 个字节 的整数倍，但填充后的 TCP 头部最长不得超过 60 个字节。
15 Data（数据）：TCP 数据段中的数据部分是可选的，且长度可变，整个 TCP 数 据段的大小受网络层 IPv4 数据包 64kB（65536 个字节）大小的限制。这样一来，最大 的 TCP 数据段大小为 65536 - 20（此 20 字节为 IPv4 数据包头部大小）=65516 个字节， 超过要进行分段。
【说明】Data 字段也是可选的，通过 SYN 数据段建立 TCP 连接，以及通过 FIN 数 据段终止一个连接时，仅有 TCP 头部，没有 Data 字段。如果一方没有数据要发送，也 可使用没有任何数据的 TCP 头部来确认收到的数据。在处理超时的许多情况中，也会发 送不带任何数据的数据段。
3.3.3 TCP 连接的建立与释放
基于 TCP 的网络应用必须事先在源端和目的端之间建立 TCP 连接，然后在数据传 输完又需要释放原来所建立的 TCP 连接，以节省网络资源，释放所占用的 TCP 端口。
- TCP 连接的建立
TCP 连接的建立是一个 3 次握手的过程，即 3 次数据段的交互过程，如图 3 - 20 所示。 在这 3 次握手过程中，两端彼此交互的数据段均没有 Data 字段部分，每一次交互完成后， 两端的 TCP 连接建立状态会发生一次变化。TCP 连接建立好后，即建立好了端到端的传 输通道，两端就可以正式相互发送数据了。
① 主机 A（通常也称为客户端）发送一个 SYN 控制位置 1 的 TCP 数据段（源端口 通常是大于 1024 的随机 TCP 端口，目的端口是服务器上指定或默认的 TCP 端口），表 示期望与服务器 B 建立连接，此数据段的初始序列号（Seq）为 x（随机），Acknowledgement Number（确认号，简称 ACK）为 0（因为此时还没有收到对方任何 TCP 数据段），进入 SYN_SENT 状态。
② 服务器B回复SYN和ACK控制位均置1的TCP数据段，此数据段的序列号为y（随机），确认号为客户端发送的SYN数据段序列号加1（即x+1），以此作为对客户端的SYN报文的确认，进入SYN_RCVD状态。
③ 主机A发送一个ACK控制位置1的数据段，序列号为x+1，确认号为服务器B发送的SYN+ACK数据段序列号加1（即y+1），以此作为对服务器的SYN+ACK数据段的确认，进入ESTABLISHED状态。当服务器B收到客户端的ACK数据段后进入ESTABLISHED状态。
【经验之谈】为什么客户端在最后还要发送一次ACK确认数据段呢？这主要是为了防止已失效的连接请求数据段延误到了服务器端后，产生错误连接。
假设客户端发送了连接请求，但因连接请求数据段丢失而未收到来自服务器的确认，于是客户端又重发一次连接请求，这次TCP连接成功建立。数据传输完毕后释放了连接。如果客户端最初发出的第一个请求数据段并未丢失，而是在某个网络节点长时间滞留了，以致延误到后面TCP连接释放后的某个时间才到达服务器端（这是一个早已失效的数据段），则服务器收到此失效的连接请求报文后就可能误以为客户端又发了一次新的连接请求，于是向客户端发出SYN+ACK数据段，同意建立连接。
如果不采用3次握手，那么只要服务器端发出了ACK确认数据段，新的TCP连接就建立了。但客户端事实上并没有发出建立连接的新请求，因此不会理睬服务器端的确认数据段，也不会向服务器发送数据。但服务器端却以为新的传输连接已经建立了，并一直等待客户端发送数据，因此白浪费了许多资源。如果采用TCP 3次握手的方法就可以防止上述现象发生，因为每次TCP连接的建立都需要客户端进行最后的确认，客户端不进行确认，TCP连接就建立不起来。例如在前面的情况，由于客户端不会对服务器发来的SYN+ACK数据段进行确认，因此TCP连接就不会建立。
如果数据段在TCP第三次握手中丢失了，但客户端仍认为这个连接已经建立，就会向服务器写入数据，服务器将以RST数据段响应，重置连接。
TCP连接建立好后，接下来客户端和服务器端之间就可以互传数据了。但TCP连接建立后，客户端和服务器均以建立连接时的初始序列号+1的序列号开始发送数据。如图3-20中的示例，主机A发送数据时所用的第一个序列号是x+1，服务器B发送数据时的第一个序列号是y+1。 - TCP连接释放原理
在传输数据之前，TCP通过3次握手建立的实际上是双向的连接，因此在传输完毕后，两个方向的连接必须都释放。也正因如此，TCP连接的建立是一个3次握手的过程，而TCP连接的释放则要经过4次挥手过程，具体如图3-21所示。在TCP连接释放过程中所交互的TCP数据段也是没有Data字段的。
① 主机A（客户端）想要终止连接，于是发送一个FIN控制位置1的TCP数据段，序列号为x（该序列号等于主机A前面已经传输完成的最后一个数据段的序列号），进入FIN_WAIT - 1状态。
② 服务器B回应一个ACK控制位置1的TCP数据段，序列号为m（该序列号等于服务器B前面已经传输完成的最后一个数据段的序列号加上Data字段长度），确认序列号为x + 1，作为对主机A的FIN数据段的确认，进入CLOSE_WAIT状态。
此时服务器通知上层的应用进程，释放客户端到服务器方向的连接，TCP处于半关闭状态，即客户端已经没有数据要发了，但服务器若发送数据，客户端仍要接收，所以这个状态可能会持续一段时间。
③ 主机A收到服务器B的ACK确认数据段后，就进入了FIN_WAIT状态，等待服务器发出连接释放数据段。如果服务器已经没有要向客户端发送的数据了，其应用进程就通知TCP释放连接。这时服务器B向主机A发送释放TCP连接的FIN数据段，FIN控制位置1，确认号仍为x + 1，序列号为n（n与前面的m可能相等，也可能不相等，具体在下面说明）。这时服务器进入LAST_ACK状态，等待客户端的确认。
【说明】如果在收到主机A发来的请求释放连接的TCP数据段时，服务器B也没有数据要继续向主机A发送了，也想立即释放TCP连接，则服务器B在发送FIN、ACK置位的TCP数据段时的序列号n就与前面发送ACK数据段的序列号m是一样的。反之，如果服务器B还有数据要向主机A发送，处于半关闭状态的服务器B可能后面又发送了一些数据，此时再发送FIN、ACK置位的TCP数据段时的序列号就与前面的ACK数据段的序列号m不一样了，应为半关闭状态发送的最后一个TCP数据段的序列号加1。
④ 主机A回应一个ACK控制位置1的TCP数据段，序列号为x + 1，确认序列号为n + 1，作为对服务器B的FIN数据段的确认，进入TIME_WAIT（超时等待）状态。
这时，TCP连接还没有释放掉，必须等待计时器设置的时间2MSL（Maximum Segment Lifetime，最大分段寿命）后才进入CLOSED状态。只有当双方都进入CLOSED状态后，TCP连接才会被成功释放。
3.3.4 TCP的确认机制
为了确保数据的可靠传输，TCP中采用了确认机制，起作用的是TCP头部中的Acknowledgement Number（确认号）字段和Acknowledgement（确认）这两个字段。
Acknowledgement Number字段用于指定期望接收对端的下一个数据段的起始序列号数据。同时也暗示了在此序列号前的所有字节数据均已被正确接收；Acknowledgement字段用于指示数据段中的Acknowledgement Number字段是否有效，置1时有效。
TCP数据段的序列号不是以1为单位连续增加的，而是对应数据段中Data字段中第一个字节的编号。而TCP数据段序列号是从0开始编号的，所以下一个数据段的序列号就等于上一个数据段的序列号 + Data字段字节数。如果当前一数据段的序列号为10，其Data字段长度为500个字节，则下一个数据段的序列号就是10 + 500 = 510。
目的端接收到源端发送的数据段后，会向源端发送一个ACK控制位置1的确认数据段（无数据部分），用于表明本端已接收到了哪些序列号的数据。源端收到确认数据段后，可以继续发送数据。TCP通常不会针对单个数据段进行确认，而是一次性对多个连续数据段进行确认，只需要对最近正确收到的连续数据段进行确认，即代表前面所有数据段均已正确接收。源端收到ACK数据段，发现自己已发的一些序列号数据段没有得到目的端确认，认为这些数据段在传输途中丢失了，于是从缓存中调用这些数据段进行重传。
如图3 - 22所示，假设主机A向服务器B发送的第N个数据段的序列号为M，每个数据段中Data部分的长度均为500个字节，即每个数据段的序列号在其前一个数据段的序列号基础上要加500。如第N + 1个数据段的序列号为M + 500，第N + 2个数据段的序列号为M + 1000，第N + 3个数据段的序列号为M + 1500，第N + 4个数据段的序列号为M + 2000......
【说明】如果服务器 B 只向主机 A 返回 ACK 确认应答，没有数据发送，则主机 A 所发送的数据段中的 ACK 字段值总是不变的，等于 TCP 连接建立成功后服务器 B 发送的最后一个 TCP 数据段中的序列号。
假设服务器B在成功接收到第N+2及以前所有数据段后进行确认，发送的确认数据段中的确认号即为下一个数据段的序列号。第N+2个数据段的序列号为M+1000，下一个数据段的序列号是在前一个数据段序列号基础上加500，所以确认数据段中的确认号为M+1500。
又假设后面的第N+3个数据段没有发送成功，但后面的第N+4、N+5个数据段发送成功了，服务器B也成功接收了。此时因为前面的第N+3个数据段没有发送成功，所以服务器B发送的确认数据段中的确认号仍是M+1500。这样一来，主机A在收到服务器B发来的确认数据段后便知前面3个数据段已成功接收，于是从缓存中清除这3个数据段，以腾出空间存放新发送的数据段。同时获知，第N+3个数据段及以后的数据没有被确认，出现了传输错误，于是主机A决定对第N+3以及之后已发送的所有数据段进行重发，即对第N+3、N+4、N+5这3个数据段全部重发。
其实，TCP还有一种选择性确认（Selective ACK，SACK）机制，即仅可以重传缺少部分的数据，而不用重传那些已正确接收的数据，以提高重传效率。
另外，TCP中的重传定时器（Retransmission Timer，RTT）规定在发送一个数据段的同时启动该定时器。如果在定时器过期之前，该数据段还没有被对方确认的话，则定时器被停止，然后从缓存中调用对应序列号的数据段进行重传。
3.3.5 TCP的流量控制机制
在数据传输中可能会出现这种情形，那就是发送端一次发送的数据太大，接收端来不及处理，同时可用的缓存（缓存中仅保存TCP数据段中的Data字段部分的内容，去掉TCP头部）又放不下，这时这些数据只能在接收端被丢弃了。这样就大大影响数据传输的可靠性和传输效率。
TCP头部格式中有一个Window（窗口）字段，专门提供流量控制功能，即窗口滑动机制。通过这种机制，本端告诉对方自己当前可以接收的数据量，也暗示着对端下次可一次性发送的最大数据（仅指Data字段部分）大小，以字节为单位。接收方根据自身的缓存空间大小确定当前可以接收的数据大小（Window），发送方根据接收方当前的Window大小发送相应大小的数据。当发送方收到接收方发来的一个Window字段值为0的数据段，表示接收方此时不能再接收数据了，发送方会暂停向对端发送数据，直到接收方发来Window字段值不为0的数据段。
图3-23是一个简单的TCP窗口滑动示例，实际的TCP滑动窗口技术比较复杂，HCIA层次不做要求。
① 主机 A 一开始连续发送 4 个长度为 1024 个字节的 TCP 数据段（数据段 1～4）给服务器 B，其中设置的 Window 字段值为 4096，表示本端可以接收 4096 个字节的数据。但服务器 B 上当前缓存大小只有 3072 个字节，也就是只能接收主机 A 发送的前 3 个数据段，第 4 个数据段接收不了，被丢弃了。
② 服务器 B 向主机 A 返回一个 ACK 数据段（无数据部分），Acknowledgement Number 为 3073（假设第一个数据段的序列号为 1），因为已连续接收到 3 个 1024 长度的数据段，即共接收了 3072 个字节的数据，所以下一个可接收的数据的编号就是 3073 了。此时把 Window 字段设为 3072，表示服务器 B 最多只能接收 3072 个字节的数据。
【说明】如果服务器B只是向主机A返回ACK确认数据段，则主机A发送的数据段中Window字段值总是不变的，因为本端没有接收到服务器B发来的数据，没有消耗缓存空间。
③主机A收到服务器B发来的确认数据段后便获知原来发送的第4个数据段服务器B没有成功接收，同时获知服务器B当前只能接收3072个字节的数据，确定以后每次只连续发送3个1024个字节的数据段便停止发送，等待服务器B的确认。于是主机A先发送上次没有被成功接收的第4个数据段，然后再发送2个新的数据段，即发送第4、第5、第6 3个数据段后又等待服务器B的确认。但因为主机A没有收到服务器B发来的数据（收到的ACK数据段中没有数据），所以它的窗口大小值没有改变，仍为4096。
④服务器B在收到主机A连续发送的第4、第5、第6数据段后发送一个确认数据段，此时Acknowledgement Number为6145（1024×6+1），如果服务器B收到的数据已上传，则它发送的ACK数据段中的Window字段仍为3072。
⑤主机A收到服务器B的确认数据段后再次连续发送3个1024个字节的数据段，然后再等待服务器B的确认，如此循环。
3.4 UDP
UDP是体系结构传输层中的另一个主要的协议，适用于对传输可靠性要求不高但对传输速度和时延要求较高的场景。UDP与TCP不同，UDP将数据从源端发送到目的端时，无须事先建立连接，即UDP不是面向连接的协议。
UDP采用了简单、易操作的机制在应用程序间传输数据，无TCP中的确认、重传和滑动窗口机制，因此UDP不能保证数据传输的可靠性，但它的传输效率高。对于时延敏感的应用，丢失部分数据影响并不大，就像我们看视频，中间丢掉几帧并没什么影响，甚至看不出来，但由于事先无须建立专门的连接，传输效率较高，因此用户体验更好。
视频通信中通常采用UDP。
UDP具有无连接、不可靠、以报文为边界、无流量、无拥塞控制功能等特性，但它支持各种传输方式，如单播、组播和广播方式，而TCP仅支持单播传输方式，这是它的重要优点。所以涉及广播、组播的应用层数据传输时，就只能用UDP了。
UDP数据段向下传输时也在网络层经过IPv4协议的封装，UDP数据段自身分为UDP数据段头部和数据两部分，其中UDP数据段头部仅为8个字节，具体如图3 - 24所示。相比TCP，UDP的传输效率更高，开销更小，但它无法保障数据传输的可靠性，所以更适合实时数据传输，如语音和视频通信。UDP各字段的说明如下。
① Source Port（源端口）：2个字节，标识源端的应用程序使用的UDP端口号。
② Destination Port（目的端口）：2个字节，标识目的端的应用程序使用的UDP端口号。
③ Length（长度）：4个字节，标识UDP头部和Data字段的总长度，以字节为单位。因为Data字段是可选的，所以最小的UDP数据段仅为UDP头部，长度仅为8个字节。
④ Checksum（校验和）：2个字节，用于对UDP头部和Data部分进行校验，是可选的字段。但在计算校验和时也要加上UDP伪头部，只是其中的PID为UDP的协议ID（对应的十进制值为17，十六进制值为0x11），后面是UDP数据段长度。
⑤ Data（数据）：UDP 数据段数据部分，长度可变，但整个 UDP 数据段大小也是受到网络层 IPv4 数据包最大 64kB 的限制，超过也需经过分段处理，但这个分段功能是由网络层 IPv4 协议的分片功能完成的，UDP 没有分段功能。
【说明】因为每个 UDP 数据段独立地在网络中被发送，所以不同的 UDP 数据段会通过不同的网络路径到达，先发送的数据段不一定先到达。又因为 UDP 数据包没有序列号，目的主机将无法通过 UDP 将数据段按照原来的顺序重新组合，所以此时需要应用程序提供数据段的到达确认、排序和流量控制等功能。通常情况下，UDP 采用实时传输机制和时间戳来保障语音和视频数据传输的可靠性。