目錄（終篇）：

六.TCP VS UDP

七.常見同步優(yōu)化技術(shù)

? ?1.表現(xiàn)優(yōu)化

? ? ?- 插值優(yōu)化

? ? ?-?客戶端預(yù)先執(zhí)行+回滾

? ?2.延遲對抗

? ? ?-?延遲補(bǔ)償

? ? ?-?命令緩沖區(qū)

? ? ?- 通過具體的實現(xiàn)技巧

? ?3.丟包對抗

? ? ?-?使用TCP

? ? ?-?冗余的UDP

? ?4.帶寬優(yōu)化

? ? ?-?同步對象裁剪

? ? ?-?分區(qū)、分房間

? ? ?-?數(shù)據(jù)壓縮與裁剪

? ? ?-?減少遍歷等其他手段

? ?5.幀率優(yōu)化

?? ? -?提升幀率

? ? ?- 保持幀率穩(wěn)定

? ? ?- 計算壓力分擔(dān)

八.總結(jié)

上一篇文章我們分析了物理同步的概念以及實現(xiàn)手段，這篇是該系列的最后一篇（完結(jié)撒花）。主要針對網(wǎng)絡(luò)協(xié)議以及常見優(yōu)化技術(shù)兩個方面做分析和總結(jié)。

六、TCP VS UDP

網(wǎng)絡(luò)同步本質(zhì)是數(shù)據(jù)的傳輸，當(dāng)邏輯層面優(yōu)化已經(jīng)不能滿足游戲的即時性要求時，我們就不得不考慮更深一層協(xié)議上的優(yōu)化，而這件事開發(fā)者們從上世紀(jì)90年代就開始嘗試了。

按照OSI模型（Open System Interconnection Model），我們可以將計算機(jī)網(wǎng)絡(luò)分為七層。一般來說，我們在軟件層面（游戲開發(fā)）最多能干涉的到協(xié)議就是傳輸層協(xié)議了，即選擇TCP還是UDP。網(wǎng)上關(guān)于TCP和UDP的文章與討論有很多[15]，這里會再幫大家梳理一下。

??TCP處理流程圖

TCP（Transmission Control Protocol），即傳輸控制協(xié)議，是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議[16]。該協(xié)議早在1974年就被提出并被寫進(jìn)RFC（Request for Comments）中，自發(fā)布幾十年來一直被不斷優(yōu)化和調(diào)整，如今已經(jīng)是一個包含“可靠傳輸”，“擁塞控制”等多個功能的協(xié)議了（RFC 2581中增加）。

在21世紀(jì)早期，我們因特網(wǎng)上的數(shù)據(jù)包有大約95%的包都使用了TCP協(xié)議，包括HTTP/HTTPS，SMTP/POP3/IMAP、FTP等。當(dāng)然，也包括一大部分網(wǎng)絡(luò)游戲。我們?nèi)绱似珢塾赥CP就是因為他從協(xié)議層面上提供了許多非常重要的特性，如數(shù)據(jù)的可靠性、擁塞控制、流量控制等。這些可以讓軟件應(yīng)用的開發(fā)者們無需擔(dān)心數(shù)據(jù)丟失、重傳等細(xì)節(jié)問題。

然而在游戲開發(fā)中，這些特性卻可能是網(wǎng)絡(luò)同步中的負(fù)擔(dān)。在FPS游戲中，玩家每幀都在移動，我們期望這些數(shù)據(jù)在幾毫秒內(nèi)就能送達(dá)，否則就會對玩家產(chǎn)生干擾、影響游戲體驗。因此對于FPS、RTS這種要求及時響應(yīng)的游戲，TCP協(xié)議那些復(fù)雜的機(jī)制看起來確實有點(diǎn)華而不實。

??客戶端位置要落后一些，與服務(wù)器有一定誤差（守望先鋒）

考慮到TCP協(xié)議非常復(fù)雜，這里只從幾個關(guān)鍵的點(diǎn)來談?wù)勊膯栴}[17]。

