想问个技术问题

[380wmda999]

我看了下 您的库 和 go-tun2socks 的库 都是用的lwip 这个基础库 但是 为什么您这个上下行上限却比 go-tun2socks高很多 是因为c语言 和 go 性能层次上的差距 还是说因为go-tun2socks 本身实现的问题 还有就是 我看了下 xjasonlyu/tun2socks 他的benchmark 他的评测下载速度是达到raw speed的80%的 你的benchmark 没有写raw speed是多少 就安装100%算(毫无损耗) xjasonlyu/tun2socks 也应该能达到60%+吧 但是你评测出来只有的下载速度 只有50%不到 所以不知道具体是个什么情况了

[380wmda999]

我用u盘安装了 kali linux 然后 进入到 Live系统 直连:

tun2socks:

开启tun2socks之后 第二个请求还是偶尔会出现延迟比较高的情况 只不过不像windows 系统下面那样 是必然事件了

[380wmda999]

我觉得你那边没有出现同样的情况 有可能是你的延迟很低 就算出现了 差距也在很小之间 基本看不出来 而我这边的网络 延迟在60-70ms 就算多0.5个rtt 时间线都会很明显

[heiher]

高延迟场景的

[heiher]

我觉得你那边没有出现同样的情况 有可能是你的延迟很低 就算出现了 差距也在很小之间 基本看不出来 而我这边的网络 延迟在60-70ms 就算多0.5个rtt 时间线都会很明显

socks5-client与socks5-server、socks5-server与http-server之间的延迟理论上应该是不相关的，这部分不因tun2socks方式或是浏览器直接配置socks5代理方式而变化。tun2socks的lwip协议栈与操作系统的tcp/ip协议栈是通过tun设备互联的，通信延迟极低。

[heiher]

lwip的时钟精度没有Linux内核里的高，只要不是特别离谱，造成少量的延迟波动应该也是正常的。

[380wmda999]

socks5-client与socks5-server、socks5-server与http-server之间的延迟理论上应该是不相关的，这部分不因tun2socks方式或是浏览器直接配置socks5代理方式而变化。tun2socks的lwip协议栈与操作系统的tcp/ip协议栈是通过tun设备互联的，通信延迟极低。

我的理解应该是 丢包在 浏览器-> tun2socks 之间 也就是协议栈的处理 在某些特定情况下 可能没处理好 导致额外的延迟 不然无法解释 为什么 不开tun2socks 就不出现这种问题 (也就是说操作系统的内核协议栈 处理了那种特殊情况 所以不会有额外的延迟)
开了以后 windows下 是必然出现 我装的kali linux 在硬件上是 偶而出现 你那边在高延迟的网络下 测试也很少出现第二次请求 比第一次请求时间长的情况 而且就算第二次比第一次长 差距也是在10ms以内 的

[heiher]

想不到浏览器和lwip之间会丢包的可能性，我是怀疑lwip的tcp timer精度不高。

[380wmda999]

也有可能 这个问题再追就要追到lwip的协议栈里面去了 而且估计还是windows 和 linux的兼容性问题 好像需要到lwip那边去提issue了

[scruel]

想问下这个 issue 中提到的 mark 是干什么用的呢？是给哪个请求步骤的数据包打标记呢？我是安卓设备，增加 mark: 1234 后就连不上网了。 另外对于同一个 socks5 server，使用 sagernet app 直接非 root（挂 tun0）用都没啥问题。 但 root 下用自定义路由+hev tun，部分应用会无法联网，比如推特只能看文字，不能正常显示图片和视频。

ip route add default dev rmnet_hev0 table 16666
ip rule add uidrange 10403-10403 lookup 16666 pref 9000