TCP的美妙之处，莫过于流量与拥塞控制环节，相信也是让包括小采风在内的看官们，感受到乌云压城的厚重。秉承通信学子的责任与义务，怀着不破楼兰誓不还的信念，今天终于可以好好聊一聊这份厚重，希望能给各位看官带来些许帮助。
问题的千丝万缕，错综复杂，让人深处迷乱而难以逃脱，为了柳暗花明又一村的开阔，首先需要明确问题相关概念的定义，务必准确清晰，其次能够整体性看待。本文的思路，选择问题的多个方面，依次介绍，最终从整体性的角度，来总结提升。事不宜迟，马上开始今天的旅行。
一、序列号与确认号（Seq与Ack）
（1）学习目的
教科书在介绍TCP的优势时谈到，TCP可以提供可靠性传输，包括无差错、不丢失、不重复和有序性，而保证以上四点的关键，在于Seq和Ack。
a）丢包的情况主要分为两种，其一是因为网络时延和校验和字段错误，解决方法为快速重传；其二是网络拥塞致使超时未收到确认，解决方法为超时重传，快速重传与超时重传的区别在下文中介绍，两种方法保证无差错和不丢失；
b）TCP的传输基于IP，而IP是无连接、不可靠的，IP包到达的无序致使上层TCP报文段的无序，收端根据Seq字段按顺序排列，保证不重复和有序性；
（2）截图分析
图1：Seq 和 Ack
图1为10.32.106.159和10.32.106.62间的基于TCP的通信过程，分别记为159和62。Seq表示本地数据的序列号，Len表示本地发送数据的大小，Ack表示期待对方发送数据的序列号。因为TCP是双向数据传输，仅分析159向62发送数据的过程，具体分析如下：
a）从51号包可知，159的发送数据Seq为3681，发送数据长度为1448；因为TCP具有累计确认特性，即多次发送一次确认，其特性由不同系统决定，所以52号包再次发送；从52号包可知，159下一次发送数据Seq为5129，发送数据长度为1448；
b）从53号包可知，62的确认号Ack为6577，即6577=5129+1448，意味着6577以前的数据全部收到，期待159下次发送数据的Seq为6577，同理，可以验证其他包的对应字段；
那么收端收到数据后，如何保证不重复和有序性呢？请看下图2：
图2：收端数据排序
收端收到数据后，根据数据段的序列号排序，如果重复则丢掉，如果缺失则重传。
二、发送窗口、接收窗口和拥塞窗口
（1）学习目的
TCP的流量控制，最重要的就是关于窗口的内容。窗口有发送窗口、接收窗口和拥塞窗口，在正式理解三个窗口的含义前，小采风冥思苦想，从生活中举例，方便看官们理解。
华山，天下第一险。西峰索道，是感受华山险峻必经之地。那么从西峰索道下来的人流量次该如何决定呢？且认为有两个因素。其一是索道终点的出口服务能力，其二是索道中间的风力情况。人流量高峰时，索道终点的出口服务能力有限制，会根据服务能力的高低，实时通知索道口调整索道乘坐人数；而当天的风力情况，也是索道口在调整索道乘坐人数时必须考虑的因素。如果索道终点的服务能力可以有300人，而风力情况只能允许有200人，那么索道口只能选择索道乘坐人数为200。
在TCP传输的流量控制和拥塞控制中，300即为接收窗口，风力情况的200即为拥塞窗口，最终确定的乘坐人数200为发送窗口。接收窗口，会因为接收端数据处理能力而动态调整，且容易确定；而拥塞窗口，即网络当前状态，难以确定；发送窗口由接收窗口和拥塞窗口的较小值确定
（2）截图分析接收窗口
图3：接收窗口动态变化
wireshark中显示的win仅为接收窗口大小，其会因为滑动窗口机制而发生变化，其最大值为接收端缓冲区的大小，滑动窗口机制如图4：
图4：滑动窗口机制
a）发送数据被确认时，窗口左侧向右侧移动，称为窗口合拢；
b）接收端处理数据并释放接收缓存时，窗口右侧向右移动，称为窗口张开；
c）若窗口左侧和右侧重合，此时窗口为0，无论拥塞窗口如何，发端均不能发送数据；
（3）拥塞窗口的维护
拥塞窗口是发送方维护的一个虚拟窗口，基于各种算法逼近网络的拥塞临近点，其维护过程如图5所示：
图5：拥塞窗口维护过程
a）初始值设置：因为网络情况未知，所以初始报文大小为2、3或者4个MSS（最大报文长度，具体介绍在下文）
b）慢启动：若发出去的包得到确认，则可以增大窗口长度；窗口增加策略为，收到n个Ack，则增加n个MSS；因为基数比较低，发生拥塞概率低，传输速度比较慢；
c）临界值窗口：如果之前发生过拥塞，以拥塞点为参考（超时和快速重传时有参考）；如果没有发生过，选取较大值；
d）拥塞避免：与慢启动相比，一个往返时间增加一个MSS；如何理解一个Ack与一个往返时间呢？在图1中，51到53号包代表的收发过程，为一个往返时间，但是两个Ack（53号Ack为51号和52共同拥有）
三、超时重传与快速重传
（1）超时重传
a）发生阶段：发生拥塞后，在一个RTO（超时重传时间，由公式计算而得）时间内，未收到Ack
b）拥塞窗口调整：发生拥塞，即网络状态不良，初始值设置为1个MSS，后重新进入慢启动阶段；临界窗口值，可以设置为发生拥塞时的窗口值的一半，也可以设置为发生拥塞时为被确认的数据量的一半，如图6所示：
图6：超时重传后拥塞窗口调整
c）超时重传影响：在RTO阶段，没有传送其他数据，且RTO时间相对较长；且重新回到慢启动阶段；万分之一的超时重传也会对性能产生很大的影响
（2）快速重传
a）发生阶段：快速重传可以发生在任意阶段；
b）现象描述：发送方连续收到3个以上相同的Ack，即意味着包丢失，立即使用快速重传，如图7所示：
图7：快速重传
因为Seq=991851的数据段发生丢失，则1334、1335和1336连续发送三个Ack，表明数据段丢失；
c）为什么是3？：上文有介绍，IP包的无序致使TCP段的无序，不过无序的偏差通常在3以内，即1182号包通常在1184包后面，不会跑到1186包后
d）拥塞窗口调整：若快速重传发生在拥塞避免阶段，进行拥塞窗口调整，只是传送慢一些；临界窗口值为未被确认数据量的一半，然后加上3个MSS，此过程称之为快速回复，如图8所示：
图8：快速恢复
四、延时确认与Nagle算法
（1）学习目的
TCP主要处理两种数据，一种是成块的大数据，另一种是交互的小数据。交互的小数据，比如41个字节的IP包，20个字节的IP头，20个字节的TCP头，1个字节的数据，针对此种小数据，使用延时确认与Nagle减少数据包，减轻网络负担；
（2）延时确认
在发送确认包前，延迟一段时间发送，在这段时间内如果有数据传输，则确认信息和数据一起发送；
（3）Nagle算法
发送数据且等待确认包的过程中，若有小数据生成，则凑满一个MSS或者收到确认后再发送；
（4）经典案例（来自《wireshark网络分析的艺术》）
a）问题描述：在TCP连接终止时，会出现四次挥手的情况，小采风曾经在文章里描述过，可是问题让人很忧伤，请看下图9：
图9：“错误”的TCP连接终止
按照TCP三次握手四次挥手的理论，42号包的Ack的值应为443，可是却显示442，让人费解，排除是wireshark软件的错误；
b）问题解决：经过作者的妙手回春，问题得到正确的解决，如下图10：
图10：“错误”TCP挥手解释
由于客户端采取延时确认策略，故将四次挥手中的第二次和第三次合并为一次发送，即为43号包，而42号包是来自于未终止连接时，对于曾经的数据包的确认，但是由于网络延迟的问题，在41号包发送之后才到达，所以产生严重的迷惑的现象；
五、IP分片与TCP分段
（1）学习目的
IP头中包含有标识位与偏移字段，TCP头包含序列号和确认号，需要正确区分这两种头部字段的区别；
（2）MTU与MSS
不同网络类型的数据链路层，传输的数据大小是有限的。以太网中为MTU=1500字节，不包含以太网帧头。TCP中的MSS=1500-20-20=1460字节，20分别为IP头和TCP头，为单次传输的最大长度，可以类比于华山西峰的缆车承载量。而双方MSS的告知，发生在TCP三次握手时的字段MSS，如下图11所示：
图11：MSS
（3）基于UDP的IP分片
UDP在发送报文时，并不考虑传输数据的大小，而通过IP标识位用来表示同一份数据，通过偏移字段用来表示数据的不同部分，需要明白这点，区分IP的分片与TCP的分段；
或许学习的过程，类似于登山，前面的困惑与迷乱，都是为等待“会当凌绝顶，一览众山小”的那一刻。终于对于协议有那么些理解，记得在经济学人上看过一篇推送，建设工业4.0时代，打造智慧型的系统，各个环节之间的协议是尤为必要的。希望近期的推送，能够帮助各位看官，扎实一下协议的基础，为以后做一些小小的准备。如果文章对您有用，欢迎关注和转发哦！下次见！
网友评论