kcp協(xié)議是傳輸層的一個具有可靠性的傳輸層ARQ協(xié)議。它的設(shè)計(jì)是為了解決在網(wǎng)絡(luò)擁堵情況下tcp協(xié)議的網(wǎng)絡(luò)速度慢的問題。kcp力求在保證可靠性的情況下提高傳輸速度。kcp協(xié)議的關(guān)注點(diǎn)主要在控制數(shù)據(jù)的可靠性和提高傳輸速度上面，因此kcp沒有規(guī)定下層傳輸協(xié)議，一般用udp作為下層傳輸協(xié)議，kcp層協(xié)議的數(shù)據(jù)包在udp數(shù)據(jù)報文的基礎(chǔ)上增加控制頭。當(dāng)用戶數(shù)據(jù)很大，大于一個udp包能承擔(dān)的范圍時（大于mss），kcp會將用戶數(shù)據(jù)分片存儲在多個kcp包中。因此每個kcp包稱為一個分片。

　　為了提供可靠性，kcp采用了重傳機(jī)制。為實(shí)現(xiàn)重傳機(jī)制，kcp為每個分片分配一個唯一標(biāo)識，接收方收到一個包后告知發(fā)送方接到的包的序號，發(fā)送方接到確認(rèn)后再繼續(xù)發(fā)送。而如果發(fā)送方在一定時間內(nèi)（超時重傳時間）沒有接到確認(rèn)，就說明數(shù)據(jù)包丟失了，發(fā)送方需要重傳丟失的數(shù)據(jù)包，所以發(fā)送方會把待確認(rèn)的數(shù)據(jù)緩存起來，方便重傳。

　　停等的重傳機(jī)制發(fā)送一個包后必須等待確認(rèn)后再發(fā)下一個包，傳輸速度較慢，所以為了提高發(fā)送速度，發(fā)送方可以不必再每發(fā)送一個包后就進(jìn)行等待確認(rèn)，而是可以發(fā)送多個包出去，然后等待接收方一一確認(rèn)。又由于接收方不可能同時處理無限多的數(shù)據(jù)，因此需要限制發(fā)送方往網(wǎng)絡(luò)中發(fā)送的數(shù)據(jù)數(shù)量。因此接收方限制發(fā)送方在未收到確認(rèn)之前只能發(fā)送wnd大小的數(shù)據(jù)，這個機(jī)制叫做滑動窗口機(jī)制。kcp采用滑動窗口機(jī)制來提高發(fā)送速度。由于UDP在網(wǎng)絡(luò)中的傳輸是不可靠的，因此會出現(xiàn)丟包和包的亂序。kcp是可靠的保證數(shù)據(jù)有序的協(xié)議，所以為了糾正包的亂序。接收方維護(hù)一個接收窗口。接收窗口有一個起始序號rcv_nxt以及尾序號rcv_nxt+rcv_wnd。如果接收窗口收到序號為rcv_nxt的分片那么rcv_nxt就加一，形象一點(diǎn)的說法是滑動窗口右移,并把該數(shù)據(jù)放入接收隊(duì)列供應(yīng)用層取用。如果收到的數(shù)據(jù)在窗口范圍內(nèi)但不是rcv_nxt那么就把數(shù)據(jù)保存起來,等收到rcv_nxt序號的分片時再一并放入接收隊(duì)列供應(yīng)用層取用。

　　當(dāng)網(wǎng)絡(luò)擁堵嚴(yán)重時，會發(fā)生丟包，丟包發(fā)生時kcp為了保證可靠性需要重傳數(shù)據(jù)。而發(fā)送方需要判斷什么時候發(fā)生了丟包，以及丟了哪些包。為了解決這個問題，發(fā)送方為緩存隊(duì)列中的每個包設(shè)置了包序號和超時重傳時間。當(dāng)檢測到當(dāng)前時間超過了分片的超時重傳時間，該分片還沒有得到確認(rèn)時就會觸發(fā)該分片的超時重傳。

　　數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸時間是不固定的，因此超時重傳時間比較長。而為了盡早地判斷出數(shù)據(jù)包的丟失，kcp引入了快速重傳機(jī)制。快速重傳機(jī)制工作原理是，當(dāng)發(fā)送方發(fā)送了n,n+1,n+2...等等包出去后，接收方?jīng)]有接收到n,而接收到n+1,n+2..等等n號包之后的包，這時因?yàn)閚號包之后的包都已經(jīng)接收到了，而n號包還沒有接收到，所以可以認(rèn)為n號包已經(jīng)丟失了，告知發(fā)送方可以進(jìn)行快速重傳。kcp為了支持快速重傳，接收方需要告訴發(fā)送方，哪些包已經(jīng)成功收到了，哪些包沒有收到。因此接收方返回發(fā)送方的確認(rèn)數(shù)據(jù)（ack）中包含以下信息：接收窗口左端的序號rcv_nxt,接收到的大于rcv_nxt的包序號sn。rcv_nxt的含義是接收方已經(jīng)成功按順序接收了rcv_nxt序號之前的所有包,大于rcv_nxt的序號sn表示的是在接收窗口內(nèi)的不連續(xù)的包。發(fā)送方接收到接收方發(fā)過來的數(shù)據(jù)時，首先解析rcv_nxt，把發(fā)送緩存中所有小于rcv_nxt序號的包全部移除掉（因?yàn)檫@些包全都都已經(jīng)正確接收了）。然后再解析sn,遍歷發(fā)送緩存，找到所有序號小于sn的包，這些包就是可能在網(wǎng)絡(luò)中已經(jīng)丟掉了的包,只是可能，因?yàn)橛锌赡苓@些包只是擁堵在了網(wǎng)絡(luò)中，需要更長的時間到達(dá)，所以這里我們設(shè)置一個快速重傳的門限，對每個分片維護(hù)一個快速重傳的計(jì)數(shù)，每收到一個ack解析sn后找到了一個分片，就把該分片的快速重傳的計(jì)數(shù)加一，如果該計(jì)數(shù)達(dá)到了快速重傳門限，那么就認(rèn)為該分片已經(jīng)丟失，可以觸發(fā)快速重傳，該門限值在kcp中可以設(shè)置，tcp中是3。

