tcp沒用嗎?爲何MOBA、「吃雞」遊戲不推薦用tcp協議

本文由雲+社區發表

做者:騰訊雲遊戲行業資深架構師 餘國良linux

MOBA類和「吃雞」遊戲爲何對網絡延遲要求高?

咱們知道,不一樣類型的遊戲由於玩法、競技程度不同,採用的同步算法不同,對網絡延遲的要求也不同。例如,MOBA類遊戲多使用幀同步爲主要同步算法,競技性也較高,不管從流暢性,仍是從公平性要求來講,對響應延遲的要求都最高,根據業內經驗,當客戶端與服務器的網絡延遲超過150ms時,會開始出現卡頓,當延遲超過250ms時,會對玩家操做形成較大影響,遊戲沒法公平進行。相似地,「吃雞」遊戲(如《絕地求生》)玩法對玩家座標、動做的同步要求極高,延遲稍大致使的數據不一致對體驗都會形成較大影響,其實時性要求接近MOBA類遊戲。而對於傳統mmorpg來講,多采用狀態同步算法,以屬性養成和裝備獲取爲關注點,也有必定競技性,出於對遊戲流暢性的要求,對延遲也有必定要求,同步算法的優化程度不同,這一要求也不同,通常狀況下爲保證遊戲正常進行,須要響應延遲保持在300ms如下。相比之下,對於爐石傳說、鬥地主、夢幻西遊等回合制遊戲來講,同時只有一個玩家在操做雙方數據,無數據競爭,且時間粒度較粗,甚至可經過特效掩蓋延遲,所以對網絡延遲的要求不高,即使延遲達到500ms~1000ms,遊戲也能正常進行。這裏,咱們不對同步算法作進一步說明,重點說一下協議的問題。git

傳輸層協議和延遲

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

加速方案

基於udp定製傳輸層協議,引入順序性和適當程度或者可調節程度的可靠性,修改流控算法。適當放棄重傳,如:設置最大重傳次數,即便重傳失敗,也不須要從新創建鏈接。比較知名的tcp加速開源方案有:quic、enet、kcp、udt。其中,quic是源自google的tcp替代方案,其主要目的是爲了整合TCP協議的可靠性和udp協議的速度和效率,其主要特性包括:避免前序包阻塞、減小數據包、向前糾錯、會話重啓和並行下載等,然而QUIC對標的是TCP+TLS+SPDY,相比其餘方案更重,目前國內用於網絡遊戲較少。kcp的做者是國內優秀開發者,社區也發展良好,kcp的做者和社區開發者對enet、kcp、udt作了性能測試,詳情可參見:https://github.com/skywind300..., 從測試狀況能夠看到,kcp表現不錯,其次是enet,表現最差的是udt。不過,這裏也提出一個問題,原始enet保留了tcp重傳的指數避讓特性,每次重傳間隔仍是乘以2,默認rto也較高,這多是測試中enet表現不如kcp的主要緣由,若是對enet代碼稍做調整,結果又當如何?這裏,咱們先排除傳輸性能,從其餘方面對enet和kcp作一對比(滿分5分):算法

img

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

測試中考察兩個性能指標:網絡

1)平均響應時間;架構

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

libenet的代碼調整:性能

img

​ 圖 1 調整默認RTT爲50ms 測試

img

圖 2 取消指數避讓

tc命令以下:

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

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

對比結果數據以下:

img

圖 3 不一樣丟包率和網絡延遲下TCP協議、ENET、優化後ENET的平均響應時間對比

img

圖 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的協議和算法,也沒法點石成金,要從根本上解決問題,最終仍是要回到網絡質量上。

此文已由做者受權騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨,能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號v

相關文章
相關標籤/搜索