heiher 最近的时间轴更新 heiher 最近的时间轴更新
hev.cc
CA, USA
heiher
heiher 最近回复了
11 天前 回复了 MFWT 创建的主题 › 宽带症候群 › 求问：大规模 NAT1 转 4 之下，对于这个做法的一些疑问 |
之前讨论过这个问题，当时的结论是 NAT4 比 NAT1 理论上可以更节省公网 IP 、端口资源，但是 NAT4 需要维护的公、私映射关系比 NAT1 更多，不利于 NAT 的硬件加速实现。
24 天前 回复了 phttc 创建的主题 › 宽带症候群 › 内网穿透后流量可以点对点吗？ |
我也公司只有 ipv4 ，解决方法是 NAT1 打洞: https://github.com/heiher/natmap/wiki
39 天前 回复了 heiher 创建的主题 › 分享创造 › 分享一个 tun2socks 实现 |
@TongNianShanHe 好的，我找时间看看，感谢反馈~
47 天前 回复了 heiher 创建的主题 › 分享创造 › 分享一个 tun2socks 实现 |
@Cormic client -> virtual tunnel -> socks5 server
54 天前 回复了 heiher 创建的主题 › 分享创造 › Android VPN 转 Socks5 代理应用分享 |
@t6attack 因为 IP 网络的地址类型只有 uint32 和 uint128 两种，假设支持 domain string 就像 socks5 一样，那么你这个想法就可以实现啦。
63 天前 回复了 futurejunjie 创建的主题 › 宽带症候群 › 搬家后公网 IP 可能丢失群晖如何访问 |
接受动态端口的话，了解一下 Natter/NATMap ，白嫖运营商公网 IPv4:
https://github.com/MikeWang000000/Natter
https://github.com/heiher/natmap
https://github.com/MikeWang000000/Natter
https://github.com/heiher/natmap
78 天前 回复了 heiher 创建的主题 › 分享创造 › 分享一个 tun2socks 实现 |
@testFor #31 说明一下没有主动延迟等待收集数据再合并的逻辑，这样理解与事实不符。事实是客户端将 socks5 握手中需多轮交互的多个数据片段一次准备好，并在 TCP 流中一次 send ，仅此而已。
78 天前 回复了 heiher 创建的主题 › 分享创造 › 分享一个 tun2socks 实现 |
@testFor #31 暂不支持，socks5 握手预测的实质是将多轮交互的客户端侧数据一次发送(大概率合并在一个报文中)：
假设客户端与服务端通信的前、反向链路延迟都是 100ms 的话，两种方式的传输模式和延迟情况大致如下:
经典：
客户端：Hello ，我支持的鉴权方法有：123 (100ms)
服务端：Hello ，我选鉴权方法 1 (100ms)
客户端：请帮我建立与 xxx 的连接 (100ms)
服务端：好的，连接已经建立好 (100ms)
合计：400ms
预测：
客户端：Hello ，我支持的鉴权方法有：123 ；请帮我建立与 xxx 的连接 (100ms)
服务端：Hello ，我选鉴权方法 1 ；好的，连接已经建立好 (100ms)
合计：200ms
假设客户端与服务端通信的前、反向链路延迟都是 100ms 的话，两种方式的传输模式和延迟情况大致如下:
经典：
客户端：Hello ，我支持的鉴权方法有：123 (100ms)
服务端：Hello ，我选鉴权方法 1 (100ms)
客户端：请帮我建立与 xxx 的连接 (100ms)
服务端：好的，连接已经建立好 (100ms)
合计：400ms
预测：
客户端：Hello ，我支持的鉴权方法有：123 ；请帮我建立与 xxx 的连接 (100ms)
服务端：Hello ，我选鉴权方法 1 ；好的，连接已经建立好 (100ms)
合计：200ms
78 天前 回复了 heiher 创建的主题 › 分享创造 › 分享一个 tun2socks 实现 |
@testFor #29 没有主动延迟的意思。
刚测了访问国内四个网站的传输时间情况，socks5 服务端在局域网另一主机，测试主机配置 tun0 为默认路由(ipv4 & ipv6)，数据来自 firefox 开发者选项的 timing:
刚测了访问国内四个网站的传输时间情况，socks5 服务端在局域网另一主机，测试主机配置 tun0 为默认路由(ipv4 & ipv6)，数据来自 firefox 开发者选项的 timing:
78 天前 回复了 heiher 创建的主题 › 分享创造 › 分享一个 tun2socks 实现 |
@testFor 有关 TCP delay 都是系统默认配置，“粘包”效果是因为 socks5 客户端有意实现为预测发送，是有减少延迟作用的。不知道切换前怎样，切换后应该是 dns 经过 socks5 服务器端，不知道是不是因为 dns 的延迟。浏览器的开发者选项中网络传输页面应该可以显示每个资源的加载时间，不妨对比看看，需要注意的是尽可能网络环境的抖动影响，比如本地跑 socks5 服务器，访问本地或国内 http 资源。
Select Language