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、SACK
 
 4、D-SACK
 
关注： '重传'的'发展'历史,按照上面的'递增'关系

③  超时重传

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

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

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

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

④  快速重传

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

2、'原理'讲解

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

3、TCP '重复确认'和'快速重传'的一个'案例',用 Wireshark 分析,'显示'如下：
 
 TCP Dup ACK                --> '重传ACK'
 
 TCP Fast Retransmission    --> 'TCP 快速重传'
 
说明： 这个'现象'比较难刻意'构造'

⑤  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