kcp协议与tcp协议类似,是一种ARQ协议。他的优点在于比tcp的延迟更小30%-40%,但相应的会牺牲一部分的带宽,大该比tcp多浪费10%~20%。tcp的设计目标是增大网络利用率,而kcp的设计目标是增大网络传输速率。因此kcp与tcp对比,kcp有如下机制可以提高传输速度:

1.kcp的RTO每次是增加为1.5倍,相比tcp的2倍,具有更短的超时重传时间
2.无延迟ACK,通过配置让ack立即发送,而tcp为了增加网络利用率会尽量让ack与用户数据一起发送
3.快速重传门限可控制,可以适当缩小fastack门限,提高重传响应速度
4.earlyRetrans机制,无用户数据时立刻发送ack
5.拥塞控制可取消,取消拥塞控制后,用户的发包速率不受网络拥塞的影响

golang版本kcp源码下载地址:https://github.com/skywind3000/kcp

一个发送数据接收数据的基本流程如下

//用户有一段数据buf需要发送,于是调用send函数

kcp1.Send(buf.Bytes())//send函数将buffer分片成kcp的数据包格式,存在待发送队列中

kcp1.flush()//将发送队列中的数据通过下层协议(UDP)进行发送

//kcp2接收到下层协议(UDP)传进来的数据底层数据buffer

kcp2.Input(buffer[:hr], true, false)//调用Input函数将UDP接收的数据buffer转换成kcp的数据包格式

hr = int32(kcp2.Recv(buffer[:]))//kcp2将接收的kcp数据包还原成kcp1发送的buffer数据

在Send的时候用户数据长度不作限制,但在Recv的时候不一定能够一次性接收完Send的所有数据,用户在Recv后应该做校验。

 
func (kcp *KCP) Recv(buffer []byte) (n int)
    // merge fragment
    count := 0
    for k := range kcp.rcv_queue {
        seg := &kcp.rcv_queue[k]
        copy(buffer, seg.data)
        buffer = buffer[len(seg.data):]
        n += len(seg.data)
        count++
        kcp.delSegment(*seg)
        if seg.frg == 0 {
            break
        }
    }
    if count > 0 {
        kcp.rcv_queue = kcp.remove_front(kcp.rcv_queue, count)
    }
count = 0
    for k := range kcp.rcv_buf {
        seg := &kcp.rcv_buf[k]
        if seg.sn == kcp.rcv_nxt && len(kcp.rcv_queue) < int(kcp.rcv_wnd) {
            kcp.rcv_nxt++
            count++
        } else {
            break
        }
    }

    if count > 0 {
        kcp.rcv_queue = append(kcp.rcv_queue, kcp.rcv_buf[:count]...)
        kcp.rcv_buf = kcp.remove_front(kcp.rcv_buf, count)
    }
// fast recover
    if len(kcp.rcv_queue) < int(kcp.rcv_wnd) && fast_recover {
        // ready to send back IKCP_CMD_WINS in ikcp_flush
        // tell remote my window size
        kcp.probe |= IKCP_ASK_TELL
    }

recv函数将接收消息队列中的数据包还原成原来的消息格式,通过buffer返回给调用者

还会把rcv_buf中的与接收序号相匹配的数据拷贝到rcv_queue中。这里注意到在Input->parse_data函数中有同样的处理,这里之所以需要重复处理是因为kcp.rcv_queue的大小可能会发生改变,len(kcp.rcv_queue) < int(kcp.rcv_wnd)条件有可能重新成立。

fast_recover标识的意思是快速告知对端我又有窗口大小空出来了,因为在Input函数中有可能窗口会满了,此时发送给对端的是窗口满消息,而在recv过后,因为取走了消息,可用接收窗口又变大了,此时需要快速告知对端可以继续发消息了。

