TCP/IP详解（三）

7.3 IP记录路由选项
ping程序为我们提供了查看IP记录路由（RR）选项的机会。大多数不同版本的ping程序都提供-R参数，以提供记录路由的功能。它使得ping程序在发送出去的IP数据报中设置IP RR选项（该IP数据报包含ICMP回显请求报文）。这样，每个处理该数据报的路由器都把它的IP地址放入选项字段中。当数据报到达目的端时，IP地址清单应该复制到ICMP回显回答中，这样返回途中所经过的路由器地址也被加入清单中。当ping程序收到回显回答时，它就打印出这份IP地址清单。
这个过程听起来简单，但存在一些缺陷。源端主机生成RR选项，中间路由器对RR选项的处理，以及把ICMP回显请求中的RR清单复制到ICMP回显回答中，所有这些都是选项功能。幸运的是，现在的大多数系统都支持这些选项功能，只是有一些系统不把ICMP请求中的IP清单复制到ICMP回答中。
但是，最大的问题是IP首部中只有有限的空间来存放IP地址。我们从图3.1可以看到，IP首部中的首部长度字段只有4 bit，因此整个IP首部最长只能包括15个32 bit长的字（即60个字节）。由于IP首部固定长度为20字节，RR选项用去3个字节（下面我们再讨论），这样只剩下37个字节（60 - 20 - 3）来存放IP地址清单，也就是说只能存放9个IP地址。对于早期的ARPANET来说，9个IP地址似乎是很多了，但是现在看来是非常有限的。（在第8章中，我们将用Traceroute工具来确定数据报的路由。）除了这些缺点，记录路由选项工作得很好，为详细查看如何处理IP选项提供了一个机会。
IP数据报中的RR选项的一般格式如图7.3所示。

图7.3 IP首部中的记录路由选项的一般格式

code是一个字节，指明IP选项的类型。对于RR选项来说，它的值为7。len是RR选项总字节长度，在这种情况下为39。（尽管可以为RR选项设置比最大长度小的长度，但是ping程序总是提供39字节的选项字段，最多可以记录9个IP地址。由于IP首部中留给选项的空间有限，它一般情况都设置成最大长度。）
ptr称作指针字段。它是一个基于1的指针，指向存放下一个IP地址的位置。它的最小值为4，指向存放第一个IP地址的位置。随着每个IP地址存入清单，ptr的值分别为8，12，16，最大到36。当记录下9个IP地址后，ptr的值为40，表示清单已满。
当路由器（根据定义应该是多穴的）在清单中记录IP地址时，它应该记录哪个地址呢？是入口地址还是出口地址？为此，RFC 791 [Postel 1981a]指定路由器记录出口IP地址。我们在后面将看到，当原始主机（运行ping程序的主机）收到带有RR选项的ICMP回显回答时，它也要把它的入口IP地址放入清单中。

正常的例子
我们举一个用RR选项运行ping程序的例子。我们在主机svr4上运行ping程序到主机slip。一个中间路由器(bsdi)将处理这个数据报。下面是svr4的输出结果：

（见原书p.92的①）

分组所经过的四站如图7.4所示（每个方向各有两站），每一站都把自己的IP地址加入RR清单。

图7.4 带有记录路由选项的ping程序

路由器bsdi在不同方向上分别加入了不同的IP地址。它始终是把出口的IP地址加入清单。我们还可以看到，当ICMP回显回答到达原始系统（svr4）时，它把自己的入口IP地址也加入清单中。
我们还可以通过运行带有-v参数的tcpdump命令来查看主机sun上进行的分组交换（参见IP选项）。输出如图7.5所示。

图7.5 记录路由选项的tcpdump输出

