4.5 其他的修修补补 --- TCP NewReno
如果我们从TCP拥塞控制中只能学到一件事情，那就是拥塞控制太过复杂，要处理太多的细节才能让其正常工作，而这些细节的处理只能经过实际运行经验的反馈才能知道。这一节介绍其中的两个例子。
4.5.1 TCP SACK
最初的TCP规范使用了累积的ACK。所谓的累积的ACK是指 TCP 接收端会确认在丢包前收到的最后一个packet（注，也就是只确认按照顺序接收的最后一个packet）。你可以认为接收端会排列所有接收到的packet，任何丢失的packet在接收端的字节流里都对应一个缺口。在最初的规范里，即使已经丢失了多个packet，接收端也只能告诉发送端第一个缺口的起始位置。
很明显，这里信息的缺失会降低发送端对实际丢包情况的判断能力。用来解决这里问题的方法被称为selective acknowledgements，或者SACK。SACK也是一个TCP的扩展，它在Jacobson和Karels的早期工作（注，也就是TCP Tahoe版本）之后很快就被提出，但是过了好些年才被大众接受，因为很难证明它的有效性。
如果没有SACK，那发送端只有两种合理的策略来应对包乱序了。
悲观的策略。当发生快速重传或者超时重传时，除了重传明显已经丢失的packet（接收端处第一个丢失的packet），同时也重传所有后续的packet。悲观策略假设最坏的情况发生了：所有不确定的packet都丢失了。悲观策略的缺点是，它可能不必要的重传已经被接收端成功接收的packet。
乐观的策略。在发生丢包时（由超时或者重复的ACK触发），仅重传相应的那1个segment。乐观策略的缺点是，当一段连续的segment丢失时，要花较长时间才能恢复。而一段连续的segment丢失，在网络拥塞时是可能发生的。之所以要花较长时间是因为每个segment的丢失，都要等到前一个segment的重传对应的ACK收到了之后才能被发现。也就是说，对于一段连续丢失的segment，每个segment的重传都要消耗一个RTT。
如果有SACK，发送端可以有更好的策略：只重传被选择性确认的segment之间的segment，也就是只重传丢失的segment。
SACK需要在TCP连接建立之初，在发送端和接收端之间协商。当使用SACK时，接收端还是按照之前一样回复ACK，并且TCP header中的Acknowledgement字段的含义也没有变化。但同时在TCP header中包含接受的乱序segment（注，存在于TCP option中）。这样发送端就能识别出接收端缺失的数据，并且只重传缺失的segment，而不是重传丢失segment之后的所有segment。
SACK在TCP Reno版本中带来了性能的提升，尤其在一个RTT中多个packet丢包时（因为如果使用乐观策略，累积ACK和SACK在只丢一个包时是一样的，所以只有丢多个包才能看出性能区别）。随着带宽延时积的增加，SACK的效果越来越明显，因为带宽延时积越大，对应的TCP EffectiveWindow也就越大，相应的，在一个RTT中，会有更多packet在网络中传输，这样一个RTT中多个packet丢包的概率就更大。
SACK在1996年成为了一个IETF标准（RFC2018），对TCP来说是个及时的补充。
4.5.2 NewReno
NewReno是源自 MIT 的Janey Hoe在 1990 年代中期的研究。它可以在一个拥塞窗口内丢失多个packet时，避免像TCP Reno一样多次对拥塞窗口减半，从而提升TCP Reno在这个场景下的性能。
NewReno 的核心思想是：即使没有 SACK，重复 ACK 也携带了：（1）是否还有丢包（2）丢了哪些包，的信息。发送端可以基于这些信息，决定重传哪些包，以及如何调整自己的拥塞窗口。
下面的例子展示了TCP NewReno如何识别重复的ACK，以及如何调整拥塞窗口。
假设初始时，CongestionWindow = 10 packets，Packet 3和4丢包了。
Step
Packets ACKed
CongestionWindow
传输中的包数
传输的包
1.
None
10
10
1, 2, 3, 4, 5, 6, 7, 8, 9, 10
2.
1
11
11
11, 12
3.
2
12
12
13, 14
4.
2(DA1, R5)
13
13
15, 16
5.
2(DA2, R6)
14
14
17, 18
6.
2(DA3, R7) *
7
13
重传 3
7.
2(DA4, R8)
7
12
–
8.
2(DA5, R9)
7
11
–
9.
2(DA6, R10)
7
10
–
10.
2(DA7, R11)
7
9
–
11.
2(DA8, R12)
7
8
–
12.
2(DA9, R13)
7
7
–
13.
2(DA10, R14)
7
7
19
14.
2(DA11, R15)
7
7
20
15.
2(DA12, R16)
7
7
21
16.
2(DA13, R17)
7
7
22
17.
2(DA14, R18)
7
7
23
18.
3
7
7
24
19.
3(DA1, R19)
7
7
25
20.
3(DA2, R20)
7
7
26
21.
3(DA3, R21)*
7
7
重传 4
22.
3(DA4, R22)
7
7
27
23.
3(DA5, R23)
7
7
28
24.
3(DA6, R24)
7
7
29
25.
3(DA7, R25)
7
7
30
26.
3(DA8, R26)
7
7
32
27.
26
(7+1/7)
7
32
Step 1-3：初始时的慢启动，每个ACK都会使得CongestionWindow增加一个packet，也就是每个ACK都会带来2个新的in-flight的packets。
Step 4-5：虽然此时已经开始在接受Packet 2的重复ACK，但是因为数量还不够，TCP认为可能是包乱序引起的重复ACK，所以仍然每个ACK都会使得CongestionWindow增加一个packet，在Step 5时，拥塞窗口增加至14。
Step 6：收到了Packet 2的3个重复ACK，重传3，并将拥塞窗口减半至7，进入Fast Recovery。
Step 7-12：因为拥塞窗口为7，在传输中的packet大于等于7，此时不发送任何数据。
Step 13-17：虽然还是在收到重复ACK，之前堆积的在传输中的packet数量下降到了7。之后的每一步，每个ACK都会释放
CongestionWindow一个packet的大小，同时使得发送端可以再发送一个新数据。在这个过程中，CongestionWindow一直保持不变。Step 18：收到了Packet 3的ACK，但是在重传3之前，已经发送了Packet 18，这说明Packet 3之后的包也有可能丢了，否则此时应该收到packet 18的ACK。
Step 19-21：收到了Packet 3的3个重复ACK，Packet 4丢失无疑，重传4。但是发送端可以识别出Packet4与Packet3在一个拥塞窗口内，因此这次只有重传，拥塞窗口不会减半（NewReno的核心）。
Step 22-26：与Step13-17类似。
Step 27：收到了Packet 26的ACK，这是重传Packet 4之前发送的Packet。因此发送端可以判定，目前已经没有丢包了，因此可以进入加法递增阶段，每个ACK增加 1/CongestionWindow 个packet的大小。
值得注意的是，NewReno 被记录在 1999-2012 年的 3 个 RFC 中，每一个都修复了前一个的一些问题。这是个理解拥塞控制算法究竟有多复杂的好的例子（尤其还需要考虑到 TCP 重传机制的种种细节），同时也增加了新算法部署实施的难度。
Last updated