Kcp

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 KCP协议包含了2中模式，消息模式和流模式。今天笔者来讲讲这2种模式的区别。 2. 流模式和消息模式 回顾一下KCP协议 0 4 5 6 8 (BYTE) +---------------+---+---+-------+ | conv |cmd|frg| wnd | +---------------+---+---+-------+ 8 | ts | sn | +---------------+---------------+ 16 | una | len | +---------------+---------------+ 24 | | | DATA (optional) | | | +-------------------------------+ frg:分片，用户数据可能会被分成多个KCP包，发送出去 在xtaci/kcp-go的消息模式实现不完整，这个字段始终为0 详见issues/121 sn: 序列号 len:数据长度(DATA的长度) data:用户数据 2.1 消息模式 假定一个场景，在IM中，A向B发送了一个消息，这个消息可能是文本消息，也可能是图片消息。那么应用程序发送的数据是有逻辑的消息的概念的。 kCP协议提供了一种能力把不同的消息(应用程序)划分在不同的KCP包中。 KCP定义 MSS的默认大小为1400 bytes，MSS(maximum segment size)表示最大段大小，它本身是TCP中的概念，表示包含TCP header，整个数据包的最大大小。在KCP协议中，概念类似，表示包含KCP header在内，整个KCP包的最大大小。 超过MSS的数据将会被拆分到成多个KCP包。根据是否拆包将会分成2种情况。 1）不拆包 3条消息Msg1,Msg2,Msg3分别包含在sn为 90、91、92的KCP包中 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 KCP协议的很多东西都是脱胎于TCP协议，所以他们在思想和实现上是完全相通的。xtaci/kcp-go 包含FEC也不过4000多行代码，skywind3000/kcp 主要是C/C++的代码，也就2000多行，萌叔建议大家都去阅读下源码。 慢启动、拥塞避免、拥塞发生、快速重传，这些概念都非常唬人，但看完代码你会发现不过尔尔。 在开始正式的文章之前，萌叔打算问几个问题？ 流控是为了保护谁？ 在实现中如何体现？ 2. 流控是为了保护谁？ TCP是全双工，这里简化一下，我们只看半双工的情况 Sender发送数据给Receiver 1) Sender中的应用程序把数据写入到本机的发送缓冲区 2) 数据从发送缓冲区写入到链路中，链路可能是由实际的光缆、电缆、多个路由器节点组成。 3）数据从链路转交到Receiver的接收缓冲区 4）数据从接收缓冲区交给Receiver的应用程序 发送缓冲区大小是有限的，它必须被保护起来 Sender和Receiver之间的链路的收发能力也是有限的，且是与网络中的其它节点共享的，因此Link也必须受到保护 接收缓冲区大小也是受限的，它也应该受到保护 3. 在实现中如何体现？ 在实际实现中每一个需要保护的点，都有与之对应的参数，先上结论 3.1 使用发送端的发送窗口(snd_wnd)保护本机的发送缓冲区 3.2 使用拥塞窗口(cwnd)来保护发送端与接收端之间的链路 cwnd是动态变化的值, 算法与TCP协议基本相同 3.3 使用接收端的接收窗口(rmt_wnd, 表示接收窗口的空闲大小）保护接收端的接收缓冲区 rmt_wnd对应KCP协议的wnd, 由接收端汇报 回顾一下KCP协议 0 4 5 6 8 (BYTE) +---------------+---+---+-------+ | conv |cmd|frg| wnd | +---------------+---+---+-------+ 8 | ts | sn | +---------------+---------------+ 16 | una | len | +---------------+---------------+ 24 | | | DATA (optional) | | | +-------------------------------+ 4. 分析一次完整的写入动作 4.1 发送窗口和接收窗口对写入的影响 在KCP中，数据被拆分成Segment后 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 KCP协议是一种快速可靠传输ARQ(Automatic Repeat-reQuest)协议，能以比TCP浪费10%-20%的带宽的代价，换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。它跟QUIC协议一样也是基于UDP协议的实现。KCP从TCP协议中借鉴了大量的思路，是理解TCP/IP协议栈的非常好的资料。 补充说明下，无论是QUIC还是KCP只有在弱网络条件下，相比TCP才有优势。 KCP协议在网络分层模型的位置 +-----------------+ | SESSION | +-----------------+ | KCP(ARQ) | +-----------------+ | FEC(OPTIONAL) | +-----------------+ | CRYPTO(OPTIONAL)| +-----------------+ | UDP(PACKET) | +-----------------+ | IP | +-----------------+ | LINK | +-----------------+ | PHY | +-----------------+ KCP的设计者有意识的把KCP依赖的网络通讯给解耦了 纯算法实现，并不负责底层协议（如UDP）的收发，需要使用者自己定义下层数据包的发送方式，以 callback的方式提供给 KCP。 如果读者阅读 skywind3000/kcp 源码，可能会发现如下代码 test.cpp // 创建模拟网络：丢包率10%，Rtt 60ms~125ms vnet = new LatencySimulator(10, 60, 125); 测试和验证是不需要再真实网络上进行。 skywind3000/kcp 只是设计了最初的协议, 包括 非延迟ACK 快速重传（TCP协议也有） 非退让流控(拥塞控制，和TCP实现类同) xtaci/kcp-go 在此基础上，又增加了 加密机制 FEC(Forward Error Correction)前向纠错 PS: skywind3000和xtaci其实是大学同学 ...