通信工程毕设可以做网站吗,网站建设情况,属于免费推广的方式是,莱钢建设网站拥塞控制算法只与本地有关
一个TCP会话使用的拥塞控制算法只与本地有关。 两个TCP系统可以在TCP会话的两端使用不同的拥塞控制算法
Bottleneck Bandwidth and Round-trip time
Bottleneck 瓶颈 BBR models the network to send as fast as the available bandwidth and is 2…拥塞控制算法只与本地有关
一个TCP会话使用的拥塞控制算法只与本地有关。 两个TCP系统可以在TCP会话的两端使用不同的拥塞控制算法
Bottleneck Bandwidth and Round-trip time
Bottleneck 瓶颈 BBR models the network to send as fast as the available bandwidth and is 2700x faster than previous TCPs on a 10Gb, 100ms link with 1% loss. BBR powers google.com, youtube.com and apps using Google Cloud Platform services.
旧网络拥塞只要丢包就代表网络环境不好 tcp默认的cubic拥塞控制算法频繁上下调整滑动窗口大小锯齿状 bbr倾向于平稳发送在实际带宽比较平稳的场景下吞吐量更大
tcp为什么没有解决这个问题 tcp在linux内核里升级太困难。 tcp的一些约束导致rtt算不准比如ack delay、重传包的seq number不变
cubic: 基于丢包锯齿形吞吐事件驱动 tcp的重传包seqId不变rtt算不准tcp的ack delay时间影响rtt计算默认40ms bbr: 基于延迟 有平滑区间根据rtt建立对带宽窗口大小的模型再加上定时器quic的重传包seqId增加编号idrtt算得准。区分了具体的重传类型。
bbr当rtt开始增长时就达到了最大带宽 cubic把缓存塞满一直到丢包对丢包率的容忍非常低即使只有极少的丢包吞吐量也会急剧下降
相关命令
在Linux 下检查当前可用的拥塞算法 sysctl net.ipv4.tcp_available_congestion_control 比如reno cubic bbr bbr2 hybla highspeed htcp veno westwood vegas
当前使用了哪一种拥塞算法 sysctl net.ipv4.tcp_congestion_control
sudo tc qdisc replace dev eth0 root netem latency 50ms 在两台服务器的收发每个方向增加50ms的延迟。
sudo tc qdisc del dev eth0 root 取消上述的设置
sudo sysctl -w net.ipv4.tcp_congestion_controlcubic sudo sysctl -w net.ipv4.tcp_congestion_controlbbr sudo sysctl -w net.ipv4.tcp_congestion_controlbbr2 修改本机的拥控算法
sudo tc qdisc replace dev eth0 root netem loss 1.5% latency 50ms 在两台服务器的收发每个方向增加50ms的延迟 1.%的丢包
实验
作者在TCP上实验 作者这个图画的有点问题应该是先确定loss再传输特定数量包统计不同拥塞控制算法的吞吐量和时延 Andree Toonk 在他的博客中验证了了使用不同拥塞控制算法、延迟和丢包参数所做的各种TCP吞吐量测试的全套测试证明了在一定的丢包率1.5%、3%的情况下BBR的出色表现 测试显示了丢包和延迟对TCP吞吐量的巨大影响。在一个高延迟的路径上仅仅是少量的数据包丢失1.5%就会产生了巨大的影响。在这些较长的路径上使用除BBR以外的任何其他技术当出现哪怕是少量的丢包时都会造成很大的问题。也只有BBR在任何超过1.5%的丢包损失时都能保持一个不错的吞吐量数字。
BBR使用场景
网络在没有丢包的情况下Cubic和BBR对于这些较长时延的链路都有很好的表现。而在中度丢包的情况下BBR的表现就非常突出。
为什么要针对丢包情况而进行优化 场景在不同的地方放置有服务器需要在系统或者服务器之间有源源不断的数据传输。例如日志文件、数据库同步、业务数据的异地备份等等。在复杂的网络环境下会因为各种原因而出现丢包的情况。在这种场景下BBR将会大放异彩帮助维护更好的网络数据传输。
BBR对所谓的“长肥网络”带宽延迟积大、丢包率高的网络非常有效在CDN和视频应用等场景下也被证明有很好的表现。 事实上Youtube、Spotify和Dropbox大规模应用BBR已经有了很多的积累。这主要是因为BBR会积极地提升到最佳发送速率。
BBR缺点
wifi环境高抖动和波动导致网速变慢
算不准实时可用带宽/RTT就会导致流量偏大/偏小说白了就是计划赶不上变化
BBR算法以估测瓶颈带宽和RTT来调整发送速率这种机制在高波动和不稳定的无线环境中可能表现不佳。 带宽估测误差在WiFi环境中实际的瓶颈带宽可能变化频繁BBR的带宽估测如若不准确会导致发送速率偏高或偏低。 RTT测量波动高抖动和噪声引入的RTT测量误差容易导致BBR无法准确捕捉真实网络状况丢包和重传情况增加。
BBR依赖于精确的带宽估测和RTT测量来调整发送速率但WiFi网络中的抖动Jitter和信号波动会对这些测量造成干扰 高实时抖动WiFi信号质量因周围环境如物理障碍、干扰设备、用户密度等波动较大导致RTT和带宽测量的不稳定 不可预测的丢包WiFi网络中的随机丢包而非拥塞引起的丢包会导致BBR误判网络状况影响其测量和调整
拥塞和无线信道竞争
使用相同无线信道下的争抢导致更糟
WiFi网络中用户与用户之间使用相同无线信道会出现频繁的竞争和碰撞带来额外的传输延迟和带宽波动 共享信道在高密度用户环境中多用户竞争同一个无线信道资源相互干扰导致实际可用带宽降低。 复用性差WiFi采用CSMA/CACarrier Sense Multiple Access with Collision Avoidance高负载下其复用性差增加拥塞和排队时延
拥塞控制与公平性
高效利用带宽但挤占cubic算法带宽
BBR设计目标高效利用带宽 在WiFi环境中未必能与其它传统拥塞控制算法如Cubic的流量公平发挥作用
Aggressive的探测行为BBR在初期阶段会探测更高的发送速率可能导致瞬时拥塞丢包率增加反而影响到实际传输性能 对竞争流的不友好BBR可能在多用户共享信道条件下显得不够温和导致竞争流公平性问题影响整体网络性能。
BBR会导致高重传率
拥塞窗口计算方式
BBR的拥塞控制逻辑基于其对网络带宽和RTT的估计这与传统TCP拥塞控制算法如Cubic或Reno不同 发送速率高BBR本质上是激进的它尝试利用尽可能多的带宽。当BBR认为有较高带宽时它会快速增加发送速率。如果网络没有足够的带宽来支持这个速率就会导致队列溢出和丢包。 突发流量由于BBR在探测瓶颈带宽的过程中可能会发送短时高峰流量容易在网络中产生突发拥塞导致包丢失和重传。
RTT估算的敏感性
BBR依赖于RTT的精确测量来调整发送速率但在高抖动网络中RTT的波动性会影响BBR的准确判断。 RTT波动在高抖动的网络中RTT测量的不稳定性会导致BBR频繁调整发送速率。如果RTT波动大BBR可能会误判当前网络状况导致不适当的发送速率调整增加了丢包和重传的概率
带宽探测机制
BBR通过探测高带宽以尽可能利用网络链路但是这种探测策略在某些情况下会增加丢包率和重传次数。 主动探测BBR会定期发送探测包来评估网络带宽这种主动探测行为在网络容量不足时会导致丢包。 过度带宽利用BBR的设计目标之一是高效利用可用带宽但在一些环境中如共享宽带或限带宽环境这个行为可能会引发频繁的拥塞和重传。
适应性反馈机制
传统TCP拥塞控制算法如Reno和Cubic基于丢包或延时来调整拥塞窗口而BBR依赖于带宽和RTT估计这使得它在某些情况下面对高丢包率时的反应可能不够迅速和适应。 过度探测BBR的拥塞控制主要依据带宽估测一旦带宽估测过高而实际网络容量不足容易持续导致大量丢包。 反馈滞后网络负荷变化频繁时BBR的调整可能存在滞后。然而主流TCP算法在这种情况下可能会更快地收敛到较为稳定的状态。
优化建议
在WiFi环境中优化BBR算法
调整BBR参数 优化探测和测量周期适应更高抖动的网络环境。
使用混合控制机制 在WiFi环境中结合BBR和其他较为保守的拥塞控制算法如Cubic或Reno通过混合控制策略提高网络适应性
BBRv2
BBRv2的目标就是解决第一版中存在的一些主要缺点其改进包括了还使用聚合/运行中的参数增强了网络建模并增加了对ECN(显式拥塞通知)的支持等 ECN(显式拥塞通知)
附录
缓冲膨胀
网络设备/系统不必要地设计了过大缓冲区 当网络链路拥塞时就会发生缓冲膨胀从而导致数据包在这些超大缓冲区中排队很长时间 在先进先出队列系统中过大的缓冲区会导致更长的队列和更高的延迟并且不会提高网络吞吐量 bbr并不会试图填满缓冲区所以在避免缓冲区膨胀方面有更好表现
弱网环境,引入1.5%的丢包 cubic吞吐量下降99.7% bbr: 吞吐量下降45%
Cubic
一种较为温和的拥塞算法它使用三次函数作为其拥塞窗口的算法并且使用函数拐点作为拥塞窗口的设置值。 Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法。 今天所使用的绝大多数Linux 分发版本例如Ubuntu、Amazon Linux 等均将Cubic作为缺省的 TCP拥塞算法
iperf3
iperf3 是一个用于测量网路吞吐量的工具可以在网络性能测试中生成 TCP 和 UDP 流量负载。它被广泛用于测试网络的带宽和性能。
iperf3 -c 10.0.1.196 -p 8080
iperf3 用于启动 iperf3 客户端或服务器
-c 表示客户端模式。iperf3 可以运行在客户端模式和服务器模式中。这里的客户端模式用于发送流量到指定的服务器。
10.0.1.196 服务器的 IP 地址。在客户端模式下这个地址指定了要连接的 iperf3 服务器的 IP 地址
-p 8080 这个选项指定要连接的服务器的端口号
使用 iperf3 工具来启动一个客户端并连接到 IP 地址为 10.0.1.196端口为 8080 的 iperf3 服务器。 客户端会生成流量并发送到服务器从而对网络带宽和其他性能指标进行测试。
以下是一些常用的 iperf3 选项可以根据具体需求和测试目标来进行配置 -t指定测试的持续时间例如 -t 10 表示进行10秒的测试 -u使用UDP而不是默认的TCP协议进行测试 -b指定带宽比如UDP模式下可以使用-b 10M限制带宽为10Mbps -R反向测试在客户端接收流量而不是发送流量 -f指定输出格式例如 -f m 表示输出以兆比特为单位的结果