• 1.在TCP中，數(shù)據(jù)是通過字節(jié)流的方式發(fā)送的，但由于建立在IP協(xié)議上必須將字節(jié)流拆分成不同的包，默認(rèn)情況下協(xié)議會將你的數(shù)據(jù)包緩沖，到達(dá)一定值才會發(fā)送。這樣可能會出現(xiàn)在游戲某個階段你最后幾個包明明已經(jīng)執(zhí)行了發(fā)送邏輯，但是由于緩沖機(jī)制被限制而無法到達(dá)。不過好在我們可以通過TCP_NODELAY來設(shè)置TCP立即刷新寫入它的所有數(shù)據(jù)。

• 2.其次，TCP的可靠數(shù)據(jù)傳輸響應(yīng)并不及時。一旦數(shù)據(jù)包發(fā)生丟失或亂序，那么接收方就會一直等待這個數(shù)據(jù)的到來，其他新收到的數(shù)據(jù)只會被緩存在協(xié)議層，你在應(yīng)用層根本獲取不到任何數(shù)據(jù)也無法做任何處理。這個時候你可能要等超時重傳機(jī)制響應(yīng)后才能拿到重發(fā)的數(shù)據(jù)包，這時候可能已經(jīng)過了幾十毫秒。即使TCP擁有快速重傳機(jī)制，仍然達(dá)不到理想的延遲效果。

• 3.擁塞控制和流量控制不可控。TCP在網(wǎng)絡(luò)環(huán)境比較差的條件下，會通過調(diào)整擁塞控制窗口大小來減少包的發(fā)送來降低吞吐量，這對于延遲敏感的游戲完全是無法接受的。同樣，我們在應(yīng)用層上面也無能為力。

• 4.其他的還有一些的小問題，比如每個TCP的報頭都需要包含序列號、確認(rèn)號、窗口等數(shù)據(jù)結(jié)構(gòu)，無形中增加了流量大??；TCP需要在端系統(tǒng)中維護(hù)連接狀態(tài)，包括接收與發(fā)送緩存、擁塞控制參數(shù)等，在處理大量連接的消息時也更為繁瑣和耗時。

那么這些問題能解決么？也許能，但是從協(xié)議層面我們無能為力，因為TCP協(xié)議設(shè)計之初就不是為了及時響應(yīng)，而另一個運(yùn)輸層協(xié)議UDP看起來比較符合我們的理念。

UDP(User Datagram Protocol)，即用戶數(shù)據(jù)包協(xié)議，是一個簡單的面向數(shù)據(jù)報通信的協(xié)議[18]。該協(xié)議由David P. Reed在1980年設(shè)計并寫入RFC 768中。顧名思義，UDP設(shè)計之初就是為了讓用戶可以自由的定義和傳輸數(shù)據(jù)，不需要建立鏈接、沒有流量控制也沒有擁塞控制，但是會盡可能快的將數(shù)據(jù)傳輸?shù)侥康腎P和端口。

??UDP報頭

在上世紀(jì)90年代，Quake等游戲就開始使用UDP協(xié)議取代TCP進(jìn)行數(shù)據(jù)同步，結(jié)果也很理想。除了游戲外，其他諸如視頻、語音通信等領(lǐng)域也在廣泛使用UDP，開發(fā)者們開始基于UDP創(chuàng)建自定義的Reliable UDP通信框架（QUIC、WbRTC、KCP、UDT等[19]），一些游戲引擎（如UnrealEngine）也將RUDP集成進(jìn)來。隨著網(wǎng)絡(luò)帶寬的提高，使用UDP代替TCP目測是一個趨勢（參考Http3[20]）。

??虛幻引擎的UDP數(shù)據(jù)包，包含ACK標(biāo)記位

