@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 模式据我所知不能做到完全的放重放攻击。

@Love4Taylor

其实有人做过集成的版本，只是 kcptun 作者决定不 merge 这个功能。比如这个，https://github.com/Chion82/kcptun-raw

外挂的方案比较通用。这个可以支持 kcptun finalspeed openvpn 还有 ss 的 udp 转发。

@kuretru 96M 的那种，一小时平均 CPU 占用不能超过 10%的，确实有点吃不消。

假设，仅仅是假设：你的本地运营商不做 udp Qos,而别人的运营商做 Qos,你不希望别人能绕过 Qos，以防止挤占你的出口带宽。

这也是种自私吧 = =。

不是多倍发包方案

@akwIX

取决于使用者怎么用。我这个不多倍发包方案，只是绕过 udp qos 限制。udp qos 确实造成了很多不便。

我觉得节省出口的更好方式是看 youtube 用 720p 不用 1080p = = 。

尴尬了，原来回复是不支持 markdown 语法的，格式好乱。 可以去 kcptun 的这个 issue 下看，有我的回复:

https://github.com/xtaci/kcptun/issues/228

这不是真正的走 TCP，是给 UDP 加上 tcp/icmp 包头，以骗过 udp 防火墙。本质上仍然是 UDP，跟传统的 tcp over udp 是不同的(比如 tcp 模式的 openvpn)。

引用一下我在 github 上的回复：

```
@wangyu-
有一个疑惑，如果 udp over tcp 的话不就失去 kcptun 的意义了？
本来就是因为 tcp 协议效率低才会用 Kcptun 吧？
@wangyu-

wangyu- commented 7 hours ago • edited
@sqwwqw5 这是个非常好的问题。
普通的 udp over tcp 方案配合 kcptun 确实几乎没有意义(比如用 openvpn 把 udp 转成 tcp 再用 kcptun 加速的想法)。
udp2raw 的方式是，用 raw socket 给 udp 加上 tcp 包头，模拟 tcp 握手和 seq ack_seq，以打通 tcp NAT pipe 和骗过 udp 防火墙。但是这种模拟的 tcp 本质上还是 udp，继承 udp 的实时乱序到达特性，没有拥塞控制和重传（所以可以让上层的 kcptun 自己完全控制拥塞和重传），忽略对方的接收窗口。本质上不属于 udp over tcp，所以没有类似问题。

==updated==
重新编辑了一下，补充了些细节。

普通的 udp over tcp 方案配合 kcptun ”失去意义“的原因：tcp 只支持按序到达，破坏了上层承载的 udp 的实时性(tcp 只要丢一个包，后续的包就都要等这个包的重传完成才能投递给上层，上层承载的 udp 也继承了这个特性，会为上层 kcp 引入额外延时，也可能会误导 kcp 造成额外重传)； tcp 有激进的拥塞控制，上层承载的 udp 不能自由控制发送速率； tcp 丢包后还必须重传，kcp 有自己的重传策略，两个重传策略在一起有双倍重传的问题，造成性能下降。

注:
这里说的是 kcptun_client---->udp over tcp----->kcptun_server 的问题。
不是 udp over tcp---->kcptun_client---->kcptun_server-----> udp over tcp，虽然这个方案也有问题。
```