TCP可靠性传输是怎么是实现的？

《图解TCP/IP》这本书中提到“TCP通过校验和，序列号，确认应答，重发控制，连接管理以及窗口控制等机制实现可靠性传输。”序列号、确认应答、重发控制在TCP三次握手（连接管理）和四次挥手中都有体现，这几个机制在很多博文中写的很不错，我也学习总结过一篇，没有创新，一直是知识的搬运工。现在我更关心的是窗口控制，流控制，拥塞控制这几个机制。

首先我会问连接管理，重发控制，确认应答等机制还不能保证可靠性传输吗？为什么还需要窗口控制？

事实上前面提到的几个机制可以保证传输的可靠性，但是一条一条信号的发，显然效率太低了。我们现实生活中批处理被应用于方方面面，考虑一次传输一批信号也是常规套路，那一次发多少呢？一次发多少，需要接收方根据能一次收多少决定。

• 接收方怎么通知发送方自己能接受的数据大小？
  TCP在建立连接时，TCP首部字段中包含了接收方将能接受的数据大小，发送到发送者，确定了窗口值的大小。但是这个窗口值在传输过程中并不是恒定值，会在超时重传或者重复应答时根据一定的策略改变窗口值，之后的拥塞控制会详细描述。

窗口控制是怎么提高传输速率？

传输数据时，不需要等待窗口内数据的确认应答可以继续发送数据，效率显然会提高，收到一个应答，窗口就会向后滑动。同时如果前面数据确认应答丢失，之后的数据确认应答收到，仍然不需要重发，这也提高了传输效率。但是当发送方收到三次同样的确认应答时，会选择重发数据。

为什么还需要流控制？

我觉得窗口控制确实很好的解决了传输速率问题，但是相对静态不能动态灵活的应对流量不同的情况。流控制正是动态的设置窗口值，来解决流量浪费或流量拥堵。怎么进行流量控制呢？发送方类似于轮询机制，不断的发送探测数据包，来询问当前接收方能接受的数据大小，然后设置窗口大小。

窗口控制和流控制，提高传输速率并且动态设置窗口大小，已然很完美，为什么还需要拥塞控制？

其实这个问题写出来，就发现TCP之前的机制对拥塞控制能力很弱，流控制只是不加重拥堵的状况，并不能解决拥塞问题。

• 怎么实现的拥塞控制
  首先有一个慢启动的过程，为了避免通信刚开始大量数据造成问题。慢启动时，初始拥塞窗口值设为1，每次收到应答后拥塞窗口值加1，达到慢启动的阈值后，以一定的比例增大拥塞窗口。当发生超时重传时也需要慢启动修正，慢启动的阈值设置为当前拥塞窗口值的一半。当收到三次重复确认应答时，慢启动的阈值为当前窗口的一半，窗口也设置为新阈值+3。