一 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)：超时重传时间,即从数据发送时刻算起,超过这个时间便执行重传
特点： 超过'这个时间 [指数退避]'没有确认应答,就会'重传'报文段,这个时间根据 '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 方法
⑤ 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