输出中optlen=40表示在IP首部中有40个字节的选项空间。（IP首部长度必须为4字节的整数倍。）RR{39}的意思是记录路由选项已被设置，它的长度字段是39。然后是9个IP地址，符号“#”用来标记RR选项中的ptr字段所指向的IP地址。由于我们是在主机sun上观察这些分组（参见图7.4），因此我们所能看到ICMP回显请求中的IP地址清单是空的，而ICMP回显回答中有3个IP地址。我们省略了tcpdump输出中的其它行，因为它们与图7.5基本一致。
位于路由信息末尾的标记EOL表示IP选项“end of list”（清单结束）的值。EOL选项的值可以为0。这时表示39个字节的RR数据位于IP首部中的40字节空间中。由于在数据报发送之前空间选项被设置为0，因此跟在39个字节的RR数据之后的0字符就被解释为EOL。这正是我们所希望的结果。如果在IP首部中的选项字段中有多个选项，在开始下个选项之前必须填入空白字符，另外还可以用另一个值为1的特殊字符NOP（“no operation”）。

（下面是原书p.93①的译文）
在图7.5中，SVR4把回显请求中的TTL字段设为32，BSD/386设为255。（它打印出的值为254是因为路由器bsdi已经将其减去1。）新的系统都把ICMP报文中的TTL设为最大值（255）。
在作者使用的三个TCP/IP系统中，BSD/386和SVR4都支持记录路由选项。这就是说，当转发数据报时，它们都能正确地更新RR清单，而且能正确地把接收到的ICMP回显请求中的RR清单复制到出口ICMP回显回答中。虽然SunOS 4.1.3在转发一个数据报时能正确更新RR清单，但是不能复制RR清单。Solaris 2.x对这个问题已作了修改。

异常的输出
下面的例子是作者观察到的，我们把它作为第9章讨论ICMP间接报文的起点。我们在子网140.252.1子网上ping主机aix（在主机sun上通过拔号SLIP连接可以访问），并带有记录路由选项。在slip主机上运行有如下输出结果：

（见原书p.94的①）

我们已经在主机bsdi上运行过这个例子。现在我们选择slip来运行它，观察RR清单中所有的9个IP地址。
在输出中令人感到疑惑的是，为什么传出的数据报（ICMP回显请求）直接从netb传到aix，而返回的数据报（ICMP回显回答）却从aix开始经路由器gateway再到netb？这里看到的正是下面我们将要描述的IP路由选择的一个特点。数据报经过的路由如图7.6所示。

图7.6 运行带有记录路由选项的ping程序，显示IP路由选择的特点

问题是aix不知道要把目的地为子网140.252.13的IP数据报发到主机netb上。相反，aix在它的路由表中有一个默认项，它指明当没有明确某个目的主机的路由时，就把所有的数据报发往默认项指定的路由器gateway。路由器gateway比子网140.252.1上的任何主机都具备更强的路由选择能力。（在这个以太网上有超过150台主机，每台主机的路由表中都有一个默认项指向路由器gateway，这样就不用在每台主机上都运行一个路由选择守护程序。）
这里没有回答的一个问题是为什么gateway不直接发送ICMP报文改变路由到aix（9.5节），以更新它的路由表？由于某种原因（很可能是由于数据报产生的改变路由是一份ICMP回显请求报文），改变路由并没有产生。但是如果我们用Telnet登录到aix上的daytime服务器，ICMP就会产生改变路由，因而它在aix上的路由表也随之更新。如果我们接着执行ping程序并带有记录路由选项，其路由显示表明数据报从netb到aix，然后返回netb，而不再经过路由器gateway。在9.5节中我们将更详细地讨论ICMP改变路由的问题。

7.4 IP时间戳选项
IP时间戳选项与记录路由选项类似。IP时间戳选项的格式如图7.7所示（请与图7.3进行比较）。

图7.7 IP首部中时间戳选项的一般格式

时间戳选项的代码为0x44。其它两个字段len和ptr与记录路由选项相同：选项的总长度（一般为36或40）和指向下一可用空间的指针（5，9，13，等）。
接下来的两个字段是4 bit的值：OF表示溢出字段，FL表示标志字段。时间戳选项的操作根据标志字段来进行，如图7.8所示。

（下面是图7.8的译文）
标志
描述
0
只记录时间戳，正如我们在图7.7看到的那样。
1
每台路由器都记录它的IP地址和时间戳。在选项列表中只有存放四对地址和时间戳的空间。
3
发送端对选项列表进行初始化，存放了4个IP地址和四个取值为0的时间戳值。只有当列表中的下一个IP地址与当前路由器地址相匹配时，才记录它的时间戳。
图7.8 时间戳选项不同标志字段值的意义

