多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
通常IP路由是动态的,即每个路由器都要判断数据报下面该转发到哪个路由器。应用程序对此不进行控制,而且通常也并不关心路由。它采用类似Traceroute程序的工具来发现实际的路由。 源站选路(source routing)的思想是由发送者指定路由。它可以采用以下两种形式: • 严格的源路由选择。发送端指明IP数据报所必须采用的确切路由。如果一个路由器发现源路由所指定的下一个路由器不在其直接连接的网络上,那么它就返回一个“源站路由失败”的ICMP差错报文。 • 宽松的源站选路。发送端指明了一个数据报经过的IP地址清单,但是数据报在清单上指明的任意两个地址之间可以通过其他路由器。 Traceroute程序提供了一个查看源站选路的方法,我们可以在选项中指明源站路由,然后检查其运行情况。 一些公开的Traceroute程序源代码包中包含指明宽松的源站选路的补丁。但是在标准版中通常并不包含此项。这些补丁的解释是“ Van Jacobson的原始Traceroute程序(1988年春)支持该特性,但后来因为有人提出会使网关崩溃而将此功能去除。”对于本章中所给出的例子,作者将这些补丁安装上去,并将它们设置成允许宽松的源站选路和严格的源站选路。 图8-6给出了源站路由选项的格式。 ![](https://box.kancloud.cn/2016-04-13_570df0ef9d058.png) 这个格式与我们在图7-3中所示的记录路由选项格式基本一致。不同之处是,对于源站选路,我们必须在发送IP数据报前填充IP地址清单;而对于记录路由选项,我们需要为IP地址清单分配并清空一些空间,并让路由器填充该清单中的各项。同时,对于源站选路,只要为所需要的IP地址数分配空间并进行初始化,通常其数量小于9。而对于记录路由选项来说,必须尽可能地分配空间,以达到9个地址。 对于宽松的源站选路来说,code字段的值是0x83;而对于严格的源站选路,其值为0x89。 len和ptr字段与7.3节中所描述的一样。 源站路由选项的实际称呼为“源站及记录路由”(对于宽松的源站选路和严格的源站选路,分别用LSRR和SSRR表示),这是因为在数据报沿路由发送过程中,对IP地址清单进行了更新。 下面是其运行过程: • 发送主机从应用程序接收源站路由清单,将第1个表项去掉(它是数据报的最终目的地址),将剩余的项移到1个项中(如图8-6所示),并将原来的目的地址作为清单的最后一项。指针仍然指向清单的第1项(即,指针的值为4)。 • 每个处理数据报的路由器检查其是否为数据报的最终地址。如果不是,则正常转发数据报(在这种情况下,必须指明宽松源站选路,否则就不能接收到该数据报)。 • 如果该路由器是最终目的,且指针不大于路径的长度,那么(1)由p t r所指定的清单中的下一个地址就是数据报的最终目的地址;(2)由外出接口(outgoing interface)相对应的IP地址取代刚才使用的源地址;(3)指针加4。 可以用下面这个例子很好地解释上述过程。在图8-7中,我们假设主机S上的发送应用程序发送一份数据报给D,指定源路由为R1,R2和R3。 ![](https://box.kancloud.cn/2016-04-13_570df0efb5746.png) 在上图中,#表示指针字段,其值分别是4、8、12和16。长度字段恒为1 5(三个IP地址加上三个字节首部)。可以看出,每一跳IP数据报中的目的地址都发生改变。 当一个应用程序接收到由信源指定路由的数据时,在发送应答时,应该读出接收到的路由值,并提供反向路由。Host Requirements RFC指明,TCP客户必须能指明源站选路,同时, TCP服务器必须能够接收源站选路,并且对于该TCP连接的所有报文段都能采用反向路由。如果TCP服务器下面接收到一个不同的源站选路,那么新的源站路由将取代旧的源站路由。