TCP/IP(十二)TCP的确认、超时、重传机制

一   TCP的确认应答机制

确认应答机制: 每次'收到数据' '都会' 给对端发送一个'应答报文(ACK)'

①  带重传的肯定确认

确认机制: '超时' 重传的 '肯定' 确认  --> 完成了'两个作用',或者说有'两个含义'1、'肯定[正确]' 确认小结： 我的确认信息是'针对正确数据'做确认,而'不是错误'的数据一般情况,确认分为'两种类'型:[1]、一种是收到'正确'的数据,向'发送方'发送一个确认信息,告诉它当前我'正确收到'这些数据[2]、一种是收到'错误'数据之后,也会向发送方发送一个确认信息,我当前收到这些数据'接收错误'对于TCP确认机制,采用的是'[1] 前者',只针对'正确接收的数据'做'确认'补充： '错误'的数据包括出现了'差错[乱序]、丢失、重复',对于这三类,'不会'发送任何的'确认'机制

思考： 如何'告诉发送方'其发送的数据有'错误'?答： 接收方根据'有没有'收到确认信息判断也即： 如果在'一段时间内'发送方没有收到接收方的确认信息,那么就可以判定当前的数据是错误传递的2、'重传'对于'错误传递'的机制,TCP当中采用的是'重传方式'来解决错误数据思考：确认机制在'具体实现'的时候,它是'怎样'告诉对方当前哪些数据我是'正确'接收?TCP 通过'累计确认'机制  --> 主要体现在'TCP报文段'的 ACK 确认号 和 '序列号'超时跟网络的'性能'有关 --> 网络拥塞、网络带宽、传输速率  --> 一段时间没有收到就认为'错误'

②  细节 

二   TCP的重传机制

说明： 关于'超时'这里不再探讨了,在'三次握手'和'四次挥手'的过程中'内核参数'已经讲过

①  RTT和RTO

理解： RTT 和 RTO '概念'RTT(Round Trip Time)：一个连接的'往返'时间,即数据发送时刻'到'接收到确认的时刻的'差'值RTT 表示数据包从'发送'到'收到确认应答'的时间,也就是包的'往返'时间

RTO(Retransmission Time Out)：超时重传时间,即从数据发送时刻算起,超过这个时间便执行重传备注： RTO协议实现值'最小1s'特点： 超过'这个时间 [指数退避]'没有确认应答,就会'重传'报文段,这个时间根据 'RTT' 来设置的RTT和RTO的'关系'：由于网络波动不确定性,每个RTT都是动态变化的,所以RTO也应随着RTT'动态'变化

②   TCP的重传机制

常见的'重传'机制：1、'超时'重传2、'快速'重传3、SACK4、D-SACK关注： '重传'的'发展'历史,按照上面的'递增'关系

③  超时重传

TCP 会在以下'两种'情况发生'超时重传'：1、'数据包'丢失2、'确认应答'丢失

思考： 假设在'重传'的情况下,超时时间 RTO '较长或较短'时,会'发生'什么事情呢？

思考： Linux 是'如何计算' RTO 的呢?

思考： 超时重发的'问题'?  -->  '超时重发的时间等待太长'  -->  '快速重传'

④  快速重传

1、'原理图'快速重传的'工作原理'： 是当收到'三个'相同的ACK报文时,会在定时器'过期之前',重传丢失的报文段

2、'原理'讲解

思考： 快速重传机制的'问题'?1、快速重传机制只解决了'一个'问题,就是'超时时间'的问题2、但是'不知道'该重传 '哪些' TCP 报文,于是就有 SACK 方法

⑤  SACK  重点

SACK（Selective Acknowledgment） '选择性确认'

内核参数： /proc/sys/net/ipv4/tcp_sack

⑥  Duplicate SACK

细节点： 'D-SACK'也是使用'SACK'来'传递'信息

D-SACK

案例'1'： ACK '丢包'

案例'2'： 网络'延时'

原理'讲解'

D-SACK 的 '优点'内核参数： /proc/sys/net/ipv4/tcp_dsack