网络性能瓶颈：带宽不是元凶，延迟才是

"网络很慢"是史上最没用的故障报告之一，因为"慢"可能来自六个截然不同的原因，而大家的本能反应——砸带宽——几乎解决不了什么问题。大多数网络瓶颈不是带宽不足，而是更具体的东西，找到真正的瓶颈永远比瞎猜强。下面就来巡检一下瓶颈真正藏在哪里，以及如何发现它们。

瓶颈一：是延迟，不是带宽

最常见的误判。带宽是你一次能搬运多少数据，延迟是每次往返要多久，两者完全不是一回事。团队看到系统慢就去买更多带宽，结果毫无作用，因为问题从头到尾都是延迟。

判断方法是：如果你传大文件没问题，但交互操作感觉很卡，那就是延迟问题，不是带宽问题。带宽问题表现为传大量数据很慢；延迟问题表现为所有东西都感觉很迟钝，尤其是那些需要多次往返的频繁通信，因为每一次往返都要付一次延迟的代价。在砸钱买带宽之前，先搞清楚你到底是哪一种——如果是延迟，多买的带宽就是白烧钱。

瓶颈二：话多的应用

这个和延迟相关，也往往是"网络很慢"背后真正的罪魁祸首。一个应用如果发出大量小型往返请求，每一个请求都要付一次延迟成本，累积起来就变成了明显的卡顿。网络可能完全健康，问题出在应用自己在上面聊太多了。

经典案例是 N+1 模式：先发一个请求获取列表，然后每个条目再发一个请求，把本该两三次往返搞定的事情变成几十次。解决方法跟网络完全无关，而是应用侧的问题——把请求批量起来，每次往返多拉取一些，停止那些废话。这件事值得早点查，因为经常被赖到网络头上，但其实是应用的问题、网络很健康。看看一个操作实际产生了多少次往返，如果是很多小请求，那就是你的瓶颈所在。

瓶颈三：链路饱和

有时候确实是容量问题——某条链路跑在或接近上限，所有共享这条链路的东西都会变慢。这是真实存在的，但关键是要确认它而不是假设它。看看利用率，慢的时候链路是不是真的跑在上限附近，还是游刃有余？只有链路真的饱和了，加容量才有帮助。假设饱和而不去查，就会买到根本解决不了问题的带宽，因为那条链路从来就不是瓶颈所在。

瓶颈四：单个过载的设备或路径

流量往往会汇聚到特定的设备或路径上，其中某一个可能成为堵点。某个设备处理量超出能力范围、某条路径是所有流量的必经之路、某台设备过载了。整个网络看起来都慢，但真正的瓶颈只是一个承压的组件。找到它的方法是看流量在哪里汇聚，以及是否有某个设备或路径已经打满而其他都还好。解决方法可能是重新分配流量或者疏通那一个点，而不是动其他任何东西。

瓶颈五：距离和部署位置

组件的部署位置本身就会造成任何带宽都解决不了的瓶颈。如果频繁互相通信的组件相隔很远——应用在一个地域、数据库在另一个地域——每次交互都要付一次距离造成的延迟，反复累积。瓶颈是架构、是部署位置，不是网络容量。解决方法是把频繁通信的组件拉近——同一个地域、同一可用区——而不是升级链路。如果你的慢和组件离它们通信对象很远高度相关，那部署位置就是瓶颈。

瓶颈六：过载的共享服务

有时候感觉像网络瓶颈，实际上是某个特定的共享服务被压垮了。DNS、某个中心服务、所有流量都经过的共享资源。当它撑不住时，所有依赖它的东西都会感觉慢，呈现出来的是全网变慢，但真正受限的是一个具体的服务。值得查一下大家都依赖的那些共享依赖，因为一个紧张的共享服务会让整个网络看起来都有病。

如何真正诊断而不是瞎猜

贯穿所有这些的主题是：不要猜，要测量。"网络很慢"需要变成"到底是哪个具体的东西是瓶颈"，而这需要去查看。通过症状模式判断是延迟还是带宽；查看链路是真的饱和了还是游刃有余；查看是否有单个设备或路径打满了；查看话多的应用是不是真正原因；查看距离和部署位置是否在反复制造延迟；查看共享服务是否被压垮了。每种有不同的解决方法，而这正是为什么对着一个模糊的"慢"投诉砸带宽往往什么都改变不了的原因。

先找到真正的瓶颈。它很少是大家一开始假设的那个，错误的解决方法既费钱又让人失望。