kcp

这次仅粗略了解了一下kcp，没有对ARQ算法细究。

1.kcp-go作者实现了net.Coon接口，所以实际在处理recv(粘包)和send(保证发完)等逻辑时，感知不到底层是tcp还是kcp，换句话说tcp也是这么写。

2.对于服务器来说，对每个客户kcp也是新建一个对应的goroutine来处理，这一点也是和tcp一样的

3.所以很容易在kcp和tcp上再封装一层，只需要在Create的时候指定是tcp还是kcp就可以了

当然，也发现了一些kcp与tcp不一样的地方。 比如：一个在服务器端非常不一样的例子： 对于tcp来说，每个客户端连接都会有一个fd，因为tcp是面向链接的，有了fd才建立起四元组才能和对端发信，读写都是在这个fd上

但是kcp，只有一个系统fd在读写，就是listen的这个。因为kcp是udp实现的，不需要面向链接也没法面向链接，kcp根据从recvfrom中返回的RemoteAddr 来区分不同的“链接”，并且为每个新的RemoteAddr创建一个session，这个session可以认为是“用户层fd”，消息来了根据RemoteAddr分发给对应session（放到buffer里，等用户调用Read）。

从客户端的角度来看，所有客户端都是知道服务器的同一个ip+port组合，有消息都是udp往这发，所以服务器也都是从这里收，写的时候udp直接指定RemoteAddr sendto就可以，也没有必要新建fd

kcp之所以快，和它的用户态也有很大关系。

另外就是kcp没有定义诸如 SYN/FIN之类的标志，所以应用层必须增加心跳包类的机制来判断“链接”是否失效了。针对网络攻击也要有不一样的手段？

kcp C作者说： TCP是为流量设计的（每秒内可以传输多少KB的数据），讲究的是充分利用带宽。 而KCP是为流速设计的（单个数据包从一端发送到一端需要多少时间），以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。 TCP信道是一条流速很慢，但每秒流量很大的大运河，而KCP是水流湍急的小激流。

也就是说，tcp更注重单位时间内的流量要大，而kcp的算法要的是更快，所以重传更敏感等，在丢包率高和长距离的传输上表现更平稳。 但也不能说kcp就比tcp屌什么的，在网络刚兴起的时候带宽肯定是宝贵的资源，tcp为充分利用带宽而设计无可厚非。 但是在当今4G/5G横行，流量便宜的年代，kcp是否就要比tcp好呢？我觉得这不是关键，因为网络本身发展的太快了，从2G->3G->4G->5G，未来还有6G，7G 等5G真正普及了，kcp比tcp快的优势就更小了，而且5G已经足够快了。所以说，流量重要吗？重要，也不重要；更快一点好吗？好，也没那么好。