拥塞窗口被初始化为1个报文段（即另一端通告的报文段大小），收到一个ACK后，拥塞窗口从1个报文段增加为2，即可发送两个报文段，当继续收到这两个报文段的ACK时，拥塞窗口就增加为4，这是一种指数增加关系。发送方去拥塞窗口与通告窗口中最小值作为发送上限。其实这宗一种渐进循环的策略，当吞吐量在某些点上达到了互联网的容量时，于是中间路由器开始丢弃分组，而通知发送方它的拥塞窗口开得过大了。这里又隐藏了许多的实现细节，如丢失重传问题以及如何避免一下子又从慢启动起步这种慢效率的传输过程。这些后续会学习到。这里更多先对慢启动算法的一个初步认识。
窗口的大小应该设置为多大呢？也就是我们的TCP缓存应该设置多大呢？按理论计算，这个应该跟“带宽时延乘积”有关，具体公式如下：
capacity（bit）=bandwidth（b/s）* round-trip time（s）
这个值依赖于网络速度和两端的RTT，可以有很大的变动。例如一条穿越美国（RTT约为60ms）的T1的电话线路（1544000b/s）的带宽延迟乘积为11580字节。这是没有问题的，但对于一条穿越美国的T3电话线路（45000000b/s）的带宽时延乘积则为337500字节，这个值远远超过了最大所允许的TCP通告窗口大小（16字节窗口大小=65535字节）。别忘记了TCP头部还有一各选项可以补充，后续会介绍如果通过选项解决这种超大型窗口问题。“带宽时延乘积”是一个理论值，就是我们能往发送到到接收端之间的网络最多塞满多少数据。
学习总结
本此总结主要是学习了基于TCP协议交互的一些流程与细节问题，如“交互式输入”以及“成块数交互”的场景介绍，在“成块式传送”中是如何利用“通告窗口”作为接收方的限流以及发送方如何利用“拥塞窗口”进行限流并借助“慢启动”的方式渐进循环的摸索互联网的最大极限。