reformate wiki and documents

This commit is contained in:
skywind3000 2015-05-29 11:07:14 +08:00
parent 695e44711f
commit 1b070f3b63

View File

@ -3,57 +3,38 @@ KCP - A Fast and Reliable ARQ Protocol
# 简介
KCP是一个快速可靠协议能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低
30%-40%且最大延迟降低三倍的传输效果。纯算法实现并不负责底层协议如UDP
的收发,需要使用者自己定义下层数据包的发送方式,以 callback的方式提供给 KCP。
连时钟都需要外部传递进来,内部不会有任何一次系统调用。
KCP是一个快速可靠协议能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低 30%-40%且最大延迟降低三倍的传输效果。纯算法实现并不负责底层协议如UDP的收发需要使用者自己定义下层数据包的发送方式以 callback的方式提供给 KCP。 连时钟都需要外部传递进来,内部不会有任何一次系统调用。
整个协议只有 ikcp.h, ikcp.c两个源文件可以方便的集成到用户自己的协议栈中。
也许你实现了一个P2P或者某个基于 UDP的协议而缺乏一套完善的ARQ可靠协议实现
那么简单的拷贝这两个文件到现有项目中,稍微编写两行代码,即可使用。
整个协议只有 ikcp.h, ikcp.c两个源文件可以方便的集成到用户自己的协议栈中。也许你实现了一个P2P或者某个基于 UDP的协议而缺乏一套完善的ARQ可靠协议实现那么简单的拷贝这两个文件到现有项目中稍微编写两行代码即可使用。
# 技术特性
TCP是为流量设计的每秒内可以传输多少KB的数据讲究的是充分利用带宽。而KCP
是为流速设计的单个数据包从一端发送到一端需要多少时间以10%-20%带宽浪费
的代价换取了比 TCP快30%-40%的传输速度。TCP信道是一条流速很慢但每秒流量很大
的大运河而KCP是水流湍急的小激流。KCP有正常模式和快速模式两种通过以下策略
达到提高流速的结果:
TCP是为流量设计的每秒内可以传输多少KB的数据讲究的是充分利用带宽。而 KCP是为流速设计的单个数据包从一端发送到一端需要多少时间以10%-20%带宽浪费的代价换取了比 TCP快30%-40%的传输速度。TCP信道是一条流速很慢但每秒流量很大的大运河而KCP是水流湍急的小激流。KCP有正常模式和快速模式两种通过以下策略达到提高流速的结果
#### RTO翻倍vs不翻倍
TCP超时计算是RTOx2这样连续丢三次包就变成RTOx8了十分恐怖而KCP启动快速
模式后不x2只是x1.5实验证明1.5这个值相对比较好),提高了传输速度。
TCP超时计算是RTOx2这样连续丢三次包就变成RTOx8了十分恐怖而KCP启动快速模式后不x2只是x1.5实验证明1.5这个值相对比较好),提高了传输速度。
#### 选择性重传 vs 全部重传:
TCP丢包时会全部重传从丢的那个包开始以后的数据KCP是选择性重传只重传真正
丢失的数据包。
TCP丢包时会全部重传从丢的那个包开始以后的数据KCP是选择性重传只重传真正丢失的数据包。
#### 快速重传:
发送端发送了1,2,3,4,5几个包然后收到远端的ACK: 1, 3, 4, 5当收到ACK3时
KCP知道2被跳过1次收到ACK4时知道2被跳过了2次此时可以认为2号丢失不用
等超时直接重传2号包大大改善了丢包时的传输速度。
发送端发送了1,2,3,4,5几个包然后收到远端的ACK: 1, 3, 4, 5当收到ACK3时KCP知道2被跳过1次收到ACK4时知道2被跳过了2次此时可以认为2号丢失不用等超时直接重传2号包大大改善了丢包时的传输速度。
#### 延迟ACK vs 非延迟ACK
TCP为了充分利用带宽延迟发送ACKNODELAY都没用这样超时计算会算出较大
RTT时间延长了丢包时的判断过程。KCP的ACK是否延迟发送可以调节。
TCP为了充分利用带宽延迟发送ACKNODELAY都没用这样超时计算会算出较大 RTT时间延长了丢包时的判断过程。KCP的ACK是否延迟发送可以调节。
#### UNA vs ACK+UNA
ARQ模型响应有两种UNA此编号前所有包已收到如TCP和ACK该编号包已收到
光用UNA将导致全部重传光用ACK则丢失成本太高以往协议都是二选其一
KCP协议中除去单独的 ACK包外所有包都有UNA信息。
ARQ模型响应有两种UNA此编号前所有包已收到如TCP和ACK该编号包已收到光用UNA将导致全部重传光用ACK则丢失成本太高以往协议都是二选其一而 KCP协议中除去单独的 ACK包外所有包都有UNA信息。
#### 非退让流控:
KCP正常模式同TCP一样使用公平退让法则即发送窗口大小由发送缓存大小、接收
端剩余接收缓存大小、丢包退让及慢启动这四要素决定。但传送及时性要求很高的小
数据时,可选择通过配置跳过后两步,仅用前两项来控制发送频率。以牺牲部分公平
性及带宽利用率之代价换取了开着BT都能流畅传输的效果。
KCP正常模式同TCP一样使用公平退让法则即发送窗口大小由发送缓存大小、接收端剩余接收缓存大小、丢包退让及慢启动这四要素决定。但传送及时性要求很高的小数据时可选择通过配置跳过后两步仅用前两项来控制发送频率。以牺牲部分公平性及带宽利用率之代价换取了开着BT都能流畅传输的效果。
# 基本使用
@ -118,65 +99,30 @@ TCP是为流量设计的每秒内可以传输多少KB的数据讲究的
```cpp
int ikcp_wndsize(ikcpcb *kcp, int sndwnd, int rcvwnd);
```
该调用将会设置协议的最大发送窗口和最大接收窗口大小默认为32.
该调用将会设置协议的最大发送窗口和最大接收窗口大小默认为32. 这个可以理解为 TCP的 SND_BUF 和 RCV_BUF只不过单位不一样 SND/RCV_BUF 单位是字节,这个单位是包。
3. 最大传输单元:
纯算法协议并不负责探测 MTU默认 mtu是1400字节可以使用ikcp_setmtu来设置
该值。该值将会影响数据包归并及分片时候的最大传输单元。
纯算法协议并不负责探测 MTU默认 mtu是1400字节可以使用ikcp_setmtu来设置该值。该值将会影响数据包归并及分片时候的最大传输单元。
4. 最小RTO
不管是 TCP还是 KCP计算 RTO时都有最小 RTO的限制即便计算出来RTO为40ms
于默认的 RTO是100ms协议只有在100ms后才能检测到丢包快速模式下为30ms
以手动更改该值:
不管是 TCP还是 KCP计算 RTO时都有最小 RTO的限制即便计算出来RTO为40ms由于默认的 RTO是100ms协议只有在100ms后才能检测到丢包快速模式下为30ms可以手动更改该值
```cpp
kcp->rx_minrto = 10;
```
# 最佳实践
#### 内存分配器
# 更多内容
默认KCP协议使用 malloc/free进行内存分配释放如果应用层接管了内存分配可以
用ikcp_allocator来设置新的内存分配器注意要在一开始设置
协议的使用和配置都是很简单的,大部分情况看完上面的内容基本可以使用了。如果你需要进一步进行精细的控制,比如改变 KCP的内存分配器或者你需要更有效的大规模调度 KCP链接比如 3500个以上或者想把它和 TCP结合那么可以继续延伸阅读
> ikcp_allocator(my_new_malloc, my_new_free);
[KCP 最佳实践](wiki/KCP-Best-Practice)
#### 前向纠错注意
# 相关应用
[dog-tunnel](https://github.com/vzex/dog-tunnel): GO语言开发的网络隧道使用了 KCP协议并将 KCP移植到了一个 GO版本的实现
[lua-kcp](https://github.com/linxiaolong/lua-kcp)KCP的 Lua扩展用于 Lua服务器
为了进一步提高传输速度,下层协议也许会使用前向纠错技术。需要注意,前向纠错会根
据冗余信息解出原始数据包。相同的原始数据包不要两次input到KCP否则将会导致kcp
以为对方重发了这样会产生更多的ack占用额外带宽。
比如下层协议使用最简单的冗余包:单个数据包除了自己外,还会重复存储一次上一个数
据包,以及上上一个数据包的内容:
```cpp
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%。
# 欢迎捐赠