@zhujinliang 现在在的公司就是做网络的 怕有利益纠纷不太敢搞网络相关的开源 所以做做别的东西

@levelworm 细节特别多，缺乏资料。 没有遇到诡异的 timing 。

PCB 图上面的 CPU(严格来说 spdc1024 是 SoC ，内含 CPU)、DSP 、nor flash 、nand flash 全都要模拟。

cpu 本身不难模拟，6502 cpu 模拟器网上有现成的。麻烦的是 SoC 上面各种特殊寄存器。0x00~0x3f 每一个都有不同的功能，比如切内存（实际上有好几段内存都可以切页，方式还不同）、timer0/1/A/B 、中断控制、驱动 lcd 、电压比较（测电池电量）、RTC 时钟、RTC 定时器、IO port(各种方向控制，锁存不锁存等细节)。0x00~0x3f 的寄存器几乎每一个单独拉出来细节都可以写一页纸。

资料极度缺乏，当年文曲星流行的时候基本上就没有。SoC spdc1024 、DSP spds104a 厂家 sun plus 根本就没公开公布过任何资料。 后来 GGV 网站被攻击才泄露出来一些，但是很多细节资料里并没有解释，要猜和慢慢 debug 。

nor 和 nand 擦除、修改等等操作，各有 10 来种指令序列，也要模拟。

我也不是从头开始写的，我是从曾半仙的 cc800(另一型号文曲星，不过硬件差别挺大的)模拟器 fork 的。DSP 部分是 fork 的 lee 的 pc1000emux 里的代码，然后 debug 和看资料改进。

@lyric 不用了 之前 github 空投领的$200 币 因为一直懒得搞提现，都快跌没了也没领

@Avn

>Wine 把 Windows API 转换成 macOS API
>Rosetta 把 x86 指令转换成 ARM 指令
>它两个是不同级别的转译，一个是操作系统级别、一个是硬件级别，不是包含关系

这个说的没错

但是人家楼主明确说，要学的是 x86-64 -> ARM 指令转译。 你建议看 wine ，能学到 x86-64 -> ARM 转译吗？

wine 在 macos 上运行 底层还是靠 Rosetta 2 转译 并不是自己实现了类似技术

@cnbatch 我也遇到过类似的情况：

(有时候)1. 本来 udp 连接很快，但是过了几天会非常慢。如果重连换个连接就会快起来。

