速读原著-TCP/IP(ICMP的差错)

• 2020 年 3 月 12 日
• 笔记

第21章 TCP的超时与重传

21.10 ICMP的差错

让我们来看一下 T C P是怎样处理一个给定的连接返回的 I C M P的差错。T C P能够遇到的最常见的I C M P差错就是源站抑制、主机不可达和网络不可达。

当前基于伯克利的实现对这些错误的处理是： • 一个接收到的源站抑制引起拥塞窗口 c w n d被置为1个报文段大小来发起慢启动，但是慢启动门限s s t h re s h没有变化，所以窗口将打开直至它或者开放了所有的通路（受窗口大小和往返时间的限制）或者发生了拥塞。 • 一个接收到的主机不可达或网络不可达实际上都被忽略，因为这两个差错都被认为是短暂现象。这有可能是由于中间路由器被关闭而导致选路协议要花费数分钟才能稳定

到另一个替换路由。在这个过程中就可能发生这两个 I C M P差错中的一个，但是连接并不必被关闭。相反， T C P试图发送引起该差错的数据，尽管最终有可能会超时（回想图 2 1 – 1中T C P在9分钟内没有放弃的情况）。当前基于伯克利的实现记录发生的 I C M P差错，如果连接超时， I C M P差错被转换为一个更合适的的差错码而不是“连接超时”。早期的B S D实现在任何时候收到一个主机不可达或网络不可达的I C M P差错时会不正确的放弃连接。

一个例子 可以通过在连接中拨号 S L I P链路的断开来观察一个 I C M P主机不可达的差错是如何被处理的。建立一个从主机 s l i p到主机a i x的连接（从扉页前的图中可以看到这个连接经过了我们的拨号S L I P链路）。在建立连接并发送一些数据之后，在路由器 s u n和n e t b之间的S L I P链路被断开，这引起 s u n上的默认路由表项（见 9 . 2节）被移去。我们希望 s u n对目的为1 4 0 . 2 5 2 . 1 以太网的I P数据报响应I C M P主机不可达。希望观察T C P如何处理这些I C M P差错。下面是主机s l i p的交互会话：

图2 1 – 1 2显示了在路由器 b s d i上截获的t c p d u m p的相应输出（去掉了连接建立和所有的窗口通告）。我们连接到在主机 a i x上的回显服务器并键入“ test line”（第1行），它被回显（第2行）且回显被确认（第3行），接着我们断开了S L I P链路。

我们键入“another line”（第3行之后）并希望看到T C P超时和重传报文。的确，这一行在收到应答前被发送了6次。第4 ~ 1 3行显示了第1次传输和接着的4次重传，每个都产生了一个来自路由器s u n的I C M P主机不可达。这正是我们所希望的：从 s l i p来的I P数据报发往路由器b s d i（这是一个指向s u n的默认路由器），并到达检测到链路中断的 s u n。在发生这些重传时， S L I P链路又被连通，在第 1 4行的重传被交付。第 1 5行是来自a i x的回显，而第1 6行是对这个回显的确认。

这表明T C P忽略I C M P主机不可达的差错并坚持重传。我们也可以观察到所预期的在每一次重传超时中的指数退避：第 1次约为2 . 5秒，接着乘2（约5秒），乘4（约1 0秒），乘8（约2 0秒），乘1 4（约4 0秒）。

接着我们键入输入的第3行（“line number 3”）并看到它在第1 7行被发送，在第1 8行回显，并在第1 9行对回显进行确认。

现在我们希望观察在接收到 I C M P主机不可达后， T C P重传并放弃的情况。于是再次断开S L I P链路，之后键入“the last line”，并观察到在T C P放弃之前该行被发送了1 3次（我们已经从结果中删除了第3 0 ~ 4 3行，它们是额外的重传）。

然而，我们所观察到的现象是 s o c k程序在最终放弃时打印出来的差错信息：“没有到达主机的路由”。这与U n i x的I C M P主机不可达的差错类似（图 6 – 1 2）。这表明T C P保存了它在连接上收到的I C M P差错，并在最终放弃时打印出该差错，而不是“连接超时”。

最后，注意到第2 2 ~ 4 6行与第6 ~ 1 4行不同的重传间隔。看起来我们键入的第 3行在第1 7 ~ 1 9行被发送和确认时（无任何重传），T C P更新了它的估计器。最初的重传超时时间现在是 3秒，后续取值为6, 12, 24, 48，直至上限6 4。