时延抖动和通信的本质

简介: 时延抖动和通信的本质

先从网络时延抖动的根源说起。

信息能否过去取决于信道容量,而信道利用率则取决于编码。这是香农定律决定的。

考虑到主机处理非常快,忽略处理时延,端到端时延就是信息传播时延,但现实中通信信道利用率非常不均匀,统计复用的意思是,某些时刻信息量太大以至信道过载,某些时刻信息量过小导致信道轻载甚至空载,因此引入少量 buffer 平滑这种统计波动,同时提高信息到达率和信道利用率。

关于统计复用网络的全部就以上这么多,抖动则来源于对以上描述具体操作时的弄巧成拙。

信息在链路某处若超过信道容量一定过不去,问题的核心是在实际有空闲容量资源发送它前你最多容忍多久,而这恰恰不由你决定,它不仅由 buffer 大小决定,还由通信协议决定。

buffer 过大导致的排队时延是不得已的,你的应用对 0~buffer_size/bw 的时延抖动无能为力。只能寄希望于设备厂商压缩 buffer 大小。

协议时延分端到端协议抖动和底层协议抖动,而端到端协议抖动可以避开。比如应用层自己都认为可以丢弃的数据,tcp 却擅作主张非要死命重传而引入至少 rtt 量级的时延抖动,这时就可以选择 udp 进行有损传输。

底层协议抖动比较难避开。比如 wifi 提供一种尽力而为的传输服务,如果传输一帧时出现冲突,wifi 会自行重试多次而引入 0~n*10ms 级的时延抖动,即使应用层并不需要这种努力也不行。

网络中或大或小的 buffer,网络边缘的无线 wifi,再加上使用了 tcp,都是抖动的根源,端到端时延不可能稳定,解决问题的方法很简单,在应用层加 buffer,这才是问题的实质,buffer 带来的问题通过再加一个 buffer 就能解决,重读上面的 3 个段落,可将 buffer 分两类,常规意义上的交换机可排队 buffer 算空间类,而 tcp,wifi 类的重传,重试行为算时间类,两类 buffer 共同引入了时延抖动。

buffer 引入的时延抖动显然是一种统计波动,而统计波动只要一个 buffer 就能平滑,这不,圆回来了一个圈。

最近帮朋友做一个无 buffer 协议,顺带着就聊聊 buffer 的本质。无 buffer 协议是一个非常简单的传输协议,“信息能否过去取决于信道容量,而信道利用率则取决于编码。” 没 buffer 什么事,意思是如果过不去就随他,能过多少是多少,通过编码来完全或部分恢复丢失的信息,这便是一个无抖动的 有损传输协议,这也是信息传输的本质需求,它从来不要求 100% 高保真,本质上有损的传输,为什么用时间来抵偿呢。

为啥长链路吞吐干不过短链路,困扰程序员多年的长肥管道问题,都能用香农公式说明白,信道容量和带宽 B 和信噪比 S/N 正相关,随着链路长度增加,B,S 不变,N 在增加,S/N 减小。印证我之前文章里另一种解释,随链路长度增加,好事发生的概率是各好事的概率相乘,坏事则是各概率相加,就殊途同归了。

计算机网络不讲这个,但本质上还是这个。计算机网络讲的是在目标处 100% 保真重现源信息,又不能违背香农自然律,就必须用协议靠时间去弥补信道固有损失,吞吐 = 保真数据量/时间,无论在数据中加冗余,还是抵偿了时间,表现都是降低了吞吐。

用空间换时间,提高信噪比,用冗余编码确保信息保真,带宽不满足时等一会儿再发,信息丢失了重新发一遍,这些其实都是在对抗不了香农定律后试图弥补损耗的不同方法,但计算机网络围绕基于 buffer 的 “包交换”,也就是统计复用的分组交换技术展开,因此后两种方法值得关注,其中,buffer 是核心。 有趣的是,包交换之前的打电话恰恰相反,因此你听到的电话那头的声音明显失真,但绝不卡顿。

明显失真,但绝不卡顿,看上去不错,但计算机网络却是明显卡顿,但绝不失真。

来看 buffer 的本质。

把 buffer 看作一种信用货币,而带宽则是我们买东西的实际货币,就好理解了。现代社会,实际货币也算信用货币,就像 bdp = bw * proprt + buffer 一样。通俗讲,信用货币就是每一元的币值不必对应某种等价物 比如黄金,而可以 “凭信用” 发行货币,只要拿到货币的人可以偿还等值就行。

相关文章
|
运维 监控 网络协议
使用netperf测试网络时延
使用netperf测试网络时延
1369 1
|
网络协议 网络架构
广播是否不会增加网络通信量?
广播是否不会增加网络通信量?
56 0
|
3月前
|
监控 网络协议 安全
|
弹性计算 网络协议 算法
记一次典型的TCP传输吞吐效率问题
客户在ECS上实现了一个供小图片上传的接口,通过高防->SLB->ECS的网络链路将接口发布给终端用户,但是发现上传的速率很不理想。初看起来像是高防问题,但是通过排查最终发现这是一个典型的TCP传输吞吐量问题,并且是由于后端服务器端的配置而引起,在此记录下排查过程和相关原理。
记一次典型的TCP传输吞吐效率问题
|
4月前
|
自动驾驶 算法 5G
5G中的超可靠低延迟通信(URLLC)
【8月更文挑战第31天】
634 0
|
6月前
计算机网络——计算机网络的性能指标(上)-速率、带宽、吞吐量、时延
计算机网络——计算机网络的性能指标(上)-速率、带宽、吞吐量、时延
185 1
|
6月前
|
缓存 网络架构
计算机网络——数据链路层-可靠传输的实现机制:停止-等待协议SW(确认与否认、超时重传等,信道利用率及相关练习题)
计算机网络——数据链路层-可靠传输的实现机制:停止-等待协议SW(确认与否认、超时重传等,信道利用率及相关练习题)
133 0
|
7月前
|
存储 网络协议 数据中心
|
7月前
|
网络协议 网络安全 区块链
常见网络延迟测量方法
常见网络延迟测量方法
449 0
|
缓存 NoSQL 应用服务中间件
零拷贝并非万能解决方案:重新定义数据传输的效率极限
本文讨论了零拷贝在优化数据传输效率方面的局限性。尽管零拷贝技术在减少数据传输过程中的内存拷贝次数方面有很大的优势,但它并非适用于所有情况。文章介绍了一些其他的优化方法,如异步I/O和直接I/O的组合、根据文件大小选择不同的优化方式。至此,我们的计算机基础专栏就结束了,不知道大家有没有发现,操作系统底层提供了丰富的解决方案来支持应用程序的复杂性和可扩展性。对于任何工作中遇到的问题,我们都可以从操作系统的角度寻找解决方法。
145 0
零拷贝并非万能解决方案:重新定义数据传输的效率极限