如果路由器由于没有空间而不能增加时间戳选项，那么它将增加溢出字段的值。
时间戳的取值一般为自午夜开始计的毫秒数，UTC，与ICMP时间戳请求和回答相类似。如果路由器不使用这种格式，它就可以插入任何它使用的时间表示格式，但是必须打开时间戳中的高位以表明为非标准值。
与我们遇到的记录路由选项所受到的限制相比，时间戳选项遇到情况要更坏一些。如果我们要同时记录IP地址和时间戳（标志位为1），那么就可以同时存入其中的四对值。只记录时间戳是没有用处的，因为我们没有标明时间戳与路由器之间的对应关系（除非我们有一个永远不变的拓扑结构）。标志值取3会更好一些，因为我们可以插入时间戳的路由器。一个更为基本的问题是，你很可能无法控制任何给定路由器上时间戳的正确性。这使得试图用IP选项来计算路由器之间的跳站数是徒劳的。我们将看到（第8章）traceroute程序可以提供一种更好的方法来计算路由器之间的跳数。

7.5 小结
ping程序是对两个TCP/IP系统连通性进行测试的基本工具。它只利用ICMP回显请求和回显回答报文，而不用经过传输层（TCP/UDP）。Ping服务器一般在内核中实现ICMP的功能。
我们分析了在LAN，WAN以及SLIP链路（拔号和线路）上运行ping程序的输出结果，并对串行线路上的SLIP链路吞吐量进行了计算。我们还讨论并使用了ping程序的IP记录路由选项。利用该IP选项，我们可以看到它是如何经常使用默认路由的。在第9章我们将再次回到这个讨论主题。另外，我们还讨论了IP 时间戳选项，但它在实际使用时有所限制。

习题
7.1 请画出7.2节中ping输出的时间线。
7.2 若把bsdi和slip主机之间的SLIP链路设置为9600 b/s，请计算这时的RTT。假定默认的数据是56字节。
7.3 当前BSD版中的ping程序允许我们为ICMP报文的数据部分指定一种模式。（数据部分的前8个字节不用来存放模式，因为它要存放发送报文的时间。）如果我们指定的模式为0xc0，请重新计算上一题中的答案。（提示：阅读2.4节。）
7.4 使用压缩SLIP（CSLIP，见2.5节）是否会影响我们在7.2节中看到的ping输出中的时间值？
7.5 在图2.4中，ping环回地址与ping主机以太网地址会出现什么不同？



7－7
8 Traceroute程序

8.1 引言
由Van Jacobson编写的Traceroute程序是一个能更深入探索TCP/IP协议的方便可用的工具。尽管不能保证从源端发往目的端的两份连续的IP数据报具有相同的路由，但是大多数情况下是这样的。Traceroute程序可以让我们看到IP数据报从一台主机传到另一台主机所经过的路由。Traceroute程序还可以让我们使用IP源路由选项。

（下面是原书p.97①的译文）
使用手册上说：“程序由Steve Deering提议，由Van Jacobson实现，并由许多其他人根据C. Philip Wood, Tim Seaver 及Ken Adelman等人提出的令人信服的建议或补充意见进行调试。”

8.2 Traceroute程序的操作
在7.3节中，我们描述了IP记录路由选项（RR）。为什么不使用这个选项而另外开发一个新的应用程序？有三个方面的原因。首先，原先并不是所有的路由器都支持记录路由选项，因此该选项在某些路径上不能使用。（Traceroute程序不需要中间路由器具备任何特殊的或可选的功能。）
其次，记录路由一般是单向的选项。发送端设置了该选项，那么接收端不得不从收到的IP首部中提取出所有的信息然后全部返回给发送端。在7.3节中，我们看到大多数Ping服务器的实现（内核中的ICMP回显回答功能）把接收到的RR清单返回，但是这样使得记录下来的IP地址翻了一番（一来一回），这样会受到一些限制，这一点我们在下一段讨论。（Traceroute程序只需要目的端运行一个UDP模块----其他不需要任何特殊的服务器应用程序。）
最后一个原因也是最主要的原因是，IP首部中留给选项的空间有限，不能存放当前大多数的路径。在IP首部选项字段中最多只能存放9个IP地址。在原先的ARPANET中这是足够的，但是对现在来说是远远不够的。
Traceroute程序使用ICMP报文和IP首部中的TTL字段。TTL字段（生存周期）是由发送端初始设置一个8 bit字段。推荐的初始值由分配数字RFC指定，当前值为64。较老版本的系统经常初始化为15或32。我们从第7章中的一些ping程序例子中可以看出，发送ICMP回显回答时经常把TTL设为最大值255。
每个处理数据报的路由器都需要把TTL的值减1或减去数据报在路由器中停留的秒数。由于大多数的路由器转发数据报的时延都小于1秒钟，因此TTL最终成为一个跳站的计数器，所经过的每个路由器都将其值减1。

