在TCP的首部有一个窗口大小字段，他表示接收方的剩余缓冲区大小，让发送方可以调整自己的发送窗口大小。通过滑动窗口，就可以实现TCP的流量控制，不至于发送太快，导致太多的数据丢失。
连续ARQ带来的第二个问题是：网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，必须得有一个确认回复。提高网络效率的方法是：累积确认 。接收方不需要逐个进行回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据全都收到。例如，收到 1234，接收方只需要告诉发送方我收到4了，那么发送方就知道1234都收到了。
第三个问题是：如何处理丢包情况。在停止等待协议中很简单，直接一个超时重传就解决了。但，连续ARQ中不太一样。例如：接收方收到了 123 567，六个字节，编号为4的字节丢失了。按照累积确认的思路，只能发送3的确认回复，567都必须丢掉，因为发送方会进行重传。这就是GBN（go-back-n) 思路。
但是我们会发现，只需要重传4即可，这样不是很浪费资源，所以就有了：选择确认SACK 。在TCP报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方，就可以根据这个选项字段只重传丢失的数据了。
可靠传输小结到这里关于TCP的可靠传输原理就已经介绍的差不多。最后进行一个小结：
通过连续ARQ协议与发送-确认回复模式来保证每一个数据包都到达接收方
通过给字节编号的方法，来标记每一个数据是属于重传还是新的数据
通过超时重传的方式，来解决数据包在网络中丢失的问题
通过滑动窗口来实现流量控制
通过累积确认+选择确认的方法来提高确认回复与重传的效率
当然，这只是可靠传输的冰山一角，感兴趣可以再深入去研究（和面试官聊天已经差不多了[狗头]）。
拥塞控制拥塞控制考虑的是另外一个问题：避免网络过分拥挤导致丢包严重，网络效率降低 。
拿现实的交通举例子：
高速公路同一时间可通行的汽车数量是一定的，当节假日时，就会发生严重的堵车。在TCP中，数据包超时，会进行重传，也就是会进来更多的汽车，这时候更堵，最后导致的结果就是：丢包-重传-丢包-重传。最后整个网络瘫痪了。
这里的拥塞控制和前面的流量控制不是一个东西，流量控制是拥塞控制的手段：为了避免拥塞，必须对流量进行控制。拥塞控制目的是：限制每个主机的发送的数据量，避免网络拥塞效率下降。就像广州等地，限制车牌号出行是一个道理。不然大家都堵在路上，谁都别想走。
拥塞控制的解决方法是流量控制，流量控制的实现是滑动窗口，所以拥塞控制最终也是通过限制发送方的滑动窗口大小来限制流量 。当然，拥塞控制的手段不只是流量控制，导致拥塞的因素有：路由器缓存、带宽、处理器处理速度等等。提升硬件能力（把4车道改成8车道）是其中一个方法，但毕竟硬件提升是有瓶颈的，没办法不断提升，还是需要从tcp本身来增加算法，解决拥塞。
拥塞控制的重点有4个：慢开始、快恢复、快重传、拥塞避免。这里依旧献祭出大学老师的ppt图片：
Y轴表示的是发送方窗口大小，X轴表示的是发送的轮次（不是字节编号）。
最开始的时候，会把窗口设置一个较小的值，然后每轮变为原来的两倍。这是慢开始。
当窗口值到达ssthresh值，这个值是需要通过实时网络情况设置的一个窗口限制值，开始进入拥塞避免，每轮把窗口值提升1，慢慢试探网络的底线。
如果发生了数据超时，表示极可能发生了拥塞，然后回到慢开始，重复上面的步骤。
如果收到三个相同的确认回复，表示现在网络的情况不太好，把ssthresh的值设置为原来的一半，继续拥塞避免。这部分称为快恢复。
如果收到丢包信息，应该尽快把丢失的包重传一次，这是快重传。
当然，窗口的最终上限是不能无限上涨的，他不能超过接收方的缓存区大小。
通过这个算法，就可以在很大程度上，避免网络拥挤。