RFC2757-Long Thin Networks-chifire自译本(3)

本文链接：https://blog.csdn.net/chifire/article/details/3758

- ESRO [RFC2188]

- RDP [RFC908, RFC1151]

- VMTP [VMTP]

3 TCP协议的状况（The Case for TCP）

这是无线领域争论最为激烈的问题，这里列出几个主要反对观点：

- 通常认为，TCP在实现无堵塞损失方面做得不够好。TCP的反对者认为，与其为无线媒介而修补TCP还不如重新设计来得方便。

- TCP的报头开销太大。

- 是到了该理顺机制的时机了，TCP协议实在是太笨重了，不适合轻型的、可移动的设备使用。

当然，支持TCP的观点也不少：

- 从兼容性角度出发，在Internet的剩余领域中使用同样的协议是完美的解决方案。任何无线连接的扩展规范都应当被审议。

- 传统的机制可以被重新使用（例如：three-way handshake，即三向握手）

- 链路层的FEC和ARQ技术可以降低BER，这样TCP丢包主要原因只是堵塞或网络连接的持续中断。现代W-WAN科技（(CDPD, US-TDMA, CDMA, GSM）已经这样做了，极大地提高了TCP的吞吐能力。

- 通过移动IP（Mobile IP [RFC2002]）可以实现不同技术间的切换，但自始至终贯穿的是同一个协议，即TCP/IP协议。

- 假设有TCP那么丰富的研发经验，随便哪个协议都会显得相对不够成熟，这一点并非象TCP应用广泛那样容易被人理解。

总而言之，我们认为TCP在远程-窄带网络上的性能还可以有显著地改善。在后续的章节我们将讨论其实现机制。

Montenegro, et al. Informational [Page 11]

4 候选优化（Candidate Optimizations）

在无线介质上优化TCP操作还有大量的工作要做。即使卫星网络通常归于LFN（远程肥胖网）体系，我们当前关注的LTN（远程窄带网）仍可从其身上受益。例如，IETF的卫星TCP工作组的工作为本节内容提供了极大帮助[AGS98, ADGGHOSSTT98]。

4.1 TCP：当前机制（TCP: Current Mechanisms）

TCP发送方基于接收方的反馈信号来调整其对带宽的使用，由于LTN网络的等待时间长，这种调整就比其它延迟短的网络相对慢些。同样，延迟的确认（ACKs）也不利于连接等待时间的估算。假定TCP能增大其段内单元的拥塞窗口，少量的MTU可能更会减慢这种调整过程。

4.1.1 慢启动与拥塞避免（Slow Start and Congestion Avoidance）

慢启动与拥塞避免[RFC2581]的实质就是Internet的稳定性。有两种理由说明无线媒介的反面效果：

- 只要TCP中继的计时期满，发送方就会认为网络发生拥挤，并调用慢启动。正如TCP所期望的那样，抛开拥塞所引起的损耗，尽可能地减小因讹误而引起的损耗。

- 发送方根据收到的确认（ACKs）信号数量来增大其窗口，当然，其到达速率依赖于发送方与接收方间的往返周期（RTT，round-trip-time），这意味着长等待时间的连接（象LTN网络），有较长的斜坡时间（ramp-up），这种依赖性将持续到管道被充满为止。

- 在慢启动过程中，发送方会增大其段内单元的窗口，这就是这样做的重要原因，即要使用适当大小的MTU，且要降低链路层的损耗。

4.1.2快中继和快恢复（Fast Retransmit and Fast Recovery）

当TCP发送方收到重复的确认（ACKs），快中继（fast retransmit，[RFC2581]）将推断一个段已经丢失，从而发送方将对此包进行重新发送，而不必等待超时，进而节省了时间。

Montenegro, et al. Informational [Page 12]

在快中继之后，发送方会调用快恢复[RFC2581]算法。快恢复允许发送方通过减半其传输速率（在避免堵塞基础上调节其窗口的增长）来避免慢启动，从而节省时间。

通常，除了带宽延迟乘积以外，TCP也能增长其窗口。然而在LTN连接中，堵塞窗口可能会保持非常小，不到四段，在很长时间内是因为下列原因：

1. 典型情况下，通过连接传递的文件的尺寸都相对要小些（如Web请求、Web文件对象、email消息、文件等等），尤其是LTN的用户，在回应时间已经很长的情况下，更不愿意进行大尺寸文件的传输。

2. 如果连接的位错率高（BER）的话，堵塞窗口往往会停在很小的状态。

3. 当LTN与高度堵塞的有线Internet入口结合时，堵塞引起的丢包产生的效果与2类似。

4. 通常，ISP/操作员在他们的拨号路由器（dialup router）中为每个用户配置的缓冲数目很小（甚至少到只有3个包）。

5. 通常，在LTN中建议采用小的socket缓冲，以避免实时操作（RTO，real time operation）中的数据膨胀，并减小竞争传输包的数量。

小窗口极大地阻碍了发送方利用快中继的好处，而且，在单个窗口中实现多重损耗的高效恢复也需要采用新的建议（NewReno [RFC2582]）。另外，在没有包重排序的慢速通道上，要等待三次重复的ACK确认信号到达，这样延迟中继也没有什么必要。

建议：尽快实现快中继及快恢复，这是优化实现的普遍方式，同时也是建议标准（[AGS98]）所推荐的卫星环境下快中继/快恢复的实现方式。很显然，NewReno [RFC2582]在发送方处理单个窗口中局部ACK确认信号及多重损耗方面还是很有帮助的，但是由于其属于实验性的机制，所以并不受到推荐。做为替代，SACK [RFC2018]是建议采用的机制。

Montenegro, et al. Informational [Page 13]

4.2 基于T/TCP[RFC1397, RFC1644]的连结设置（Connection Setup with T/TCP [RFC1397, RFC1644]）

TCP在新连接建立时要进行三向握手（"three-way handshake"），只有当此会话成功完成后，方可进行数据的传输。T/TCP允许在建立连接的同时，并行地进行数据的交换，从而使等待时间长的远程网络能够节省小事务的操作时间。

建议：T/TCP并不受推荐，原因如下：

- 它是实验性的RFC。

- 它的应用范围并不十分广泛，而且必须在连接的两端进行配置。

- 从安全性角度看，T/TCP比TCP本身更易受到殊如地址伪装之类的攻击。

- T/TCP的一些好的特性（如消除了并发过程中的三向握手过程，查询-回应式的事务处理等）也同样被HTTP/1.1上的连接所采用，而且后者更加稳固，应用范围也更广泛。

在[ADGGHOSSTT98]中并没有对卫星环境下的T/TCP做出建议。

4.3 慢启动建议（Slow Start Proposals）

交互式用户在TCP连接开始时能看到由于慢启动而产生的网络回应，因此大量的建议都提出，在等待时间长的环境中应取消慢启动。

Internet的稳定性是极为重要的，因而这些建议必须论证其在重要路线上不会对Internet的堵塞水平产生负面影响。

4.3.1 大初始化窗口（Larger Initial Window）

传统的慢启动含有一个段的初始化窗，是LTN上耗时的带宽改造方案。由于TCP标准支持的最大值为2，大于一个段的初始化窗尚在研究阶段 [RFC2414, AHO98]，至于更高的取值，本质上还是实验性的。

Montenegro, et al. Informational [Page 14]

在[RFC2415]描述了对初始化窗进行增加三个信息包的模拟，但它并没有为信息包衰减率提供有效的解决办法，但它还是有助于在端设备慢启动（见下个建议）阶段缩短初始化的回应时间。

[RFC2416]中论述了当初始化窗超过TCP协议可用的缓冲区数目时的状况，并指明，这种情况与堵塞窗口超过缓冲区数目时的情形是一样的。

在[RFC2581]中，允许有两个段的初始化堵塞窗口。在将来，当LFN和LTN的性能得到极大提高后，可能会出现更大的多达四个段的初始化窗口。

建议：立即在设备上实现该提议。优化研究表明，3个段是安全的初始化设定，即在2，3，4三种选择中取中间的。现在，使用2个段的（遵照RFC2581）方式至少允许客户端通过运行质询-回应式的应用，从未经修改的服务器上获取初始ACK确认信号，而不用再等待200毫秒的ACK超时，从而少走了两个往返过程。使用3个段的初始化窗[RFC2415]看来　有前途，可能在未来的研究和实验中被采用。　

4.3.2 在慢启动期间增大窗口（Growing the Window during Slow Start）

发送方可根据从接收方处返回的ACK应答信号流来增大其窗口。特别是在慢启动过程中，该信号流非常重要。有两个建议已经被研究过，一是ACK应答计数，二是ACK每节应答。

4.3.2.1 应答计数（ACK Counting）

ACK应答计数是主要思想是：

- 根据获取的数据（按字节计数），而非ACK的数量（即ACK应答计数）来增大窗口，以使每个ACK应答计数达到最满状态，这将使信息膨胀而引起堵塞。[Allman98]中解释了有限字节计数（Limited Byte Counting,LBC），即窗口增大被限制在2个段内则不会产生严重的信息膨胀，从而有助于提高性能。