func (kcp *KCP) Send(buffer []byte) int {
var count int
if len(buffer) == 0 {
return -1
} // append to previous segment in streaming mode (if possible)
if kcp.stream != 0 {
n := len(kcp.snd_queue)
if n > 0 {
seg := &kcp.snd_queue[n-1]
if len(seg.data) < int(kcp.mss) {
capacity := int(kcp.mss) - len(seg.data)
extend := capacity
if len(buffer) < capacity {
extend = len(buffer)
} // grow slice, the underlying cap is guaranteed to
// be larger than kcp.mss
oldlen := len(seg.data)
seg.data = seg.data[:oldlen+extend]
copy(seg.data[oldlen:], buffer)
buffer = buffer[extend:]
}
} if len(buffer) == 0 {
return 0
}
} if len(buffer) <= int(kcp.mss) {
count = 1
} else {
count = (len(buffer) + int(kcp.mss) - 1) / int(kcp.mss)
} if count > 255 {
return -2
} if count == 0 {
count = 1
} for i := 0; i < count; i++ {
var size int
if len(buffer) > int(kcp.mss) {
size = int(kcp.mss)
} else {
size = len(buffer)
}
seg := kcp.newSegment(size)
copy(seg.data, buffer[:size])
if kcp.stream == 0 { // message mode
seg.frg = uint8(count - i - 1)
} else { // stream mode
seg.frg = 0
}
kcp.snd_queue = append(kcp.snd_queue, seg)
buffer = buffer[size:]
}
return 0
}

send函数主要功能是把用户需要发送的字符数组转化成kcp的数据包。如果用户的数据超过一个MSS,还会对数据进行分片。这里有两种分片的方式,消息方式和流方式。消息方式把用户数据分片,为每个分片设置ID,将分片后的数据一个一个地存入发送队列种,接收方通过id解析回原来的包,消息方式一个分片的数据量可能不能达到MSS(最大分片大小)。流方式则是会检测每个发送队列里的分片是否达到最大mss,如果没有达到就会用新的数据填充分片。流方式的网络速度优于消息方式,但是流方式接收方接收时是一个分片一个分片地接收,而消息方式kcp接收函数会自己把原本属于一个数据的分片重组回来。

func (kcp *KCP) flush(ackOnly bool)

flush函数大致功能如下:

发送ack

发送探测窗口消息

将发送队列中的消息存入缓存队列(缓存队列实际上就是发送窗口)

检查缓存队列中当前需要发送的数据(包括新传数据与重传数据)

根据重传数据更新发送窗口大小

if change >  {
inflight := kcp.snd_nxt - kcp.snd_una
kcp.ssthresh = inflight /
if kcp.ssthresh < IKCP_THRESH_MIN {
kcp.ssthresh = IKCP_THRESH_MIN
}
kcp.cwnd = kcp.ssthresh + resent
kcp.incr = kcp.cwnd * kcp.mss
}

在发生快速重传的时候,会将慢启动阈值调整为当前发送窗口的一半,并把拥塞窗口大小调整为kcp.ssthresh + resent,resent是触发快速重传的丢包的次数,resent的值代表的意思在被弄丢的包后面收到了resent个数的包的ack。这样调整后kcp就进入了拥塞控制状态。

    if lost >  {
kcp.ssthresh = cwnd /
if kcp.ssthresh < IKCP_THRESH_MIN {
kcp.ssthresh = IKCP_THRESH_MIN
}
kcp.cwnd =
kcp.incr = kcp.mss
}

如果发生的超时重传,那么就重新进入慢启动状态。

