建网站能上传多少数据在线磁力搜索引擎

运营商针对 UDP 进行限制，这是 QUIC 以及类似 UDP-Based 协议的推广阻力之一，上了线很多问题，丢包，慢等的问题严重增加运维，运营成本。

按照运营商五元组 QoS 这种简单粗暴不惹事的原则，只要换一个端口就可绕开限制。很多 UDP 服务，用久了就慢，往往重启一下就好了，大概就是这原因，我不是运营商，所以不能确定。

此外，若限制单 IP 或源 IP/目标 IP 二元组，考虑到 NAT，可能引起用户投诉，所以如果要限制 IP 二元组，一般发生在 NAT 之前。

千万不要觉得运营商在公网大流量下解析 TCP，UDP 报头是什么难事，TCP 和 UDP 报头均将两个端口号放在前 32 位，解析两个协议可用同一套代码，从固定位置取值 hash 即可。如果 TCP 当初将端口号安排在报头变长部分，或者干脆和 payload 一起加密，就真没法解析了，运营商就没办法将数据包映射到流。但这也损害了端主机的分层模型-必须在解密后才能解复用(密钥从何协商而来?)，或至少要先 “理解” 上层逻辑，从 TLV 中解出端口…

UDP-Based 协议的优势是可随便换端口，可这么好的特性往往大家都不用，偏偏把 UDP 视作 “连接”。QUIC 头有个 Connection ID 字段，这个才标识 “连接”，UDP packet 只是一个箱子，所以 QUIC 可以通过不断换端口来避开 QoS 限制。若是自研协议，可以学 QUIC 的样子换端口，加个 “会话层” 而已。

我此前的经验，换端口有时没有效果有时有，限速发生在不同位置效果不同。举个例子，如果运营商对你的流量做了 NAT，且在 NAT 之前针对你的源 IP/目标 IP 二元组限制，那换端口也没用，但在 NAT 之后，多 inner IP 共享少得多的 outer IP，典型的 NAPT 场景，运营商一般不会对 IP 二元组进行限制以免误伤招致投诉甚至客户流失，这种情况下，你换端口，基本上就绕过了。

此外，IPv6 可能还不太一样，虽然 IPv6 号称可以点到点，但同时也可以更精细定位到谁是谁。

在 QoS 限制五元组之外，运营商还可能针对目标端口进行限制。由于 UDP 无连接，易打洞的特点，在公网私搭服务器是相对容易的，但凡运营商发现有大流量发向同一端口，可能就会限制了。关于目标端口要不要换的问题，能换就换。
我倾向于在传输层以上实现自己的换端口协议，无论换源端口还是换目标端口，就像 QUIC 那样。

再看 TCP。

TCP 自带拥塞控制，sender 发太猛会丢包，丢包会乘法比例减少 cwnd，似乎不需要额外 QoS 限制。但运营商的事该做还得做，且谁也不能保证 sender 的 TCP 实现一定标准，现在有很多魔改，如一个报文发两遍，所谓 FEC 就是这样跟运营商对着干，抢带宽。

运营商 QoS 手段很简单，跟 UDP 一样，直接针对元组限速或丢包(也可能是管理员疏忽或懒惰，加上的限制策略忘删了)。应对方案也一样，断开重连，换个端口。但由于很多应用都没断点续传，TCP 重连成本很高，虽有 fastopen 新特性，但运营商设备往往不支持。

但可构建 TCP 隧道，实现类似直播的延时 buffer，断点续传，通过这个方法重连 TCP 隧道，达到换端口的目的。或构建多条隧道实现平滑切端口。

TCP 四次挥手太昂贵，Time-Wait 没现实意义，为降低 TCP 断连成本，选择 RST 而不是优雅断开是高尚的。

TCP 为闭环，处理 SYN/FIN 状态机最麻烦，如果经常和 TCP 打交道，80%+ 的问题都和连接管理相关，但 TCP 连接管理标准中想避开的问题发生概率极低。不为小概率事件付出太多，这是 RST 断连的依据。fastopen 运营商不支持也没办法，但还是要试一下 SYN 报文携带一些数据能不能过去，我用该手段做过一个敲门方案，完全可以通过(但不能保证所有线路都可通过)，如果对端是自己的，那就收了，省掉握手开销。

换端口，RST 重连，SYN 捎带，这些都是简单常见的绕开限制的方法，至于别的一些奇技淫巧，参考 TCP 不可靠传输 和 假 TCP。

浙江温州皮鞋湿，下雨进水不会胖。