当前位置: 首页 > 软件库 > 程序开发 > 协议和规范 >

KCP

快速可靠网络传输协议
授权协议 GPLv2
开发语言 C/C++
所属分类 程序开发、 协议和规范
软件类型 开源软件
地区 国产
投 递 者 诸葛绍元
操作系统 跨平台
开源组织
适用人群 未知
 软件概览

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

整个协议只有 ikcp.h, ikcp.c两个源文件,可以方便的集成到用户自己的协议栈中。也许你实现了一个P2P,或者某个基于 UDP的协议,而缺乏一套完善的ARQ可靠协议实现,那么简单的拷贝这两个文件到现有项目中,稍微编写两行代码,即可使用。

技术特性

TCP是为流量设计的(每秒内可以传输多少KB的数据),讲究的是充分利用带宽。而KCP是为流速设计的(单个数据包从一端发送到一端需要多少时间),以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。TCP信道是一条流速很慢,但每秒流量很大的大运河,而KCP是水流湍急的小激流。KCP有正常模式和快速模式两种,通过以下策略达到提高流速的结果:

RTO翻倍vs不翻倍:

TCP超时计算是RTOx2,这样连续丢三次包就变成RTOx8了,十分恐怖,而KCP启动快速   模式后不x2,只是x1.5(实验证明1.5这个值相对比较好),提高了传输速度。

选择性重传 vs 全部重传:

TCP丢包时会全部重传从丢的那个包开始以后的数据,KCP是选择性重传,只重传真正   丢失的数据包。

快速重传:

发送端发送了1,2,3,4,5几个包,然后收到远端的ACK: 1, 3, 4, 5,当收到ACK3时,   KCP知道2被跳过1次,收到ACK4时,知道2被跳过了2次,此时可以认为2号丢失,不用   等超时,直接重传2号包,大大改善了丢包时的传输速度。

延迟ACK vs 非延迟ACK:

TCP为了充分利用带宽,延迟发送ACK(NODELAY都没用),这样超时计算会算出较大   RTT时间,延长了丢包时的判断过程。KCP的ACK是否延迟发送可以调节。

UNA vs ACK+UNA:

ARQ模型响应有两种,UNA(此编号前所有包已收到,如TCP)和ACK(该编号包已收到   ),光用UNA将导致全部重传,光用ACK则丢失成本太高,以往协议都是二选其一,而   KCP协议中,除去单独的 ACK包外,所有包都有UNA信息。

非退让流控:

KCP正常模式同TCP一样使用公平退让法则,即发送窗口大小由:发送缓存大小、接收   端剩余接收缓存大小、丢包退让及慢启动这四要素决定。但传送及时性要求很高的小   数据时,可选择通过配置跳过后两步,仅用前两项来控制发送频率。以牺牲部分公平   性及带宽利用率之代价,换取了开着BT都能流畅传输的效果。

基本使用

  1. 创建 KCP对象:

    // 初始化 kcp对象,conv为一个表示会话编号的整数,和tcp的 conv一样,通信双
    // 方需保证 conv相同,相互的数据包才能够被认可,user是一个给回调函数的指针
    ikcpcb *kcp = ikcp_create(conv, user);
  2. 设置回调函数:

    // 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包)时需要调用:
    ikcp_input(kcp, received_udp_packet, received_udp_size);

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

协议配置

