@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，虽然这个方案也有问题。
```