下雨,正则安喝完奶睡了,小小在补她那由于拖延而必须在今天下午完成的数学作业,疯子正好趁此睡一会儿,她带两个孩子,太累了。
而我,作文。
交换式以太网,IP路由互联网,PCIe总线,这些都不再是 共享资源的随机系统 了,它们都进化成了 排队系统 ,如今这种共享资源的随机系统,只剩下了TCP!
由于人们已经不再记得CSMA/CD,绝大多数人对TCP存在跪舔式的误解,我还是一如既往地喜欢喷TCP!但本文不是。本文没时间扯TCP,没意思。
一个共享资源的随机系统,什么最重要?是性能,还是公平性?业内普遍的结论是公平性,这才招致了很多人剑走偏锋在性能上走火入魔,比如TCP加速这种。但凡优化性能的,就一定会损失公平性,然而,who care…
二进制指数退避算法,就是共享资源随机系统的一个伟大的算法。
记得刚学计算机网络课程的时候,讲过CSMA/CD算法,这是一个共享总线式的随机协同系统,没有控制中心安排节点发送数据的顺序,大家也都彼此不沟通,然而神奇的是, 所有节点 想什么时候发送数据就能什么时候发送,只要在发现冲突后遵循指数退避等待相应的时间后再重发即可!
这个指数退避规则很简单,本文不会详细描述,直接百度一下就好。
后来,我们学习了TCP协议,并且任何教科书上都会讲到TCP超时定时器的处理,最终我们学到了, TCP超时时间也是指数退避的。
TCP和早期共享总线以太网貌似八竿子打不着,但是却遵循了同样一个指数级退避原则,这里面必有关联。
后来,哦,不,是直到很久以后,我们觉得TCP是个端到端主机协议,对于真正的网络而言,它和早期的供共享总线的以太网对链路的认知一样,就是个盲人。
所以,我们可以把整个互联网看作是一个共享总线(实际上是共享带宽)的以太网,TCP节点节点就是CSMA/CD的主机,TCP节点之间互相不沟通,但是它们却和CSMA/CD系统的主机一样,想什么时候发送就什么时候发送,只要遵循 退避原则 即可。
- 对于CSMA/CD以太网而言,冲突意味着要退避;
- 对于TCP而言,超时意味着要退避(至于什么快速重传,那是后来的事情,一开始只有超时!)。
现在问题来了, 退避为什么要指数级退避,而不是减法退避,或者乘以某个系数退避?
这个问题,此后再也不好找答案。
不信你去搜搜,看看有没有解释这个,如此简单的事实却没有人从数学上去解释…
本文,我来通俗解释二进制指数退避算法的缘由。即为什么是二进制指数退避,而不是减法退避,也不是固定系数乘法退避。
当知道了二进制退避算法的具体操作之后,谁还会在乎Why呢?知道Why并不会多赚钱,不会晋升,也不会让老婆称赞…
但是知道Why,会使人开心。
二进制退避算法,其实换个名字,就很好理解了,那就是 确定系统中的节点数量,并找到自己的slot。
是的, 节点
i
i
i在和一群互相不通信不沟通的系统
n
n
n个节点的资源争抢博弈中,找到自己
s
l
o
t
i
slot_i
sloti。
为什么是二进制指数退避,要先从二分法说起。不要纠结于什么二进制指数退避这种名子,所谓的二进制指数退避,你就把它当成 二分法探测 就好了。
系统中的节点是彼此不沟通的,没有任何一个节点知道系统的全局情况,这是一个真正随机的分布式系统。
一开始,节点
n
n
n假设整个系统只有节点
n
n
n自己,这是一个初始状态,于是它开始直接使用共享资源,忽略其它节点的存在,直到一个 冲突事件 将其纠正。
节点
n
n
n检测了冲突,以太网冲突信号或者TCP超时,它怎么办呢?
它理所当然会认为 系统中至少还存在着另外一个节点。 于是节点
n
n
n会把自认为全部属于自己的资源让出一半给这个想象中的竞争者。于是,节点
n
n
n的资源降低为之前的一半试试看。
同样收到冲突信号的另一个节点也会相应地假设。
现在假设总资源分别被如二者分成了两份,那么两个节点该如何判断哪一份是属于自己的呢?由于系统运作的前提是所有节点彼此不沟通,那么,最好的方案就是 随机 。即:
两个节点随意使用一共2个slot的资源。
这样两个节点共享两个slot,它们还是有冲突的可能,它们有
50
%
50\%
50%的可能会争抢同一个slot…
问题是,像这样,两个节点再次出现冲突,怎么办?
答案只能是(算法的要求,为什么?这点后面会说)继续二分退避。此时冲突的概率就降低到了
25
%
25\%
25%,如果再次冲突,就再次二分退避,冲突概率继续降低到
12.5
%
12.5\%
12.5%…
两个节点的情况下,如此反复,最终,两个节点之间不冲突的概率随着冲突次数而降低,序列就是
(
1
−
1
2
)
,
(
1
−
1
4
)
,
(
1
−
1
8
)
,
.
.
.
,
(
≈
1
)
(1-\dfrac{1}{2}),(1-\dfrac{1}{4}),(1-\dfrac{1}{8}),... ,(\approx 1)
(1−21),(1−41),(1−81),...,(≈1),即 如果继续二分切分资源,互不沟通的两个节点总会不冲突把数据发送成功的!
第一个推论已经完成。就像做菜一样,放在一边,备用。
接下来继续分析。我来推倒多米诺骨牌。
事实上,由于每个节点对系统的理解都是局部的,没有任何节点具有全局视图,因此,没有哪个节点知道系统中一共有多少节点。
当节点在第一次检测到冲突后退避了一半的资源之后再次检测到冲突,该节点无法分辨下面的两种情况:
- 和唯一另外的节点再次以
50
%
50\%
- 出现了第三个节点,并与其发生了冲突。
根据以上分析,当第一种情况发生时,按照二进制指数减半资源的使用,是可以趋向于成功抢占资源的。那么问题就是第二种情况如何处理。
最优美的答案就是唯一的答案, 那就是和第一种情况一样,既然无法区分两种情况,那就全部当成第一种情况!
如果出现第三个节点,由于随机协作系统所有节点都是公平对等的,所有 这第三个节点对于既有的两个节点的影响是均等的。 也就是说,既有的每一个节点均需要 假设有一个新的节点与之竞争。 这个新的节点对既有的两个节点的影响,在 概率上 是相等的。按照协作系统公平性假设,检测到冲突的节点就需要出让一半的资源给潜在的竞争者。
- 如果某个节点第一次遭遇冲突,那么它假设检测到第
1
1
1
2
\dfrac{1}{2}
- 在承诺的
1
2
\dfrac{1}{2}
2
2
1
4
\dfrac{1}{4}
- 在承诺的
1
4
\dfrac{1}{4}
3
3
1
8
\dfrac{1}{8}
- …
把这个基本事实归纳下去。所以,结论就是:
不管系统中当前有多少(
≥
2
\geq2
≥2)节点,只要检测到冲突(CSMA/CD检测到冲突信号,或者TCP超时),检测节点均要假设有一个节点与之进行公平对等竞争,检测节点均需要分配一半资源给与之冲突的节点:
假设
k
k
k为冲突次数,那么节点需要退避到的资源使用率就是
(
1
2
)
k
(\dfrac{1}{2})^k
(21)k,由于网络分层协议的保证,为了保证效率,
k
k
k一般会有最大值约束,超过该最值,则传输放弃。
以上这些话,就是 二进制指数退避算法 的具体操作要旨!
理解了上面的描述,对于理解 为什么是减半,而不是减1 就很容易了。这是因为,只有减半才能让系统平衡。
二进制指数退避算法,只是共享资源的随机系统中的 一种可行的确保稳定的算法,而不是最高效的算法。
CSMA/CD的冲突检测退避算法就是一个简单的优化。它采用了 再随机算法 平滑了误判的影响。
所谓的误判,就是上面两点之间的误判,重复一遍:
- 和唯一另外的节点再次以
50
%
50\%
- 出现了第三个节点,并与其发生了冲突。
所以,假设一个节点已经经历了
i
i
i次冲突,按照二进制指数退避算法,它理应退避到
(
1
2
)
i
(\dfrac{1}{2})^i
(21)i的资源使用,然而搞不好其它所有节点都是新来的呢,所以,大家再次随机,让每个检测到冲突的节点,在
{
0
,
1
2
,
.
.
.
(
1
2
)
k
}
\{0,\dfrac{1}{2},...(\dfrac{1}{2})^k\}
{0,21,...(21)k}中随机选择一个作为资源退避的份额即可。
总结来讲, 二进制指数退避算法 ,如果不叫这个名字,改作 二分法资源探测算法 ,我想就更加容易被理解了。你要明白,适用这个算法的系统,必须有以下特征:
- 节点随机使用资源;
- 节点完全公平对等;
- 节点间互不知情。
同时,我们要知道,正是因为上述的第3点解耦合带来的灵活性,造成了:
- 二进制指数退避算法不是最优的。
但是,无论如何,它是:
- 公平的;
- 稳定的。
所以,它是:
- 优美的!
此外,所有的共享总线资源随机分布式系统,均可以转化为排队系统,比如:
- 总线式以太网转换为交换式以太网
- PCI总线转换为PCIe总线
- 缓存一致性协议中的写操作
- …
只有IP路由网络,一开始就是排队系统…
无论是哪种,它们的核心都是 资源的统计复用。
当然了,我知道有人会觉得我这天天分析这种简单又不赚钱不讨好的东西,很low,没关系,我觉得你也很low,人各有所好,不可强求,不在一个频道上,所以我也不屑交流。
我敢肯定,绝大多数人是不懂这些东西的,网上也很少几乎没有人去分析,所以,我想帮助这些希望获得答案的人。仅此。
浙江温州,皮,鞋湿,
下雨,进水,不会,胖。
原文链接: https://blog.csdn.net/dog250/article/details/90340322
欢迎关注
微信关注下方公众号,第一时间获取干货硬货;公众号内回复【pdf】免费获取数百本计算机经典书籍;
也有高质量的技术群,里面有嵌入式、搜广推等BAT大佬
原创文章受到原创版权保护。转载请注明出处:https://www.ccppcoding.com/archives/406565
非原创文章文中已经注明原地址,如有侵权,联系删除
关注公众号【高性能架构探索】,第一时间获取最新文章
转载文章受原作者版权保护。转载请注明原作者出处!