Moba類游戲為什么對網絡延遲要求高？
我們知道竿奏，不同類型的游戲因為玩法挤忙、競技程度不一樣，采用的同步算法不一樣泣栈，對網絡延遲的要求也不一樣。例如，對于爐石傳說南片、斗地主掺涛、夢幻西游等回合制游戲來說，同時只有一個玩家在操作雙方數據疼进，無數據競爭薪缆，且時間粒度較粗，甚至可通過特效掩蓋延遲伞广，因此對網絡延遲的要求不高拣帽，即便延遲達到500ms~1000ms，游戲也能正常進行嚼锄；對于傳統mmorpg來說减拭，多采用狀態(tài)同步算法，以屬性養(yǎng)成和裝備獲取為關注點区丑，也有一定競技性拧粪，出于對游戲流暢性的要求，對延遲也有一定要求沧侥，同步算法的優(yōu)化程度不一樣既们，這一要求也不一樣，一般情況下為保證游戲正常進行正什，需要響應延遲保持在300ms以下啥纸；相比之下MOBA類游戲多使用幀同步為主要同步算法，競技性也最高婴氮，無論從流暢性斯棒，還是從公平性要求來說，對響應延遲的要求都最高主经，根據業(yè)內經驗荣暮，當客戶端與服務器的網絡延遲超過150ms時，會開始出現卡頓罩驻，當延遲超過250ms時穗酥，會對玩家操作造成較大影響，游戲無法公平進行惠遏。這里砾跃，我們不對同步算法做進一步說明，重點說一下協議的問題节吮。
傳輸層協議和延遲
不同傳輸層協議在可靠性抽高、流量控制等方面都有差別，而這些技術細節(jié)會對延遲造成影響透绩。tcp追求的是完全可靠性和順序性翘骂，丟包后會持續(xù)重傳直至該包被確認壁熄，否則后續(xù)包也不會被上層接收，且重傳采用指數避讓策略碳竟，決定重傳時間間隔的RTO(retransmission timeout)不可控制草丧，linux內核實現中最低值為200ms，這樣的機制會導致丟包率短暫升高的情況下應用層消息響應延遲急劇提高莹桅，并不適合實時性高昌执、網絡環(huán)境復雜的游戲。
加速方案：
基于udp定制傳輸層協議统翩，引入順序性和適當程度或者可調節(jié)程度的可靠性，修改流控算法此洲。適當放棄重傳厂汗，如：設置最大重傳次數，即使重傳失敗呜师，也不需要重新建立連接娶桦。比較知名的tcp加速開源方案有：quic、enet汁汗、kcp衷畦、udt。其中知牌，quic是源自google的tcp替代方案祈争，其主要目的是為了整合TCP協議的可靠性和UDP協議的速度和效率，其主要特性包括：避免前序包阻塞角寸、減少數據包菩混、向前糾錯、會話重啟和并行下載等扁藕，然而QUIC對標的是TCP+TLS+SPDY沮峡，相比其他方案更重，目前國內用于網絡游戲較少亿柑。kcp的作者是國內優(yōu)秀開發(fā)者邢疙，社區(qū)也發(fā)展良好，kcp的作者和社區(qū)開發(fā)者對enet望薄、kcp疟游、udt做了性能測試，詳情可參見：github.com/skywind3000/kcp/wiki/KCP-Benchmark 痕支，從測試情況可以看到乡摹，kcp表現不錯，其次是enet采转，表現最差的是udt聪廉。不過瞬痘，這里也提出一個問題，原始enet保留了tcp重傳的指數避讓特性板熊，每次重傳間隔還是乘以2框全，默認rto也較高，這可能是測試中enet表現不夠好的主要原因干签，如果對enet代碼稍作調整津辩，結果又當如何？這里容劳，我們先排除傳輸性能喘沿，從其他方面對enet和kcp做一對比（滿分5分）。
我們對libenet略微做一些調整——默認rtt從500ms調整成50ms, 去除超時重傳的指數避讓策略竭贩。Linux下用TC命令模擬網絡延遲和丟包率蚜印，控制延遲分別為30ms, 50ms, 70ms，控制丟包率分別為1%, 3%, 5%, 7%, 10%留量，在模擬出的不同網絡環(huán)境下窄赋，對tcp, 原始enet和改進后的enet進行了對比測試。
測試中考察兩個性能指標：
1）平均響應時間;
2）響應時間超過300ms的包的比例楼熄。
libenet的代碼調整：
tc命令如下：
延遲100ms(rtt為200ms)： tc qdisc add dev eth0 root netem delay 100ms
1%丟包率：tc qdisc add dev eth0 root netem loss 1%
對比數據如下：
從圖中可見，在平均響應方面缕粹，TCP協議的劣勢不明顯伐债，在延遲為30ms，丟包率為1%時致开，改進后的enet平均rtt為69ms, 原始enet平均rtt為67ms, tcp平均rtt為67ms峰锁；但是從響應時間超過300ms的比例看，在延遲為30ms双戳，丟包率為1%時虹蒋，改進后的enet rtt超過300ms的包為0，而tcp rtt超過300ms的比例則超過了2%飒货，如果是在游戲中魄衅，這個表現已經能明顯影響游戲體驗了。結果表明塘辅，tcp在網絡稍不穩(wěn)定的情況下就已經有比較大的問題了晃虫，改進后的enet有明顯優(yōu)勢。
總結
測試結果符合預期扣墩，在實時性方面哲银，tcp協議的網絡抗性欠佳扛吞，對moba類或其他實時性要求較高的游戲，我們不建議使用tcp作為協議載體荆责。事實上滥比，王者榮耀，亂斗西游的通信協議也確實是基于udp封裝的做院，別問我是怎么知道的盲泛。
后話
對于開發(fā)人員來說，優(yōu)化協議和同步算法是在已有網絡環(huán)境下提升用戶體驗的可用方法键耕，也是較平民化的方法寺滚，在網絡抖動有限、丟包并不頻繁屈雄、網絡環(huán)境不至于太差的情況下村视，的確能有效提高游戲體驗；然而這種方法也存在局限性棚亩，在網絡環(huán)境超出可控范圍蓖议，如在地鐵上虏杰、商場里等人潮擁擠讥蟆、存在網絡熱點，延遲或丟包率極高的環(huán)境中纺阔，還是無法解決問題瘸彤，所謂“巧婦難為無米之炊”，再牛X的協議和算法笛钝，也無法點石成金质况，要從根本上解決問題，最終還是要回到網絡質量上玻靡。和平民化方法相比结榄，改變網絡質量需要在資源和底層調度策略上的積累，如何優(yōu)化遍布全國各地乃至全球各地的玩家網絡接入點到服務器端的網絡鏈路囤捻？如何優(yōu)化玩家客戶端最后一公里即客戶端到無線基站的接入qos(Quality of Service)臼朗？這種方法可以稱之為高富帥方法，而有這種大規(guī)模需求蝎土，又能采用這種方法的视哑，放眼望去，恐怕只能看到一家公司了：騰訊誊涯。好消息是挡毅，騰訊已經將這種能力在騰訊云開放了，稱之為：智營網優(yōu)暴构，cloud.tencent.com/document/product/594/10028?
