1
ericwood067 2022-01-01 15:59:27 +08:00
买个能刷 openwrt 的路由器,装个 adguardhome 方便高效,adguardhome 比较吃内存,所以买个内存大一些的
|
2
ccming 2022-01-01 16:01:23 +08:00 via iPhone 1
R4S 4gb 版
|
3
xiaomimei 2022-01-01 16:07:03 +08:00 via Android
软路由装个 pihole
|
4
Codeword 2022-01-01 16:18:57 +08:00 via Android
跑个题 如果只是是为了去广告可以试试 dnspod 的 DOH ,自带广告拦截规则
|
6
mineralsalt 2022-01-01 18:02:24 +08:00
推荐 r4s, 刷 openwrt, 上面有 adguardhome 服务
|
7
yjs778 2022-01-01 18:43:20 +08:00
@mineralsalt r2s 不香吗
|
8
jtshs256 2022-01-01 18:51:10 +08:00 via iPhone
百元的话弄那种矿渣的 arm 机器好了
|
9
cvbnt 2022-01-01 19:39:56 +08:00 via Android
AC2100
|
10
documentzhangx66 2022-01-01 20:55:20 +08:00 1
现在大部分网站都是 https 。如果要在路由器上拦截广告,这就相当于路由器做了中间人攻击。你的浏览器上会对每个被拦截网站弹出一个证书告警,而且你还必须全部同意。如果有时候这种行为不是路由器为了拦截广告做的,而是真正的中间人攻击,你没有仔细去分辨,那就惨了。
其次,路由器要对每个请求做判断,接着对过滤出来的请求解包,接着解析 https ,还要解析 http ,发现有广告后这些还要重新打包+加密,这些过程会大幅度提高延迟,就算那种几十万一台的企业级设备也无法避免这种问题。这种延迟,如果你玩 lol 或 cs go 或王者,对于高手来说,可能就是残血反杀时一条技能释放数据的到达优先级被降低了。而且为了能尽量减少这种延迟,你路由器的处理器、内存、主板地多强,功耗得多大才行?这些增加的设备性能,会大幅度提高设备价格,降低性价比。这些增加的功耗,你算算一年要多花多少钱。 当然,如果拦截广告对你来说是第一刚需,上面就当我没说。但我觉得上面的老哥说得好,你应该在你常用设备上,在浏览器上安装广告拦截。 |
11
webshe11 2022-01-01 22:18:00 +08:00 via Android
@documentzhangx66 楼主可能想从 DNS 层面去广告,不用中间人就可以解决很多广告
|
12
chenyx9 2022-01-02 00:51:14 +08:00 via Android
楼主可能就是想在 Hosts 文件里把已知广告网址的解析指向本地环回吧…
|
13
notgoda 2022-01-02 01:12:17 +08:00 via iPhone
|
14
MCVector 2022-01-02 04:16:24 +08:00
Raspberry pi 装个 pihole 就行啦
|
15
Codeword 2022-01-02 08:36:06 +08:00 via Android
@notgoda 需要腾讯云账号或者 dnspod 账号,登录之后在控制台的公共解析-我的配置可以免费开通,在之后就照着里面的说明配置就可以了
|
16
amirobotics 2022-01-02 10:16:47 +08:00
pihole, Adguard home, nextdns, dnspod 红鱼等等。。。
|
17
hronro 2022-01-02 12:16:33 +08:00
@documentzhangx66 #10
这个可以 rule-based ,如果是游戏的包甚至直接是所有 UDP 的包就不解析,这样对延迟敏感的应用就不会有太大的影响。 另外也可以像楼上提到过的,只在 DNS 层面做拦截,这样虽然拦截的广告有限,不过在性能上不会有太大的影响。 |
18
documentzhangx66 2022-01-02 13:09:05 +08:00
@hronro 要解析的。
1.需要先解析一系列 tcp 包,是不是 http 或 https 。这里需要缓存,需要拼接。 2.https 还需要继续解密。 3.解析完毕后,这才到了规则判断。此时还要根据规则库的索引类型进行一次查找。如果没查到,后面的继续解析才会跳过。 |
19
hronro 2022-01-02 13:58:07 +08:00
@documentzhangx66 #18
HTTPS 从 SNI 就能过滤掉一大部分不需要处理的包了,不一定要全部解密。 不过话说回来,都走 TCP 了,应该不是对延迟特别敏感的应用。而广告的部分大概率都是在 HTTP/HTTPS 里面,应该不会有走 UDP 的广告吧(暂时不考虑 QUIC ,QUIC 在国内短期之内应该也搞不起来)。所以只要对 UDP 全部不处理直接放行,就可以避免误伤延迟敏感型应用。 |
20
documentzhangx66 2022-01-02 17:23:23 +08:00
@hronro
大部分嘛? 我看了一下 AdBlock 的一部分规则: https://easylist-downloads.adblockplus.org/easylistchina.txt 针对这一条 hudong.pl.youku.com/jsapi/interact/playerPlugins.js 像 SNI 这种只能处理 host 或 hostname 的: hudong.pl.youku.com 是处理不了 URL 后面这一部分 Path 路径的: jsapi/interact/playerPlugins.js 不带 Path 的纯 hostname 在规则里,不到 1/3 。 而且无论如何,当路由器这种网络设备,开始识别并处理包内内容时,就一定会出现延迟、性能、功耗等问题。 |
21
hronro 2022-01-02 18:50:31 +08:00
@documentzhangx66 #20
感觉你有点较真了。 1. 我说的是「一大部分」,不是「大部分」。如果是我没表达清楚,那我现在更正一下,我是指有相当数量的包不用解密,这个占比具体有多少,我没做过测试我也不清楚。 2. 我说的那部分不用解密的包,是指从 SNI 拿到 host 之后,发现这个 HOST 压根不在规则列表里面,所以可以跳过不用处理的包,以及在规则里直接用 HOST 就能判断是广告的包,这两个部分加在一起的总和。占比相当于是 「(非广告的包 + HOST 广告规则的包)/ 所有的 TCP 包」,而你对比的占比则是「 HOST 广告规则的包 / 所有广告规则的包」,拿这两个来比较是没有意义的。 3. 我其实想说的重点是 UDP 啊。TCP 的包再怎么增加延迟都无所谓,只要性能不是差的离谱就行,而广告基本都是 TCP 。而延迟敏感的 UDP 直接不处理就习了,反正 UDP 里也不太可能有广告。 |
22
documentzhangx66 2022-01-02 19:24:49 +08:00
@hronro
1.不是较真,我以前,还真没去看过 AdBlock 的规则列表,只是见过它自动更新。 看你上一条评论这么一说,我有点好奇了,于是去看了一眼最新的规则列表里的内容,它的 URL 都发在上一条回复你的评论里了。 结论也正如我上一条回复你的评论,全 hostname 的规则,真的不多。 不多的意思是,我原本和你看法一样,以为至少百分之七八十应该是这种纯 hostname 的规则,结果我猜错了... 2.你这说法没问题,没发现自然就跳过了。 但问题是,就算没发现,你仔细想想它的实现细节: 每条 tcp 流做了分割后,对分割后的数据包或者说是数据结构,都要尝试提取一下 SNI-hostname ; 接着还要拿到一个巨大的列表里去做字符串匹配,这一来一回, 对于 CPU 来说,字符串的匹配与列表的索引结构,多少条存取与对比指令的周期给浪费了; 而对于运行速度更慢的内存来说,这些操作还涉及到一堆 malloc 或 realloc 开销,造成更多的时间浪费,就算是极端优化后用预先开辟的环状内存结构,整块内存的存取也需要花费几次内存周期; 最后这些网络数据包还得先缓存到网卡甚至内存中,缓存的数据要处理还得经过系统设备与系统两个队列,最好的方案也是 IOCP 或 epoll 甚至 DMA ,就算如此,它们每次进行系统设备或系统队列的存取,都得来一次总线级别的中断,这在时间上的代价也是相当的大。 你如果不打游戏 + 不大流量下载 + 不压榨路由器 + 路由器买的是非常贵的,那么路由器在闲时,也许这些操作加起来还不到 1 个 ms 的延迟开销,你自然无所谓。 但如果你打游戏 + 大流量下载 + 压榨路由器 + 路由器买的是高性价比版本,那么路由器内各本来各配件的性能不会太高,且工作负载不低,同时你还跑一堆小脚本来压榨它,这样一搞,它处理 sni-hostname 时,对整个系统的处理所造成的延迟就会更大。 3.现在的 http/https ,除了极少骚操作之外,其他基本上都是 TCP 的。另外,运营商也会对 UDP 的优先级做了降级处理。并且很多公司 /单位,因为买了安全设备,比如流控、防火墙、WAF 、入侵检测等等,这些安全设备里往往都有 UDP 防范,所以很多专业的 APP 甚至游戏,考虑了这个问题,当 UDP 环境很差时,很少会用 UDP 。 |
23
ak47947 2022-01-04 10:52:47 +08:00
这个不错,我回去试试 dns 的方案
|