1.TCP概述
2.段结构
3.TCP设置超时重传时间
1.TCP概述
2.段结构
3.TCP设置超时重传时间
a.RTT表示一个数据包从发送端发出, 到接收到接收端饭回的确认信号(ack)所经历的总时间 b.为什么不能用一个固定的超时时间?如果超时时间设置的太短(比如固定位100ms), 那么在RTT比较大的网络中, 会导致大量不必要的重传, 浪费带宽, 加重网络拥堵; 如果设得太长(比如固定为2s), 那么在数据包真正丢失时, 需要等很久才重传, 导致应用响应缓慢; 因此, TCP的RTO必须是动态的, 基于对当前网络状况的实时测量
理解计算RTO的公式:1).SRTT = α * SRTT + (1 - α) * RTT_sample, 对历史SRTT的加权平均, α通常取 0.875, 是一个平滑因子a.SRTT表示平均往返时间, RTT_sample表示当前的往返时间b.α接近1表示新的SRTT严重依赖历史值, 对单次波动不敏感, 不会因为一次突然的网络抖动就大幅度改变对RTT的估计
上面的公式计算超时时间, 无法更好的处理下面的问题a.网络突然变差("太懒" -> 反应迟钝)- 历史状态: SRTT = 100ms, 如果 RTO = SRTT, 那么RTO也就是100ms- 网络事件: 网络拥堵, 一个数据包花了500ms才收到确认- SRTT更新: 新SRTT = 0.875*100 + 0.125*500 = 156.25ms, 看, SRTT只缓慢地上升到了156ms- 灾难性后果: 如果此时RTO = 新SRTT = 156ms; 那么, 所有那些因为同样拥堵而延迟、RTT在200ms到400ms之间的数据包, 都会在156ms时被判定为超时并重传; 但事实上它们并没有丢, 只是慢了; 这会导致不必要的重传, 加剧网络拥堵- 比喻: 就像一个人平时的通勤时间是30分钟, 今天路上出了大车祸, 他预计要2小时才能到; 如果你只按他"平均通勤时间"的35分钟来等他, 你会在35分钟后就觉得他失联了并开始报警找人, 但实际上他还在路上b.网络非常稳定时("过于敏感")- 历史状态: 网络极其稳定, SRTT = 100ms; 如果RTO = SRTT, 那么RTO是100ms, 这很好- 网络事件: 一个非常正常的、轻微的波动, 一个数据包花了110ms(只比平均多了10ms)- SRTT更新: 新SRTT = 0.875*100 + 0.125*110 = 101.25ms, 看, SRTT被这个正常波动"拉高"了一点- 潜在后果: 如果RTO = 新 SRTT = 101.25ms, 那么下一个数据包, 只要它的RTT回到正常的100ms, 或者哪怕只是105ms, 它都会在101.25ms时被判定为超时！在一个稳定的网络上, 你的协议自己制造了不必要的重传, 这就像"杞人忧天"- 比喻: 你根据朋友昨天快了1分钟到, 就把你们的碰头时间也提前了1分钟; 结果今天他准点到, 反而被你认为是迟到了
2).RTTVAR = β * RTTVAR + (1 - β) * |SRTT - RTT_sample|, RTTVAR让超时时间变得智能; 当网络稳定时, RTT_sample和SRTT很接近, |SRTT - RTT_sample|的值很小, 因此RTTVAR会逐渐变小, 此时的RTO = SRTT + 4 * RTTVAR也会是一个比较紧的、小的值可以快速检测到真正的丢包; 当网络波动大/拥堵时: RTT_sample可能会远大于SRTT, |SRTT - RTT_sample|的值会突然变大, 这使得RTTVAR会迅速增大; 此时的RTO = SRTT + 4 * RTTVAR也会随之显著增大, 给那些只是因为拥堵而延迟的数据包更多的时间, 避免了不必要的重传a.SRTT: 根据历史数据预测的"期望值"b.RTT_sample: 实际测量到的"真实值"c.|SRTT - RTT_sample|: 预测误差, 即"实际情况与我们的预期相差多远"
3). RTO = SRTT + 4 × RTTVAR, 常数4是经过大量实验验证的经验值a.如果K太小(比如 K=1 或 2)你发现RTO太"紧"了, 网络随便一个小波动(比如一个数据包多排队了几毫秒), RTT就超过了 RTO; 结果: 不必要的重传大量发生, 这些多余的数据包挤占了本已繁忙的网络带宽, 反而加剧了拥堵, 形成恶性循环b.如果K太大(比如 K=8 或 10)你发现RTO太"松"了, 当数据包真的丢失了(比如在路由器上被丢弃了), 系统需要等待非常长的时间才愿意重传结果: 应用层(比如你的网页浏览器、视频通话软件)需要忍受漫长的等待才能恢复丢失的数据,用户体验非常糟糕(卡顿、转圈)
