1 、家庭装修用的机柜通常不会移动，装修时肯定已考虑好位置。普通住宅一般会选择电视柜、书房作为线缆汇聚点。
2 、布线时建议预留 10 - 20 米左右的线缆盘在机柜内，以便日后做适当调整。
3 、强电装修时，业主最好在现场，确保线缆预留足够长度（ 1 - 3 米）。否则一剪刀下去线缆过短，日后拽不动，定会懊悔数十年。
4 、多余的线缆可以先不处理，86 面板也不用急于盒盖，先用电工胶布裹住线头进行保护，然后再进行刮墙等装修工作。等专业的弱电师傅到场（建议直接找装宽带的小哥谈价格，他们把这当作赚外快，会非常乐意，而且搞好关系，日后宽带有问题也能有个照应），评估环境后进行融纤、打水晶头并修剪余线，之后再盖 86 盒。光纤末端可以采用 45 度斜口的，还可以尝试用防水保护盒适当 DIY 做防护（这一点我也没试过）。
5 、术业有专攻，不要轻易觉得“我行我上”。带双屏蔽的六类、七类网线打水晶头/免打模块既是手艺活，也是力气活。需要专业的线钳和卡线刀，最重要的是经验。自己动手的话，要么触点不良导致网线不通，要么收口不干净造成短接乱序，更不用说熔纤所需的专业装备了。不然，不仅弄得自己手指疼痛，墙内网线还可能因接线失败越弄越短，那就麻烦大了。另外，不要贪图便宜让强电师傅来弄弱电，他们往往一把剪刀走天下，难以做弱电这种精细活儿。
6 、如果是新屋装修，要考虑每个房间预埋两芯光缆是否足够。一般需展望 10 - 20 年的光网发展，如今网络速率已达 400 - 800G ，可以了解一下它们使用的是什么线缆、什么模块、几芯。
7 、我个人估计不建议使用配线架，因为一般家庭也就十来根网线，定位后基本不动，除了需要加装等量模块外（费钱），还需要考虑模块、网线是否接地等（测试仪上 G 灯不亮），以后网线氧化老旧后，接触不良频繁闪断导致降速，机柜留长一点线，直怼交换机，自己用款绑带调整一下就好了。

（下图为 2019 年装修方案，每房间预埋 3 根 7 类双屏蔽网线 + 一根 8 芯 OM4 多模光纤，目前使用体验依然良好）

https://i.v2ex.co/o0I3LpLUl.jpeg
https://i.v2ex.co/Qz2EHn3Fl.jpeg
https://i.v2ex.co/1o7ol48Jl.jpeg
https://i.v2ex.co/p6mA9149l.jpeg
https://i.v2ex.co/QCb7Rh91l.jpeg

自研 5G 调解器、融合式摄像头、续航时间

gemini 2 可以根据路径、日期、智能等条件批量合并

程序员、理工男特有的偏执，洋洋洒洒几百字，一看价格 7 块钱😭

...
*) ipv6 - added FastTrack support;
*) ipv6 - added routing FastPath support;
...

16 Pro + iOS 18.3 beta +中国移动 断网断到飞起

https://imgur.com/a/4x8WvCS

1 、其实 ROS address-list 就是等价于 linux 中的 ipset ，不过 v4/v6 双栈需要分开来写而已。
2 、利用 1 、2 楼提到的公共列表或者其它 BGP dump 、geoip dump ，加上一些自定义 IP 的白名单，可以合成自己最终的 cn address-list ，再配合 github 的 workflows 每周一 build 生成最终的 rsc 文件，release 到 github 制品仓库后，配合 ros 的计划任务直接 fetch 后 import 导入即可，这也算是人为制造一个场景熟悉 github 的 CI/CD 流程吧。

核心代码参考：
```
echo '/ip firewall address-list remove [/ip firewall address-list find list="cn"]' > $outfile

for line in `cat myip.txt`;do
ip=`echo $line |awk -F , '{print $1}'`
comment=`echo $line |awk -F , '{print $2}'`
commentstr=""
if [ ! -z $comment ];then
commentstr=`echo comment\=\"$comment\"`
fi
echo "do { /ip firewall address-list add list=cn address=$ip $commentstr } on-error={}" >> $outfile
done
```

@hackroad 目前我在用的 Mikrotik CCR2004-1G-12S+2XS 用来做主路由还是不错的， 全光口 ，12*10G + 2*25G ，支持主流猫棒，2.5G 协商即插即用（我用的是 ODI 也叫 HSGQ ），目前电信/联通/移动三路接入，新方案以及跑了近一年，很稳定，没有需要踩的坑。

两个 25G 口拿 cx5 互相对打过，在 br 没有规则的情况下能跑到超过 20G ， 因为没有交换芯片，cpu 50%，平时也不太用，就是留个幻想而已。

Mikrotik 家的 AP 就别选了，基本还是 Wi-Fi 6 / ac wave 2 水平，没 fem ，虽然有 capman 做统一管理，但是性价比其实不高，还不如买几个国产 Wi-Fi 7 做 AP 性价比高，效果也好。

@hackroad 撇去 5 位数价格不说，25G 端口不兼容 2.5 猫棒不说，我怕它 4 个风扇同时起飞耳朵受不了。
@bibiisme 连接首包还是得过 cpu ，对于已经建立的连接可以直接交由硬件转发，上 QOS 、策略路由还得过 cpu ，我觉得更像是驱动程序吧。

所以，现实世界中我觉得所谓的 “硬路由”、“软路由” 其实边界和定义是很模糊的。

鱼和熊掌不可兼得，参考：
- https://www.bilibili.com/video/BV17ozzY1Eyx 《大多数人忽略的 wifi7 路由器重要性能指标！硬 qos 你知道吗？》

其实“硬路由”这个定义本来就不是很清晰，一般的“硬”是指在网络数据包能实现线速转发，但是一但涉及到使用防火墙，如 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 ），这也是我目前的方案。

https://i.v2ex.co/gotpjUD0l.jpeg

对于楼主的需求，其实就是一个 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 上雕花，毫无价值。

@bigtear dns-jumper 这种表格有数字还能排序的形式还不够直观 ☺️ 最关键的问题我因为说了，你的单一网络本身就是最大的瓶颈，响应速度几乎就是你的网络延迟。 加上 dns 服务器普遍都会存在防火墙，类似 223.5.5.5 还有每日，每小时限速测率，还没有考虑 isp 对 53 等端口的特殊关照，所以说您做这个小工具也就是有个图表能看看而已，意义其实并不大，放到任意用户的手里结果都会不一样的。但是作为练手的作品，我是非常肯定您的想法和动手能力的，起码东西做出来了。