Web工作流程是怎樣的

這篇文章主要介紹“Web工作流程是怎樣的”，在日常操作中，相信很多人在Web工作流程是怎樣的問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Web工作流程是怎樣的”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Web和網游的最大不同也許就在于數據同步。

Web工作流程（這里不包括頁游）雖然也有很多變化，但是一般都分為大致三步。

1. 在瀏覽器輸入網址， 瀏覽器通過HTTP協議請求服務器加載數據，服務器在收到HTTP請求之后，從數據庫加載相應的數據（有可能是HTML,JS等一些用于瀏覽器渲染的數據）并返回給客戶端。這一步我稱之為查詢。

2. 瀏覽器收到服務器返回的數據之后，將數據渲染并呈現給用戶。這一步我稱之為渲染。

3. 用戶在看到瀏覽器呈現的內容之后，根據需要去執行不同的操作，這些操作為導致瀏覽器將一些數據發往服務器進行處理，這一步我稱為提交。

大部分Web邏輯除了在這三步之間循環之外，還有一個很重要的特點，那就是幾乎很少于旁人進行實時交互。比如你在某論壇改了名字，也需要對方手動刷新才能看到。當然也有可以實現顯示的，但那是極少的功能才有待遇（并且一般都是通過Hang住HTTP請求來實現的），這里暫時不考慮這種情況。

因此，市面上對Web的高可伸縮性的研究，大都維繞著數據庫來做。因此HTTP的數據同步量真的沒有什么好研究的，他這種模式幾乎已經把數據同步量壓縮到最低了。只有用戶操作才會加載數據，這是多么節省的一種數據同步方式啊。

網游本身就是一個強交互的模式，玩家A做了一個操作，所有應該能看到玩家A的其他玩家都必須能看到玩家A做了什么操作（只是理論上，也許由于某種技能別人看不到，這里不討論這種情況）。

這樣數據的同步量就會非常大，而且這種數據量，會隨著同時在線的玩家指數性增加。

于是人們研究了各種減少數據同步量的算法，比如AOI、幀同步等。

這里我先私自把游戲分為開房間和大地圖兩種模式。

開房間模式的游戲,一般同一個房間的人數不會過多。所以最簡單的做法就是，直接同步位置和狀態。

每個人客戶端移動過程中定時（比如10ms)廣播坐標給房間內所有玩家，然后客戶根據新坐標，做插值補償。這又被作影子跟隨算法，即客戶端實際表現，永遠落后于客戶端真正的位置。

如果客戶端放了一個技能，就把這個技能效果廣播給房間內的所有玩家。

但是這里會存在一個問題，如果這是一個延時類技能，比如幾秒后生效，那么服務器在收到釋放技能時就需要廣播一次，當技能真正生效時，還需要再次廣播一次。如果是一個每隔幾秒生效就生效一次的buff就會更麻煩，每次buff生效，都要進行消息廣播。數據量會遠超于玩家的操作頻次。

即然大部分數據量都是狀態同步引起的，那么我所有狀態全讓客戶端自己運算不就完了嘛，這就是幀同步的本質。客戶端擁有整個游戲的全部運算邏輯，將整個游戲進程人為劃分為邏輯幀，每個邏輯幀玩家上報自己的操作，由服務器進行房間內廣播。客戶端收到操作為自己還原各種狀態。如果房間內有N個人，每個人僅僅操作M次，數據同步量只有M*N條消息，遠低于之前的狀態同步數據量。這對于流量并不富裕的手機來說尤其是個好消息。

如何保證所有客戶端邏輯和表現都一致，除了要做正確一邏輯幀操作還原外，還有一點很重要，就是復原隨機邏輯（戰斗中經常會有各種概率判斷)。這一點可以通過偽隨機序列來保證。

下面來看看大地圖模式（這里的大地圖模式，是指所有玩家在一張地圖上，并且戰斗過程中不切換場景）。

在大地圖模式，所有玩家都在一張地圖上行動，因此玩家數量與房間內的數據根本不是一個數據級（雖然有可能為了增加同時在線人數，可能會去地圖進行分塊處理，但是那也遠大于房間內人數)。

這也就意味著將數據（操作數據或狀態數據）廣播給地圖上的所有玩家，是不現實的。所以必須要采用AOI算法，來選取需要收到這些數據的玩家。然后將這些數據組播給選取到的玩家。

當使用了AOI算法之后，一般來講人數的量級與上面開房間模式需要同步的人數量級差不多了。

那么是否使用了AOI之后，同樣可以采用幀同步算法優化掉狀態同步呢。

答案顯然是否定的，上面也提到，所有的戰斗系統一般都會有概率的存在，而一張大地圖上必須也只可能有一個偽隨機序列（因為玩家之間的視野是交錯的）。這也就意味著所有的客戶端不可能事先知道這個偽隨機序列走到哪一步了（每場戰斗都會使偽隨機序列前進一步，如果要所有客戶端都實時知道當前偽隨機序列的進度，就必須在每一場戰斗之，將當前隨機數廣播給地圖內所有玩家，這顯然是不是現實的)。

從上面的分析可以得出一個結論，制約大地圖模式使用幀同步算法的惟一因素，就是無法復原隨機邏輯。那么如果我們游戲地圖內沒有隨機因素（暫且不論是不是有可能），是否可以在AOI的基礎上再使用幀同步算法的變種呢。

我們來分析幾種情況來看看是否可行，這里需要強調一點，我們假設整個通信采用TCP傳輸，而TCP是有FIFO性質的，而服務器采用的是單線程模式。

1. 玩家B先看到了玩家A，然后玩家A被打了掉了5滴血，最終玩家A還有75滴血。

玩家B首先在視野內看到了玩家A，這時會同步到玩家A的血量為80. 

然后B收到了玩家A被打的操作（這個操作固定傷5滴血）,玩家B將80減去5得出玩家A還有75滴血的結果。顯然這是正確的。

雖然可能buf之類的帶時間的不好控制，但是想信經過合理的設計，邏輯上應該是沒有問題的。

2. 玩家B還沒收看到玩家A，然后玩家A被打掉了5滴血。

玩家B收到玩家A被打的操作消息后，發現自己視野內還沒有加載出玩家A的數據（注意是從服務器加載到的數據，不是客戶端還沒有把模型之類的數據加載完), 于是將消息拋棄。

之后，玩家B收到的從服務器請求來的數據，A的血量為75。顯然這也沒有錯。

所以在沒有偽隨機存在的情況下，完全可以使用幀同步算法的理論，進一步優化狀態同步。

很巧我們最近開發的游戲，大地圖上的表現確實不需要偽隨機序列。

到此，關于“Web工作流程是怎樣的”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！