Dreamer2q Blog
见到,不如不见
Dreamer2q

Code is cheap, talk is expensive

64日志

记一次网络丢包问题填坑过程

创建于 2022-05-22 共 1500 字,阅读约 6 分钟 更新于 39 天前
浏览 66评论 0

发现问题

最近几天发现宿舍电脑的远程使用体验越来越差劲了,已经达到了我不能容忍的地步了。达到什么程度呢?比十年前的 Android 手机体验还差劲(想象一下一个山寨的安卓机器,被安装了各种毒瘤应用的使用体验)。但是出于某些原因我又不得不使用它,因为手头丐版的 m1 air 属实太垃圾了,不能开太多东西,所以我大部分情况下都比较依赖 RDP 用来缓解电脑上的压力。

问题排查

遇到这种卡顿的问题往往和网络质量脱不了关系,因此我第一时间检查了我的网络环境,显然没有检查到什么问题,因此初步排除运营商的问题。加上宿舍最近网络情况非常的不稳定,基本断定是宿舍网络问题。


为了方便排查问题,我特意画了一个简陋的拓扑图。整个图比较复杂的点在于“openwrt”是一个旁路路由 (软路由),在“192.168.1.0/24”子网内有两个网关,每个网关有自己独立的“wan”出口,其中“openwrt”自带公网 IP,因此属于连回宿舍的入口。而名为”ac88u”的由于其有 8 个 Lan 口,因此兼具“路由”+“交换机”的角色。(以下简称“A”为“ac88u”,“B”为“openwrt”)

我的需求是通过 RDP 访问 PC 机器,通过“B”的入口链路会出现规律性的抖动(丢包),因此体验极其差劲;如果通过“A”则不会出现此问题。因此我初步怀疑问题在“B”这里:

由上图可以看得出来,丢包率居然高达 44%,说明“A”或者“B”肯定一个有问题。

其实这里应该就能看出来,问题很大可能出在“A”身上,因此流量是这样走的:“B”-->“A”-->“PC”。当时我已经被绕得挺晕的了,就一直没看出来。


后面我又测试从“A->(ping)->B”和“B->(ping)->A”,发现它们都有不小的丢包率,这次我是直接懵了,A 和 B 直接通过一条网线连接,中间没有经过任何的 hop 怎么会出现这种离谱的丢包率呢?难道是网线的问题吗?然后我还真就在舍友的帮助下一个一个对了一下网线的连接情况:

黄色网线是“Lan1”充当另一个”wan“口,Lan2 是“PC”,Lan5 是“B”。然后我发现一个问题,“PC”和“B”居然相隔太远了,一个在“1、2、3、4”,另外一个在“5、6、7、8”中。为何这样说呢?因为“1234”和“5678”之间的交换是有限制的。

AC88u特色的8个Lan口,4个Lan口CPU直接负责,另外4个Lan口通过交换芯片扩展。

这里表面上看起来有 8 个 LAN 口,但是后面 4 个是芯片扩展出来的。所以我感觉问题就出在这里,于是我让舍友换了一下位置:

到这里神奇的事情就发现了,丢包率消失了:

所以,这里确实证实了我们的猜测,也找到了问题的根源。使用路由器充当交换机的角色不是很靠谱,当然这里也和我糟糕的网络拓扑有点关系。

总结与改进

这次的问题出在路由器身上,本质是由于错误的接线,没有使用好路由器的硬件转发能力,导致线路受堵。同时整个网络非常依赖这个路由器做转发,如果路由器挂掉,整个网络就挂掉了。这种情况我已经经历了好几次,路由器莫名其妙的挂掉了,然后需要手动重启路由器,如果没有人在宿舍那就真的没办法远程修复了。

其实上述我漏了一点,那就是“openwrt”和“PC”都只是作为一台虚拟机而存在的,这里我将“openwrt”单独拿出来是因为,这个软路由使用了直通的网卡,所以可以看出一台独立的机器。我原本的想法是,这样做可以增加虚拟机的出口带宽,不会和其它虚拟机挤用一个千兆口,因为还有一台 NAS 虚拟机提供内网的文件服务(如果同时传输文件和进行大量下载的话会抢占一个口的带宽)。不过考虑到这种场景毕竟没啥用处,为了求稳可以考虑改成和其它虚拟机公用一个 Lan 口。

经过这次折腾,我也算有学到了许多东西,就比如“mtr”作为一个非常好用的调试命令,比单纯使用“ping”或者“traceroute”直观很多。

最后,终于用上了一个非常流畅的远程桌面环境,回到了最初的体验。当然如果更进一步,可以考虑进行链路集合,将多“wan”带来的上传速度进行叠加,这样宽带加大后可以获得一个更好的体验。