UDP的可靠传输
UDP与TCP
提到UDP的可靠传输，TCP是绕不过的话题。TCP相对于UDP的传输结果的区别也就是TCP的数据传输是可靠的，而UDP的数据传输是不可靠的。
下图可以看到TCP和UDP的区别：
可以看到，虽然UDP的数据传输是不可靠的，但是也有很多应用场景。最主要的原因就是因为UDP能够实现实时传输的功能，而TCP无法很好地做到实时传输。
那是否能够实现既能够实时传输数据，又能够可靠地传输呢？
答案是：可以。
首先了解一些TCP的可靠传输由哪些机制实现
- ACK机制：针对发送端发出的数据包的确认应答信号ACK
- 重传机制：针对数据包丢失或者出现定时器超时的重发机制
- 顺序机制：针对数据包到达接收端主机顺序乱掉的顺序控制
- 窗口机制：针对高效传输数据包的流动窗口控制
- 拥塞机制：针对避免网络拥堵时候的流量控制
UDP是面向报文的，缓存区有数据就传输。因此UDP不存在这些机制，但是可以通过添加控制头的形式实现这些机制的功能。KCP协议就是这样的一个快速可靠协议。
KCP协议
KCP简介：KCP协议没有规定下层传输协议，但是一般用udp作为下层传输协议，KCP层协议的数据包在UDP数据报文的基础上增加控制头。得到的结果就是以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。
KCP是在UDP传输的数据上增加一个包头，用于确保数据的可靠和有序。如下：
- [0,3]前0~3个字节是conv:连接号。UDP是无连接的，conv用于表示来自于哪个客户端。对面向连接的一种替代
- [4]cmd:命令字。如，IKCP_CMD_ACK确认命令，IKCP_CMD_WASK接收窗口大小询问命令，IKCP_CMD_WINS接收窗口大小告知命令，
- [5]frg:分片，用户数据可能会被分成多个KCP包，发送出去
- [6,7]wnd:接收窗口大小，发送方的发送窗口不能超过接收方给出的数值
- [8,11]ts:时间序列
- [12,15]sn:序列号
- [16,19]una:下一个可接收的序列号。其实就是确认号，收到sn=10的包，una为11
- [20,23]len：数据长度
- data:用户数据
KCP实现TCP的可靠传输机制
确认机制：可以由KCP协议头的una字节实现。
顺序机制可以通过sn序列号字节实现，在程序逻辑中将发送来的KCP包按照sn序号排序在rec_buf中（KCP保存接收数据的一个缓存区）。实现接收数据包不乱序的功能。
窗口机制：可以由wnd接收窗口大小实现。即接收方目前可以接收的大小。该窗口的大小是动态调整的，与窗口的大小和缓冲区现有数据多少有关。接收方每次都会告诉发送方我还能接收多少，发送方就控制下，确保自己发送的数据不多于接收端可以接收的大小。假设接收方的窗口已满，发送方一定时间后还会发送探测窗口数据询问对方的窗口size
重传机制：KCP主要使用两种策略来决定是否需要重传KCP数据包，超时重传、选择重传。
- 超时重传
TCP超时计算是RTOx2 （Retransmission TimeOut，RTO即重传超时时间），这样连续丢三次包就变成RTOx8了，而KCP非快速模式下每次+RTO，急速模式下+0.5RTO（实验证明1.5这个值相对比较好），提高了传输速度。KCP中使用时间序列ts来计算超时时间。 - 选择重传
老的TCP丢包时会全部重传从丢的那个包开始以后的数据，KCP是选择性重传，只重传真正丢失的数据包。
拥塞机制：KCP在发生快速重传，数据包乱序时，采用的是TCP快恢复的策略。(但是KCP的优势在于可以完全关闭拥塞控制，非常自私的进行发送。网络拥塞并不是用户的问题，是链路层带宽大小的问题，KCP可以始终保持最大发送流量)
上述就是基于UDP的KCP协议实现可靠传输的大致基本原理，KCP的源码还涉及到很多细节，包括不限于重传模式的选择，流量控制等功能的实现。
TCP与KCP的对比
TCP TCP协议的可靠性让使用TCP开发更为简单，同时它的这种设计也导致了慢的特点。 TCP是为流量设计的（每秒内可以传输多少KB的数据），讲究的是充分利用带宽。 TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，建立了繁琐的握手过程以及重传策略。由于TCP内置在系统协议栈中，极难对其进行改进。
KCP KCP协议就是在保留UDP快的基础上，提供可靠的传输，应用层使用更加简单——TCP可靠简单，但是复杂无私，所以速度慢。KCP尽可能保留UDP快的特点下，保证可靠。 TCP是为流量设计的（每秒内可以传输多少KB的数据），讲究的是充分利用带宽。KCP是为流速设计的（单个数据包从一端发送到一端需要多少时间），以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。TCP信道是一条流速很慢，但每秒流量很大的大运河，而KCP是水流湍急的小激流。 tcp追求的是完全可靠性和顺序性，丢包后会持续重传直至该包被确认，否则后续包也不会被上层接收，且重传采用指数避让策略，决定重传时间间隔的RTO(retransmission timeout)不可控制，linux内核实现中最低值为200ms，这样的机制会导致丢包率短暂升高的情况下应用层消息响应延迟急剧提高，并不适合实时性高、网络环境复杂的游戏。