（下面是原书p.98①的译文）
RFC 1009 [Braden and Postel 1987]指出，如果路由器转发数据报的时延超过1秒，那么它将把TTL值减去所消耗的时间（秒数）。但很少有路由器这么实现。新的路由器需求文档RFC [Almquist 1993]为此指定它为可选择功能，允许把TTL看成一个跳站计数器。

TTL字段的目的是防止数据报在路由选择时无休止地在网络中流动。例如，当路由器瘫痪或者两个路由器之间的连接丢失时，路由选择协议有时会去检测丢失的路由并一直进行下去。在这段时间内，数据报可能在循环回路被终止。TTL字段就是在这些循环传递的数据报上加上一个生存上限。
当路由器收到一份IP数据报，如果其TTL字段是0或1，则路由器不转发该数据报。（接收到这种数据报的目的主机可以将它交给应用程序，这是因为不需要转发该数据报。但是在通常情况下，系统不应该接收TTL字段为0的数据报。）相反地，路由器将该数据报丢弃并给信源机发一份ICMP“超时”信息。Traceroute程序的关键在于包含这份ICMP信息的IP报文的信源地址是该路由器的IP地址。
我们现在可以猜想一下Traceroute程序的操作过程。它发送一份TTL字段为1的IP数据报给目的主机。处理这份数据报的第一个路由器将TTL值减1，丢弃该数据报，并发回一份超时ICMP报文。这样就得到了该路径中的第一个路由器的地址。然后Traceroute程序发送一份TTL值为2的数据报，这样我们就可以得到第二个路由器的地址。继续这个过程直至该数据报到达目的主机。但是目的主机哪怕接收到TTL值为1的IP数据报，也不会丢弃该数据报并产生一份超时ICMP报文，这是因为数据报已经到达其最终目的地。那么我们该如何判断已经到达目的主机了呢？
Traceroute程序发送一份UDP数据报给目的主机，但它选择一个不可能的值作为UDP端口号（大于30,000），使目的主机的任何一个应用程序都不可能使用该端口。因为，当该数据报到达时，将使目的主机的UDP模块产生一份“端口不可到达”错误（见6.5节）的ICMP报文。这样，Traceroute程序所要做的就是区分接收到的ICMP信息是超时还是端口不可到达，以判断什么时候结束。

（下面是原书p.99①的译文）
Traceroute程序必须可以为发送的数据报设置TTL字段。并非所有与TCP/IP接口的程序都支持这项功能，同时并非所有的实现都支持这项能力，但目前大部分系统都支持这项功能，并可以运行Traceroute程序。这个程序界面通常要求用户具有超级用户权限，这意味着它可能需要特殊的权限以在你的主机上运行该程序。

8.3 局域网输出
我们现在已经做好运行Traceroute程序并观察其输出的准备了。我们将使用从svr4到slip，经路由器bsdi的简单互连网（见内封面）。 bsdi和slip之间是9600 b/s的SLIP链路。

（见原书p.99的②）

