談談網絡遊戲中的延遲解決方案

2019 年 10 月 6 日
筆記

我們平常玩的很多網絡遊戲，比如英雄聯盟/王者榮耀/PUBG等，你感覺到卡頓往往不是因為你的網速問題，而是因為網絡延時導致的，比如說LOL美服的遊戲服務器在美國，而你在中國的華中地區玩着美服LOL，那麼你的延遲可能會在300ms左右，因為網絡請求從美國到中國華中地區需要經過很多的路由，這裏面會消耗掉很多時間，如果發生了丟包，那麼重發需要的延遲更是會加倍增長，而延遲往往在150ms以上時往往就會影響到你的遊戲體驗了。

市面上會有一些遊戲加速器，它們會在國外安置服務器，搭建一條線路，來保證你的請求能夠迅速的被處理，來降低遊戲的延遲。

現在很多的遊戲以及直播等低延遲需求的應用，一般都不會再使用原生的TCP或者UDP來進行傳輸，而是在兩者的基礎上進行擴展修改，取其優異，比如TCP的傳輸可靠，UDP的傳輸速度。

仔細想想以前在計算機網絡課程中學習TCP/UDP時，就對TCP的所謂可靠傳輸感覺很怪異，真的是可靠到太過慎重了，說到慎重就不得不提這個月的一部新番《這個勇者明明超強卻過分慎重》。

昨天看了第一話，吹爆！

說回TCP，當時覺得它的超時重傳RTO時間每次都會翻倍，如果一個包多次超時，那下次重發這個包不是需要很久，延遲這不就上來了？還有它的重傳，丟了一個包就需要重傳之後所有的包，過分的慎重，雖然說可以保證可靠性，但是這對於我們毫秒級即時通訊之類的應用確實不太友好。

在此前提下，有了很多基於TCP或是UDP的改良，專門針對網絡遊戲以及音視頻通話中的延遲，本篇要說的就是KCP協議。

KCP協議是什麼

KCP是一個快速可靠協議，能以比 TCP浪費10%-20%的帶寬的代價，換取平均延遲降低 30%-40%，且最大延遲降低三倍的傳輸效果。

純算法實現，並不負責底層協議（如UDP）的收發，需要使用者自己定義下層數據包的發送方式，以 callback的方式提供給 KCP。

連時鐘都需要外部傳遞進來，內部不會有任何一次系統調用。

有一種叫KCPtun的實現，可以把我們的TCP請求轉化成KCP+UDP在公網上傳輸。

KCP與TCP的比較

TCP是為流量設計的（每秒內可以傳輸多少KB的數據），講究的是充分利用帶寬。而 KCP是為流速設計的（單個數據包從一端發送到一端需要多少時間），以10%-20%帶寬浪費的代價換取了比 TCP快30%-40%的傳輸速度。

TCP信道是一條流速很慢，但每秒流量很大的大運河，而KCP是水流湍急的小激流。

KCP有正常模式和快速模式兩種，通過以下策略達到提高流速的結果：

RTO翻倍vs不翻倍(RTO超時重傳)：

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

選擇性重傳 vs 全部重傳：

TCP丟包時會全部重傳從丟的那個包開始以後的數據，KCP是選擇性重傳，只重傳真正丟失的數據包。

快速重傳：

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

延遲ACK vs 非延遲ACK：

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

UNA vs ACK+UNA：

ARQ模型響應有兩種，UNA（此編號前所有包已收到，如TCP）和ACK（該編號包已收到），光用UNA將導致全部重傳，光用ACK則丟失成本太高，以往協議都是二選其一，而 KCP協議中，除去單獨的 ACK包外，所有包都有UNA信息。

非退讓流控：

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

如果網絡永遠不卡，那 KCP/TCP 表現類似，但是網絡本身就是不可靠的，丟包和抖動無法避免（否則還要各種可靠協議幹嘛）。在內網這種幾乎理想的環境里直接比較，大家都差不多，但是放到公網上，放到3G/4G網絡情況下，或者使用內網丟包模擬，差距就很明顯了。公網在高峰期有平均接近10%的丟包，wifi/3g/4g下更糟糕，這些都會讓傳輸變卡。

可能你玩的很多遊戲，或者說使用的加速器，都是利用了KCP來降低延遲。

如何使用

下面是KCP在GitHub上的地址，只需要將其中ikcp.c，ikcp.h兩個文件導入你的協議棧中就可以使用了。

https://github.com/skywind3000/kcp

創建 KCP對象：

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

設置回調函數：

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

循環調用 update：

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

輸入一個下層數據包：

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

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