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

时间才愿意重传

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

用户体验非常糟糕(卡顿、转圈)
相关推荐
_星辰大海乀5 小时前
IP 协议
服务器·网络·tcp/ip·nat·子网掩码·ip协议
屿行屿行6 小时前
【Linux】Socket编程(基于实际工程分析)
linux·服务器·网络
runepic6 小时前
Python + PostgreSQL 批量图片分发脚本:分类、去重、断点续拷贝
服务器·数据库·python·postgresql
企鹅侠客7 小时前
Linux性能调优 详解磁盘工作流程及性能指标
linux·运维·服务器·性能调优
企鹅侠客7 小时前
Linux性能调优 再谈磁盘性能指标和进程级IO
linux·运维·服务器·性能调优
虚伪的空想家8 小时前
云镜像,虚拟机镜像怎么转换成容器镜像
服务器·docker·容器·k8s·镜像·云镜像·虚机
在路上@Amos8 小时前
Linux 命令行查看 串口hex数据
linux·运维·服务器
人工智能训练8 小时前
Linux 系统核心快捷键表(可打印版)
linux·运维·服务器·人工智能·ubuntu·容器·openeuler
Vanranrr9 小时前
C++临时对象与悬空指针:一个导致资源加载失败的隐藏陷阱
服务器·c++·算法
dualven_in_csdn10 小时前
【疑难问题】某些win11机器 网卡统计也会引起dns client 占用cpu问题
运维·服务器·网络