雖然UDP很自由，但是需要開發(fā)者們自己寫代碼完善他。我們需要自己去寫服務(wù)器客戶端建立鏈接的流程，我們需要手動將數(shù)據(jù)分包，我們還需要自己實現(xiàn)應(yīng)用層面的可靠數(shù)據(jù)傳輸機(jī)制。另外，UDP還有一個傳輸上的小劣勢——當(dāng)路由器上的隊列已滿時，路由器可以根據(jù)優(yōu)先級決策在丟棄TCP數(shù)據(jù)包前先丟失UDP，因為他知道TCP數(shù)據(jù)丟失后仍然會進(jìn)行重傳。

總的來說，對于那些對延遲很敏感的游戲，UDP的傳輸模式更加適合而且彈性很大，同時他也可以勝任那些同步頻率比較低的游戲，但是UDP的開發(fā)難度比較高，如果是自己從零開發(fā)確實有相當(dāng)多的細(xì)節(jié)需要考慮，所以建議大家在已有的RUDP框架上進(jìn)行優(yōu)化。

七、常見同步優(yōu)化技術(shù)

梳理完同步的發(fā)展歷史，我們最后再來總結(jié)一下常見的網(wǎng)絡(luò)同步優(yōu)化技術(shù)。首先，提出一個問題，網(wǎng)絡(luò)同步優(yōu)化到底是在優(yōu)化什么？

在單機(jī)游戲中，從我們按下按鍵到畫面的響應(yīng)中間經(jīng)歷了輸入采樣延遲、渲染流水線、刷新延遲、顯示延遲等。而在一個網(wǎng)絡(luò)游戲中，從我們按下按鍵到另一個機(jī)器收到指令，則會經(jīng)歷一個極為耗時的網(wǎng)絡(luò)延遲（相比之下，單機(jī)的延遲可以忽略不計）。網(wǎng)絡(luò)延遲其實也包括處理延遲、傳輸延遲（主要延遲）、排隊延遲以及傳播延遲，一般我們會將這些延遲統(tǒng)稱為網(wǎng)絡(luò)延遲，我們優(yōu)化的目的就是想盡各種辦法降低或是抵消掉這個延遲。

??單機(jī)延遲

數(shù)據(jù)從客戶端傳輸?shù)椒?wù)器的一個來回稱為一個RTT。在CS架構(gòu)下，其實每個客戶端的行為一直是領(lǐng)先于服務(wù)器1/2個RTT的，數(shù)據(jù)從客戶端發(fā)送到服務(wù)器有一個1/2的RTT延遲，服務(wù)器處理后通知客戶端又有一個1/2的RTT延遲。P2P架構(gòu)下，由于沒有權(quán)威服務(wù)器，我們可以省去1/2的 RTT延遲，但是在目前的網(wǎng)絡(luò)游戲中，為了對抗作弊行為以及容納更多的玩家，我們不得不采用CS架構(gòu)。

??網(wǎng)絡(luò)延遲RTT示意

由于在網(wǎng)絡(luò)游戲中，延遲是不可避免的，所以我們的優(yōu)化手段就是如何減小這個延遲以及如何讓玩家感受不到延遲。下面我會從表現(xiàn)優(yōu)化、延遲對抗、丟包對抗、帶寬優(yōu)化以及幀率優(yōu)化這幾個方面來做一下總結(jié)，

a.插值優(yōu)化

內(nèi)插值的目的是解決客戶端離散信息更新導(dǎo)致的突變問題，外插值的目的是解決網(wǎng)絡(luò)延遲過大或者抖動導(dǎo)致間歇性收不到數(shù)據(jù)而卡頓的問題，兩種方案并不沖突，可以同時采用。在具體應(yīng)用時，我們可以使邏輯幀與渲染幀分離（參考 王者榮耀技術(shù)總監(jiān)復(fù)盤），這樣在客戶端沒有收到新數(shù)據(jù)的時候還可以繼續(xù)更新渲染位置（只對渲染的模型位置信息進(jìn)行插值）。

b.客戶端預(yù)先執(zhí)行+回滾