协议默认模式是一个标准的 ARQ,需要通过配置打开各项加速开关:

  1. 工作模式:

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

    nodelay :是否启用 nodelay模式,0不启用;1启用。interval :协议内部工作的 interval,单位毫秒,比如 10ms或者 20msresend :快速重传模式,默认0关闭,可以设置2(2次ACK跨越将会直接重传)nc :是否关闭流控,默认是0代表不关闭,1代表关闭。普通模式:`ikcp_nodelay(kcp, 0, 40, 0, 0);极速模式: ikcp_nodelay(kcp, 1, 10, 2, 1);

  2. 最大窗口:

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

    该调用将会设置协议的最大发送窗口和最大接收窗口大小,默认为32.

  3. 最大传输单元:

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

  4. 最小RTO:

    不管是 TCP还是 KCP计算 RTO时都有最小 RTO的限制,即便计算出来RTO为40ms,由于默认的 RTO是100ms,协议只有在100ms后才能检测到丢包,快速模式下为30ms,可以手动更改该值:

    kcp->rx_minrto = 10;

最佳实践

内存分配器

默认KCP协议使用 malloc/free进行内存分配释放,如果应用层接管了内存分配,可以  用ikcp_allocator来设置新的内存分配器,注意要在一开始设置:

ikcp_allocator(my_new_malloc, my_new_free);

前向纠错注意

为了进一步提高传输速度,下层协议也许会使用前向纠错技术。需要注意,前向纠错会根据冗余信息解出原始数据包。相同的原始数据包不要两次input到KCP,否则将会导致kcp以为对方重发了,这样会产生更多的ack占用额外带宽。

比如下层协议使用最简单的冗余包:单个数据包除了自己外,还会重复存储一次上一个数据包,以及上上一个数据包的内容:

Fn = (Pn, Pn-1, Pn-2)

P0 = (0, X, X)
P1 = (1, 0, X)
P2 = (2, 1, 0)
P3 = (3, 2, 1)

这样几个包发送出去,接收方对于单个原始包都可能被解出3次来(后面两个包任然会重复该包内容),那么这里需要记录一下,一个下层数据包只会input给kcp一次,避免过多重复ack带来的浪费。

管理大规模连接

如果需要同时管理大规模的 KCP连接(比如大于3000个),比如你正在实现一套类 epoll的机制,那么为了避免每秒钟对每个连接调用大量的调用 ikcp_update,我们可以使用ikcp_check来大大减少 ikcp_update调用的次数。 ikcp_check返回值会告诉你需要在什么时间点再次调用 ikcp_update(如果中途没有 ikcp_send, ikcp_input的话,否则中途调用了 ikcp_send, ikcp_input的话,需要在下一次interval时调用 update)

标准顺序是每次调用了 ikcp_update后,使用 ikcp_check决定下次什么时间点再次调用ikcp_update,而如果中途发生了 ikcp_send, ikcp_input的话,在下一轮 interval 立马调用 ikcp_update和 ikcp_check。 使用该方法,原来在处理2000个 kcp连接且每个连接每10ms调用一次update,改为 check机制后,cpu从 60%降低到 15%。

相关应用

  • dog-tunnel: GO开发的网络隧道,使用 KCP极大的改进了传输速度,并移植了一份 GO版本 KCP
  • lua-kcp:KCP的 Lua扩展,用于 Lua服务器
  • asio-kcp: 使用 KCP的完整 UDP网络库,完整实现了基于 UDP的链接状态管理,会话控制,KCP协议调度等

协议比较

如果永远不丢包那么 KCP和 TCP性能差不多,但网络会卡,造成卡的原因就是丢包和抖动。在内网里直接比较,大家都差不多,但是放到公网上,放到3G/4G网络情况下,或者使用内网丢包模拟,差距就很明显了。公网在高峰期有平均接近10%的丢包,wifi/3g/4g下更糟糕,这正是造成各种网络卡顿的元凶。

感谢 asio-kcp 的作者 zhangyuan 对 KCP 与 enet, udt做过的一次横向评测,结论如下:

  • ASIO-KCP has good performace in wifi and phone network(3G, 4G).
  • Extra using 20% ~ 50% network flow for speed improvement.
  • The kcp is the first choice for realtime pvp game.
  • The lag is less than 1 second when network lag happen. 3 times better than enet when lag happen.
  • The enet is a good choice if your game allow 2 second lag.
  • UDT is a bad idea. It always sink into badly situation of more than serval seconds lag. And the recovery is not expected.
  • enet has the problem of lack of doc. And it has lots of functions that you may intrest.
  • kcp's doc is chinese. Good thing is the function detail which is writen in code is english. And you can use asio_kcp which is a good wrap.
  • The kcp is a simple thing. You will write more code if you want more feature.
  • UDT has a perfect doc. UDT may has more bug than others as I feeling.

具体见:横向比较 和 评测数据,为犹豫选择的人提供了更多指引。

欢迎捐赠

欢迎使用支付宝对该项目进行捐赠

欢迎使用支付宝手扫描上面的二维码,对该项目进行捐赠。捐赠款项将用于改进 KCP性能以及后续持续优化。

  • KCP

    什么是KCP?为什么要使用KCP? KCP是一个快速可靠协议。它主要的设计目的是为了解决在网络拥堵的情况下TCP协议网络速度慢的问题,增大网络传输速率,但相当于TCP而言,会相应的牺牲一部分带宽。 kcp没有规定下层传输协议,一般用UDP作为下层传输协议。kcp层协议的数据包在UDP数据报文的基础上增加控制头。当用户数据很大,大于一个UDP包能承担的范围时(大于MSS),kcp会将用户数据分片存储

  • 1.概述 对于游戏开发,尤其是 MOBA(多人在线竞技)游戏,延迟是需要控制的。但是对于传统的 TCP(网络友好,很棒),并不利于包的实时性传输,因为他的超时重传和拥塞控制都是网络友好,对于我们包的实时性,没有优势。所以一般都是需要基于 UDP 去实现一套自己的网络协议,保证包的实时,以及可靠。其实就是牺牲 TCP 的友好,牺牲带宽,以空间换时间。基于 UDP,网上有一些优秀的协议,比如 KCP。

  • 文件名大小更新时间 kcp-netty-master02018-10-10 kcp-netty-master\.gitignore1552018-10-10 kcp-netty-master\.travis.yml772018-10-10 kcp-netty-master\CNAME132018-10-10 kcp-netty-master\LICENSE10662018-10-10 kcp-ne

  • Xtcp.h  #pragma once #include <frp/IDisposable.h> #include <frp/net/IPEndPoint.h> #include <frp/threading/Hosting.h> namespace frp { namespace xtcp { class Xtcp : public IDisposable {

  •         项目中用的是"github.com/xtaci/kcp-go",这个仓库不仅仅实现了kcp算法,而且在kcp算法层面上又包装了一层,比如说提供了多种数据加密方式和FEC前向纠错,用起来非常方便。         这一篇先分析kcp-go库对kcp算法包装这部分,先分析怎么用,怎么用都不知道去谈算法个人觉得没有意义,kcp算法层面的东西后面再分析。 1:先分析服务器层面的 func

  •         亲爱的各位读者你们好,由于前段时间忙于部分项目的重构和优化,未能及时更新文章,不少读者催更,哈哈,我还是很开心能抽出时间给大家再来分享下kcp的相关技术内幕,以及之前完善自己的网络库增加了KCP的客户端服务器收发支持(结尾会分享封装的客户端服务器C++源码)。 KCP概述          对于游戏开发,尤其是MOBA游戏,或者全球唯一服架构类型的游戏,对于网络的要求比一般游戏要高

  • 基于KCP的可靠UDP封装 交互原理 客户端服务端交互过程: 1)客户端与服务端都指定端口和IP,客户端服务端启动后,都创建KCP和socket ; 2)客户端在启动后,首先向服务端发送链接消息,在服务端未回复链接成功的确认标识时,客户端不断向服务端发送链接请求消息; 3)服务端在收到链接请求消息后,重置本地KCP,并向客户端发送链接成功确认消息,并启动服务端心跳,检测客户端消息; 4)客户端在收

 相关资料
  • 问题内容: 因为我不想自己做,所以我正在寻找Java的良好FFT实现。首先,我在这里使用了FFT Princeton的 这个,但是它使用了对象,而我的探查器告诉我,由于这个事实,它的速度并不是很快。所以我再次搜索了一下,发现了一个:更快的FFT Columbia 。也许你们中的一个知道另一种FFT实现?我想拥有“最好的”应用程序,因为我的应用程序必须处理大量的声音数据,并且用户不喜欢等待… ;-)

  • 介绍 常言道:欲练神功,必先练好基本功。之前做了一个关于IP路由,默认网关和掩码的问答贴,做完这个帖子觉得如果对网络知识点做一个系统的阐述,应该会很有帮助。 本系列文章着重于讲解网络管理实际应用中常常涉及的重要知识点,尽量以实用为主。准备写的几个章节暂时有(可能会有增减): 网络传输 交换机 VLAN与Trunk 路由(上) 路由(下) 链路聚合 IP地址与子网 NAT原理与配置 ICMP与ARP

  • 本文向大家介绍Linux网络编程之基于UDP实现可靠的文件传输示例,包括了Linux网络编程之基于UDP实现可靠的文件传输示例的使用技巧和注意事项,需要的朋友参考一下 了解网络传输协议的人都知道,采用TCP实现文件传输很简单。相对于TCP,由于UDP是面向无连接、不可靠的传输协议,所以我们需要考虑丢包和后发先至(包的顺序)的问题,所以我们想要实现UDP传输文件,则需要解决这两个问题。方法就是给数据

  • This file describes the network protocol used by Ceph. In order to understand the way the structures are defined it is recommended to read the introduction of Network Encoding first. Hello The protoco

  • 扩展说明 远程通讯的服务器及客户端传输实现。 扩展接口 org.apache.dubbo.remoting.Transporter org.apache.dubbo.remoting.Server org.apache.dubbo.remoting.Client 扩展配置 <!-- 服务器和客户端使用相同的传输实现 --> <dubbo:protocol transporter="xxx" />

  • 两台计算机是怎样进行数据传递的

  • 本文向大家介绍Android 中构建快速可靠的 UI 测试,包括了Android 中构建快速可靠的 UI 测试的使用技巧和注意事项,需要的朋友参考一下 前言 让我一起来看看 Iván Carballo和他的团队是如何使用Espresso, Mockito 和Dagger 2 编写250个UI测试,并且只花了三分钟就运行成功的。 在这篇文章中,我们会探索如何使用Mockito(译者注:Mockito

  • 问题内容: 我正在为Swift 编写本教程:https : //www.raywenderlich.com/125311/make- game-like-candy-crush-spritekit-swift- part-1 并遇到以下代码: 我正是这样写的,但是Xcode给了我这些错误: 我从苹果的文档中找到了以下代码:https : //developer.apple.com/document