可靠UDP，KCP协议快在哪？

WeTest 导读

云真机已经支持手机端的画面投影。云真机实时操做，对延迟的要求比远程视频对话的要求更高（100ms之内）。在无线网络下，如何更实时、更可靠的传输视频流就成了一个挑战。经过websocket、RTMP、UDP的比较，最后选择了可靠的UDP协议KCP来进行实时音视频的传输。

 

---

 

1 简介

KCP是一个快速可靠协议，能以比 TCP浪费10%-20%的带宽的代价，换取平均延迟下降 30%-40%，且最大延迟下降三倍的传输效果。纯算法实现，并不负责底层协议（如UDP）的收发，须要使用者本身定义下层数据包的发送方式，以 callback的方式提供给 KCP。 连时钟都须要外部传递进来，内部不会有任何一次系统调用。本文传输协议之考虑UDP的状况。

 

名词说明（源码字段）：
用户数据：应用层发送的数据，如一张图片2Kb的数据
MTU：最大传输单元。即每次发送的最大数据
RTO：Retransmission TimeOut，重传超时时间。
cwnd:congestion window，拥塞窗口，表示发送方可发送多少个KCP数据包。与接收方窗口有关，与网络情况（拥塞控制）有关，与发送窗口大小有关。
rwnd:receiver window,接收方窗口大小，表示接收方还可接收多少个KCP数据包
snd_queue:待发送KCP数据包队列
snd_nxt:下一个即将发送的kcp数据包序列号
snd_una:下一个待确认的序列号

 

1.1 使用方式

1. 建立 KCP对象：

// 初始化 kcp对象，conv为一个表示会话编号的整数，和tcp的 conv同样，通讯双

// 方需保证 conv相同，相互的数据包才可以被承认，user是一个给回调函数的指针

ikcpcb *kcp = ikcp_create(conv, user);

2. 设置传输回调函数（如UDP的send函数）：

// KCP的下层协议输出函数，KCP须要发送数据时会调用它

// buf/len 表示缓存和长度

// user指针为 kcp对象建立时传入的值，用于区别多个 KCP对象

int udp_output(const char *buf, int len, ikcpcb *kcp, void *user)

{

  .... 

}

// 设置回调函数

kcp->output = udp_output;

3. 循环调用 update：

// 以必定频率调用 ikcp_update来更新 kcp状态，而且传入当前时钟（毫秒单位）

// 如 10ms调用一次，或用 ikcp_check肯定下次调用 update的时间没必要每次调用

ikcp_update(kcp, millisec);

4. 输入一个应用层数据包（如UDP收到的数据包）：

// 收到一个下层数据包（好比UDP包）时须要调用：ikcp_input(kcp,received_udp_packet,received_udp_size);

处理了下层协议的输出/输入后 KCP协议就能够正常工做了，使用 ikcp_send 来向
远端发送数据。而另外一端使用 ikcp_recv(kcp, ptr, size)来接收数据。

[ kcp源码流程图 ]

 

 

总结：UDP收到的包，不断经过kcp_input喂给KCP，KCP会对这部分数据（KCP协议数据）进行解包，从新封装成应用层用户数据，应用层经过kcp_recv获取。应用层经过kcp_send发送数据，KCP会把用户数据拆分kcp数据包，经过kcp_output，以UDP（send）的方式发送。

 

1.2 KCP的配置模式

这部分KCP文档有介绍，理解KCP协议无需过于关注。协议默认模式是一个标准的 ARQ，须要经过配置打开各项加速开关：

 

1. 工做模式：

int ikcp_nodelay(ikcpcb *kcp, int nodelay, int interval, int resend, int nc)

• nodelay ：是否启用 nodelay模式，0不启用；1启用。

• interval ：协议内部工做的 interval，单位毫秒，好比 10ms或者 20ms

• resend ：快速重传模式，默认0关闭，能够设置2（2次ACK跨越将会直接重传）

• nc ：是否关闭流控，默认是0表明不关闭，1表明关闭。

   

 

普通模式： ikcp_nodelay(kcp, 0, 40, 0, 0);

极速模式： ikcp_nodelay(kcp, 1, 10, 2, 1)

 

1. 最大窗口

int ikcp_wndsize(ikcpcb *kcp, int sndwnd, int rcvwnd);

该调用将会设置协议的最大发送窗口和最大接收窗口大小，默认为32. 这个能够理解为 TCP的 SND_BUF 和 RCV_BUF，只不过单位不同 SND/RCV_BUF 单位是字节，这个单位是包。

 

2. 最大传输单元：

纯算法协议并不负责探测 MTU，默认 mtu是1400字节，可使用ikcp_setmtu来设置该值。该值将会影响数据包归并及分片时候的最大传输单元。

 