输出的第一个无标号行给出了目的主机名和其IP地址，指出traceroute程序最大的TTL字段值为30。40字节的数据报包含20字节IP首部，8字节的UDP首部和12字节的用户数据。（12字节的用户数据包含每发一个数据报就加1的序号，送出TTL的副本以及发送数据报的时间。）
输出的后面两行以TTL开始，接下来是主机或路由器名，以及其IP地址。对于每个TTL值，发送3份数据报。每接收到一份ICMP报文，就计算并打印出往返时间。如果在5秒种内仍未收到3份数据报的任意一份的响应，则打印一个星号，并发送下一份数据报。在上述输出结果中，TTL字段为1的前三份数据报的ICMP报文分别在20，10和10 ms收到。TTL字段为2的3份数据报的ICMP报文则在120 ms后收到。由于TTL字段为2到达最终目的主机，因此程序就此停止。
往返时间是由发送主机的traceroute程序计算的。它是指从traceroute程序到该路由器的总往返时间。如果我们对每段路径的时间感兴趣，可以用TTL字段为N+1所打印出来的时间减去TTL字段为N的时间。
图8.1给出了tcpdump的运行输出结果。正如我们所预想的那样，第一个发往bsdi的探测数据报的往返时间是20 ms而后面两个数据报往返时间是10 ms的原因是发生了一次ARP交换。tcpdump结果证实了确实是这种情况。
目的主机UDP端口号最开始设置为33435，且每发送一个数据报加1。可以通过命令行选项来改变开始的端口号。UDP数据报包含12个字节的用户数据，我们在前面traceroute程序输出的40字节数据报中已经对其进行了描述。
后面tcpdump打印出了TTL字段为1的IP数据报的注释[ttl 1]。当TTL值为0或1时，tcpdump打印出这条信息，以提示我们数据报中有些不太寻常之处。在这里我们可以预见到TTL值为1，而在其它一些应用程序中，它可以警告我们数据报可能无法到达其最终目的主机。我们不可能看到路由器传送一个TTL值为0的数据报，除非发出该数据报的该路由器已经崩溃。

图8.1 从svr4到slip的traceroute程序示例的tcpdump输出结果

因为bsdi路由器将TTL值减到0，因此我们预计它将发回“传送超时”的ICMP报文。即使这份被丢弃的IP报文发送往slip，路由器也会发回ICMP报文。
有两种不同的ICMP“超时”报文（见p.71页的图6.3），它们的ICMP报文中code字段不同。图8.2给出了这种ICMP错误报文的格式。

图8.2 ICMP超时报文

我们所讨论的ICMP报文是在TTL值等于0时产生的，其code字段为0。
主机在组装分片时可能发生超时，这时，它将发送一份“组装报文超时”的ICMP报文。（我们将在11.5节讨论分片和组装。）这种错误报文将code字段置1。
图8.1的第9-14行对应于TTL为2的3份数据报。这3份报文到达最终目的主机，并产生一份ICMP端口不可到达报文。
计算出SLIP链路的往返时间是很有意义的，就象我们在7.2节中所举的Ping例子，将链路值设置为1200 b/s一样。发送出动的UDP数据报共42个字节，包括12字节的数据，8字节UDP首部，20字节的IP首部以及（至少）2字节的SLIP帧（2.4节）。但是与Ping不一样的是，返回的数据报大小是变化的。从图6.9可以看出，返回的ICMP报文包含发生差错的数据报的IP首部以及紧随该IP首部的8字节数据（在traceroute程序中，即UDP首部）。这样，总共就是20 + 8 + 20 + 8 + 2，即58字节。在数据速率为960 B/s的情况下，预计的RTT就是（42 + 58/960），即104 ms。这个值与svr4上所估算出来的110 ms是吻合的。
图8.1中的源端口号（42804）看起来有些大。traceroute程序将其发送的UDP数据报的源端口号设置为Unix进程号与32768之间的逻辑或值。对于在同一台主机上多次运行traceroute程序的情况，每个进程都查看ICMP返回的UDP首部的源端口号，并且只处理那些对自己发送回答的报文。
关于traceroute程序还有一些必须指出的事项。首先，并不能保证现在的路由也是将来所要采用的路由，甚至两份连续的IP数据报都可能采用不同的路由。如果在运行程序时，路由发生改变，你就会观察到这种变化，这是因为对于一个给定的TTL，如果其路由发生变化，traceroute程序将打印出新的IP地址。
第二，不能保证ICMP报文的路由与traceroute程序发送的UDP数据报采用同一路由。这表明所打印出来的往返时间可能并不能真正体现数据报发出和返回的时间差。（如果UDP数据报从信源到路由器的时间是1秒，而ICMP报文用另一条路由返回信源用了3秒时间，则打印出来的往返时间是4秒。）
第三，返回的ICMP报文中的信源IP地址是UDP数据报到达的路由器接口的IP地址。这与IP记录路由选项（7.3节）不同，记录的IP地址指的是发送接口地址。由于每个定义的路由器都有2个或更多的接口，因此，从A主机到B主机上运行traceroute程序和从B主机到A主机上运行traceroute程序所得到的结果可能是不同的。事实上，如果我们从slip主机到svr4上运行traceroute程序，其输出结果变成了：

