為什么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做了性能測試，詳情可參見：https://github.com/skywind3000/kcp/wiki/KCP-Benchmark， 從測試情況可以看到，kcp表現不錯，其次是enet，表現最差的是udt。不過，這里也提出一個問題，原始enet保留了tcp重傳的指數避讓特性，每次重傳間隔還是乘以2，默認rto也較高，這可能是測試中enet表現不如kcp的主要原因，如果對enet代碼稍作調整，結果又當如何?這里，我們先排除傳輸性能，從其他方面對enet和kcp做一對比(滿分5分).