func (kcp *KCP) Input(data []byte, regular, ackNoDelay bool) int {
una := kcp.snd_una
if len(data) < IKCP_OVERHEAD {
return -
} var maxack uint32
var lastackts uint32
var flag int
var inSegs uint64 for {
var ts, sn, length, una, conv uint32
var wnd uint16
var cmd, frg uint8 if len(data) < int(IKCP_OVERHEAD) {
break
} data = ikcp_decode32u(data, &conv)
if conv != kcp.conv {
return -
} data = ikcp_decode8u(data, &cmd)
data = ikcp_decode8u(data, &frg)
data = ikcp_decode16u(data, &wnd)
data = ikcp_decode32u(data, &ts)
data = ikcp_decode32u(data, &sn)
data = ikcp_decode32u(data, &una)
data = ikcp_decode32u(data, &length)
if len(data) < int(length) {
return -
} if cmd != IKCP_CMD_PUSH && cmd != IKCP_CMD_ACK &&
cmd != IKCP_CMD_WASK && cmd != IKCP_CMD_WINS {
return -
} // only trust window updates from regular packets. i.e: latest update
if regular { kcp.rmt_wnd = uint32(wnd) }
kcp.parse_una(una)
kcp.shrink_buf() if cmd == IKCP_CMD_ACK {
kcp.parse_ack(sn)
kcp.shrink_buf()
if flag == {
flag =
maxack = sn
} else if _itimediff(sn, maxack) > {
maxack = sn
}
lastackts = ts
} else if cmd == IKCP_CMD_PUSH {
if _itimediff(sn, kcp.rcv_nxt+kcp.rcv_wnd) < {
kcp.ack_push(sn, ts)
if _itimediff(sn, kcp.rcv_nxt) >= {
seg := kcp.newSegment(int(length))
seg.conv = conv
seg.cmd = cmd
seg.frg = frg
seg.wnd = wnd
seg.ts = ts
seg.sn = sn
seg.una = una
copy(seg.data, data[:length])
kcp.parse_data(seg)
} else {
atomic.AddUint64(&DefaultSnmp.RepeatSegs, )
}
} else {
atomic.AddUint64(&DefaultSnmp.RepeatSegs, )
}
} else if cmd == IKCP_CMD_WASK {
// ready to send back IKCP_CMD_WINS in Ikcp_flush
// tell remote my window size
kcp.probe |= IKCP_ASK_TELL
} else if cmd == IKCP_CMD_WINS {
// do nothing
} else {
return -
} inSegs++
data = data[length:]
}
atomic.AddUint64(&DefaultSnmp.InSegs, inSegs) if flag != && regular {
kcp.parse_fastack(maxack)
current := currentMs()
if _itimediff(current, lastackts) >= {
kcp.update_ack(_itimediff(current, lastackts))
}
} if _itimediff(kcp.snd_una, una) > {
if kcp.cwnd < kcp.rmt_wnd {
mss := kcp.mss
if kcp.cwnd < kcp.ssthresh {
kcp.cwnd++
kcp.incr += mss
} else {
if kcp.incr < mss {
kcp.incr = mss
}
kcp.incr += (mss*mss)/kcp.incr + (mss / )
if (kcp.cwnd+)*mss <= kcp.incr {
kcp.cwnd++
}
}
if kcp.cwnd > kcp.rmt_wnd {
kcp.cwnd = kcp.rmt_wnd
kcp.incr = kcp.rmt_wnd * mss
}
}
} if ackNoDelay && len(kcp.acklist) > { // ack immediately
kcp.flush(true)
} else if kcp.rmt_wnd == && len(kcp.acklist) > { // window zero
kcp.flush(true)
}
return
}

input函数接收udp协议传过来的报文,把udp报文解码成kcp报文进行缓存。

kcp报文分为ack报文,数据报文,探测窗口报文,响应窗口报文四种。

kcp报文的una字段表示对端希望接收的下一个kcp包序号,也就是说明接收端已经收到了所有小于una序号的kcp包。解析una字段后需要把发送缓冲区里面包序号小于una的包全部丢弃掉。 ack报文则包含了对端收到的kcp包的序号,接到ack包后需要删除发送缓冲区中与ack包中的发送包序号(sn)相同的kcp包。上述una和ack处理完后,需要更新kcp.snd_una(发送端第一个未被确认的包),如果snd_una增加了那么就说明对端正常收到且回应了发送方发送缓冲区第一个待确认的包,此时需要更新cwnd(拥塞窗口)

收到数据报文时,需要判断数据报文是否在接收窗口内,如果是则保存ack,如果数据报文的sn正好是待接收的第一个报文rcv_nxt,那么就更新rcv_nxt(加1)。如果配置了ackNodelay模式(无延迟ack)或者远端窗口为0(代表暂时不能发送用户数据),那么这里会立刻fulsh()发送ack。

