基于 udp 定制传输层协议，引入顺序性和适当程度或者可调节程度的可靠性，修改流控算法。适当放弃重传，如：设置最大重传次数，即使重传失败，也不需要重新建立连接。比较知名的 tcp 加速开源方案有：quic、enet、kcp、udt。其中，quic 是源自 google 的 tcp 替代方案，其主要目的是为了整合 TCP 协议的可靠性和 udp 协议的速度和效率，其主要特性包括：避免前序包阻塞、减少数据包、向前纠错、会话重启和并行下载等，然而 QUIC 对标的是 TCP+TLS+SPDY，相比其他方案更重，目前国内用于网络游戏较少。kcp 的作者是国内优秀开发者，社区也发展良好，kcp 的作者和社区开发者对 enet、kcp、udt 做了性能测试，kcp 表现不错，其次是 enet，表现最差的是 udt。不过，这里也提出一个问题，原始 enet 保留了 tcp 重传的指数避让特性，每次重传间隔还是乘以 2，默认 rto 也较高，这可能是测试中 enet 表现不如 kcp 的主要原因。
浅谈moba游戏的技术和需求(2)
主流的moba在传输层协议上采用udp，上层实现tcp的一些功能，以及通过一定的冗余数据保证尽量少的重传发生，如果非要才用tcp，也有一些对优化办法，
其次很多都是建议moba采用定点，但是定点的数学库麻烦，很多都要自己重写，如果非要采用浮点也有一些办法。
下面主要针对这2点进行讨论。
请问游戏服务器，端口映射应用TCP协议还是UDP协议？端口号是否有影响？例如我的世界的服务器。.
从原理上，TCP的优势有：
简单直接的长连接
可靠的信息传输
数据包的大小没有限制
任何一个和TCP打过交道的人都知道，要实现一个稳定的TCP网络连接，需要处理各种隐藏的坑，比如断线检测、慢速客户端响应阻塞数据包，对开放连接的各种dos攻击，阻塞和非阻塞IO模型等等。
除了上面列出的这些问题外，一个好的TCP模块确实不好编码实现。
但是，TCP最糟糕的特性是它对阻塞的控制。一般来说，TCP假定丢包是由于网络带宽不够造成的，所以发生这种情况的时候，TCP就会减少发包速度。
在3G或WiFi下，一个数据包丢失了，你希望的是立马重发这个数据包，然而TCP的阻塞机制却完全是采用相反的方式来处理！
而且没有任何办法能够绕过这个机制，因为这是TCP协议构建的基础。这就是为什么在3G或者WiFi环境下，ping值能够上升到1000多毫秒的原因。
为什么不用UDP
UDP相对TCP来说既简单又困难。
举个例子来说，UDP是基于数据包构建，这意味着在某些方面需要你完全颠覆在TCP下的观念。UDP只使用一个socket进行通信，不像TCP需要为每一个客户端建立一个socket连接。这些都是UDP非常不错的地方。
但是，大多数情况下你需要的仅仅是一些连接的概念罢了，一些基本的包序功能，以及所谓的连接可靠性。可惜的是，这些功能UDP都没有办法简单的提供给你，而你使用TCP却都可以免费得到。
这也是人们为什么经常推荐TCP的原因。在用TCP的时候你可以不考虑这些问题，直到你需要同步连接的数量级达到500以上的时候。
所以，是的，UDP没有提供所有的解决方法，但是就像你看到的那样，这也正是UDP好用的地方。在某种意义上来说，TCP对UDP就好比是Hibernate和手写SQL的区别。
为什么用RUDP，而不用TCP或UDP
（RUDP：Reliable UDP）
可靠用户数据报协议（RUDP）是一种基于可靠数据协议 (RDP： RFC908 和 1151 （第二版 )) 的简单分组传输协议。作为一个可靠传输协议， RUDP 用于传输 IP 网络间的电话信号。它允许独立配置每个连接属性，这样在不同的平台可以同时实施不同传输需求下的协议。 UDP/IP 协议中的 RUDP 是分层的并为虚拟连接提供可靠有序发送（直到重新发送的最大数目）。 RUDP 设计灵活，便于多种传输层使用。传输电讯号协议就是其应用之一。
RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。
为了与网络 TCP 通信量同时工作， RUDP 使用类似于 TCP 的重发机制和拥塞控制算法。在最大化利用可用带宽上，这些算法都得到了很好的证明。
RUDP 特征包括：
客户机确认响应服务器发送给客户机的包；
视窗和拥塞控制，服务器不能超出当前允许带宽；
一旦发生包丢失，服务器重发给客户机；
比实时流更快速，称为“缓存溢出”。
http3不再使用tcp协议的原因
http3不再使用tcp协议的原因
上一篇文章整理了http0.9-http3的整个变化过程，但是说的不是很详细。比如浏览器是如何利用http1.1的，多个请求如何处理？http2到http3的底层协议特点以及对应的改变背景都没有说清楚。
今天就专门针对http3不再使用底层的tcp协议这个问题作为引子，详细阐述下对应的改变原因。
首先说我们经常提到的 TCP协议 ：
TCP协议通过数据分片、到达确认、超时重发、滑动窗口、失序处理、重复处理、数据校验等规定，为使用TCP连接的双方提供一个面向连接、可靠的字节流服务。
但是TCP连接这个概念还是比较抽象。
我们可以这么理解，电话两端有两个接线员，电话之间通过电话线进行连接。在正式通话时，电话员A向接线员B拨号并说了这么一句话：有人吗？接线员B回了一句：我在！接线员A又说道：ok我知道了。这相当于TCP连接建立时的三次握手，用来确定双方状态。之后两边电话员就可以正常你来我往的通话了。
同时为了避免两个人的沟通内容有缺失等问题，两边还规定了如何交流，信号中断了如何处理等等。
TCP断开时则需要进行四次挥手过程，这个就没必要细说了。至于为什么是前三后四，这是因为校验太多了也没用，所以就采取了最少验证次数。
接下来聊聊 UDP协议 ：
我们要知道，它最大的特点是无连接。也就是信息在传输数据之前不需要建立连接，当想要发送数据时，就把数据包尽可能快地扔到网络上，至于收没收到，就不管了（虽然这很重要）
那么，既然UDP协议这么不可靠，HTTP3为何还要使用UDP协议？
我们在上一篇文章中也讲到了HTTP2的一些问题，其中基于TCP协议的HTTP协议永远无法解决队头阻塞的问题，这样的话，数据传输速度无法进一步加快。
HTTP3是基于UDP协议的，它同时还做了一些其他处理，比如增加数据包重传、拥塞控、调整传输节奏等等。其其核心思想是将TCP协议在内核实现的诸如可靠传输、流量控制、拥塞控制等功能转移到用户态来实现，同时在加密传输方向的尝试也推动了TLS1.3的发展。
至于说http3的缺点，那就是后话了，等五年后有兴趣了我再来补充！
相关推荐：
