為什麼MOBA類和“吃雞”遊戲不推薦用tcp協議

    我們知道，不同型別的遊戲因為玩法、競技程度不一樣，採用的同步演算法不一樣，對網路延遲的要求也不一樣。例如，MOBA類遊戲多使用幀同步為主要同步演算法，競技性也較高，無論從流暢性，還是從公平性要求來說，對響應延遲的要求都最高，根據業內經驗，當客戶端與伺服器的網路延遲超過150ms時，會開始出現卡頓，當延遲超過250ms時，會對玩家操作造成較大影響，遊戲無法公平進行。類似地，“吃雞”遊戲（如《絕地求生》）玩法對玩家座標、動作的同步要求極高，延遲稍大導致的資料不一致對體驗都會造成較大影響，其實時性要求接近MOBA類遊戲。而對於傳統mmorpg來說，多采用狀態同步演算法，以屬性養成和裝備獲取為關注點，也有一定競技性，出於對遊戲流暢性的要求，對延遲也有一定要求，同步演算法的最佳化程度不一樣，這一要求也不一樣，一般情況下為保證遊戲正常進行，需要響應延遲保持在300ms以下。相比之下，對於爐石傳說、鬥地主、夢幻西遊等回合制遊戲來說，同時只有一個玩家在操作雙方資料，無資料競爭，且時間粒度較粗，甚至可透過特效掩蓋延遲，因此對網路延遲的要求不高，即便延遲達到500ms~1000ms，遊戲也能正常進行。這裡，我們不對同步演算法做進一步說明，重點說一下協議的問題。

    不同傳輸層協議在可靠性、流量控制等方面都有差別，而這些技術細節會對延遲造成影響。tcp追求的是完全可靠性和順序性，丟包後會持續重傳直至該包被確認，否則後續包也不會被上層接收，且重傳採用指數避讓策略，決定重傳時間間隔的RTO(retransmission timeout)不可控制，linux核心實現中最低值為200ms，這樣的機制會導致丟包率短暫升高的情況下應用層訊息響應延遲急劇提高，並不適合實時性高、網路環境複雜的遊戲。

基於udp定製傳輸層協議，引入順序性和適當程度或者可調節程度的可靠性，修改流控演算法。適當放棄重傳，如：設定最大重傳次數，即使重傳失敗，也不需要重新建立連線。比較知名的tcp加速開源方案有：quic、enet、kcp、udt。其中，quic是源自google的tcp替代方案，其主要目的是為了整合TCP協議的可靠性和udp協議的速度和效率，其主要特性包括：避免前序包阻塞、減少資料包、向前糾錯、會話重啟和並行下載等，然而QUIC對標的是TCP+TLS+SPDY，相比其他方案更重，目前國內用於網路遊戲較少。kcp的作者是國內優秀開發者，社群也發展良好，kcp的作者和社群開發者對enet、kcp、udt做了效能測試，詳情可參見：， 從測試情況可以看到，kcp表現不錯，其次是enet，表現最差的是udt。不過，這裡也提出一個問題，原始enet保留了tcp重傳的指數避讓特性，每次重傳間隔還是乘以2，預設rto也較高，這可能是測試中enet表現不如kcp的主要原因，如果對enet程式碼稍作調整，結果又當如何？這裡，我們先排除傳輸效能，從其他方面對enet和kcp做一對比（滿分5分）：

我們對libenet略微做一些調整——預設rtt從500ms調整成50ms, 去除超時重傳的指數避讓策略。Linux下用TC命令模擬網路延遲和丟包率，控制延遲分別為30ms, 50ms, 70ms，控制丟包率分別為1%, 3%, 5%, 7%, 10%，在模擬出的不同網路環境下，對tcp, 原始enet和改進後的enet進行了對比測試。

測試中考察兩個效能指標：

1）平均響應時間;

2）響應時間超過300ms的包的比例。

libenet的程式碼調整：

圖 1 調整預設RTT為50ms

圖 2 取消指數避讓

tc命令如下：

模擬延遲100ms(rtt為200ms)： tc qdisc add dev eth0 root netem delay 100ms

模擬1%丟包率：tc qdisc add dev eth0 root netem loss 1%

對比結果資料如下：

圖 3 不同丟包率和網路延遲下TCP協議、ENET、最佳化後ENET的平均響應時間對比

圖 4 不同丟包率和網路延遲下TCP協議、ENET、最佳化後ENET的超時響應比例對比

從圖中可見，在平均響應方面，TCP協議的劣勢不明顯，在延遲為30ms，丟包率為1%時，改進後的ENET平均RTT為69ms, 原始ENET平均RTT為67ms, TCP平均RTT為67ms；但是從響應時間超過300ms的比例看，在延遲為30ms，丟包率為1%時，改進後的ENET RTT超過300ms的包為0，而TCP RTT超過300ms的比例則超過了2%，如果是在遊戲中，這個表現已經能明顯影響遊戲體驗了。結果表明，TCP在網路稍不穩定的情況下就已經有比較大的問題了，改進後的ENET有明顯優勢。

4    總結

測試結果符合預期，在實時性方面，TCP協議的網路抗性欠佳，對MOBA類或其他實時性要求較高的遊戲，我們不建議使用TCP作為協議載體。事實上，王者榮耀，亂鬥西遊的通訊協議也確實是基於UDP封裝的，別問我是怎麼知道的。

5  後話

對於開發人員來說，最佳化協議和同步演算法是在已有網路環境下提升使用者體驗的可用方法，也是較平民化的方法，在網路抖動有限、丟包並不頻繁、網路環境不至於太差的情況下，的確能有效提高遊戲體驗；然而這種方法也存在侷限性，在網路環境超出可控範圍，如在地鐵上、商場裡等人潮擁擠、存在網路熱點，延遲或丟包率極高的環境中，還是無法解決問題，所謂“巧婦難為無米之炊”，再牛X的協議和演算法，也無法點石成金，要從根本上解決問題，最終還是要回到網路質量上。