預(yù)測的目的是讓玩家能在本地操作后立刻收到反饋，提升游戲體驗，回滾是為了保證服務(wù)器的權(quán)威性?？蛻舳祟A(yù)測包括位置預(yù)測以及行為預(yù)測兩種，位置預(yù)測需要高頻率的執(zhí)行，因為移動在每幀都可能發(fā)生，而其他行為預(yù)測則相對低頻一些，包括開槍、扔手雷、釋放技能等。另外，對于延遲不太敏感的游戲（比如MMO），可以放寬校驗條件（超過一定誤差再糾正），這樣即使降低服務(wù)器幀率客戶端也不會有什么感覺。

??仔細(xì)可以看出來本地的角色響應(yīng)更快，同時利用插值解決位置突變問題

a.延遲補(bǔ)償

服務(wù)器（注意是服務(wù)器而不是客戶端）記錄一段時間內(nèi)所有玩家的位置歷史，在發(fā)生傷害計算時根據(jù)延遲對所有玩家角色進(jìn)行位置的回滾與處理，可以盡量還原當(dāng)時的場景。

??角色身后的線表示延遲補(bǔ)償回退的位置信息

b.命令緩沖區(qū)

把遠(yuǎn)端的數(shù)據(jù)緩存在一個buffer里面，然后按照固定頻率從buffer里面取，可以解決客戶端卡頓以及網(wǎng)絡(luò)抖動問題。不過緩沖區(qū)與延遲是有沖突的，緩沖區(qū)越大，證明我們緩存的遠(yuǎn)端數(shù)據(jù)就越多，延遲就越大。

??守望先鋒采用的Inputbuffer

c.從具體實現(xiàn)的技巧上對抗延遲

客戶端操作加一個前幺時間，釋放技能等行為前有一個播放動畫表現(xiàn)的時間來抵消掉同步RTT的延遲。比如角色釋放無敵技能在進(jìn)入無敵狀態(tài)前做一個過度動畫，客戶端播放動畫后進(jìn)入無敵，但是服務(wù)器可以在收到指令后直接進(jìn)入無敵狀態(tài)從而抵消延遲。在游戲Halo中，有很多類似的例子，如在客戶端玩家扔手雷的時候，我們可以在本地立刻播放扔手雷的動畫并發(fā)送請求到服務(wù)器，然后服務(wù)器收到后不需要播放動畫立刻生成手雷并同步，這樣客戶端真正扔出手雷的表現(xiàn)就是0延遲的。

??光環(huán)中采用的扔手雷方案

a.使用TCP而不是UDP

由于TCP不會丟包，對于延遲不敏感的游戲還是優(yōu)先采取TCP來對抗丟包

b.冗余UDP數(shù)據(jù)包

一次性發(fā)送多個幀的數(shù)據(jù)來對抗丟包。UDP同步數(shù)據(jù)時經(jīng)常容易丟包，我們雖然可以使用上層實現(xiàn)UDP的可靠性，但是像幀同步這種同步數(shù)據(jù)量比較小的游戲可以采用冗余UDP的方案，即后續(xù)的UDP包會冗余一定量的前面已發(fā)送的UDP包，這樣即使丟失了部分包我們也能保證拿到完整的遠(yuǎn)端數(shù)據(jù)。

注：王者榮耀、守望先鋒、火箭聯(lián)盟等等游戲都使用類似的方案，該方案不僅僅適用于幀同步

帶寬優(yōu)化的目的是減小客戶端以及服務(wù)器的同步壓力，避免大量數(shù)據(jù)同時傳輸造成處理不過來，排隊甚至是丟失。帶寬優(yōu)化是非常靈活且多變的，我們需要根據(jù)游戲的玩法來調(diào)整我們的優(yōu)化行為。

a.同步對象裁剪