3. 最小RTO：

无论是 TCP仍是 KCP计算 RTO时都有最小 RTO的限制，即使计算出来RTO为40ms，因为默认的 RTO是100ms，协议只有在100ms后才能检测到丢包，快速模式下为30ms，能够手动更改该值：
kcp->rx_minrto = 10;

 

1.3 KCP为何存在？

首先要看TCP与UDP的区别，TCP与UDP都是传输层的协议，比较二者的区别主要应该是说TCP比UDP多了什么？

面向链接：TCP接收方与发送方维持了一个状态（创建链接，断开链接），双方知道对方还在。
可靠的：发送出去的数据对方必定可以接收到，并且是按照发送的顺序收到的。
流量控制与拥塞控制：TCP靠谱经过滑动窗口确保，发送的数据接收方来得及收。TCP无私，发生数据包丢失的时候认为整个网络比较堵，本身放慢数据发送速度。

TCP协议的可靠与无私让使用TCP开发更为简单，同时它的这种设计也致使了慢的特色。UDP协议简单，因此它更快。可是，UDP毕竟是不可靠的，应用层收到的数据多是缺失、乱序的。KCP协议就是在保留UDP快的基础上，提供可靠的传输，应用层使用更加简单。

 

其余差异，TCP以字节流的形式，UDP以数据包的形式。不少人觉得，UDP是不可靠的，因此sendto(1000),接收端recvfrom(1000)可能会收到900。这个是错误的。所谓数据包，就是说UDP是有界的，sendto(300),sendto(500)；接收到，recvfrom(1000),recvfrom(1000)那么可能会收到300，500或者其中一个或者都没收到。UDP应用层发送的数据，在接收缓存足够的状况下，要么收到全的，要么收不到。

 

总结：TCP可靠简单，可是复杂无私，因此速度慢。KCP尽量保留UDP快的特色下，保证可靠。

 

2 KCP原理

2.1 协议简介

KCP是一个可靠的传输协议，UDP自己是不可靠的，因此须要额外信息来保证传输数据的可靠性。所以，咱们须要在传输的数据上增长一个包头。用于确保数据的可靠、有序。

0                         4      5     6      8 (BYTE)

+-------------------+----+----+----+ 

|      conv      | cmd | frg |  wnd | 

+-------------------+----+----+----+   8

|         ts         |             sn           | 

+-------------------+----------------+  16

|       una       |             len          |

+-------------------+----------------+   24

|                                                   |

|            DATA (optional)          |

|                                                   |

+-------------------------------------+

conv:链接号。UDP是无链接的，conv用于表示来自于哪一个客户端。对链接的一种替代
cmd:命令字。如，IKCP_CMD_ACK确认命令，IKCP_CMD_WASK接收窗口大小询问命令，IKCP_CMD_WINS接收窗口大小告知命令，
frg:分片，用户数据可能会被分红多个KCP包，发送出去
wnd:接收窗口大小，发送方的发送窗口不能超过接收方给出的数值
ts:时间序列
sn:序列号
una:下一个可接收的序列号。其实就是确认号，收到sn=10的包，una为11
len：数据长度
data:用户数据

 

后面的讲解，主要以极速模式： ikcp_nodelay(kcp, 1, 10, 2, 1)为主，启用nodelay设置，刷新间隔控制在10ms，开启快速重传模式，关闭流量控制。

 

2.2 数据发送过程

2.2.1 数据发送准备

用户发送数据的函数为ikcp_send。
ikcp_send(ikcpcb kcp, const char buffer, int len)
该函数的功能很是简单，把用户发送的数据根据MSS进行分片。如上图，用户发送1900字节的数据，MTU为1400byte。所以，该函数会把1900byte的用户数据分红两个包，一个数据大小为1400，头frg设置为1，len设置为1400；第二个包，头frg设置为0，len设置为500。切好KCP包以后，放入到名为snd_queue的待发送队列中。

注：流模式状况下，kcp会把两次发送的数据衔接为一个完整的kcp包。非流模式下，用户数据%MSS的包，也会做为一个包发送出去。

MTU，数据链路层规定的每一帧的最大长度，超过这个长度数据会被分片。一般MTU的长度为1500字节，IP协议规定全部的路由器均应该可以转发（512数据+60IP首部+4预留=576字节）的数据。MSS，最大输出大小（双方的约定），KCP的大小为MTU-kcp头24字节。IP数据报越短，路由器转发越快，可是资源利用率越低。传输链路上的全部MTU都一至的状况下效率最高，应该尽量的避免数据传输的工程中，再次被分。UDP再次被分的后（一般1分为2），只要丢失其中的任意一份，两份都要从新传输。所以，合理的MTU应该是保证数据不被再分的前提下，尽量的大。
以太网的MTU一般为1500字节-IP头（20字节固定+40字节可选）-UDP头8个字节=1472字节。KCP会考虑多传输协议，可是在UDP的状况下，设置为1472字节更为合理。

 

