首先肯定一下楼主所说的方法是有效果的，尤其是在应对楼主所描述QOS场景时。

但是有些观点太不准确，误导性比较强：

>在一般的运营商Qos里面，只有两种策略。

>解决Qos就两种方式

>当然；最好的办法是：
1：限速，针对每个隧道限制最大带宽
2：多并发，
3：设置每个隧道的时效，超过时效释放，重新发起新隧道

>只要这四个条件一直变，就可以完全避开Qos策略。

>--tcp to emulate a TCP connection(linux)
这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包，
nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了，

首先是Qos策略，除了楼主说的两种Qos策略，我能想到的其他的比较容易实现的Qos策略：

1. 在路由策略里tcp流量的优先级比udp高。 如果网络上tcp流量比较大，就优先丢udp来保证tcp的质量。
2. udp流量的带宽总量受限。
3. udp丢包极高，或者完全被屏蔽。
4. 运营商的设备对udp nat的支持不好，不管流量大小，过一段时间nat pipe就无法保留。 (这条可能不应该算Qos策略)

(至于运营商有没有用上面的策略，我没有证据。 不过我至少比较确定我遇到过3)

楼主说的方法对1~3就没什么作用。

关于“最好的办法”，“完全避开Qos策略”，“--tcp 其实没有任何意义”：
我想说很多实际问题不存在“最好的办法”。 有些朋友的“kcptun断流，或者跑不满带宽”，这个问题可能有很多原因，有可能是楼主说的QOS策略，也可能是其他原因。 对症下药的方法才是好的方法。 楼主说的方法确实可以比较好的解决楼主描述的QOS场景。
但是如果说这种方法可以一劳永逸，”完全避开Qos策略“，别的某某方法”没有任何意义“，实在是太不准确。

--tcp to emulate a TCP connection(linux)
这个其实没有任何意义，在运营商的设备中，不可能去深度解析你的数据包，
nat转发性能本来就不高，如果再识别你的数据包，性能就捉襟见肘了，

检测一个链接是tcp还是udp，只要看ip包头里一个字节就可以，不需要特别”深度“的检测。nat本来就要根据流量是tcp还是udp走不同的逻辑。区分流量是tcp还是udp，本来就应该是nat设备功能的一部分，并不需要什么额外工作。

--tcp模拟三次握手，主要原因不是为了应对高深的检测，主要是为了兼容中间nat设备，让nat pipe可以正确建立。

最后，总结下。如果楼主所说的功能可以完美实现，确实可以增加一种应对Qos的选项。能不能实现就看有没有开发者有时间精力了。