核心目的是根據(jù)相關(guān)性剔除那些不需要同步的對象（這里都是指在同一個服務(wù)器內(nèi)），比如一個玩家距離我很遠(yuǎn)，我們的行為彼此不會影響，所以就不需要互相同步對方的數(shù)據(jù)。裁剪方式有非常多，常見的SOI（Spheres of Influence），靜態(tài)區(qū)域（把場景劃分為N個小區(qū)域，不在一個區(qū)域不同步），視錐裁剪（更多用于渲染），八叉樹裁剪等。相關(guān)性還可能會涉及到聲音等其他因素，需要根據(jù)自己項目來決定。

這里著重提一點(diǎn)AOI ( Area Of Interest [21][22])?，即根據(jù)玩家的位置維護(hù)一個動態(tài)的視野列表，視野外的對象會被完全忽略（能大幅的減少同步對象的遍歷與比較）。其基本思想也是判斷相關(guān)性，實現(xiàn)方式有很多，其中基于格子的空間劃分算法是網(wǎng)絡(luò)游戲中常見的實現(xiàn)方案。在虛幻引擎中，大世界同步框架ReplicationGraph[23]的核心思想也是如此。不過要注意的是，對于MMO這種可能有大量角色同時進(jìn)行連續(xù)移動的游戲，視野列表頻繁的增刪查操作也可能對服務(wù)器造成一定的壓力。

??虛幻中的ReplicationGraph方案，寶箱會被添加到附近的格子里面

b.分區(qū)，分房間

對于大型MMO來說，這是常見的手段，將不同的玩家分散到不同的場景內(nèi)（不同的服務(wù)器），這樣減小服務(wù)器處理數(shù)據(jù)的壓力，減小延遲。對于大世界游戲而言，不同服務(wù)器可能接管同一個地圖不同區(qū)域的服務(wù)，其中的跨服數(shù)據(jù)同步比較復(fù)雜。

c.數(shù)據(jù)壓縮與裁剪

坐標(biāo)與旋轉(zhuǎn)是我們常見的同步內(nèi)容，但是很多數(shù)據(jù)其實是不需要同步的。比如對于大部分3D游戲角色的Pitch以及Roll是不會改變的，我們只要同步Y(jié)aw值即可。對于非第一人稱游戲，我們可以接著把四個字節(jié)float類型的Yaw壓縮到兩個字節(jié)的uint16里面，玩家根本不會有什么體驗上的差異。類似的方法可以應(yīng)用到各種同步數(shù)據(jù)里面。

此外，在狀態(tài)同步里面，我們可以采用增量發(fā)送來減少數(shù)據(jù)量，即第一次發(fā)送完整的數(shù)據(jù)信息后只發(fā)送哪些發(fā)生過變化的數(shù)據(jù)，這可以大大減少網(wǎng)絡(luò)同步的流量。

可以搜一下這兩篇文章：《Exploring in UE4》網(wǎng)絡(luò)同步原理深入（下）

以及《守望先鋒》回放技術(shù)-陣亡鏡頭、全場最佳和亮眼表現(xiàn)? 分別講解了虛幻引擎的屬性同步系統(tǒng)以及守望的回放增量同步處理

d.減少遍歷以及更細(xì)力度的優(yōu)化

在Halo以及虛幻引擎里面都會對同步對象做優(yōu)先級劃分，發(fā)送頻率調(diào)整等。在狀態(tài)同步中，我們還需要合適的手段來快速定位發(fā)生變化的數(shù)據(jù)，如屬性置臟、利用反射減少非同步屬性的遍歷等。進(jìn)一步的，我們還可以根據(jù)客戶端的類型以及信息作出更細(xì)致的同步信息過濾以及設(shè)置優(yōu)先級，比如對同步屬性進(jìn)行優(yōu)先級劃分等（目前還沒有見到過粒度如此細(xì)致的，但理論上是可行的）。

幀率優(yōu)化是一個重要且復(fù)雜的難題，涉及到方方面面的技術(shù)細(xì)節(jié)，這里主要針對網(wǎng)絡(luò)同步相關(guān)內(nèi)容做一些分析。