2.2.2 实际发送

KCP会不停的进行update更新最新状况，数据的实际发送在update时进行。发送过程以下图所示：

[ KCP 发送过程 ]

 

步骤1：待发送队列移至发送队列
KCP会把snd_queue待发送队列中的kcp包，移至snd_buf发送队列。移动的包的数量不会超过snd_una+cwnd-snd_nxt，确保发送的数据不会让接收方的接收队列溢出。该功能相似于TCP协议中的滑动窗口。cwnd=min(snd_wnd,rmt_wnd,kcp->cwnd)的最小值决定，snd_wnd，rmt_wnd比较好理解可发送的数据，可发送的数据最大值，应该是发送方能够发送的数据和接收方能够接收的数据的最小值。kcp->cwnd是拥塞控制的一个值，跟网络情况相关，网络情况差的时候，KCP认为应该下降发送的数据，后面会有详细的介绍。
如上图中，snd_queue待发送队列中有4个KCP包等待发送，这个时候snd_nxt下一个发送的kcp包序列号为11，snd_una下一个确认的KCP包为9（8已经确认，9，10已经发送可是还没获得接收方的确认）。由于cwnd=5，发送队列中还有2个发送了可是还未获得确认，因此能够从待发送队列中取前面的3个KCP包放入到发送队列中，序列号分别设置为11,12,13。

 

步骤2：发送发送队列的数据
发送队列中包含两种类型的数据，已发送可是还没有被接收方确认的数据，没被发送过的数据。没发送过的数据比较好处理，直接发送便可。重点在于已经发送了可是还没被接收方确认的数据，该部分的策略直接决定着协议快速、高效与否。KCP主要使用两种策略来决定是否须要重传KCP数据包，超时重传、快速重传、选择重传。

 

一、超时重传
TCP超时计算是RTOx2，这样连续丢三次包就变成RTOx8了，而KCP非快速模式下每次+RTO，急速模式下+0.5RTO（实验证实1.5这个值相对比较好），提升了传输速度。

 

[ RTO算法对比图 ]

 

二、快速重传
发送端发送了1,2,3,4,5几个包，而后收到远端的ACK: 1, 3, 4, 5，当收到ACK3时，KCP知道2被跳过1次，收到ACK4时，知道2被跳过了2次，此时能够认为2号丢失，不用等超时，直接重传2号包，大大改善了丢包时的传输速度。TCP有快速重传算法，TCP包被跳过3次以后会进行重传。
注：能够经过统计错误重传（重传的包实际没丢，仅乱序），优化该设置。

 

三、选择重传
老的TCP丢包时会所有重传从丢的那个包开始之后的数据，KCP是选择性重传，只重传真正丢失的数据包。可是，目前大部分的操做系统，linux与android手机均是支持SACK选择重传的。

 

步骤3：数据发送
经过步骤2断定，kcp包是否须要发送，若是须要发送的kcp包则经过，kcp_setoutput设置的发送接口进行发送，UDP一般为sendto。步骤3，会对较小的kcp包进行合并，一次性发送提升效率

 

2.3 数据接收过程

KCP的接收过程是将UDP收到的数据进行解包，从新组装顺序的、可靠的数据后交付给用户。

 

2.3.1 KCP数据包接收

 

kcp_input输入UDP收到的数据包。kcp包对前面的24个字节进行解压，包括conv、 frg、 cmd、 wnd、 ts、 sn、 una、 len。根据una，会删除snd_buf中，全部una以前的kcp数据包，由于这些数据包接收者已经确认。根据wnd更新接收端接收窗口大小。根据不一样的命令字进行分别处理。数据接收后，更新流程以下所示：

[ 接收处理流程图 ]

 

一、IKCP_CMD_PUSH数据发送命令
a、KCP会把收到的数据包的sn及ts放置在acklist中，两个相邻的节点为一组，分别存储sn和ts。update时会读取acklist，并以IKCP_CMD_ACK的命令返回确认包。以下图中，收到了两个kpc包，acklist中会分别存放10,123,11,124。
b、kcp数据包放置rcv_buf队列。丢弃接收窗口以外的和重复的包。而后将rcv_buf中的包，移至rcv_queue。原来的rcv_buf中已经有sn=10和sn=13的包了，sn=10的kcp包已经在rcv_buf中了，所以新收到的包会直接丢弃掉，sn=11的包放置至rcv_buf中。
c、把rcv_buf中前面连续的数据sn=11，12，13所有移动至rcv_queue，rcv_nxt也变成14。

