计算机网络学习笔记15--拥塞控制&TCP性能分析&传输层总结

本文深入探讨了网络拥塞控制的概念及其实现方法,包括拥塞的成因与代价、拥塞控制与流量控制的区别,以及端到端拥塞控制和网络辅助拥塞控制的具体实施策略。特别针对TCP拥塞控制进行了详细解析,介绍了其基本原理、慢启动策略、加性增-乘性减机制等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

https://www.bilibili.com/video/BV1Up411Z7hC?p=4&spm_id_from=pageDriver

如有错误之处请指出,谢谢!

目录

拥塞控制

拥塞(Congestion)

用色的成因和代价

场景1:分组时延太大

场景2:吞吐率降低

场景3

 Q为什么拥塞控制在传输层做

拥塞控制的方法

端到端拥塞控制

网络辅助的拥塞控制

ATM ABR拥塞控制

ABR:available bit rate

RM(resource management )cells

TCP拥塞控制

TCP拥塞控制的基本原理

加性增-乘性减:AIMD

 慢启动:SS

Loss事件的处理

总结

 TCP拥塞控制算法

 例题

 TCP性能分析

TCP吞吐率

例子

TCP的公平性

 公平性与UDP(TCP吃亏)

研究:对TCP有好的UDP

公平性与并发性TCP连接

例子:链路速率为R,已有9个连接

传输层总结


p53-p57

拥塞控制

拥塞(Congestion)

非正式定义:

太多发送主机发送了太多数据或者发送速度太快,以至于网络无法处理

表现:

分组丢失(路由器缓存溢出)

分组延迟过大(在路由器缓存中排队)

拥塞控制VS流量控制

可靠数据传输根据端到端符合个体利益,拥塞控制像是一个社会问题

流量控制是不要让接收方溢出,而拥塞控制是不要让网络溢出

A top-10 problem

用色的成因和代价

场景1:分组时延太大

路由器向C、D主机总带宽未C 

由于路由器有无限的缓存,不存在丢包,所以没有重传机制

左边的图表示吞吐率

因为共享带宽,输出最大带宽为C/2

右边的图表示时延

输入接近C/2时时延接近无限

 因为一直在排队,形成排队的速度大于处理的速度,越后面的分组等的时间越久

场景2:吞吐率降低

一个路由器有有限的buffer

Sender重传分组

 因为重传造成了资源的浪费

定时器与丢失叠加造成了更多的重传

场景3

 多跳产生了多个主机传输间的竞争

 Q为什么拥塞控制在传输层做

A应该是单个应用不知道其他应用是否也在发数据,所以就不能控制自己的发送速率。而多个应用的数据是汇总到传输层,所以传输层才知道数据是否太多

拥塞控制的方法

端到端拥塞控制

网络层不需要显式地提供支持

端系统通过观察loss,delay等网络行为判断是否发生拥塞

TCP采取这种方法

网络辅助的拥塞控制

路由器向发送方显式地反馈网络拥塞信息(端系统利用信息来调节)

简单的拥塞指示(1bit):SNA,DECbit,TCP/IP ECN,ATM

指示发送方应该采取何种速率

ATM ABR拥塞控制

ABR:available bit rate

弹性服务

如果发送方路径“underloaded”负载低:使用可用带宽

如果发送方路径拥塞:将发送方速率降到最低保障速率

RM(resource management )cells

穿插在data cells中间

发送方发送

交换机设置RM cell位(网络辅助)

      NI bit:rate不许增长

      CI bit:拥塞指示

RM cell由接收方返回给发送方(得到了路径上所有的交换机RM cell,并返回给发送方)

在RM cell中有显式地速率(ER)字段:两个字节

      拥塞的交换机可以将ER置为更低的值

     发送方获知路径所能支持的最小速率

数据cell中的EFCI位:拥塞的交换机将其设为1

如果RMcell前面的data cell的EFCI位被设为1,那么发送方在返回RM cell中置CI位

TCP拥塞控制

TCP拥塞控制的基本原理

Sender限制发送速率

设置一个变量叫拥塞窗口CongWin

 CongWin:

动态调整以改变发送速率

反应所感知到的网络拥塞

Q如何感知网络拥塞?

A

Loss事件=timeout或3个重复的ACK

发生loss事件后,发送方降低速率

Q如何合理的调整发送速率

A

加性增-乘性减:AIMD 拥塞避免机制

慢启动:SS

加性增-乘性减:AIMD

原理:逐渐增加发送速率,谨慎探测可用带宽,知道发生loss

方法:AIMD

Additive Increase:每个RTT将CongWin增大一个MSS-----拥塞避免

Multiplicative Decrease:发生loss后将CongWin减半

 慢启动:SS

TCP建立时,CongWin=1

eg:MSS=500 byte,RTT=200ms

初始速率=20kbps

可用带宽可能远远高于初始速率

希望快速增长

原理:

 当连接开始时,指数型增长

 每个RTT将CongWin翻倍

收到每个ACK进行操作

初始速率很慢,但是快速攀升

Q何时应该指数性增长切换线性增长(拥塞避免)?

当CongWin达到Loss事件前值的1/2时 

实现方法:

变量Threshold

Loss事件发生时,Threshold被设为Loss事件前CongWin值的1/2

蓝色为TCP早期版本:重新进入慢启动