（见原书p.101的①）

这次打印出来的bsdi主机的IP地址是140.252.13.66，对应于SLIP接口，而上次的地址是140.252.13.35，是以太网接口地址。由于traceroute程序同时也打印出与IP地址相关的主机名，因而主机名也可能变化。（在我们的例子中，bsdi上的两个接口都采用相同的名字。）
考虑图8.3的情况。它给出了两个局域网通过一个路由器相连的情况。两个路由器通过一个点对点的链路相连。如果我们在左边LAN的一个主机上运行traceroute程序，那么它将发现路由器的IP地址为if1和if3。但在另一种情况下，就会发现打印出来的IP地址为if4和if2。if2和if3有着同样的网络号，而另两个接口则有着不同的网络号。

图8.3 traceroute程序打印出的接口标识

最后，在广域网情况下，如果traceroute程序的输出是可读的域名形式，而不是IP地址形式，那么会更好理解一些。但是由于traceroute程序接收到ICMP报文时，它所获得的唯一信息就是IP地址，因此，在给定IP地址的情况下，它做一个“反向域名查看”工作来获得域名。这就需要路由器或主机的管理员正确配置其反向域名查看功能（并非所有的情况下都是如此）。我们将在14.5节描述如何使用DNS将一个IP地址转换成域名。

8.4 广域网输出
我们前面所给出的小互连网的输出例子对于查看协议运行过程来说是足够了，但对于像全球互连网这样的大互连网来说，应用traceroute程序就需要一些更为实际的东西。
图8.4是从sun主机到NIC (Network Information Center)的情况。

图8.4 从sun主机到nic.ddn.mil的traceroute程序

由于运行的这个例子包含文本，非DDN站点（如，非军方站点）的NIC已经从nic.ddn.mil转移到rs.internic.net，即新的“InterNIC"。
一旦数据报离开tuc.noao.edu网，它们就进入了telcom.arizona.edu网络。然后这些数据报进入NASA Science Internet，nsn.nasa.gov。TTL字段为6和7的路由器位于JPL (Jet Propulsion Laboratory)上。TTL字段为11所输出的sura.net网络位于Southeastern Universities Research Association Network上。TTL字段为12的域名GSI是Government sys tems, Inc., NIC的运营者。
TTL字段为6的第二个RTT（590）几乎是其它两个RTT值（234和262）的两倍 。它表明IP路由的动态变化。在发送主机和这个路由器之间发生了使该数据报速度变慢的事件。同样，我们不能区分是发出的数据报还是返回的ICMP差错报文被拦截。
TTL字段为3的第一个RTT探测值（204）比TTL字段为2的第一个探测值（233）值还小。由于每个打印出来的RTT值是从发送主机到路由器的总时间，因此这种情况是可能发生的。
图8.5的例子是从sun主机到作者出版商之间的运行例子。

图8.5 从sun.tuc.noao.edu主机到aw.com的traceroute程序

在这个例子中，数据报离开telcom.arizona.edu网络后就进行了地区性的网络westnet.net (TTL字段值为6和7)。然后进行了由Advanced Network & Services运营的NSFNET主干网，t3.ans.net，（T3是对于主干网采用的45 Mb/s电话线的一般缩写。）最后的网络是alter.net，即aw.com与互连网的连接点。

