一般来讲，国内运营商都有QoS
百度百科：QoS （ Quality of Service，服务质量）指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力，是网络的一种安全机制， 是用来解决网络延迟和阻塞等问题的一种技术。
说白了就是在网络拥堵的时候运营商会直接把一些不重要的流量包丢掉，至于啥是“不重要的”就要去问运营商了（看人下菜碟）。对被 QoS的用户来说，表现就是、网速降低、丢包、ping 值极不稳定，给钱越多的网络质量越好，例如带宽更高，丢包更少，延迟更低。
当然QoS是不区分TCP和UDP的，对于UDP而言，除了常规QoS，还有更严格的限制甚至在某些极端情况下会屏蔽掉UDP，主要原因是UDP无连接、无状态、支持广播、最大努力送达等特性让运营商控制UDP的成本太高
来一张喜闻乐见的对比图
一般游戏为了保证实时性，都会采用udp进行网络传输，比如玩射击游戏角色正在行走的时候，网络卡了一下，但是一秒不到游戏角色已经移动到下一个位置了，这是UDP的表现，它尽最大努力送达，允许丢包；假设是TCP，网络卡一下，你会发现游戏画面暂停了，角色向卡幻灯片一样的往前行走，因为TCP是面向连接的，丢包会重发，到达会确认。
当然游戏不全是UDP，TCP甚至更上层的HTTP也有，这完全取决于游戏对延迟的要求。
那么游戏中到底是用UDP还是TCP呢？
- 如果是由客户端间歇性的发起无状态的查询，并且偶尔发生延迟是可以容忍，那么使用HTTP/HTTPS吧。
- 如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么可考虑使用TCP长连接
- 如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，一些MMO类游戏），那么考虑使用UDP
在玩一些外服游戏（游戏服务器在国外）的时候，直连效果差，需要加一层代理也就是加速器，实现加速效果，因为游戏一般为UDP传输但运营商对UDP干扰严重，所以需要将游戏客户端到代理服务器之间的连接做一些处理。
UDP QoS下面详细说一下针对UDP的QoS，UDP socket每次发包都换一个不同的源端口，如果一个设备疯狂发送UDP包，将会在短时间内创造大量的五元组。传统的状态防火墙，状态NAT会用一个 五元组来追踪一条 连接 。如果连接过多，就会对这些保存状态的设备造成很大的压力，这种压力主要体现在两个方面：
- 存储压力：设备不得不配置大量的内存来保存大量的连接。
- 处理器压力：设备不得不在数据包到来的时候花更多的时间来匹配到一条连接。
由于UDP的无状态特征，没有任何报文指示一条连接什么时候该创建什么时候该销毁，设备必须有能力自行老化已经创建的UDP连接，且不得不在权衡中作出抉择：
- 如果老化时间过短，将会破坏正常通信但通信频率很低的UDP连接。
- 如果老化时间过长，将会导致已经无效的UDP连接消耗大量的内存，这将为DDoS攻击创造一个攻击面。
攻击者只需要用不同的UDP五元组构造报文使其经过状态设备即可，由于UDP报文没有任何指示连接创建销毁的控制信息，状态设备不得不平等对待任何新来的五元组，即为它们创建连接，并且指定相同的老化时间。TCP与此完全不同，由于存在syn，fin，rst等控制信息，状态设备便可以针对不同状态的TCP连接指定不同的老化时间，ESTABLISHED状态的连接显然要比其它状态的连接老化时间长得多。
这导致使用TCP来实施同样的攻击会困难很多。为什么快速构造不同的TCP五元组达不到UDP同样的效果？如果你只是盲目的用不同源端口发送syn，在没有真正的对端回应的情况下，这种状态的连接将会很快老化掉(10秒以内，甚至更短)。
如果你构造使用不同端口的大量真正的TCP连接，那么在状态设备受到伤害的同时，你自己也必须付出巨大的代价来维持住这些连接。你发起一个TCP连接，为了让状态设备保存这条连接，你自己也不得不保存这条连接，除非你通过海量的反射主机同时发起真连接，否则在单台甚至少量的主机上，这种攻击很难奏效。
对于无状态设备，我们便不必再纠结五元组连接的保持了。但是UDP短期构造海量五元组的能力仍然会影响无状态设备包分类算法的正常运行。基于包分类算法的优先级队列，缓存管理几乎也是通过五元组计算来完成的，UDP的特征将会使无状态设备对其做流量管控变得困难。其结果就是，眼睁睁任凭UDP流量挤满各级队列缓存却没有办法将其精确识别出来，即便是BBR遇到了UDP流量，也只能自降pacing rate而兴叹。
运营商对TCP更加友好，对UDP不友好，但却无力深度检测TCP连接的真实性。
一个简单的例子就是将正常TCP数据的protocol字段改成UDP，丢包率大大增加了，甚至根本无法通信！
if (iph->protocol == IPPROTO_TCP) {
iph->protocol = IPPROTO_UDP;
ip_send_check(iph);
udph->check = 0;
} else if (iph->protocol == IPPROTO_UDP) {
iph->protocol = IPPROTO_TCP;
ip_send_check(iph);
}
加速器原理
加速器的原理很简单，就是UDP代理，主要难在两点，其一是怎么处理游戏客户端到加速器服务器之间的UDP连接，其二是怎么让游戏客户端去连接这个加速器（一般游戏客户端是没有设置代理服务器的功能的）
处理UDP处理UDP有两种思路，一种是协议套娃，将游戏的UDP包外面套一层TCP（UDP over TCP ），到了目的地再把TCP解包成UDP，最后在发送到游戏服务器，返回的数据包也做同样处理；另外一种是伪造TCP（FakeTCP），对UDP数据包加上伪造的TCP包头，让其看起来像是TCP协议，欺骗运营商。
UDP over TCPUDP over TCP 或者 UDP in TCP都是一回事，就是把UDP协议封装到TCP协议里。其缺点是会影响UDP传输的速率和实时性，因为TCP有可靠传输、拥塞控制、按序到达等特性，这些特性都是会牺牲速率和实时性且无法避免掉的：
- 如果网络很好不丢包，那么UDP in TCP方案会工作得很好；如果网路稍微有一点丢包，数据包的延迟会极大得增加。 （按序到达造成的副作用）
- 如果带宽充足，UDP in TCP方案也会工作得很好；如果UDP数据发送的数据一但超过了TCP的带宽，连接就会卡住一段时间，有时候会造成超过10秒的时间无法发送数据。（可靠传输、拥塞控制造成的副作用）
原理如下图所示
常见项目：
- https://github.com/mullvad/udp-over-tcp
- $$R中的udp in tcp选项
- v2ray中的VMess协议也是支持ucp over tcp
用raw socket给UDP协议直接加上伪造的TCP包头，把UDP伪装成TCP；本质上还是UDP，不需要经过系统的TCP协议栈，所以不会有UCP over TCP引入的问题。但是伪装成TCP的UDP流量可以骗过运营商的防火墙，可以避免UDP断流。这就是FakeTCP。原理如下图