黑色为后来版本:慢启动后,执行加性增-乘性减

Loss事件的处理

 3个重复的ACKs:

CongWin切到一半

然后线性增长

Timeout事件:

CongWin直接设为1个MSS

然后指数增长

到达threshold后,再线性增长

Q为什么两个处理不同

3个重复ACKs表示网络还能够传输一些segments

timeout事件表明拥塞更为严重

总结

当CongWin低于Threshold,发送方处于慢启动阶段,CongWin指数增长

当CongWin大于Threshold,发送方处于拥塞避免阶段,CongWin线性增长

当收到3个重复ACKs时,Threshold减为原来CongWin的一半,CongWin=Threshold

当timeout时,Threshold减为原来CongWin的一半,CongWin=1

 TCP拥塞控制算法

rate≈CongWin/RTT,流水线机制一个RTT可能收到多个ACK,对于每个ACKCongWin+1,速率就成倍增长了

 例题

 TCP性能分析

TCP吞吐率

例子

 Q:TCP在未来是否还适用

 TCP连接丢包率极低,对链路的设计要求极高

TCP的设计有些参数不满足当今某些硬件需求了

高速网络下需要设计新的TCP

TCP的公平性

TCP是公平的

 细线:最终TCP吞吐率相等

粗线:限制了整个带宽的瓶颈带宽R

 

 公平性与UDP(TCP吃亏)

多媒体应用通常不使用TCP,以免被拥塞控制机制限制速率

使用UDP:以恒定速率发送,能够容忍丢失

产生了不公平

研究:对TCP有好的UDP

公平性与并发性TCP连接

 某些应用会打开多个并发连接

Web浏览器

产生公平性问题

例子:链路速率为R,已有9个连接

新来的应用请求1个TCP,获得R/10的速率

新来的应用请求11个TCP,获得R/2的速率

传输层总结

为什么要开发Tcpdive        在过去的几年里,随着移动互联网的飞速发展,整个基础网络已经发生了翻天覆地的变化。  用户接入网络的方式,除了宽带和光纤之外,还有2G/3G/4G/WiFi,5G也已经在路上了。  作为使用范围最广的传输层协议,TCP诞生于固网时代,在设计之初并没有考虑到上述种种情况,  这导致了它在某些场景下,性能并不是最优的。因此大多数的CDN厂商和一些规模较大的互联网公司都会  进行TCP协议的优化,以提供更好的用户体验,如更快的访问速度,更低的访问失败率,更流畅的视频播放等。 而当我们尝试优化TCP协议时,却面临着不少难点: 可用的工具少。  和TCP相关的工具,比如tcpdump,netstat和ss,虽然很好用,但是使用场景并不是TCP协议的性能评测,  能够提供的性能信息实在有限。 依靠个人感觉,进行盲试。  不知道瓶颈在哪,盲目修改,或者直接套用已有的优化方法。  盲目修改常导致徒劳无功,直接套用现成的方法,由于大家的应用场景不尽相同,也不一定有效。 测试成本高。  对TCP协议的性能评测主要采用两种方法。  一种是通过对上层应用的测试,来评估TCP协议的性能。这种方法的评价指标有限,而且是上层应用相关的。  另一种是依靠第三方测试服务。这种方式的样本量有限,且成本较高。 无法准确地评价优化效果。  上述的两种测试方法,都涉及到应用层面,因此测量的不仅仅是TCP协议本身,还参杂了干扰因素。   Tcpdive的设计目标        针对上述问题,我们决定设计一个专门的TCP协议性能评测工具,也就是Tcpdive。  之所以起这个名字,是因为dive有深入研究的意思:) Tcpdive具有一些特性,实际上也是我们的设计目标: 对TCP协议的性能进行较为全面的刻画,有助于发现瓶颈。  如此一来,就能找到痛点,不用再盲目地进行优化。 易于部署和使用,无需改动生产环境,使用成本低。  这一点非常重要,因为不需要修改内核或者应用程序,比较容易推广。 独立于上层应用,能够准确地评价优化效果。  直接对TCP协议的性能进行刻画,而不依赖于具体的应用。  因此能够排除上层应用的干扰,量化地评价优化效果。   Tcpdive的基本原理        Tcpdive是基于linux内核的探测点机制,使用systemtap脚本语言和内嵌C代码来实现的。  通过定义几类相互关联的探测点和库函数,来收集和处理运行中内核的数据,以及修改内核的处理逻辑。         为什么要基于systemtap呢?systemtap的神奇之处在于,不修改内核的情况下就能获取内核中的任何信息, 还可以修改内核的处理逻辑。所以虽然被它虐了千百遍,但还是觉得这套探测点机制非常有用。当然它也不是 十全十美的,比如作为一种调试语言,它是够用的,但是把它用作一种开发语言,则会遇到不少问题。通过不 断的尝试,大多数问题最终都获得比较好的解决。         目前Tcpdive已经部署到作为流量入口的负载均衡服务器上,在新浪的线上环境7*24h运行,可以说是比较稳定的。 Tcpdive的主要功能 作为一个TCP协议的性能评测工具,Tcpdive提供了大量的性能指标,从以下维度来对每条TCP连接进行刻画: 传输情况 丢包和重传 拥塞控制 HTTP处理   传输:   损失和重传: 拥塞控制: HTTP 处理:     标签:tcpdive
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

软糖工程001

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值