作者：许敏华，腾讯 IEG 高级工程师
商业转载请联系腾讯 WeTest 获得授权，非商业转载请注明出处。
原文链接：http://wetest.qq.com/lab/view/391.html
云真机已经支持手机端的画面投影。云真机实时操作，对延迟的要求比远程视频对话的要求更高（100ms 以内）。在无线网络下，如何更实时、更可靠的传输视频流就成了一个挑战。通过 websocket、RTMP、UDP 的比较，最后选择了可靠的 UDP 协议 KCP 来进行实时音视频的传输。
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:下一个待确认的序列号
// 初始化 kcp 对象，conv 为一个表示会话编号的整数，和 tcp 的 conv 一样，通信双
// 方需保证 conv 相同，相互的数据包才能够被认可，user 是一个给回调函数的指针
ikcpcb *kcp = ikcp_create(conv, user);
// KCP 的下层协议输出函数，KCP 需要发送数据时会调用它
// buf/len 表示缓存和长度
// user 指针为 kcp 对象创建时传入的值，用于区别多个 KCP 对象
int udp_output(const char *buf, int len, ikcpcb *kcp, void *user)
{
....
}
// 设置回调函数
kcp->output = udp_output;
// 以一定频率调用 ikcp_update 来更新 kcp 状态，并且传入当前时钟（毫秒单位）
// 如 10ms 调用一次，或用 ikcp_check 确定下次调用 update 的时间不必每次调用
ikcp_update(kcp, millisec);
// 收到一个下层数据包（比如 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）的方式发送。
这部分 KCP 文档有介绍，理解 KCP 协议无需过于关注。协议默认模式是一个标准的 ARQ，需要通过配置打开各项加速开关：
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)
int ikcp_wndsize(ikcpcb *kcp, int sndwnd, int rcvwnd);
该调用将会设置协议的最大发送窗口和最大接收窗口大小，默认为 32. 这个可以理解为 TCP 的 SND_BUF 和 RCV_BUF，只不过单位不一样 SND/RCV_BUF 单位是字节，这个单位是包。
纯算法协议并不负责探测 MTU，默认 mtu 是 1400 字节，可以使用 ikcp_setmtu 来设置该值。该值将会影响数据包归并及分片时候的最大传输单元。
不管是 TCP 还是 KCP 计算 RTO 时都有最小 RTO 的限制，即便计算出来 RTO 为 40ms，由于默认的 RTO 是 100ms，协议只有在 100ms 后才能检测到丢包，快速模式下为 30ms，可以手动更改该值：
kcp->rx_minrto = 10;
首先要看 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 快的特点下，保证可靠。
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，开启快速重传模式，关闭流量控制。
用户发送数据的函数为 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 字节更为合理。
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 数据包，超时重传、快速重传、选择重传。
1、超时重传
TCP 超时计算是 RTOx2，这样连续丢三次包就变成 RTOx8 了，而 KCP 非快速模式下每次 +RTO，急速模式下 +0.5RTO（实验证明 1.5 这个值相对比较好），提高了传输速度。
[ RTO 算法对比图 ]
2、快速重传
发送端发送了 1,2,3,4,5 几个包，然后收到远端的 ACK: 1, 3, 4, 5，当收到 ACK3 时，KCP 知道 2 被跳过 1 次，收到 ACK4 时，知道 2 被跳过了 2 次，此时可以认为 2 号丢失，不用等超时，直接重传 2 号包，大大改善了丢包时的传输速度。TCP 有快速重传算法，TCP 包被跳过 3 次之后会进行重传。
注：可以通过统计错误重传（重传的包实际没丢，仅乱序），优化该设置。
3、选择重传
老的 TCP 丢包时会全部重传从丢的那个包开始以后的数据，KCP 是选择性重传，只重传真正丢失的数据包。但是，目前大部分的操作系统，linux 与 android 手机均是支持 SACK 选择重传的。
步骤 3：数据发送
通过步骤 2 判定，kcp 包是否需要发送，如果需要发送的 kcp 包则通过，kcp_setoutput 设置的发送接口进行发送，UDP 通常为 sendto。步骤 3，会对较小的 kcp 包进行合并，一次性发送提高效率
KCP 的接收过程是将 UDP 收到的数据进行解包，重新组装顺序的、可靠的数据后交付给用户。
kcp_input 输入 UDP 收到的数据包。kcp 包对前面的 24 个字节进行解压，包括 conv、 frg、 cmd、 wnd、 ts、 sn、 una、 len。根据 una，会删除 snd_buf 中，所有 una 之前的 kcp 数据包，因为这些数据包接收者已经确认。根据 wnd 更新接收端接收窗口大小。根据不同的命令字进行分别处理。数据接收后，更新流程如下所示：
[ 接收处理流程图 ]
1、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 包数据进行组合返回给用户。
2、IKCP_CMD_ACK 数据确认包
两个使命：1、RTO 更新，2、确认发送包接收方已接收到。
正常情况：收到的 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 流量控制与拥塞控制
）
RTT：一个报文段发送出去，到收到对应确认包的时间差。
SRTT(kcp->rx_srtt)：RTT 的一个加权 RTT 平均值，平滑值。
RTTVAR(kcp->rx_rttval)：RTT 的平均偏差，用来衡量 RTT 的抖动。
流量控制是点对点的通信量的控制，是一个端到端的问题。总结起来，就是发送方的速度要匹配接收方接收（处理）数据的速度。发送方要抑制自身的发送速率，以便使接收端来得及接收。
KCP 的发送机制采用 TCP 的滑动窗口方式，可以非常容易的控制流量。KCP 的头中包含 wnd，即接收方目前可以接收的大小。能够发送的数据即为 snd_una 与 snd_una+wnd 之间的数据。接收方每次都会告诉发送方我还能接收多少，发送方就控制下，确保自己发送的数据不多于接收端可以接收的大小。
KCP 默认为 32，即可以接收最大为 32*MTU=43.75kB。KCP 采用 update 的方式，更新间隔为 10ms，那么 KCP 限定了你最大传输速率为 4375kB/s，在高网速传输大内容的情况下需要调用 ikcp_wndsize 调整接收与发送窗口。
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 如下图所示：
参考资料：
https://github.com/skywind3000/kcp/wiki/Flow-Control-for-Users
手机投射静态演示
目前，“WeTest 助手” 的手机控制器已经上线，完美复制真机体验，体验畅快淋漓的操作！
点击链接：http://wetest.qq.com/cloud/help/effective 即可下载 “WeTest 助手”。
如果使用当中有任何疑问，欢迎咨询腾讯 WeTest 企业 QQ：800024531
腾讯 WeTest 有奖征文活动进行中，欢迎投稿！了解详情：
http://wetest.qq.com/lab/view/379.html