相比單機(jī)游戲，網(wǎng)游需要同時考慮客戶端與服務(wù)器的幀率，這并不是單純地提升幀率的問題，如何優(yōu)化與平衡是一個很微妙的過程。

a.提升幀率

這個不用多說，幀率低就意味著卡頓，玩家的體驗就會很差。不同游戲的性能瓶頸都可能不一樣，包括內(nèi)存問題（GC、頻繁的申請與釋放）、IO（資源加載、頻繁的讀寫文件，網(wǎng)絡(luò)包發(fā)送頻率過大，數(shù)據(jù)庫讀取頻繁）、邏輯問題（大量的遍歷循環(huán)，無意義的Tick，頻繁的創(chuàng)建刪除對象，過多的加鎖，高頻率的Log）、AI（尋路耗時[24]）、物理問題（復(fù)雜模擬，碰撞次數(shù)過多）、語言特性（腳本語言比較費(fèi)時）等，客戶端相比服務(wù)器還有各種復(fù)雜的渲染問題（Drawcall太多，半透明，動態(tài)陰影等）。這些問題需要長期的測試與調(diào)試，每個問題涉及到的具體細(xì)節(jié)可能都有所不同，需要對癥下藥才行。

??虛幻引擎中的性能數(shù)據(jù)展示

b.保持幀率穩(wěn)定與匹配

假如你的客戶端與服務(wù)器幀率已經(jīng)優(yōu)化到極致，你也不能任其自由變化。首先，要盡量保持服務(wù)器的幀率穩(wěn)定（減少甚至是消除玩家比賽時的所有潛在的卡頓問題），考慮一款對延遲比較敏感的射擊游戲，如果你的客戶端在開槍時遇到了服務(wù)器卡頓，那么就可能造成校驗失敗，導(dǎo)致客戶端看到的行為與服務(wù)器行為不一致。其次，還要保持客戶端與服務(wù)器的幀率匹配。對于延遲不敏感的游戲，考慮到玩家的體驗以及服務(wù)器的壓力，客戶端的幀率可以高于服務(wù)器多倍，但是這個比例是需要通過實際的測試來調(diào)整。而對于延遲敏感的游戲，我們一般需要盡量讓服務(wù)器的幀率接近客戶端，這樣服務(wù)器才能更及時的相應(yīng)，減少延遲帶來的誤差。此外，我們也不能讓客戶端的幀率無限提高，對于某些同步算法，客戶端與服務(wù)器過高的幀率差異可能造成不斷的拉回卡頓。所以，很多游戲會采取鎖幀的方式來保證游戲的穩(wěn)定性。

c.計算壓力分擔(dān)

對于MMO這種服務(wù)器壓力比較大的游戲，我們通常會考慮把一部分計算資源轉(zhuǎn)交給客戶端去計算（甚至是計算后再返還給服務(wù)器），比如物理運(yùn)算、自動尋路、AI邏輯計算等。其實將這種方式使用到極致的例子就是幀同步，服務(wù)器只做一些簡單的校驗即可。

總的來說，網(wǎng)絡(luò)同步優(yōu)化是一個長期的不斷試錯的過程，我們需要合理的利用計算機(jī)資源，把最重要的資源用在最重要的功能上面，減少重復(fù)的計算與流程，并需要配合一些經(jīng)驗和技巧來規(guī)避那些不好解決的問題。

八、總結(jié)

??歷史上“幀同步”和“狀態(tài)同步”的網(wǎng)絡(luò)游戲?qū)Ρ?/span>

??“幀同步”和“狀態(tài)同步”的使用場景與特點(diǎn)對比

