为什么不能基于流量或时延做路由度量，而不仅仅基于跳数。原因在于这里存在一个自反馈：

• 路由决策导致流量变化；
• 时延由流量变化而变化；
• 流量时延影响路由决策。

当某条链路流量减少时，路由协议会将其度量调低，这便吸引更多流量，导致该链路再次拥塞，从而引发持续震荡。特别是：

• 如果感知和更新的时间尺度短于流量变化的时间尺度，路由协议会对短暂的流量波动做出过度反应，加剧震荡；
• 如果感知和更新的时间尺度大于流量变化的时间尺度，路由协议将使用过期信息做路由决策，导致路由与实际状态不一致，影响路由稳定性。

因此，一般而言路由决策都会选择相对稳定和独立的度量，比如跳数，然后辅助以流量工程(MPLS-TE，SR-TE，SDN 等)来保证服务质量。这里的核心是，流量引导必须独立于路由协议本身，这是摆脱自反馈的唯一途径，从而有效避免流量颠簸。

以上的道理在做计算机网络的圈子里是人皆知，但延伸到交通网络却不能举一反三了。

河南穷游(关于去程，参考 https://blog.csdn.net/dog250/article/details/145357711)，从洛阳出发返回上海，经停亳州，导航给出了最佳路径，走宁洛高速，为了避开南京，我手工切换到了盐洛高速，然而大约上午 10 点，导航 “发现了更好路径，节省 20 分钟”，询问是否切换。总之，导航死活都要让我走宁洛，但我死活坚持走盐洛。果不其然，盐洛一路畅通，到了下午时，宁洛南京附近开始由黄色变声深红。

宁洛，路径最短，大众常选，盐洛，稍远，如何决策。上午 10 点钟，宁洛南京附近持续绿色畅通，如此相比盐洛而言肯定快 20 分钟左右，但这只是 “此时” 的状态，当我下午到达南京附近时，这个 “此时状态” 显然是一个滞后好几个小时的 “过时” 信息，过时信息怎么能做路由决策呢？

如果按照长程依赖的统计特征做流量工程，这个导航决策就非常容易了。如果根据长期信息做统计，识别到 “南京附近逢下午必堵” 这个模式，导航就不会建议我切换到宁洛了，因为它显然根据历史信息 “预测” 到了未来的拥堵。

但这个根据统计信息的预测功能几乎没人做，不光导航产品没有，TCP/IP 拥塞控制领域也没人做。原因可能跟理工背景从业者受到的训练方式有关，执着于实时和精确，而不是偏好历史和统计，难以接受概率和随机。

总有人赞同不合理的设计，因为只有不合理的设计时，大家就习惯了不合理。我老婆争论说她很喜欢这个建议更好路径的功能，觉得很有用。我认为大多数人离了导航回不了家并非夸大其辞，大多数人是看不懂地图的，这意味着他们没有能力独立于流量做路由决策，只能看别人怎么走自己跟随，他们没有能力决策，因此需要某种指示，这是社会分工的自然结果，没什么不好，但这显然对提供指示的导航提出了更好的要求。

导航的问题在于，它没有摆脱自反馈，因此它制造了拥堵(它把相同的状态反馈给所有客户端，进而造成流量聚集)。我问我老婆，如果现在只有一个机会切换到宁洛，后面切不回来了，如何，前面拐还是不拐，相信实时的导航还是相信没事就看地图看路况的我。到了宿州段，看到长三角牌的车纷纷右上匝道拐入 G3 京台高速，我就暗笑，这波流量正是造成下午南京附近拥堵的流量，昨天这样，今天如此，明后天依旧。

但 KPI，绩效考核难崩，稳定好用的导航一定是简单的，几乎所有玩花活儿的功能都是为了做而做，把事情弄巧成拙后再用另一个类似的花活儿来修正，于是就是两个功能，加之对实时和精确的执着以及对统计复用和长程依赖的偏见，总之，系统和产品永远难以稳定。

我曾经建议用每天特定时间段改一套参数或切一个算法替换修改拥塞控制算法代码的建议被否决，经理的理由是 “状态需要实时计算”，“历史信息是过时的”，照这么说，所有信息都是历史信息，根本就不存在实时信息，然而事实是，人们的行为并非完全随机的，在长时间尺度看，完全是可预测的，正如每个人的生活都很规律一样，所有人行为的合集也很规律，流量也是，不管是交通流量，还是 TCP/IP 网络流量。

浙江温州皮鞋湿，下雨进水不会胖。