网络拥塞—导致传输异常—解决方法：重传
拥塞原理-原因：
1.路由器无限缓存时： 不会丢包，排队时间无限长
C为路由器出口带宽固定，刚开始输出速率= 输入速率， 随着输入速率逐渐增大， 最终输出速率 = 路由器带宽 不再增大， 数据包在路由缓存中无限排队， 时延越来越大，最终超过计时器，触发重传
2.路由器缓存有限时：内存溢出丢包需要重传，在队列中未丢失的分组也要被无意义的重传，浪费带宽（因为排队时延太大触发重传计时器）
3.丢包后上游服务器带宽被浪费
如何感知是否拥塞？
超时/收到来自接收方的三个冗余ACK——判定出现拥塞
传输异常
丢包：数据报传输途中丢失、接收端的ACK确认报文在传输途中丢失、接收端异常未响应ACK或被接收端丢弃。
乱序：前面的包丢了
重传
TCP两种重传机制：超时重传和快速重传
超时重传：在请求包发出去的时候，开启一个计时器（计算重传时间），当计时器达到时间之后，没有收到ACK，则就进行重发请求的操作，一直重发直到达到重发上限次数或者收到ACK
快速重传 ：拥塞控制中应用
当接收方收到的数据包是不正常的序列号，那么接收方会重复把应该收到的那一条ACK重复发送，这个时候，如果发送方收到连续3条的同一个序列号的ACK，那么就会启动快速重传机制，把这个ACK对应的发送包重新发送一次
TCP定时器—（超时间隔设定问题）
超时间隔必须略大于往返时间(RTT) ：等于RTT会造成不必要的重传，过大于不能很快重传数据包导致时延过大。
1.估计往返时间（解决超时间隔大于谁的问题）EstimatedRTT：TCP在某一次成功发送做一次RTT测量（最近的一次成文sampleRTT）,并与之前的平均RTT做加权计算得出新的平均RTT（因为不同时间网络的拥塞，系统负载情况不同，所以要保持更新）
RFC给出的α推荐值是0.125—最新的sampleRTT反映了当前的网络情况，所以权值要很大。
2.RTT偏差值（解决略大多少的问题）DevRTT: DevRTT是SampleRTT和EstimatedRTT的平均差值
3. 计算重传时间（Timeoutintervel）
为何快速重传是选择3次ACK？
主要的考虑还是要区分包的丢失是由于链路故障还是乱序等其他因素引发。两次duplicated ACK时很可能是乱序造成的！三次duplicated ACK时很可能是丢包造成的！四次duplicated ACK更更更可能是丢包造成的！但是这样的响应策略太慢。丢包肯定会造成三次duplicated ACK!综上是选择收到三个重复确认时窗口减半效果最好，这是实践经验。
