Closed digiw closed 1 month ago
@digiw 图里没有clash的ebpf啊
@digiw 图里没有clash的ebpf啊
参考
@digiw meta的ebpf性能和dae的根本是两个次元 https://docs.google.com/spreadsheets/u/0/d/1UaWU6nNho7edBNjNqC8dfGXLlW0-cm84MM7sH6Gp7UE/htmlview?pli=1
@digiw meta的ebpf性能和dae的根本是两个次元 https://docs.google.com/spreadsheets/u/0/d/1UaWU6nNho7edBNjNqC8dfGXLlW0-cm84MM7sH6Gp7UE/htmlview?pli=1
你说的没错,不过看上述测试链接里meta的版本是2023年的1.13.2,我安慰自己说今年的alpha通道迭代版本已经过去无数了,高低能干一仗的吧...
@digiw meta的ebpf本质是ebpf->tun,和dae的ebpf不一样
@digiw meta的ebpf本质是ebpf->tun,和dae的ebpf不一样
根据此前测试图的显示发现,效能暴增的是对直连流量的转发处理,代理流量的处理上没有拉开特别大的差距。其次dae的信息不多,找到一个出处: https://github.com/daeuniverse/dae/issues
对,就是这个dae
只能干到这儿了,水平有限,只能希望开发大佬能整合它了,据说这个功能还带高版本内核支持才行。
有现成的了
有现成的了
你一提醒,看了看仓库里,还真有!
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
被老哥一波幽默到了哈哈!我的固件已经使用Firewall4的 NFTABLE 规则了,openclash也是支持的我记得,但问题是tun模块在opc里面已经不更新了,只有meta这个独苗还更新着,dae那个东西由是个单独的插件.... 我在这里顶楼那个“Pull Request ”里,看到两位大佬有讨论这个事情,参考:https://github.com/vernesong/OpenClash/pull/3893
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
被老哥一波幽默到了哈哈!我的固件已经使用Firewall4的 NFTABLE 规则了,openclash也是支持的我记得,但问题是tun模块在opc里面已经不更新了,只有meta这个独苗还更新着,dae那个东西由是个单独的插件.... 我在这里顶楼那个“Pull Request ”里,看到两位大佬有讨论这个事情,参考:#3893
你不看用户名的吗?
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
被老哥一波幽默到了哈哈!我的固件已经使用Firewall4的 NFTABLE 规则了,openclash也是支持的我记得,但问题是tun模块在opc里面已经不更新了,只有meta这个独苗还更新着,dae那个东西由是个单独的插件.... 我在这里顶楼那个“Pull Request ”里,看到两位大佬有讨论这个事情,参考:#3893
你不看用户名的吗?
哎呀卧槽,是大佬你啊!好吧,opc现在都更到v0.46.016-beta,这盼望ebpf眼睛都盼肿了,希望作者能给加上
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
被老哥一波幽默到了哈哈!我的固件已经使用Firewall4的 NFTABLE 规则了,openclash也是支持的我记得,但问题是tun模块在opc里面已经不更新了,只有meta这个独苗还更新着,dae那个东西由是个单独的插件.... 我在这里顶楼那个“Pull Request ”里,看到两位大佬有讨论这个事情,参考:#3893
你不看用户名的吗?
哎呀卧槽,是大佬你啊!好吧,opc现在都更到v0.46.016-beta,这盼望ebpf眼睛都盼肿了,希望作者能给加上
别盼了,已经用过了然后自己实用的时候关了。 原因是现在ClashMeta实现eBPF方式如我之前说的有巨大缺陷, 然后开了eBPF又会导致流量吞入再防火墙之前。。。 选择一个eBPF端口后该端口所有流量都会经过Clash TUN所以性能很低。所以暂时别太希望这个。 但是如果这个功能加上后我调试eBPF以及对于未来改进ClashMeta eBPF实现会很有帮助, 我也不知道为啥他不让我Pull 进来。
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
被老哥一波幽默到了哈哈!我的固件已经使用Firewall4的 NFTABLE 规则了,openclash也是支持的我记得,但问题是tun模块在opc里面已经不更新了,只有meta这个独苗还更新着,dae那个东西由是个单独的插件.... 我在这里顶楼那个“Pull Request ”里,看到两位大佬有讨论这个事情,参考:#3893
你不看用户名的吗?
哎呀卧槽,是大佬你啊!好吧,opc现在都更到v0.46.016-beta,这盼望ebpf眼睛都盼肿了,希望作者能给加上
别盼了,已经用过了然后自己实用的时候关了。 原因是现在ClashMeta实现eBPF方式如我之前说的有巨大缺陷, 然后开了eBPF又会导致流量吞入再防火墙之前。。。 选择一个eBPF端口后该端口所有流量都会经过Clash TUN所以性能很低。所以暂时别太希望这个。 但是如果这个功能加上后我调试eBPF以及对于未来改进ClashMeta eBPF实现会很有帮助, 我也不知道为啥他不让我Pull 进来。
我感觉,似乎openclash得抛弃那个老tun模块才行? 所以 我现在只能开着tproxy模式,就指望这openwrt高版本的内核能有福利到这个模式!我这算不算擦边啊...
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
被老哥一波幽默到了哈哈!我的固件已经使用Firewall4的 NFTABLE 规则了,openclash也是支持的我记得,但问题是tun模块在opc里面已经不更新了,只有meta这个独苗还更新着,dae那个东西由是个单独的插件.... 我在这里顶楼那个“Pull Request ”里,看到两位大佬有讨论这个事情,参考:#3893
你不看用户名的吗?
哎呀卧槽,是大佬你啊!好吧,opc现在都更到v0.46.016-beta,这盼望ebpf眼睛都盼肿了,希望作者能给加上
别盼了,已经用过了然后自己实用的时候关了。 原因是现在ClashMeta实现eBPF方式如我之前说的有巨大缺陷, 然后开了eBPF又会导致流量吞入再防火墙之前。。。 选择一个eBPF端口后该端口所有流量都会经过Clash TUN所以性能很低。所以暂时别太希望这个。 但是如果这个功能加上后我调试eBPF以及对于未来改进ClashMeta eBPF实现会很有帮助, 我也不知道为啥他不让我Pull 进来。
我感觉,似乎openclash得抛弃那个老tun模块才行? 所以 我现在只能开着tproxy模式,就指望这openwrt高版本的内核能有福利到这个模式!我这算不算擦边啊...
没事,敢想才敢做。 这里又没有什么奇怪的空指针为ClashMeta 发展指明方向,说不定你狠狠学一波GO能在我们之前完成呢。目前这个eBPF更新还只是和OpenClash UI 打通了。怎么实现还要看大伙的努力和项目的发展了。
代理性能都差不多,但直连性能有巨大差距,根本原因是因为Clash就算直连依然走Tun 。现在OpenClash只是用各种阴间规则让Tun少走流量罢了。 如果我有时间狠狠抄一波dae的实现, 改装meta分支,使所有DIRECT映射的流量特征在一定lifespan期限内不经过UTUN那么就可以达到类似性能。 好了我接着回去做我真的做完了这些收获超多星星让OpenClash再也不用写iptables绕过规则的大美梦去了。
被老哥一波幽默到了哈哈!我的固件已经使用Firewall4的 NFTABLE 规则了,openclash也是支持的我记得,但问题是tun模块在opc里面已经不更新了,只有meta这个独苗还更新着,dae那个东西由是个单独的插件.... 我在这里顶楼那个“Pull Request ”里,看到两位大佬有讨论这个事情,参考:#3893
你不看用户名的吗?
哎呀卧槽,是大佬你啊!好吧,opc现在都更到v0.46.016-beta,这盼望ebpf眼睛都盼肿了,希望作者能给加上
别盼了,已经用过了然后自己实用的时候关了。 原因是现在ClashMeta实现eBPF方式如我之前说的有巨大缺陷, 然后开了eBPF又会导致流量吞入再防火墙之前。。。 选择一个eBPF端口后该端口所有流量都会经过Clash TUN所以性能很低。所以暂时别太希望这个。 但是如果这个功能加上后我调试eBPF以及对于未来改进ClashMeta eBPF实现会很有帮助, 我也不知道为啥他不让我Pull 进来。
我感觉,似乎openclash得抛弃那个老tun模块才行? 所以 我现在只能开着tproxy模式,就指望这openwrt高版本的内核能有福利到这个模式!我这算不算擦边啊...
没事,敢想才敢做。 这里又没有什么奇怪的空指针为ClashMeta 发展指明方向,说不定你狠狠学一波GO能在我们之前完成呢。目前这个eBPF更新还只是和OpenClash UI 打通了。怎么实现还要看大伙的努力和项目的发展了。
看起来这个目标还得有点距离,倒是最近在隔壁看到singbox热度涨,貌似是支持ebpf的,但易用性上比opc要弱很多!
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days
Verify Steps
Describe the Feature
发现ebpf的性能非常有优势,十分期待opc可以支持开启这个特性!!
Describe Alternatives
No response