(其他有的时候)2. udp 刚连就很慢。如果手动反复重连，多试几次可以挑出来一个快(或者说丢包低)的 session 。然后可以保持快的速度很久。 (就好像底层有什么负载均衡机制，会把 udp session 分到不同的设备，反复手动重连可以“挑”出来一个快的设备）

>fec 然后疯狂发包就是了

别教别人乱搞 超过一定限度发越多丢越多

>我咋感觉现在这些欧洲国家没那么好拿永居。

对码农来说，

德国永居只要 27 个月（蓝卡途径），德语好可以更快； 爱尔兰 stamp4 只要两年。

主要难度是找到那边工作。

是那个 linnuxx 吗？ 我聊了两句发现有问题， 翻了下他 github 记录，发现了他在你的 issue 里骂人，然我直接把他 block 了：

https://github.com/wangyu-/udp2raw/issues/519

@fan88 我觉得我前面好像已经说过了啊

这个帖子里这么多人怼你，你不觉得自己理解和沟通上有一些问题吗

windows 下用虚拟机，能桥接就桥接，最简单。

不能桥接就从 windows DNAT 到虚拟机里 (windows 能不能 dnat icmp ，我不确定)

这个功能跟心跳检测的区别是什么？

>在半个小时内测了差不多 10 次，测试结果实在很诡异，有时端口全通，有时仅有个位数端口阻断，有时几十个、几百个，最多的一次竟然有一千多个！

感觉你说的现象，像是中间负责 UDP NAT 的设备 allocate 新端口处理不过来，或者是负责审查的设备跟不上新 udp session 建立。不像是故意这么搞你。

> 文档中确实提到对 UDP 没有任何的加速效果。
> 所以我想表达的是，他不只是没有加速效果，甚至是副作用更大

很正常，主要还是你理解不到位。

正常情况下如果套了不对的东西，就是套得越多越慢。

> @fan88 文档表达意思其实很清楚：它不保证 UDP 流量被代理后的品质。

对

>代码估计都没有针对 UDP 做任何事情，甚至额外的逻辑可能产生负优化。 这不是很正常的情况么？

实际可能更差。 我没看过代码，但是我猜 hy2 的 udp 是用 quic datagram 实现的。quic datagram 也是走拥塞控制的，比直接走 udp 还差。

本来 wireguard 是 udp ，wireguard 里面跑着 tcp ；现在 wireguard 外面又跑了层 quic 。tcp 跑在 quic 里面，两层拥塞控制，再慢也不奇怪。

不是有 udp 模式吗，觉得有反作用可以用 udp

>2 、我想到了多年前的 UDPspeed ，虽然他的主要目的并不是伪装而是抗丢包，但他内置了加密功能。我想知道他的内置加密功能足以对抗审查吗？

你内层流量已经是 wireguard 了， 数据安全已经由 wireguard 保障了。 你只需要伪装不需要强加密。udpspeeder 的 xor 也是一种伪装。 至于够不够用，自己试一试，以结果为准。

如果想要更强的伪装可以用 udp2raw, tcp 模式是加密混淆(aes+hmac) + 伪装成 tcp, udp 模式是仅加密混淆。

@duffercn 用 bridge 或者 host-only 网卡，运行在虚拟机里。 然后把公网 ip 的一个端口 dnat 到虚拟机里。

称不上完美。套壳 wireguard 实在没多少选择，这个帖子里提到的软件，除了 faketcp 类和 fec 类的，其他东西本来就不是设计用来 tunnel wireguard 的。

用 wireguard+ faketcp +fec 看似一套方案解决 tcp 和 udp 。 但是就 tcp 来说，这套方案没有魔改的拥塞控制, tcp 速度很可能比不上有魔改拥塞控制的方案。 但是 tcp 延迟相比大部分其他方案有优点，对打游戏什么的有帮助。

如果倾向 tcp 速度的话，不如 udp 走 faketcp+fec ，tcp 走别的(BBR, kcptun ，hy2)。

大概就像这个的图里面的： https://github.com/wangyu-/UDPspeeder/wiki/UDPspeeder---kcptun-finalspeed---%24%24-%E5%90%8C%E6%97%B6%E5%8A%A0%E9%80%9Ftcp%E5%92%8Cudp%E6%B5%81%E9%87%8F

另外，如果你想要 VPN 一样的接口的话，可以在 ss 基础上加个 socks2tun （或者类似的东西）,把 socks5“转成” VPN. (不支持 icmp)

据我了解，hy2 是魔改 quic ，手动控制拥塞控制，不能多倍发包。检测到丢包了再重传的不算多倍发包。

有多倍发包的是 net-speeder 这种纯多倍发包，或者是 kcptun-go udpspeeder 这种支持 fec 的。

> 按照出口带宽的现象推测：普通 ip 标准出口的带宽资源是有限的，除了 vip 线路其他共享一个带宽池，在超售带宽的前提下选择性丢包。hy2 这类的拥塞协议应该是通过多倍发包策略获得更多机会也别再大流量下有更好的表现
> udp qos 或者掐断应该是面向墙内一些 isp 自己的策略，推测是防止 udp 反射之类的 ddos 流量

所以你是想说，只考虑简单丢包的情况，不考虑别的情况。 那 wireguard over hy2 可能有一些意想不到的效果，也可能没有, 我不确定。

udp 简单丢包：
1. 如果上层只代理 tcp 。 那不如只用 hy2 ，不用 wireguard 。没有 tcp over tcp 的问题，底层 udp 有丢包，重传一下也就解决了；因为有激进的拥塞策略，速度可以保证，就是延迟会高。
2. 上层只代理 tcp ，对延迟还有要求。 那就用打开了 fec 的 kcptun ，延迟有改善，其他同 1
3. 上层要代理 udp ，这种情况才需要上 wireguard 。 先尝试用 faketcp ，看转成 tcp 丢包能不能降低，如果能问题解决。 如果不能，那就用 udpspeeder 加 fec 。 如果真的只是“简单”丢包，一般 fec 都可以解决；解决不了的话，很可能你的线路就不是简单丢包（参考下面）。

udp 非简单丢包（比如流量大了被掐断；再比如发得越多丢得越多）：
1. 上层只代理 tcp 。 那不如你试试 bbr 锐速这种，直接不走 udp 。
2. 上层要代理 udp 。 你试试转成 faketcp, 看问题能不能解决。 如果不能，那基本上没什么好办法了。 可以试一些非常规方案，比如不停换端口，但是别抱太大希望。 如果再解决不了，建议放弃这个线路。

>选个不稳定线路通过 udp over quic 等自带拥协议的用激进流控策略获得低延迟+大流量稳定性。

在 wireguard 下面增加一个可靠传输层，只会增加延迟，不会降低。

不太理解在有 udp qos 的情况下，udp over quic 或者 udp over kcp 解决了啥问题。 quic 和 kcp 底层还是 udp ，不管加了什么激进的流控策略，底层还是 udp 。

如果你说的 udp qos 只是简单的丢包，说不定有一些意想不到的效果。 如果你说的 udp qos 是断流或者有速率限制，那么你在上层做什么激进的策略也解决不了。