《TCP/IP协议 详解》思考总结 · TCP下篇

前言
这篇文章是整个读书总结系列的最后一篇，有关TCP我想总结的内容都会在这篇文章结束。当然这并不是TCP的全部，总共的五篇文章都只是计算机网络的基础。枯燥而又繁杂的知识点只是进入网络领域的入场券，学会理解了基础才可能继续往下深耕。

作为上篇的承接，下篇我们开始着手认识TCP的拥塞避免策略。对于传统的TCP而言，拥塞的判断完全依赖于丢包的情况，这样判断的理由是基于对现实网络情况的总结经验。我们会考虑超时和收到重复ack两种情况的拥塞，并对于它们的不同做出不同的决断。之后会简单介绍一个TCP连接上的四个定时器。文章的最后我们简单讨论了TCP的现在和未来。

说实话我并不认为TCP这些具体的操作内容对于阅读者有任何的意义，因为这些书本理论的东西和实际存在了非常大的鸿沟。我希望的是，能在介绍这些内容的过程中，和读者分享一个感受：TCP做为一个工程化的东西，受限于技术、硬件等等条件，设计的过程是充满推断和妥协的。如何使用有限的资源实现一个理论上不可能的需求，TCP给我们上了非常好的一课。

《TCP/IP协议 卷一》后面的章节还介绍了一些其他的内容，主要是几个应用层的协议。可以简单看一看了解一下，需要时再去参考。不再专门讨论总结。

TCP的拥塞避免
TCP提供了可靠的传输服务。其中一个很重要的策略就是接收端必须返回ack，用以让发送端确认数据抵达。但这个策略的问题在于，不可靠的信道上发送的数据报和返回的ack都有可能丢失，为了解决这个问题，发送数据时，TCP会在发送端设置一个定时器用以检查ack的返回。如果定时器溢出时还没有收到接收端的ack，那么发送端就会重传这部分的数据。

TCP发送数据的ack和两军问题不同在于，数据正确送达只需要发送端确认即可。所以问题变的简单很多，只需要一次单向握手就可以解决。

要实现一个高效的传输服务，关键就在于超时和重传策略的确定。简单来说，选择一个合适的超时间隔和超时如何继续重传是非常重要的。

首先让我们看一看超时时间间隔的选择。在TCP当中有一个非常重要的概念：RTT（往返时间Round-Trip Time）。在计算机网络中它是一个重要的性能指标。

什么是RTT
摘取一段教材的定义

“We define the round-trip time, which is the time it takes for a small packet to travel from client to server and back to the client.”

“The RTT includes packet-progation delays, packet-queuing delays and packet -processing delay.”

RTT指代的是从发送端发送数据开始，接收端收到数据立即确认，到发送端收到来自接收端确认往返双向的时延。通常情况下一个单向的时延我们是这样计算的。

单向时延 = 传输时延（t1） + 传播时延（t2） + 排队时延（t3）

t1指数据从进入节点到传输媒体所需的时间，通常等于 数据块长度/信道带宽

t2指信号在信道上传播所需的时间，通常等于 信道长度/传播速率

t3通常受每一跳设备及收发两端负荷情况还有吞吐情况影响

上述公式中可以看出，RTT的大小受多个因素影响。假设在同一个连接上t1可以认为保持不变，但路由器和网络流量的不确定，导致RTT的大小是会经常发生变化的。为了解决这样一个问题，TCP会跟踪这些变化并不断调整RTT，以此为根据来设置相应的超时间隔。

为了方便理解，先举一个简单的例子：

作者读高中的时候每天骑车往返与学校和家，假设往返一趟的时间是20min。每天放学的时间是5：40 pm，那么在六点之前如果我还没有回家，父母就会电话老师询问是否学校有留堂。

参考上面的内容，父母会根据我往返学校的时间得出我大概的回家时间，如果我没有按时回来，那么大概率的情况是有意外情况的发生。

对比参考RTT，指代的就是我往返学校的时间，父母就是发送端。TCP会根据RTT来决定超时间隔，判断发送数据报的ack大概的返回时间，从而设置定时器。如果定时器溢出发送端仍然没有收到ack，那么我们有理由认为数据报在传输的过程中丢失，需要进行重传。

本文不介绍RTT测量相关的内容，有兴趣的朋友可以自行查阅

这里需要强调的是，对于发送端而言，报文被传送出去之后发生的事情，实际都是无处可知的。TCP很多时候采取的策略都是基于已有的部分信息，结合实验得出的普遍结论来推断得到的。结合重传策略来说，在定时器溢出时，发送端实际并不知道数据报的实际情况。但是TCP会以此作为信道拥塞的判定标准，认为信道发生拥塞需要处理。

信道拥塞这个结论的前提是数据报的丢失是因为拥塞而不是分组数据受到损坏（一般来说损坏导致的丢失远小于1%），获取的RTT是相对准确的。试想，如果前提条件不再成立，那么信道拥塞的结论是否还值得相信呢？

在网络不太稳定的场景（比如无线网络）中，无线网络因为短暂的信号干扰会导致的丢包。但传统的TCP流控算法会认为发生拥塞从而指数避让，导致速率大幅下降。很显然在TCP设计之初并没有考虑到这样的情况。

实际这也是一个必然。工作中的经历时常让我思考完美这个东西在工程当中是否真的存在，因为考虑到成本，时间以及技术等等各方面的限制，要做到让各方面都满意实际并不现实。总结过往的经验&