rcv_queue的数据是连续的，rcv_buf多是间隔的
d、kcp_recv函数，用户获取接收到数据（去除kcp头的用户数据）。该函数根据frg，把kcp包数据进行组合返回给用户。

 

二、IKCP_CMD_ACK数据确认包
两个使命：一、RTO更新，二、确认发送包接收方已接收到。

 

正常状况：收到的sn为11,una为12。表示sn为11的已经确认，下一个等待接收的为12。发送队列中，待确认的一个包为11，这个时候snd_una向后移动一位，序列号为11的包从发送队列中删除。

[ 数据确认包处理流程 ]

 

异常状况：以下图所示，sn!=11的状况均为异常状况。sn<11表示，收到重复确认的包，如原本觉得丢失的包从新又收到了，因此产生重复确认的包；sn>17，收到没发送过的序列号，几率极低，多是conv没变重启程序致使的；112，则启动快速重传

[ KCP快速确认 ]

 

确认包发送，接收到的包会所有放在acklist中，以IKCP_CMD_ACK包发送出去

 

3 流量控制与拥塞控制

 

3.1 RTO计算（与TCP彻底同样）

RTT：一个报文段发送出去，到收到对应确认包的时间差。
SRTT(kcp->rx_srtt)：RTT的一个加权RTT平均值，平滑值。
RTTVAR(kcp->rx_rttval)：RTT的平均误差，用来衡量RTT的抖动。

 

3.2 流量控制

流量控制是点对点的通讯量的控制，是一个端到端的问题。总结起来，就是发送方的速度要匹配接收方接收（处理）数据的速度。发送方要抑制自身的发送速率，以便使接收端来得及接收。

KCP的发送机制采用TCP的滑动窗口方式，能够很是容易的控制流量。KCP的头中包含wnd，即接收方目前能够接收的大小。可以发送的数据即为snd_una与snd_una+wnd之间的数据。接收方每次都会告诉发送方我还能接收多少，发送方就控制下，确保本身发送的数据很少于接收端能够接收的大小。

 

KCP默认为32，便可以接收最大为32*MTU=43.75kB。KCP采用update的方式，更新间隔为10ms，那么KCP限定了你最大传输速率为4375kB/s，在高网速传输大内容的状况下须要调用ikcp_wndsize调整接收与发送窗口。

 

KCP的主要特点在于实时性高，对于实时性高的应用，若是发生数据堆积会形成延迟的持续增大。建议从应用侧更好的控制发送流量与网络速度持平，避免缓存堆积延迟。（详见参考资料）

 

3.3 拥塞控制（KCP可关闭）

KCP的优点在于能够彻底关闭拥塞控制，很是自私的进行发送。KCP采用的拥塞控制策略为TCP最古老的策略，无任何优点。彻底关闭拥塞控制，也不是一个最优策略，它全是会形成更为拥堵的状况。
网络中链路的带宽，与整条网络中的交换节点（路由器、交换机、基站等）有关。若是，全部使用该链路的流量超出了，该链路所能提供的能力，就会发生拥塞。车多路窄，就会堵车，车越多堵的越厉害。所以，TCP做为一个大公无私的协议，当网络上发送拥堵的时候会下降自身发送数据的速度。拥塞控制是整个网络的事情，流量控制是发送和接收两方的事情。
当发送方没有按时接收到确认包，就认为网络发生了拥堵行为。TCP拥塞控制的方式，归结为慢开始、拥塞避免，以下图所示

[ 拥塞控制算法 ]

 

KCP发生丢包的状况下的拥塞控制策略与TCP Tahoe版本的策略一致。TCP Reno版本已经使用快恢复策略。所以，丢包的状况下，其实KCP拥塞控制策略比TCP更为苛刻。

KCP在发生快速重传，数据包乱序时，采用的是TCP快恢复的策略。控制窗口调整为已经发送没有接收到ack的数据包数目的一半+resent。

注：目前kernel 3.2以上的linux，默认采用google改进的拥塞控制算法，Proportional Rate Reduction for TCP。该算法的主要特色为，的cwnd以下图所示：

 

 

 

 

手机投射静态演示

 

---

 

目前，“WeTest助手”的手机控制器已经上线，完美复制真机体验，体验畅快淋漓的操做！

 

点击连接：http://wetest.qq.com/cloud/help/effective 便可下载“WeTest助手”。

 

 

 

若是使用当中有任何疑问，欢迎咨询腾讯WeTest企业QQ：800024531

 

  腾讯WeTest有奖征文活动进行中，欢迎投稿！了解详情：
http://wetest.qq.com/lab/view/379.html