　　丟包發(fā)生時，由于滑動窗口的存在，假設(shè)第n個包丟失了，但是此時n+1，n+2號包卻已經(jīng)傳輸成功了，此時最好只重傳丟失的n號包，而不重傳成功傳輸?shù)膎+1，n+2號包,這個機(jī)制叫做選擇重傳,選擇重傳的關(guān)鍵在于接收方要告知發(fā)送方哪些包已經(jīng)收到了，哪些包沒有收到，為了最小化數(shù)據(jù)量，接收方可以告訴發(fā)送方哪些包已經(jīng)按序收到了，哪些包是收到的但是不連續(xù)。所以返回的ack中包含rcv_nxt和sn。rcv_nxt代表收到的所有連續(xù)的包，sn代表哪些不連續(xù)的包收到了，那么根據(jù)這兩個參數(shù)可以計(jì)算出來沒有收到的包的序號。

　　當(dāng)網(wǎng)絡(luò)實(shí)在很擁堵的時候（一般由于網(wǎng)絡(luò)消息太多，堵車了），kcp會限制發(fā)送方發(fā)送的數(shù)據(jù)量，這叫做擁塞控制，擁塞控制就是告訴發(fā)送方，網(wǎng)絡(luò)太堵了，應(yīng)該少發(fā)一些數(shù)據(jù)，因此在滑動窗口的機(jī)制上引入了擁塞窗口，也就是說發(fā)送發(fā)發(fā)送的數(shù)據(jù)不得超過擁塞窗口，擁塞窗口的大小會隨網(wǎng)絡(luò)情況而變快，網(wǎng)絡(luò)快擁塞窗口就大，反之同理。

　　那么擁塞窗口應(yīng)該等于多少呢？解決這一問題的原則是，讓網(wǎng)絡(luò)充分被利用，但是不能堵塞，這里引入了慢啟動機(jī)制，慢啟動也就是控制擁塞窗口從0開始增長，隨著數(shù)據(jù)不斷地成功傳輸，擁塞窗口逐漸增大，直至達(dá)到飽和，也就是網(wǎng)絡(luò)的收發(fā)平衡。為了快速達(dá)到網(wǎng)絡(luò)的收發(fā)平衡，擁塞窗口采用倍數(shù)增長。也就是每成功發(fā)送一個數(shù)據(jù)擁塞窗口加一，舉個例子，窗口大小為1時，發(fā)送一個數(shù)據(jù)，成功后窗口變成2，之后發(fā)送兩個數(shù)據(jù)出去，成功接收后窗口大小變?yōu)?。為了方便讓更多的用戶連入網(wǎng)絡(luò)時，網(wǎng)絡(luò)能有足夠的流量提供給用戶，還可以設(shè)置擁塞門限，擁塞門限值就是當(dāng)用戶擁塞窗口快速增長到門限值后就減慢增加速度，緩慢增長，騰出流量給其它用戶。

　　但是當(dāng)網(wǎng)絡(luò)很擁堵的情況下，導(dǎo)致發(fā)送數(shù)據(jù)出現(xiàn)重傳時，這時說明網(wǎng)絡(luò)中消息太多了，用戶應(yīng)該減少發(fā)送的數(shù)據(jù)，也就是擁塞窗口應(yīng)該減小。怎么減小呢，在快速重傳的情況下，有包丟失了但是有后續(xù)的包收到了，說明網(wǎng)絡(luò)還是通的，這時采取擁塞窗口的退半避讓,擁塞窗口減半，擁塞門限減半。減小網(wǎng)絡(luò)流量，緩解擁堵。當(dāng)出現(xiàn)超時重傳的時候，說明網(wǎng)絡(luò)很可能死掉了，因?yàn)槌瑫r重傳會出現(xiàn)，原因是有包丟失了，并且該包之后的包也沒有收到，這很有可能是網(wǎng)絡(luò)死了，這時候，擁塞窗口直接變?yōu)?，不再發(fā)送新的數(shù)據(jù)，直到丟失的包傳輸成功。

　　在上述原理之下，kcp為了提高傳輸速度，還可以有許多選項(xiàng)供用戶選擇：

　　　　kcp的擁塞控制可以取消

　　　　ack回復(fù)可以設(shè)置成無延遲ack回復(fù)

　　　　kcp的快速重傳門限可以控制

　　總之，kcp采取一系列措施盡量提高網(wǎng)絡(luò)傳輸速率，在網(wǎng)絡(luò)實(shí)時性和可靠性要求比較高的場景下可以考慮kcp協(xié)議代替tcp協(xié)議。