3.5 面向连接的传输: TCP

1.TCP概述

2.段结构

3.TCP设置超时重传时间


1.TCP概述

csharp 复制代码

2.段结构

csharp 复制代码

3.TCP设置超时重传时间

csharp 复制代码
a.RTT表示一个数据包从发送端发出, 到接收到接收端饭回的确认信号(ack)所经历的总时间 

b.为什么不能用一个固定的超时时间?

如果超时时间设置的太短(比如固定位100ms), 那么在RTT比较大的网络中, 会导致大量不必要

的重传, 浪费带宽, 加重网络拥堵; 如果设得太长(比如固定为2s), 那么在数据包真正丢失

时, 需要等很久才重传, 导致应用响应缓慢; 因此, TCP的RTO必须是动态的, 基于对当前网络

状况的实时测量

csharp 复制代码
理解计算RTO的公式:

1).SRTT = α * SRTT + (1 - α) * RTT_sample, 对历史SRTT的加权平均, α通常取 

0.875, 是一个平滑因子

a.SRTT表示平均往返时间, RTT_sample表示当前的往返时间

b.α接近1表示新的SRTT严重依赖历史值, 对单次波动不敏感, 不会因为一次突然的网络抖动就

大幅度改变对RTT的估计
csharp 复制代码
上面的公式计算超时时间, 无法更好的处理下面的问题

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分钟; 结果今天他准

点到, 反而被你认为是迟到了

csharp 复制代码
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|: 预测误差, 即"实际情况与我们的预期相差多远"

csharp 复制代码
3). RTO = SRTT + 4 × RTTVAR, 常数4是经过大量实验验证的经验值

a.如果K太小(比如 K=1 或 2)

你发现RTO太"紧"了, 网络随便一个小波动(比如一个数据包多排队了几毫秒), RTT就超过了 

RTO; 结果: 不必要的重传大量发生, 这些多余的数据包挤占了本已繁忙的网络带宽, 反而加

剧了拥堵, 形成恶性循环

b.如果K太大(比如 K=8 或 10)

你发现RTO太"松"了, 当数据包真的丢失了(比如在路由器上被丢弃了), 系统需要等待非常长的

时间才愿意重传

结果: 应用层(比如你的网页浏览器、视频通话软件)需要忍受漫长的等待才能恢复丢失的数据,

用户体验非常糟糕(卡顿、转圈)
相关推荐
小白银子8 小时前
零基础从头教学Linux(Day 52)
linux·运维·服务器·python·python3.11
せいしゅん青春之我11 小时前
[JavaEE初阶] 防止网络传输中的中间人入侵---证书
服务器·网络·网络协议·java-ee
Wang's Blog12 小时前
Linux小课堂: 输入重定向与管道操作详解
linux·运维·服务器
w236173460113 小时前
Linux 服务器安全巡检与加固:从命令到实操(CentOS/Ubuntu 通用)
linux·服务器·安全·安全加固·安全巡检
TG_yunshuguoji13 小时前
阿里云云代理商:阿里云CDN刷新机制是什么?
服务器·阿里云·云计算
Jtti13 小时前
香港硬防服务器防御DDOS攻击的优点
运维·服务器·ddos
lpfasd12315 小时前
第2部分:Netty核心架构与原理解析
运维·服务器·架构
若尘拂风16 小时前
centos 7.9 编译安装 freeswitch 1.10.12
服务器·udp·freeswitch·sip