8.5 IP源站选路选项
通常IP路由是动态的，即每个路由器都要判断数据报下面该转发到哪个路由器。应用程序对此不进行控制，而且通常也并不关心路由。它采用类似traceroute程序的工具来发现实际的路由。
源站选路(source routing)的思想是由发送者指定路由。它可以采用以下两种形式：
•严格的源路由选择。发送端指定IP数据报所必须采用的确切路由。如果一个路由器发现源路由所指定的下一路由器不在其直接连接的网络上，那么它就返回一个“源站路由失败”的ICMP差错报文。
宽松的源站选路。发送端指定一个数据报经过的IP地址清单，但是数据报在清单上指定的任意两个地址之间可以通过其它路由器。
Traceroute程序为我们提供了一个查看源站选路的方法，我们可以在选项中指明源站路由，然后检查其运行情况。

（原书p.104①的译文）
一些公开的Traceroute程序源代码包中包含指明宽松的源站选路的补丁。但是在标准版中通常并不包含此项。这些补丁的解释是“Van Jacobson的原始Traceroute程序（1988年春）支持该特性，但他后来因为有人提出会使网关崩溃而将此功能去除。”对于本章中所给出的例子，作者将这些补丁安装上，并将它们设置成允许宽松的源站选路和严格的源站选路。

图8.6给出了源站路由选项的格式。

图8.6 IP首部源站路由选项的通用格式

这个格式与我们在图7.3中所示的记录路由选项格式基本一致。但不同之处是，对于源站选路，我们必须在发送IP数据报前填充IP地址清单，而对于记录路由选项，我们需要为IP地址清单分配并清空一些空间，并让路由器填充该清单中的各项。同时，对于源站选路，我们只要为所需要的IP地址数分配空间并进行初始化，通常其数量小于9。而对于记录路由选项来说，我们必须尽可能地分配空间，以达到9个地址。
对于宽松的源站选路来说，code字段的值是0x83，而对于严格的源站选路，其值为0x89。len和ptr字段与我们在7.3节中所描述的一样。
源站路由选项的实际称呼为“源站及记录路由”（对于宽松的源站选路和严格的源站选路，分别用LSRR和SSRR表示），这是因为在数据报沿路由发送过程中，对IP地址清单进行更新。下面是其运行过程：
•发送主机从应用程序接收源站路由清单，将第一个项去掉（它是数据报的最终目的地址），将剩余的项移到一个项中（如图8.6所示），并将原来的目的地址作为清单的最后一项。指针仍然指向清单的第一项（即，指针的值为4）。
•每个处理数据报的路由器检查其是否为数据报的最终地址。如果不是的话，则正常转发数据报。（在这种情况下，必须指明宽松源站选路，否则我们就不能接收到该数据报。）
•如果该路由器是最终目的，且指针不大于路径的长度，那么（1）由ptr所指定的清单中的下一个地址就是数据报的最终目的地址，（2）由出接口(outgoing interface)相对应的IP地址取代刚才使用的源地址，然后，（3）指针加4。
可以用下面这个例子很好地解释上述过程。在图8.7中，我们假设主机S上的发送应用程序发送一份数据报给D，指定源路由为R1，R2和R3。

图8.7 IP源路由示例

在上图中，#表示指针字段，其值分别是4，8，12和16。长度字段恒为15（三个IP地址加上三个字节首部）。可以看出，每一跳IP数据报中的目的地址都发生改变。
当一个应用程序接收到由信源指定路由的数据时，在发送回答时，应该读出接收路由值，并提供反向路由。

（下面是原书p.105①的译文）
Host Requirements RFC指明，TCP客户必须能指明源站路由选择，同时，TCP服务器必须能够接收源站路由选择，并且对于该TCP连接的所有报文段都能采用反向路由。如果TCP服务器下面接收到一个不同的源站路由选择，那么新的源站路由将取代旧的源站路由。

宽松的源站选路的traceroute程序示例
使用traceroute程序的 -g 选项，我们可以为宽松的源站选路指明一些中间结点。采用该选项可以最多指定8个中间路由。（其个数是8而不是9的原因是，所使用的编程接口要求最后的表目是目的主机。）
在图8.4中，去往NIC，nic.ddn.mil的路由经过NASA Science Internet。在图8.8中，我们通过指定路由器 enss142.UT.westnet.net (192.31.39.21) 作为中间路由器来强制数据报通过NSFNET：

图8.8 采用宽松源站选路通过NSFNET到达nic.ddn.mil的traceroute程序