@renothing
想要理解为什么 tun 设备的 MTU 为什么一般应该固定为 1500，你可以从 OpenVPN 的 4 个 MTU 选项入手(这个能查到的资料比较多)：
--tun-mtu --link-mtu --mssfix --fragment ；另外再了解一下 DF 标志。

tinyFecVPN 里面现在有 2 个 MTU,一个是 tun 设备的 mtu，仿照 OpenVPN 推荐的方式固定为 1500 ；另一个是 FEC 编码器的 MTU，mode 0 模式下影响数据的切分。

@renothing

1500 的那个只是 tun 设备的 mtu。

OpenVPN 里面 tun 设备的 mtu 一般都是固定为 1500 的，不论是你改 mssfix 还是 fragment 都不影响这个。

>而且今天的版本，传输速度神奇不在。

确保你把 --mode 1 选项去掉

@renothing

今天更新的版本为了能让设置了 DF 标志的 ip packet 通过，tun 设备的默认 MTU 调大了，对--mode 1 模式产生了一些影响，所以你之前能用的参数现在不适用了。现在用默认参数就不会有 MTU 问题了。

@renothing

你这个应该是自己改了参数的，这个 WARN 只有在--mode 1 时候才会报，更新后默认参数是--mode 0 --mtu 1250。你去掉--mode 1 参数就好了。

--mode 1 得配合 iptables 的 TCPMSS 选项，等我接下来在 readme 里说一下怎么用（也有可能我会在代码里实现个 mss fix 功能），暂时先用 mode 0。

@hu6360567

更新了一版，调整了默认参数，现在用默认的参数预计不会有任何 MTU 问题了。

@hu6360567

尝试一下两端加上 --mode 0 --mtu 1200

@hu6360567

我没测试过 ipv6，这个软件默认也只会分配 ipv4 地址；能不能说下你是怎么弄的 ipv6 映射？

>参考 cloudwindy 你一定要注意安全哇
这个软件只是加速器，不能直接用来科学上网。我知道你是好心提醒，但是把这个和 cloudwindy 的比较，反而可能给我带来麻烦。

>既然名字都有了 vpn，还不如直接开放功能
>话说可以改个名字啊，VPN 关键字去了多好

VPN 全名是 Virtual Private Network，虚拟专用网络。很多大学都有 VPN 系统，比如：
https://vpn.pku.edu.cn/
https://sslvpn.tsinghua.edu.cn/
VPN≠科学上网，也并不一定允许你把数据包路由到外网去。VPN 只是泛指一种网络连接方式，可能很多人接触 VPN 是因为科学上网，先入为主的认为 VPN=科学上网，这个说法有一些误导性。

请各位不要把话题歪到科学上网上去。

>大佬，安卓手机支持吗？

在安卓手机上有问题，可以运行但是发不出数据，以后会找时间解决一下。

@renothing

已经解决了，发布了一个的 release。多谢反馈。

@renothing

如果很长时间没有发送数据的话,nat pipe 会被中间路由设备掐掉，确实会出现重连的情况。tinyFecVPN 里现在没有做 nat pipe 保活的功能，后续我做一下。暂时的解决办法是在后台开个 ping 保活 nat pipe。

@zhuzhi90

去 github 上发个 issue，贴出配置和 log，详细描述下环境吧。

@sw0rd3n

tinyFecVPN 工作在 ip 层，在这一层面不应该有拥塞控制。

对于承载的 TCP 来说，拥塞控制由上层的 TCP 协议栈（在内核中）实现。

@hu6360567

目前不行。这个普及率比较低，没有做。你可以自己尝试改下代码 pr 一个。

>看了一下你的“透过 tinyFecVPN 免改 iptables 加速网络”这个节，感觉可以考虑写个小工具操作 iptables 自动实现端口重定向，socat 这个程序在 Tcp 转发上还好用，在 Udp 转发上大量的 fork，然后很容易爆内存，并不是个好选择

iptables 加了之后还得清理，有点麻烦，程序被 kill -9 后还要手动删。以后我可能会实现一个基于 epoll 的 tcp 和 udp 端口转发的小工具，集成在这个 repo 里。

@renothing

疑似是 udp 被掐断了，在前面套个 udp2raw 试试。

如果还不行的话，请开个 issue，描述一下细节。

>根据 Google 在 QUIC 协议上的实践，fec 基本上只有副作用，所以他们前两年就从 QUIC 里拿掉了 fec，供参考，并不是来挑刺的。

具体情况不了解，可能他们的网络环境比较好。也许他们说的有副作用，是因为没法选择出一套对所有人都适用的参数，又难以做到完全自动调整参数，所以总体上造成了副作用。

这个 repo 针对的是自己的网路有丢包，又有一定动手能力的人； QUIC 从设计上是一个零门槛使用的协议。所以 QUIC 的结论并不能套用在这个 repo 上。

项目 repo 里面有性能测试，在高丢包环境下确实是有明显性能提升的，scp 从 30kb/s 提升到了 3.5mb/s。而且测试方法都公开，你自己也可以轻易复现。

>话说可以改个名字啊，VPN 关键字去了多好，只是少些不必要的麻烦

之前确实想过，想叫 tinyFecRelay。不过后来还是决定起一个最直观的名字了。

>是不是对不丢包的网络没用？
对于绝对不丢包的网络，除了用专线走一条延迟更短的线路以外，基本上任何加速器都没有用。

>对于主机 P2P 游戏，加速现今有什么好思路吗(SS\VPN 对其都不甚友好)

可以把 VPN 或者 S***搭载路由器上，在路由器上实现透明路由或透明代理。 我自己个人用的是 VPN 方法，然后在路由器上用 iptables、ip rule、ip route 来实现透明的路由策略。

@shaoshuang

还有个可能是你的 udp 被运营商限速了。你用了 tinyFecVPN 之后，所有流量都走 udp 了，而原来的流量是走 tcp。

搜一下 udp2raw，可以解决这个问题。