蚂蚁和互联网的故事

2016-10-17 11:13:00

要不要出去找吃的，出去多少只，对蚂蚁而言，这是必须面对的问题。

出去多了，有收获还好，没收获的话，浪费“蚁力”不说，江湖险恶，还有丧命的风险。

出去少了，虽不至于“不知有汉，无论魏晋”，但错过食物，减少收成，却是很有可能的。

虽简单，却是生死攸关的问题。生存是第一需求，但食物越多并不完全等价于存活得越久。后者要求的是性价比，是消耗较少资源，收集较多食物。

蚂蚁们给出了自己的答案。

这个答案不是“蚁后坐阵指挥，决胜千里”。蚁后虽有王后的名头，却不过是一只专门负责下蛋的蚂蚁，并没有什么“政治”权力。况且，也没有蚂蚁坐在门口清点和汇报布阵情况供它决策。

每当有蚂蚁带着食物载誉而归时，便会在洞口放下食物，和守候在那里的蚂蚁碰一碰那两根“小天线”。等待的蚂蚁是否出发，踏上冒险之旅，取决于这种交流的次数和间隔的时长。

一旦出发，不找到点什么，蚂蚁是不会轻易回家的。因此，周围的食物越多，回来得越频繁，就有越多的蚂蚁集结出发；食物越少，回来的次数也少，家里的蚂蚁就自觉省点力，不出去白忙活了。当然，回来的少，也可能是壮烈牺牲了，说明外面危险，还是按兵不动的好。

没有统筹兼顾，没有上传下达，个体的机械和无知，却构成了整体的灵活与英明。

这种方式，在蚂蚁界已经运行了几百万年，恐龙在的时候，它们在；恐龙不在的时候，它们依然在。人类在的时候，它们在；人类不在的时候，诅咒它们也不在……

你以为这是在讲蚂蚁觅食，但其实是在讲 TCP通信。TCP协议能够流行、成为整个互联网的基石，很重要的一点是它解决了之前一直存在的“拥塞崩溃”问题。解决此问题的一个措施是“拥塞控制”：

拥塞控制是一种用来调整传输控制协议（TCP）连接单次发送的分组数量（单次发送量，在英文文献和程序代码中常叫做cwnd）的算法。它通过增减单次发送量逐步调整，使之逼近当前网络的承载量。

我们要在事先不知道带宽，或带宽一直变化的情况下，完成通信又避免拥塞。

TCP发送数据包，好比蚂蚁外出觅食；返回确认符，好比蚂蚁带回食物。很快返回大量确认符，意味着带宽充足，允许发送更多数据包，好比大量蚂蚁回巢，表明食物充足，要多派人手出去抢运。反之亦然。如果根本不返回，发送和外出也将停止，对应TCP的超时。

第一只外出的蚂蚁是如何决定出去而不是留下呢？这其实不难，一开始总得有一批侦查员，先出去打探打探，为后续行动收集情报。因为只是侦查，所以数量不用也不宜太多。对应的是TCP控制拥塞的另一招——慢启动，服务器通过 TCP 连接初始化一个新的单次发送量 (cwnd)，将其值设置为一个系统设定的保守值。每次往返都令其翻倍(指数式增长)，进而迅速向有效带宽靠拢。

一个优秀的分布式系统是没有中央节点的分布式系统。神奇的自然选择造就了蚁群，这个优秀的分布式系统。

争气的是，我们并没有“抄袭”蚂蚁，而是独立发现这一算法，并应用在TCP协议中。