我們從最開始的網(wǎng)絡(luò)游戲架構(gòu)談起，按照時間線梳理了近幾十年“幀同步”與“狀態(tài)同步”的發(fā)展歷程，并講述了各種同步技術(shù)以及優(yōu)化方案。雖然網(wǎng)絡(luò)同步是游戲中的技術(shù)，但其本質(zhì)還是計算機(jī)數(shù)據(jù)的同步。無論是Lockstep還是TimeWarp，最初都是用于計算機(jī)系統(tǒng)通信的技術(shù)，只不過應(yīng)用場景從一臺機(jī)器的內(nèi)部通信轉(zhuǎn)變?yōu)槎嗯_機(jī)器的通信，從傳統(tǒng)的應(yīng)用轉(zhuǎn)移到網(wǎng)絡(luò)游戲上面。

游戲的類型會影響到網(wǎng)絡(luò)同步的解決方案，也會影響到項目的整體架構(gòu)，所以我們在制作一款網(wǎng)絡(luò)游戲前要事先做好需求分析并確定網(wǎng)絡(luò)同步方案。同時也要意識到，網(wǎng)絡(luò)同步延遲是不可消除的，除了算法層面的優(yōu)化外還可以從實現(xiàn)技巧上來規(guī)避一些難題。

到此，歷時半年多的網(wǎng)絡(luò)同步系列終于迎來完結(jié)。不過網(wǎng)絡(luò)技術(shù)還在進(jìn)步，歷史也還在前行，讓我們一同繼續(xù)關(guān)注同步技術(shù)的發(fā)展和變化，期待未來的游戲世界。

后記：筆者花費(fèi)了近一年的時間才完成了《網(wǎng)絡(luò)同步在歷史上的發(fā)展變化》系列文章，期間查閱無數(shù)資料（論文、視頻、文章可能有200篇了）。目前該系列可以認(rèn)為是整個網(wǎng)絡(luò)上最為對游戲同步講解最為全面的文章，真心希望大家能幫忙轉(zhuǎn)發(fā)一下，讓更多需要的朋友看到。

- 原創(chuàng)不易，希望大家能點(diǎn)贊、分享支持一下 -

參考資料：[16]Glenn Fiedler, UDP vs. TCPhttps://gafferongames.com/post/udp_vs_tcp/ [Accessed:2020-12-12][17]WIKI, "Transmission Control Protocol", WIKI, 2020. Available:https://en.wikipedia.org/wiki/Transmission_Control_Protocol[Accessed:2020-12-12][18]Draveness, "為什么 TCP 協(xié)議有性能問題",? Personal Blog, 2020. Available:https://draveness.me/whys-the-design-tcp-performance/[Accessed:2020-12-12][19]WIKI, "User Datagram Protocol", WIKI, 2020. Available:https://en.wikipedia.org/wiki/User_Datagram_Protocol[Accessed:2020-12-12][20]小玩童，"Reliable UDP一覽：那些能替代TCP的RUDP方案",  Personal Blog, 2020. Available:https://juejin.cn/post/6844904089218711559[Accessed:2020-12-12][21]WIKI, "HTTP/3", WIKI, 2020. Available:https://en.wikipedia.org/wiki/HTTP/3[Accessed:2020-12-12][22]哈庫納, "聊一聊游戲服務(wù)器架構(gòu)設(shè)計－聊天功能的那些事" ,Personal Blog,2016.Available:https://my.oschina.net/ta8210/blog/709075[Accessed:2020-12-12][23]云風(fēng), “AOI服務(wù)的設(shè)計與實現(xiàn)”,Personal Blog,2012. Available:https://blog.codingnow.com/2012/03/dev_note_13.html[Accessed:2020-12-12][24]Jerry, “大世界同步方案ReplicationGraph”,知乎,2019. Available:https://zhuanlan.zhihu.com/p/56922476[Accessed:2020-12-12][25]王杰, "揭秘重度MMORPG手游后臺性能優(yōu)化方案",知乎,2018. Available:https://zhuanlan.zhihu.com/p/49787350[Accessed:2020-12-12]

虛幻引擎技術(shù)系列【使用虛幻引擎4年，我想再談?wù)勊木W(wǎng)絡(luò)架構(gòu)】