精品国产高清露脸在线观看,亚洲精品韩国专区在线观看

04月

為什么MOBA、“吃雞”游戲不推薦用tcp協(xié)議——實測數(shù)據(jù)

795 0 0

文/余國良，騰訊云游戲行業(yè)資深架構(gòu)師

MOBA類和“吃雞”游戲為什么對網(wǎng)絡延遲要求高？

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

傳輸層協(xié)議和延遲

不同傳輸層協(xié)議在可靠性、流量控制等方面都有差別，而這些技術(shù)細節(jié)會對延遲造成影響。tcp追求的是完全可靠性和順序性，丟包后會持續(xù)重傳直至該包被確認，否則后續(xù)包也不會被上層接收，且重傳采用指數(shù)避讓策略，決定重傳時間間隔的RTO(retransmission timeout)不可控制，linux內(nèi)核實現(xiàn)中最低值為200ms，這樣的機制會導致丟包率短暫升高的情況下應用層消息響應延遲急劇提高，并不適合實時性高、網(wǎng)絡環(huán)境復雜的游戲。

加速方案

基于udp定制傳輸層協(xié)議，引入順序性和適當程度或者可調(diào)節(jié)程度的可靠性，修改流控算法。適當放棄重傳，如：設置最大重傳次數(shù)，即使重傳失敗，也不需要重新建立連接。比較知名的tcp加速開源方案有：quic、enet、kcp、udt。其中，quic是源自google的tcp替代方案，其主要目的是為了整合TCP協(xié)議的可靠性和udp協(xié)議的速度和效率，其主要特性包括：避免前序包阻塞、減少數(shù)據(jù)包、向前糾錯、會話重啟和并行下載等，然而QUIC對標的是TCP+TLS+SPDY，相比其他方案更重，目前國內(nèi)用于網(wǎng)絡游戲較少。kcp的作者是國內(nèi)優(yōu)秀開發(fā)者，社區(qū)也發(fā)展良好，kcp的作者和社區(qū)開發(fā)者對enet、kcp、udt做了性能測試，詳情可參見：https://github.com/skywind3000/kcp/wiki/KCP-Benchmark，從測試情況可以看到，kcp表現(xiàn)不錯，其次是enet，表現(xiàn)最差的是udt。不過，這里也提出一個問題，原始enet保留了tcp重傳的指數(shù)避讓特性，每次重傳間隔還是乘以2，默認rto也較高，這可能是測試中enet表現(xiàn)不如kcp的主要原因，如果對enet代碼稍作調(diào)整，結(jié)果又當如何？這里，我們先排除傳輸性能，從其他方面對enet和kcp做一對比（滿分5分）：

我們對libenet略微做一些調(diào)整——默認rtt從500ms調(diào)整成50ms, 去除超時重傳的指數(shù)避讓策略。Linux下用TC命令模擬網(wǎng)絡延遲和丟包率，控制延遲分別為30ms, 50ms, 70ms，控制丟包率分別為1%, 3%, 5%, 7%, 10%，在模擬出的不同網(wǎng)絡環(huán)境下，對tcp, 原始enet和改進后的enet進行了對比測試。

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

1）平均響應時間;

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

libenet的代碼調(diào)整：

圖 1 調(diào)整默認RTT為50ms
圖 2 取消指數(shù)避讓
tc命令如下：

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

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

對比結(jié)果數(shù)據(jù)如下：

圖 3 不同丟包率和網(wǎng)絡延遲下TCP協(xié)議、ENET、優(yōu)化后ENET的平均響應時間對比
圖 4 不同丟包率和網(wǎng)絡延遲下TCP協(xié)議、ENET、優(yōu)化后ENET的超時響應比例對比
從圖中可見，在平均響應方面，TCP協(xié)議的劣勢不明顯，在延遲為30ms，丟包率為1%時，改進后的ENET平均RTT為69ms, 原始ENET平均RTT為67ms, TCP平均RTT為67ms；但是從響應時間超過300ms的比例看，在延遲為30ms，丟包率為1%時，改進后的ENET RTT超過300ms的包為0，而TCP RTT超過300ms的比例則超過了2%，如果是在游戲中，這個表現(xiàn)已經(jīng)能明顯影響游戲體驗了。結(jié)果表明，TCP在網(wǎng)絡稍不穩(wěn)定的情況下就已經(jīng)有比較大的問題了，改進后的ENET有明顯優(yōu)勢。

總結(jié)

測試結(jié)果符合預期，在實時性方面，TCP協(xié)議的網(wǎng)絡抗性欠佳，對MOBA類或其他實時性要求較高的游戲，我們不建議使用TCP作為協(xié)議載體。事實上，王者榮耀，亂斗西游的通信協(xié)議也確實是基于UDP封裝的，別問我是怎么知道的。

后話

對于開發(fā)人員來說，優(yōu)化協(xié)議和同步算法是在已有網(wǎng)絡環(huán)境下提升用戶體驗的可用方法，也是較平民化的方法，在網(wǎng)絡抖動有限、丟包并不頻繁、網(wǎng)絡環(huán)境不至于太差的情況下，的確能有效提高游戲體驗；然而這種方法也存在局限性，在網(wǎng)絡環(huán)境超出可控范圍，如在地鐵上、商場里等人潮擁擠、存在網(wǎng)絡熱點，延遲或丟包率極高的環(huán)境中，還是無法解決問題，所謂“巧婦難為無米之炊”，再牛X的協(xié)議和算法，也無法點石成金，要從根本上解決問題，最終還是要回到網(wǎng)絡質(zhì)量上。和平民化方法相比，改變網(wǎng)絡質(zhì)量需要在資源和底層調(diào)度策略上的積累，如何優(yōu)化遍布全國各地乃至全球各地的玩家網(wǎng)絡接入點到服務器端的網(wǎng)絡鏈路？如何優(yōu)化玩家客戶端最后一公里即客戶端到無線基站的接入QoS (Quality of Service)？這種方法可以稱之為高富帥方法，而有這種大規(guī)模需求，又能采用這種方法的，放眼望去，恐怕只能看到一家公司了：騰訊。好消息是，騰訊已經(jīng)將這種能力在騰訊云開放了，稱之為：智營網(wǎng)優(yōu)?，F(xiàn)在申請，免費試用！https://cloud.tencent.com/product/ino

via：騰訊云

銳亞教育