KCP是一個快速可靠協(xié)議，能以比 TCP浪費10%-20%的帶寬的代價，換取平均延遲降低 30%-40%，且最大延遲降低三倍的傳輸效果。純算法實現(xiàn)，并不負責底層協(xié)議（如UDP）的收發(fā)，需要使用者自己定義下層數(shù)據(jù)包的發(fā)送方式，并以 callback的方式提供給 KCP。連時鐘都需要外部傳遞進來，內部不會有任何一次系統(tǒng)調用。

整個協(xié)議只有 ikcp.h, ikcp.c兩個源文件，可以方便的集成到用戶自己的協(xié)議棧中。也許你實現(xiàn)了一個P2P，或者某個基于 UDP的協(xié)議，而缺乏一套完善的 ARQ可靠協(xié)議實現(xiàn)，那么簡單的拷貝這兩個文件到現(xiàn)有項目中，稍微編寫兩行代碼，即可使用。

技術特性

TCP是為流量設計的（每秒內可以傳輸多少KB的數(shù)據(jù)），講究的是充分利用帶寬。而KCP是為流速設計的（單個數(shù)據(jù)包從一端發(fā)送到一端需要多少時間），以10%-20%帶寬浪費的代價換取了比 TCP快30%-40%的傳輸速度。TCP信道是一條流速很慢，但每秒流量很大的大運河，而KCP是水流湍急的小激流。KCP有正常模式和快速模式兩種，通過以下策略達到提高流速的結果：

• RTO翻倍vs不翻倍：TCP超時計算是RTOx2，這樣連續(xù)丟三次包就變成RTOx8了，十分恐怖，而KCP啟動快速模式后不x2，只是x1.5（實驗證明1.5這個值相對比較好），提高了傳輸速度。

• 選擇性重傳 vs 全部重傳：TCP丟包時會全部重傳從丟的那個包開始以后的數(shù)據(jù)，KCP是選擇性重傳，只重傳真正丟失的數(shù)據(jù)包。

• 快速重傳：發(fā)送端發(fā)送了1,2,3,4,5幾個包，然后收到遠端的ACK: 1, 3, 4, 5，當收到ACK3時，KCP知道2被跳過1次，收到ACK4時，知道2被跳過了2次，此時可以認為2號丟失，不用等超時，直接重傳2號包，大大改善了丟包時的傳輸速度。

• 延遲ACK vs 非延遲ACK ：TCP為了充分利用帶寬，延遲發(fā)送ACK（NODELAY都沒用），這樣超時計算會算出較大RTT時間，延長了丟包時的判斷過程。KCP的ACK是否延遲發(fā)送可以調節(jié)。

• UNA vs ACK+UNA ：ARQ模型響應有兩種，UNA（此編號前所有包已收到，如TCP）和ACK（該編號包已收到），KCP有單獨ACK，且數(shù)據(jù)包和ACK包都帶UNA信息，有效降低ACK丟失成本。

• 非退讓流控：KCP正常模式同TCP一樣使用公平退讓法則，即發(fā)送窗口大小由：發(fā)送緩存大小、接收端剩余接收緩存大小、丟包退讓及慢啟動這四要素決定。但傳送及時性要求很高的小數(shù)據(jù)時，可選擇通過配置跳過后兩步，僅用前兩項來控制發(fā)送頻率。以犧牲部分公平性及帶寬利用率之代價，換取了開著BT都能流暢傳輸?shù)男Ч?/li>

基本使用

1. 創(chuàng)建 KCP對象：

   // 初始化 kcp對象，conv為一個表示會話編號的整數(shù)，和tcp的 conv一樣，通信雙方需要 // 保證 conv相同，相互的數(shù)據(jù)包才能夠被認可，user是一個給回調函數(shù)的指針。 ikcpcb *kcp = ikcp_create(conv, user);

2. 設置回調函數(shù)：

   // KCP的下層協(xié)議輸出函數(shù)，KCP需要發(fā)送數(shù)據(jù)時會調用它 // buf/len 表示緩存和長度 // user指針為 kcp對象創(chuàng)建時傳入的值，用于區(qū)別多個 KCP對象 int udp_output(const char *buf, int len, ikcpcb *kcp, void *user) { .... }  // 設置回調函數(shù) kcp->output = udp_output;

