不是多倍发包方案

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