onion83

其实“硬路由”这个定义本来就不是很清晰，一般的“硬”是指在网络数据包能实现线速转发，但是一但涉及到使用防火墙，如 PPPoe 、NAT 、mangle 、QOS 、限速等功能，基本就要用到 CPU 处理。

所谓的 “硬路由” 其实就是内置交换芯片线速转发，处理小包能力很高，性能稳定，但缺点是功能单一。
所谓的 “软路由” 其实就是通用 CPU （ arm 、x86 、mips 架构等），功能强大，但是数据处理的路径太长，小包能力偏弱，延时稍高，但是力大能砖飞。

Mikrotik 的产品本身布局就很巧妙，主要三个系列：
------------------
CRS 交换机系列，特色是拥有让人眼馋的端口例如：10G 、25G 、100G 拥有交换芯片，具备线速转发的能力，也可以玩 ROS 跑 pppoe 拨号，但是 CPU 性能很弱，pppoe 跑 800Mbps CPU 就 100% 了，也就说俗话的“跑不满”。

CCR 路由器系列，一般配置多核 CPU 主要用来跑 nat 、防火墙、流控、容器等，功能强大。有一些还拥有交换芯片，能实现低延时快速转发 L2 hardware offload ，有些还能做 L3 hardware offload 但是使用诸多限制，例如只能跑一个 bridge 、一但跑了防火墙基本就破功了，需要有一定的探索精神，但是测个速什么的绝对没问题。

RB 系列：CRS 、CCR 融合入门体验版

补充：openwrt 中的 PPE 、NSS “硬件加速模块”，x86 架构的 dpdk 个人见解是“利用硬件特效在软件层面优化转发效率”，还是属于软件层面。

目前推荐：高性价比的 homelab 玩法是，买一个国产的高性价比交换机，满配 2.5G 电口 + 10G 上联口作为接入层（ L2 ），配合 x86 架构或者 CCR 系列做为主路由（ L3 ），这也是我目前的方案。



对于楼主的需求，其实就是一个 120 块的水星交换机 (Se106 Pro)，然后再跑一个 x86 版本的 ROS 即可，两者的长处都能利用起来了。

RLHMR6REMYFP 已使用，谢谢🙏

@tootfsg r86s 本来就是有万兆网络接口版本，当然网卡比较差，是咸鱼十几块的 cx3

@XunzhiJun 你可以试试用 iperf3 -R 单边接收打流，看看问题是出现在发送侧还是接收侧这边。

这个问题也困扰我两年了，今年终于折腾明白了，典型的现象就是：上下行不对等，速度丟半，甚至更多。遗憾的是 B/Y 站搞路由器评测的，基本都是无视或者忽略这个问题。

解决思路就是启用：网管交换机端口流控 (Flow Control)，可以明显观察到 802.3x Pause Frames Transmitted 的计数变化，如果是傻瓜交换机就得听天由命了。

我也喜欢直接写 SQL 因为本质上就是和数据库打交道，SQL 才是最直观的 “官方语言”
数据库调试好，稍微修改一下到程序就能用，看代码也流畅
个人是比较反对使用程序框架包一层的，最主要的问题是会影响或者打断思路，大量的语法糖会导致开发脱离真实的世界，框架生成的代码质量也不一定可控。数据库关系都搞不清楚，后期维护越来越迷糊。

@yqdhm 这个项目凉了。。。

我是一名有着 15 年经验的业余程序员，虽未在像 V2EX 这样的专业平台与大家以代码会友，但我也认真研究了您的源代码。在此，我想先谈谈对您作品`dns-bechmark`的一些看法。

您的`dns-bechmark`作品是这样运行的：它以`dnspyre`（目前 star 数为 124 的 DNS 压力测试工具，https://github.com/Tantalor93/dnspyre ）为核心，通过 Go 语言调用外部`dnspyre`命令。这个工具会对自行收集的 DNS 服务器列表进行测试，测试时利用世界排名较靠前的 1000 个域名（ https://github.com/Tantalor93/dnspyre/blob/master/data/1000-domains ）进行并发解析。在这个过程中，`dnspyre`会输出测试的 json 结果，您的作品会解析这些结果，并结合自身的评分体系对 DNS 服务器进行评分，同时使用 GEOCODE 分类，最终生成结果 json 文件。最后通过 Web 前端读取结果，并按照评分高低进行可视化展示。

不过，这个作品存在一些问题。

首先是关于评分算法与网络性能相关的问题。作为核心的压力测试工具`dnspyre`，其本身无法规避网络性能问题。您在评分算法中设置的`LatencyRangeMax`、`LatencyRangeMin`、`LatencyFullMarkPoint`这三个算子都和网络延时密切相关。这就导致了按照您的算法，像 1.1.1.1 这样的 DNS 服务器得分远低于 223.5.5.5 ，但这与实际情况并不相符。

其次，使用`dnspyre`对公共 DNS 进行高频查询存在问题。暂且不考虑这种行为是否符合道德规范，这种高频查询会浪费公共资源。而且当单 IP 高频次查询达到一定程度时，必然会触发 DNS 服务商的防火墙，这会进一步影响评分算法的结果。

再者，您的评分算法只考虑了`errorRate`，却没有考虑解析结果的准确性，也没有考虑诸如 DNS 劫持等情况。我们都知道，在国内由于一些特殊原因，查询 Google 、Facebook 等域名时，即使局域网内配置了旁路由进行 IP 分流/cache ，RTT 几乎都是 1ms ，但这显然不符合真实的网络解析情况。

最后，在对 DNS 服务器地址使用`net.LookupIP(server)`进行解析并返回 geo code 进行分类时也有问题。因为`net.LookupIP`本身会依赖系统的 resolver 进行解析，也就是会依赖系统默认的 DNS 。然而很多公共 DNS 是在多国部署的，这样做会导致地区分类不准确。

总结来说，您的`dns-bechmark`作品有其亮点。您精心收集了全球很多 DNS 服务器，并利用`dnspyre`进行压力测试，最后将结果汇聚并进行了可视化展示，界面还算美观，这在一定程度上可以为本地优选服务器提供参考。但需要注意的是，如前文所述，影响评分结果的主要因素是网络延时，所以这个结果只能体现本地到“世界 DNS”的性能，仅对本地网络有参考价值，缺乏分享和对比价值。毕竟，通常情况下速度最快的 DNS 往往是本地宽带运营商提供的。此外，您的评分只考虑了 QPS 、延时、错误率等指标，没有对解析结果、应用层 RTT 等结果进行校验，这就可能导致得分最高的 DNS 服务器未必能提供最好的解析结果。还有一点，鉴于您的作品并非 100%原创，尤其是核心的`bechmark`程序`dnspyre`，希望您能在 README 文件中对`dnspyre`进行相关引用并致谢，这符合开源社区的礼仪规范。

--- 感谢豆包对人类回复进行了润色 ---

@bigtear 专不专业不是您自认的，V2 都是行内人士懂的人一眼便知道你作品的问题所在。如果连数据都是错的，一切的什么可视化、评价体系就是 s 上雕花，毫无价值。