kcp源码走读的更多相关文章

  1. Apache Spark源码走读之23 -- Spark MLLib中拟牛顿法L-BFGS的源码实现

    欢迎转载,转载请注明出处,徽沪一郎. 概要 本文就拟牛顿法L-BFGS的由来做一个简要的回顾,然后就其在spark mllib中的实现进行源码走读. 拟牛顿法 数学原理 代码实现 L-BFGS算法中使 ...

  2. Apache Spark源码走读之16 -- spark repl实现详解

    欢迎转载,转载请注明出处,徽沪一郎. 概要 之所以对spark shell的内部实现产生兴趣全部缘于好奇代码的编译加载过程,scala是需要编译才能执行的语言,但提供的scala repl可以实现代码 ...

  3. Apache Spark源码走读之13 -- hiveql on spark实现详解

    欢迎转载,转载请注明出处,徽沪一郎 概要 在新近发布的spark 1.0中新加了sql的模块,更为引人注意的是对hive中的hiveql也提供了良好的支持,作为一个源码分析控,了解一下spark是如何 ...

  4. Apache Spark源码走读之7 -- Standalone部署方式分析

    欢迎转载,转载请注明出处,徽沪一郎. 楔子 在Spark源码走读系列之2中曾经提到Spark能以Standalone的方式来运行cluster,但没有对Application的提交与具体运行流程做详细 ...

  5. twitter storm 源码走读之5 -- worker进程内部消息传递处理和数据结构分析

    欢迎转载,转载请注明出处,徽沪一郎. 本文从外部消息在worker进程内部的转化,传递及处理过程入手,一步步分析在worker-data中的数据项存在的原因和意义.试图从代码实现的角度来回答,如果是从 ...

  6. storm-kafka源码走读之KafkaSpout

    from: http://blog.csdn.net/wzhg0508/article/details/40903919 (五)storm-kafka源码走读之KafkaSpout 原创 2014年1 ...

  7. spring-data-redis-cache 使用及源码走读

    预期读者 准备使用 spring 的 data-redis-cache 的同学 了解 @CacheConfig,@Cacheable,@CachePut,@CacheEvict,@Caching 的使 ...

  8. ConcurrentHashMap源码走读

    目录 ConcurrentHashMap源码走读 简介 放入数据 容器元素总数更新 容器扩容 协助扩容 遍历 ConcurrentHashMap源码走读 简介 在从JDK8开始,为了提高并发度,Con ...

  9. underscorejs 源码走读笔记

    Underscore 简介 Underscore 是一个JavaScript实用库,提供了类似Prototype.js的一些功能,但是没有继承任何JavaScript内置对象.它弥补了部分jQuery ...

随机推荐

  1. 手机页面开发的meta

    <meta name="viewport" content="width=device-width, initial-scale=1"> 手机环境. ...

  2. 如何扩大重做日志(redolog)文件的大小

    假设现有三个日志组,每个组内有一个成员,每个成员的大小为1MB,现在想把此三个日志组的成员大小都改为10MB 1.创建2个新的日志组alter database add logfile group 4 ...

  3. 2_python之路之多级菜单

    python之路之多级菜单 1.使用知识点 (1)列表,字典的使用 (2)if条件判断语句 (3)for/while循环的使用 2.代码详细 #!/usr/bin/env python # _*_ c ...

  4. Deep Learning 阅读笔记:Convolutional Auto-Encoders 卷积神经网络的自编码表达

    需要搭建一个比较复杂的CNN网络,希望通过预训练来提高CNN的表现. 上网找了一下,关于CAE(Convolutional Auto-Encoders)的文章还真是少,勉强只能找到一篇瑞士的文章. S ...

  5. Disconf实践指南:安装篇

    Disconf是百度开源出来的一款基于Zookeeper的分布式配置管理软件.目前很多公司都在使用,包括滴滴.百度.网易.顺丰等公司.通过简单的界面操作就可以动态修改配置属性,还是很方便的.使用Dis ...

  6. C语言学习笔记---好用的函数memcpy与memset

    这个主要用于我个人的学习笔记,便于以后查询,顺便分享给大家. 想必在用C的时候难免会与数组,指针,内存这几样东西打交道,先以数组为例,例如有一个数组int a[5] = {1, 2, 3, 4, 5} ...

  7. HALCON初步:算子参数部分三个冒号的意义

    HALCON中存在两类基本变量:图像变量(iconic data)和控制变量(control data),其中图像变量包括image, region和XLD contours,控制变量包括intege ...

  8. 获取用户的相关请求信息, 以及包括请求头 request.environ

    #在index文件中 1. print(type(request)) #看出所属库 2. from django.core.handlers.wsgi import WSGIRequest #查看WS ...

  9. iOS学习之UITableView中Cell的操作

    接着iOS学习之Table View的简单使用 这篇,这里主要讲UITableView 中的Cell的操作,包括标记.移动.删除.插入. 为了简单快捷,直接从原来那篇的代码开始,代码下载地址:http ...

  10. filter入门

    TestFilter.java package com.cdsxt.filter; import java.io.IOException; import javax.servlet.Filter;im ...