New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
想问个技术问题 #125
Comments
我自己也在windows 下测试过 (linux没测) windows下 因为gvisor stack tcp sack的问题 导致下载速度 甚至不如go-tun2socks 但是稳定性 确实是比 go-tun2socks 好 而且 go-tun2socks 的上行 是确实很慢。 |
具体我也没有仔细剖析过,主要是不太懂Go。我想将lwip的zero-copy利用起来可能是因素之一吧。
主要是没有万兆网卡来做这个测试,不过有在低CPU性能的设备上对比过:#20 SpeedCPU Usage |
受限于 hev-socks5-tunnel 的底层协程框架,目前只能工作在 Unix 平台上。如果你有兴趣做更多的对比测试,目前建议使用 Linux 平台。 |
网卡我看了下 xjasonlyu/tun2socks 测试的网卡是10G 你这边测试的是100G |
不是100G物理网卡,而是veth的虚拟网卡。raw speed我还没跑过,如果性质与loopback类似的话,根据hev-socks5-server的结果,估计至少也有300Gbps以上吧。 |
好的 我自己再弄个虚拟机测试下 主要我常用的windows 不知道是windows下的问题还是啥 raw speed 也就是测 127.0.0.1 的上行都只有10G 感觉完全测不出来上限 |
貌似我在Ubuntu 下运行失败了
客户端 client.yaml 只修改了 mark: 438
然后就打不开网页了。。 server.yaml 的 bind-address 是绑定的本地上网的网卡吧 是路由哪里配置出问题了么
server 端也收到请求的:
可就是打不开网页 |
如果server也跑在部署了tunnel的系统上,需要让server的outgoing连接绕过tunnel。简单的方法是把server跑在一个特别的用户上,比如nobody或daemon,然后增加一个pref 10的rule: sudo ip rule add uidrange x-x lookup main pref 10
sudo ip -6 rule add uidrange x-x lookup main pref 10 |
ok 能上网了 iperf3 上下行速度测试也很高 但是 有几个问题:
直接没有回应了...收不到回应 我用firefox/chrome 上网 打开网页 新建立连接的时候 特别慢 花了好几秒 ( tun2socks-go 也是这样 但是 gvisor 不会 是lwip导致的???) |
对了 还有一点 这个只有chrome 才有 就是在访问 view-source:https://www.baidu.com/favicon.ico 因为chrome 默认会带一个 favicon.ico的请求 所以是两个请求 长连接下 第一个请求响应大约是30ms 第二个请求有三分之1概率 要花费60ms+ (也就是一直刷的情况) 如果不开tun的话 随便怎么刷 基本两个请求都是30ms 特殊情况也只会是第一个请求的响应时间很长 而不会出现第二个请求响应时间翻倍的情况 |
我这边没注意到有HTTP请求特别慢的情况,检查一下是不是DNS的问题,浏览器里开发者工具里好像可以看到请求各个阶段花的时间。 tun2socks目前只处理TCP和UDP,其它协议不处理。 |
初始连接也没遇到过,感观上是正常的。会不会是环境没有IPv6?hev-socks5-tunnel关掉IPv6试试。 |
外网的话 确实只有ipv4网络 tunnel的配置里面 ipv6 只有个这个 ipv6: 'fc00::1' 是server.yaml里面关? |
你要不下个chrome 试试 我感觉问题多是出在chrome 浏览器上面 但是 客观上来感觉 又不大可能是chrome 本身的问题 |
tunnel里关,注释掉这行: https://github.com/heiher/hev-socks5-tunnel/blob/master/conf/main.yml#L13 晚点我测测chrome |
还真是ipv6的问题 注释掉就很快了 感觉这应该是自动的吧 我外网只有ipv4 tunnel这个配置了ipv6 他优先走tun的ipv6去了 ? |
可能是有IPv6地址会优先尝试一下,超时再fallback到IPv4,socks5服务端没有IPv6就不要在tunnel里开。 |
其实icmp可以开一下 go-tun2socks 就是开了的 只需要在lwipopts.h 里面 定义一下 LWIP_ICMP 1(默认是0) 和 LWIP_ICMP6 1 就行了 这个是他协议栈里面自带的 |
不能反应真实的延迟,可能会有副作用。 |
关了ipv6好像会好一些 但是 第一次连接好像还是存在问题 我的测试方式是: |
这个 我看gvisor的icmp也是这么操作的 直接做的回复 有点像fake dns 这种操作 因为我自己也是fake了dns的 server端实际收到的是域名 而不是ip地址 这样可以防止客户端ip解析错误(dns污染)这种情况 还有就是 客户端解析的ip 可能并不是服务端对应该域名最好的ip 所以还是服务端解析域名比较好一点 |
是server 端的关系么 我看好多时候都是很久没有输出 然后突然一下子打印好几个 socks5 server connect 有些时候 打印还被中间插入了 就像这种 |
看看是不是 ulimit -n 限制的打开文件数太少?调高到 65535 试试。 |
没有打算在tun2socks上实现fake dns,本地的socks5 server可以做。 |
我默认 ulimit 是 4096 4000多个连接 我觉得 测试应该没有达到吧 我改成65535再试试看 |
还是有打印中间插入的情况 |
是不是开了多个socks5-server进程?按说同一个进程内单条日志是原子写的。 |
肯定只开个一个 配置都一样的 都是监听1080端口 多开的话 也会提示端口绑定错误啊 |
同一个用户下的不会,默认有reuseport。 |
现在没环境试,晚点看看。 |
在Chrome(124.0.6367.118)上测试了,https://www.baidu.com/favicon.ico 的问题我这无法复现。 |
打印串行的问题也没有么? 奇怪 难不成这是windows系统下独有的 我这边测试是windows 系统下装的VMware 然后 VMware 里面装的Ubuntu 20.04.2 然后测试的 我换个方式在测试下 |
服务端的打印问题是符合预期的,因为有两个logger在输出,所以没有原子性了,后面需要改进一下。
检查一下有没有可能是DNS不同,不是最优解析的原因? |
dns的解析 时间线不会在wait for server res 里面 |
你是socks server 装在本地测试的么 那么 hosts 文件 配置一下 www.baidu.com 域名解析的ip 确保一下都走同一个ip不就行了 |
取齐了解析的结果: tun2socksctrl+f5和反复开关浏览器多次测试都没有观察到不同请求的延迟明显变化。 直连 |
这个就很奇怪了 你把 socks5 server 改到 我用的这个 122.114.66.146 1082 测试一下 我确实想不出来 我自己测试的有什么问题 为什么 第二次请求 在tun2socks 下 会多40ms的延迟 我感觉我的测试方式也没有任何问题啊 |
我的这个测试方式 应该是没有任何问题的吧? 所以我就想不明白了 |
搞不懂了,socks5 server要放在本地,远程的话干扰因素不可控。 |
如果是远程server 导致的话 那么 你换成我这个远程的server 122.114.66.146:1082 应该也是会出现同样的问题的 是这样吧? |
我没试,不确定。只是说远程的链路延迟本身可能就有波动,不便于分析延迟的来源。 你再试试物理机上跑? |
我没有linux的物理机 我两个机器 一个台式 一个是联想的笔记本 两个都装的windows 系统 两台电脑都有同样的问题 但是我找不到原因所在。 |
用U盘做个Live系统试试 |
U的Live系统 和vmware 虚拟化出来的 差别? 我看空了能不能搞到一个linux 的vps 带图形化界面的 然后测试看看 |
物理机上启动,目的是避开虚拟化。 |
好 我试试 |
我觉得你那边没有出现同样的情况 有可能是你的延迟很低 就算出现了 差距也在很小之间 基本看不出来 而我这边的网络 延迟在60-70ms 就算多0.5个rtt 时间线都会很明显 |
socks5-client与socks5-server、socks5-server与http-server之间的延迟理论上应该是不相关的,这部分不因tun2socks方式或是浏览器直接配置socks5代理方式而变化。tun2socks的lwip协议栈与操作系统的tcp/ip协议栈是通过tun设备互联的,通信延迟极低。 |
lwip的时钟精度没有Linux内核里的高,只要不是特别离谱,造成少量的延迟波动应该也是正常的。 |
我的理解应该是 丢包在 浏览器-> tun2socks 之间 也就是协议栈的处理 在某些特定情况下 可能没处理好 导致额外的延迟 |
想不到浏览器和lwip之间会丢包的可能性,我是怀疑lwip的tcp timer精度不高。 |
也有可能 这个问题再追就要追到lwip的协议栈里面去了 而且估计还是windows 和 linux的兼容性问题 好像需要到lwip那边去提issue了 |
想问下这个 issue 中提到的 mark 是干什么用的呢?是给哪个请求步骤的数据包打标记呢?我是安卓设备,增加
|
我看了下 您的库 和 go-tun2socks 的库 都是用的lwip 这个基础库
但是 为什么您这个上下行上限却比 go-tun2socks高很多
是因为c语言 和 go 性能层次上的差距 还是说因为go-tun2socks 本身实现的问题
还有就是 我看了下 xjasonlyu/tun2socks 他的benchmark 他的评测下载速度是达到raw speed的80%的
你的benchmark 没有写raw speed是多少 就安装100%算(毫无损耗) xjasonlyu/tun2socks 也应该能达到60%+吧
但是你评测出来只有的下载速度 只有50%不到 所以不知道具体是个什么情况了
The text was updated successfully, but these errors were encountered: