这是我参加「第三节青训营~后端场」笔记创作活动的第5篇笔记
KCP
下面是来自于官网的介绍：
KCP是一个快速可靠协议，能以比 TCP浪费10%-20%的带宽的代价，换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。纯算法实现，并不负责底层协议（如UDP）的收发，需要使用者自己定义下层数据的发送方式，以 callback的方式提供给 KCP。连时钟都需要外部传递进来，内部不会有任何一次系统调用。TCP是为流量设计的（每秒内可以传输多少KB的数据），讲究的是充分利用带宽。而 KCP是为流速设计的（单个数据从一端发送到一端需要多少时间），以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度
KCP协议的特征
在谈KCP协议的特征前，还是先贴一下KCP协议的数据段格式。
KCP格式
1. RTO不翻倍
RTO(Retransmission-TimeOut)即重传超时时间,TCP是基于ARQ协议实现的可靠性，KCP也是基于ARQ协议实现的可靠性，但TCP的超时计算是RTO2，而KCP的超时计算是RTO1.5，也就是说假如连续丢包3次，TCP是RTO8，而KCP则是RTO3.375，意味着可以更快地重新传输数据。通过4字节ts计算RTT(Round-Trip-Time)即往返时延，再通过RTT计算RTO，ts(timestamp)即当前segment发送时的时间戳。
2. 选择性重传
TCP中实现的是连续ARQ协议，再配合累计确认重传数据，只不过重传时需要将最小序号丢失的以后所有的数据都要重传，而KCP则只重传真正丢失的数据。
3. 快速重传
与TCP相同，都是通过累计确认实现的，发送端发送了1，2，3，4，5几个包，然后收到远端的ACK：1，3，4，5，当收到ACK = 3时，KCP知道2被跳过1次，收到ACK = 4时，知道2被跳过了2次，此时可以认为2号丢失，不用等超时，直接重传2号包，大大改善了丢包时的传输速度。 1字节cmd = 81时，sn相当于TCP中的seq，cmd = 82 时，sn相当于TCP中的ack。cmd相当于WebSocket协议中的openCode，即操作码。
4. 非延迟ACK
TCP在连续ARQ协议中，不会将一连串的每个数据都响应一次，而是延迟发送ACK，即上文所说的UNA模式，目的是为了充分利用带宽，但是这样会计算出较大的RTT时间，延长了丢包时的判断过程，而KCP的ACK是否延迟发送可以调节。
5. UNA + ACK
UNA模式参考特征2和特征4，ACK模式可以参考特征3。4字节una表示cmd = 81时，当前已经收到了小于una的所有数据。
6. 非退让流控
在传输及时性要求很高的小数据时，可以通过配置忽略上文所说的窗口协议中的拥塞窗口机制，而仅仅依赖于滑动窗口。2字节wnd与TCP协议中的16位窗口大小意义相同，值得一提的是，KCP协议的窗口控制还有其它途径，当cmd = 83时，表示询问远端窗口大小，当cmd = 84时，表示告知远端窗口大小。
4字节conv表示会话匹配数字，为了在KCP基于UDP实现时，让无连接的协议知道哪个是哪个，相当于WEB系统HTTP协议中的SessionID。
1字节frg表示拆数据时的编号，4字节len表示整个数据的长度，相当于WebSocket协议中的len。
总结
至于通常使用UDP来实现KCP的原因，我想大家已经有答案了。第一个是UDP的头部相对于TCP的头部来说更小，第二个是KCP相对于TCP来说有太多的冗余功能，这样白白导致了很多不必要的开销。
KCP协议在视频加速、直播推流、MOBA游戏等场景中更是大放异彩。
TFO
TCP快速打开（TCP Fast Open，TFO）是对TCP的一种简化握手手续的拓展，用于提高两端点间连接的打开速度。简而言之，就是在TCP的三次握手过程中传输实际有用的数据。这个扩展最初在Linux系统实现，Linux服务器，Linux系统上的Chrome浏览器，或运行在Linux上的其他支持的软件。
它通过握手开始时的SYN包中的TFO cookie来验证一个之前连接过的客户端。如果验证成功，它可以在三次握手最终的ACK包收到之前就开始发送数据，这样便跳过了一个绕路的行为，更在传输开始时就降低了延迟。这个加密的Cookie被存储在客户端，在一开始的连接时被设定好。然后每当客户端连接时，这个Cookie被重复返回。
请求过程
请求Fast Open Cookie
- 客户端发送SYN数据包，该数据包包含Fast Open选项，且该选项的Cookie为空，这表明客户端请求Fast Open Cookie；
- 支持TCP Fast Open的服务器生成Cookie，并将其置于SYN-ACK数据包中的Fast Open选项以发回客户端；
- 客户端收到SYN-ACK后，缓存Fast Open选项中的Cookie。
实施Fast Open
以下描述假定客户端在此前的TCP连接中已完成请求Fast Open Cookie的过程并存有有效的Fast Open Cookie。
- 客户端发送SYN数据包，该数据包包含数据（对于非TFO的普通TCP握手过程，SYN数据包中不包含数据）以及此前记录的Cookie；
- 支持TCP Fast Open的服务器会对收到Cookie进行校验：如果Cookie有效，服务器将在SYN-ACK数据包中对SYN和数据进行确认（Acknowledgement），服务器随后将数据递送至相应的应用程序；否则，服务器将丢弃SYN数据包中包含的数据，且其随后发出的SYN-ACK数据包将仅确认（Acknowledgement）SYN的对应序列号；
- 如果服务器接受了SYN数据包中的数据，服务器可在握手完成之前发送数据；
- 客户端将发送ACK确认服务器发回的SYN以及数据，但如果客户端在初始的SYN数据包中发送的数据未被确认，则客户端将重新发送数据；
- 此后的TCP连接和非TFO的正常情况一致。
注：客户端在请求并存储了Fast Open Cookie之后，可以不断重复TCP Fast Open直至服务器认为Cookie无效（通常为过期
