基于 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的缺点,那就是后话了,等五年后有兴趣了我再来补充!