作者：騰訊雲遊戲行業資深架構師 餘國良
我們知道，不同類型的遊戲因為玩法、競技程度不一樣，采用的同步算法不一樣，對網絡延遲的要求也不一樣。例如，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分）：
我們對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有明顯優勢。
測試結果符合預期，在實時性方面，TCP協定的網絡抗性欠佳，對MOBA類或其他實時性要求較高的遊戲，我們不建議使用TCP作為協定載體。事實上，王者榮耀，亂鬥西遊的通信協定也确實是基于UDP封裝的，别問我是怎麼知道的。
對于開發人員來說，優化協定和同步算法是在已有網絡環境下提升使用者體驗的可用方法，也是較平民化的方法，在網絡抖動有限、丢包并不頻繁、網絡環境不至于太差的情況下，的确能有效提高遊戲體驗；然而這種方法也存在局限性，在網絡環境超出可控範圍，如在地鐵上、商場裡等人潮擁擠、存在網絡熱點，延遲或丢包率極高的環境中，還是無法解決問題，所謂“巧婦難為無米之炊”，再牛X的協定和算法，也無法點石成金，要從根本上解決問題，最終還是要回到網絡品質上。和平民化方法相比，改變網絡品質需要在資源和底層排程政策上的積累，如何優化遍布全國各地乃至全球各地的玩家網絡接入點到伺服器端的網絡鍊路？如何優化玩家用戶端最後一公裡即用戶端到無線基站的接入QoS (Quality of Service)？這種方法可以稱之為高富帥方法，而有這種大規模需求，又能采用這種方法的，放眼望去，恐怕隻能看到一家公司了：騰訊。好消息是，騰訊已經将這種能力在騰訊雲開放了，稱之為：智營網優。現在申請，免費試用！https://cloud.tencent.com/product/ino
想了解更多有關遊戲加速方案和案例，立即報名1月19日騰訊雲GAME-TECH沙龍杭州站，我們一起探讨：https://cloud.tencent.com/act/event/game-tech-hz.html
直播連結： http://www.itdks.com/eventlist/detail/1885