V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  onion83  ›  全部回复第 1 页 / 共 31 页
回复总数  617
1  2  3  4  5  6  7  8  9  10 ... 31  
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
```
4 天前
回复了 sanquan 创建的主题 宽带症候群 组装一台“ros 硬路由”如何实现?
@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 性价比高,效果也好。
4 天前
回复了 sanquan 创建的主题 宽带症候群 组装一台“ros 硬路由”如何实现?
@hackroad 撇去 5 位数价格不说,25G 端口不兼容 2.5 猫棒不说,我怕它 4 个风扇同时起飞耳朵受不了。
@bibiisme 连接首包还是得过 cpu ,对于已经建立的连接可以直接交由硬件转发,上 QOS 、策略路由还得过 cpu ,我觉得更像是驱动程序吧。

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

鱼和熊掌不可兼得,参考:
- https://www.bilibili.com/video/BV17ozzY1Eyx 《大多数人忽略的 wifi7 路由器重要性能指标!硬 qos 你知道吗?》
5 天前
回复了 sanquan 创建的主题 宽带症候群 组装一台“ros 硬路由”如何实现?
其实“硬路由”这个定义本来就不是很清晰,一般的“硬”是指在网络数据包能实现线速转发,但是一但涉及到使用防火墙,如 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 的计数变化,如果是傻瓜交换机就得听天由命了。
36 天前
回复了 Joker123456789 创建的主题 Java 其实,我更喜欢写 SQL
我也喜欢直接写 SQL 因为本质上就是和数据库打交道,SQL 才是最直观的 “官方语言”
数据库调试好,稍微修改一下到程序就能用,看代码也流畅
个人是比较反对使用程序框架包一层的,最主要的问题是会影响或者打断思路,大量的语法糖会导致开发脱离真实的世界,框架生成的代码质量也不一定可控。数据库关系都搞不清楚,后期维护越来越迷糊。
44 天前
回复了 p1gd0g 创建的主题 NAS 国内 Linux 测速有什么工具吗?
@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 等端口的特殊关照,所以说您做这个小工具也就是有个图表能看看而已,意义其实并不大,放到任意用户的手里结果都会不一样的。但是作为练手的作品,我是非常肯定您的想法和动手能力的,起码东西做出来了。
49 天前
回复了 doghappy 创建的主题 Android 小米手机无法通过 hostname 访问局域网设备
@ysxb1145 哥们我那里黑了,我只是说兜底。另外,国行手机你弄两个外网的 dns 你觉得这合理呢?
49 天前
回复了 doghappy 创建的主题 Android 小米手机无法通过 hostname 访问局域网设备
小米/oppo/vivo 等国产手机无论你 dhcp 配置什么地址,都有一个 114.114.114.114 作为兜底,供参考。
首先,肯定楼主的工作和探索精神 👍,但是家庭或者非专业监控机构,去监控全世界的 dns 个人觉得意义不大,dns 服务器一般都是用运营商就近提供或者使用大厂的 DNS ,对于单一网络条件下去测试全球的 QPS 和成功率,自身网络就是瓶颈,数据没有参考价值。

如果是普通用户挑选优质 DNS , 在 Windows 平台且只用于临时测试,希望测速后一键切换
友情推荐免费 dns-jumper : https://www.sordum.org/7952/dns-jumper-v2-3/3/#8

https://imgur.com/klvZrWV
这个问题我也疑惑过,因为 ipv6 的 nd 时间不固定,我抓鬼也抓了很长时间,终于被我抓出来了 -_-

1 、调试工具: https://www.remlab.net/ndisc6
2 、这个地址实在太熟了,最终结论就是 [ Apple TV ] 目的是要做智能中枢网关( https://discussions.apple.com/thread/252823422
刚才我看了一下 D840N 的后台管理页面,确实没有像 F7005TV3 的上行光模式 XEPON/XGPON 切换选项,这个只能查看其它类似案例自行探索了,实在不行就只能换 zte 7005 、7015 了

- https://www.chinadsl.net/thread-176170-1-1.html
50 天前
回复了 lyo710 创建的主题 宽带症候群 sing-box tun 模式不定时断流,需要重启
50 天前
回复了 lyo710 创建的主题 宽带症候群 sing-box tun 模式不定时断流,需要重启
已经发现 sing-box / dae 都存在这个问题,无解。已经转投 mihomo ,多种负载均衡模式、自定义健康检查、更灵活的分流特性,yaml 格式能写注释不用 json 到处找闭合括弧。跑了快一个季度,因为健康检查功能过于强大,我都忘记梯子没续费了机器都被释放掉了 -_-
1  2  3  4  5  6  7  8  9  10 ... 31  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1406 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 17:14 · PVG 01:14 · LAX 09:14 · JFK 12:14
Developed with CodeLauncher
♥ Do have faith in what you're doing.