我这边移动 20m 宽带，测试出的性能：
./iperf3 -c 10.222.2.1 -P40 -t30
[SUM] 0.00-30.00 sec 68.3 MBytes 19.1 Mbits/sec 3391 sender
[SUM] 0.00-30.00 sec 64.6 MBytes 18.1 Mbits/sec receiver

./iperf3 -c 10.222.2.1 -P40 -t30 -R
[SUM] 0.00-30.00 sec 71.3 MBytes 19.9 Mbits/sec 10046 sender
[SUM] 0.00-30.00 sec 56.6 MBytes 15.8 Mbits/sec receiver

客户端在 linux 虚拟机上，如果是路由器的话，因为 cpu 速度的原因，只有 8Mbits/sec.

@1423，性能问题去项目里提 issue，贴出配置吧。

有可能你使用的是路由器版，用了 aes128cbc 加密，导致 cpu 被打满。路由器建议用 --cipher xor --auth simple

@s82kd92l 我这边到美国西海岸 udp 基本满速， 到日本经常连都连不上，但是多线程 tcp 到日本和美国西海岸又都满速。有点费解。

当然，这纯属不负责任猜测。

@s82kd92l 我觉得运营商有时候都不是故意 UDPQos 你，只是他们设备对 udp 支持不好，或者 udp NAT 的设备压力太大导致不稳定。 我这边的移动 tcp 多线程（单线程当然不行）连国外基本都满速。 但是 udp 连有一些方向的线路总是时断时续，有的时候 nat pipe 都打不通。 既然 tcp 都满速，udp 故意 Qos 你有什么用呢。

所以我觉得这个项目某种程度上也是在帮运营商，解决 udp nat 支持不好带来的用户抱怨 = = 。

@s82kd92l 这是个好消息 ：）

可以先用 fake-tcp，如果真有 real-tcp 的需求，我再做。

@s82kd92l 你可能没理解我的意思。我的意思是这个 faketcp 对标准 tcp 的模拟不够完全，所以如果运营商做深度包检测的话，理论上有可能把 faketcp 流量区分出来，再有针对性的 qos。 所以我打算模拟个 real-tcp 来代替 fake-tcp，消除被封杀的可能。

@pisser 我没有用过，shaowvpn udp 模式应该没有问题。 他的 tcp 模式是用跟 udp2raw 类似的方式实现的，你可以直接用 tcp 模式。 如果连不上再试试套上 udp2raw

@s82kd92l @t123yh
有一点简单状态机。syn,synack,ack 这些改装的都装了。前几个数据包(udp2raw client 和 server 互相认证的认证包)，还模拟了重传。

再后面（真正承载数据的包）的模拟就比较简单了，就是 seq 增长，ack_seq 跟着收到的 seq 增长一下。

========================
我以后可能会模拟一个从外部看起来完全和 tcp 一样、无法封杀的协议。模拟重传和拥塞控制但是支持实时乱序到达。

拥塞控制模拟带来的问题可以通过多条 tcp 克服。重传带来的 overhead 大部分时间都不大，普通 tcp 不能承载 Udp 的原因主要是不支持乱序到达，一个包丢了后续的包都必须等这个包的重传完成才能投递（一个包丢了会阻塞住所有包的投递）。

这个想法的可行性是没问题的。有一篇论文就是提了这个，https://arxiv.org/pdf/1103.0463.pdf 。但是他没有公开他的实现。而且他是用改内核的“笨”方法实现的，部署难度堪忧 = =.

@s82kd92l 这个是不用配合 pcap 的。直接用 setsockopt attach 在 socket 上就可以了。见我给 kcptun-raw 提的 issue，很简单，就几行代码：

https://github.com/Chion82/kcptun-raw/issues/15

bpf filter : https://www.kernel.org/doc/Documentation/networking/filter.txt

不用担心内核版本不够新，这个据我查到的资料在 linux 2.1 版就有实现了。

@s82kd92l
这个我已经实现了，在内核态用 bpf filter 做过滤，满足过滤条件的才会传到用户态。不会遍历所有包。

看起来你在这个方面很专业呀，期待你提交的代码 ：）

@s82kd92l

补充以下，关于 icmp 模式的。我这边的 icmp 没有 nat pipe 很快失效的问题。 开着一个 ping 可以 ping 几天不掉线。

貌似性能不好是因为运营商做了 icmp 流量或者包速限制。具体是流量还是包速我没有实验。

你说得很对。tun/tap 配合 ip_forward 也可以实现。https://github.com/chobits/tapip ,github 上这个项目就是这个原理。

这算实现路线的区别吧，tun tap 的方式我没深入研究，我从一开始就感觉 raw 的方式比较容易，就 forcus 在这个方案了。

2 层 3 层同时作业，看起来确实有点脏。 不过我已经做好了同时在 2 层收发的功能。用一个隐藏选项--lower-level 可以开启。在项目的一个 issue 里有提到。

@HaoyangWei

thx :)

@s82kd92l 你说的对。icmp 隧道效果确实不好，我的 20m 带宽用 icmp 模式只能达到 6m,用 faketcp 可以打满 20m。

icmp 对一般情况没用，但是在特殊情况下，比如只有 icmp 能通的情况下，可以救急使用。icmp 几乎没给代码增加维护代价，我暂时没有砍掉的想法。我的精力确实主要 forcus 在 faketcp 上的，不用担心。

github 上确实有个 Imcptunnel 很火。

@s82kd92l
实现起来确实麻烦。 首先用 iptables 屏蔽掉内核对指定端口的 tcp 处理。 然后用 raw_socket 在 3 层发 ip 包，用另一个 raw_socket 在 2 层（链路层）收 Ip 包（因为用 iptables 屏蔽掉，就无法在 3 层收到包了）。

确实实现了简单的用户态 tcp 状态机。这个没有重传策略、拥塞控制、按序到达，所以简单很多。

名字我就不改了 = =。 这个项目可以把 udp 用 raw 发出，支持模拟成 tcp/icmp/udp 本身。所以就叫 udp2raw 了 = = 。

github 上确实有个 Imcptunnel 很多，但是那个是不能穿透 nat 的，而且有一个大问题就是没有认证 /加密机制，你架设了服务，任何人都可以用。

@suikator ss 本身是加密的，udp2raw 也有加密。不用担心失去加密。

而且 udp2raw 的加密是防重放攻击的，ss 的 udp 模式据我所知不能做到完全的放重放攻击。