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太"松"了, 当数据包真的丢失了(比如在路由器上被丢弃了), 系统需要等待非常长的

时间才愿意重传

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

用户体验非常糟糕(卡顿、转圈)
相关推荐
QT 小鲜肉6 小时前
【Linux命令大全】001.文件管理之git命令(实操篇)
linux·服务器·笔记·git·elasticsearch
曹牧9 小时前
C#:记录日志
服务器·前端·c#
运维行者_9 小时前
OPM 与传统管理工具的区别,在网络修复与自动化运维方面的优势在哪里?
运维·服务器·开发语言·网络·自动化·php·ssl
TG:@yunlaoda360 云老大11 小时前
华为云国际站代理商NAT的规格有哪些?
服务器·网络·华为云
Guheyunyi12 小时前
视频安全监测系统的三大核心突破
大数据·运维·服务器·人工智能·安全·音视频
Xの哲學12 小时前
Linux UPnP技术深度解析: 从设计哲学到实现细节
linux·服务器·网络·算法·边缘计算
柏木乃一12 小时前
进程(6)进程切换,Linux中的进程组织,Linux进程调度算法
linux·服务器·c++·算法·架构·操作系统
Run_Teenage12 小时前
Linux:进程等待
linux·运维·服务器
春日见12 小时前
眼在手上外参标定保姆级教学(vscode + opencv)
linux·运维·服务器·数码相机·opencv·ubuntu·3d
TracyGC14 小时前
Linux环境-RTX5080显卡CUDA12.8下安装mmcv/mmdetection3d
linux·运维·服务器