3. 循環(huán)調用 update：

   // 以一定頻率調用 ikcp_update來更新 kcp狀態(tài)，并且傳入當前的時鐘（毫秒單位）。 // 比如 10ms調用一次，或用 ikcp_check確定下次調用 update的時間不必每次調用。 ikcp_update(kcp, millisec);

4. 輸入一個下層數(shù)據(jù)包：

   // 收到一個下層數(shù)據(jù)包（比如UDP包）時需要調用： ikcp_input(kcp, received_udp_packet, received_udp_size);

處理了下層協(xié)議的輸出/輸入后 KCP協(xié)議就可以正常工作了，使用 ikcp_send(kcp, ptr, size)來向遠端發(fā)送數(shù)據(jù)。而另一端使用ikcp_recv(kcp, ptr, size)來接收數(shù)據(jù)。

協(xié)議配置

協(xié)議默認模式是一個標準的 ARQ，需要通過配置打開各項加速開關：

• 工作模式

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

  • nodelay ：是否啟用 nodelay模式，0不啟用；1啟用。
  • interval ：協(xié)議內部工作的 interval，單位毫秒，比如 10ms或者 20ms
  • resend ：快速重傳模式，默認0關閉，可以設置2（2次ACK跨越將會直接重傳）
  • nc ：是否關閉流控，默認是0代表不關閉，1代表關閉。

普通模式：`ikcp_nodelay(kcp, 0, 40, 0, 0); 極速模式： ikcp_nodelay(kcp, 1, 10, 2, 1);

• 最大窗口

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

該調用將會設置協(xié)議的最大發(fā)送窗口和最大接收窗口大小，默認為32.

• 最大傳輸單元

純算法協(xié)議并不負責探測 MTU，默認 mtu是1400字節(jié)，可以使用ikcp_setmtu來設置該值。該值將會影響數(shù)據(jù)包歸并及分片時候的最大傳輸單元。

• 最小RTO

不管是 TCP還是 KCP計算 RTO時都有最小 RTO的限制，即便計算出來RTO為40ms，由于默認的 RTO是100ms，協(xié)議只有在100ms后才能檢測到丟包，快速模式下該值為30ms，可以手動更改該值：

kcp->rx_minrto = 10;

內存分配器

默認KCP協(xié)議使用 malloc/free進行內存分配釋放，如果應用層接管了內存分配，可以用ikcp_allocator來設置新的內存分配器，注意要在一開始設置：

ikcp_allocator(my_new_malloc, my_new_free);

前向糾錯

為了進一步提高傳輸速度，下層協(xié)議也許會使用前向糾錯技術。需要注意，前向糾錯會根據(jù)冗余信息解出原始數(shù)據(jù)包。相同的原始數(shù)據(jù)包不要兩次input到KCP，否則將會導致kcp以為對方重發(fā)了，這樣會產生更多的ack占用額外帶寬。

比如下層協(xié)議使用最簡單的冗余包：單個數(shù)據(jù)包除了自己外，還會重復存儲一次上一個數(shù)據(jù)包，以及上上一個數(shù)據(jù)包的內容：

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

這樣幾個包發(fā)送出去，接收方對于單個原始包都可能被解出3次來（后面兩個包任然會重復該包內容），那么這里需要記錄一下，一個下層數(shù)據(jù)包只會input給kcp一次，避免過多重復ack帶來的浪費。

如果不丟包那么 KCP（）和 TCP性能差不多，KCP不會有任何優(yōu)勢，但是網(wǎng)絡會卡，造成卡的原因就是丟包和抖動，有同學在內網(wǎng)這樣好的環(huán)境下沒有用任何丟包模擬直接跑，跑出來的數(shù)據(jù)是差不多的，但是放到公網(wǎng)上，放到3G/4G網(wǎng)絡情況下，差距就很明顯了，公網(wǎng)在高峰期有平均接近10%的丟包，wifi/3g/4g下更糟糕，這正是造成各種網(wǎng)絡卡頓的元兇。

感謝asio-kcp的作者 zhangyuan 對 KCP 與 enet, udt做過的一次橫向評測，結論如下：

• ASIO-KCP hasgood 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 enetwhen 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.

具體見：橫向比較和這里。截取一段在網(wǎng)絡糟糕時，asio-kcp/enet的延遲數(shù)據(jù)：

worst network lag happen: 
asio: 10:51.21 
291  295   269   268   231   195   249   230   225   204

enet: 10:51.21 
1563   1520    1470    1482    1438    1454    1412    1637    1588    1540