http斷點續傳原理

這周完成了乙個斷點續傳的功能。

我們的遊戲裡載入地圖的邏輯簡化而言是這樣：

1.首先用本地的md5檔案校驗地**件（很多檔案）是否完整。（中間有很多步驟，任何步驟失敗都認為地圖不完整）

2.如果完整，直接載入地圖。

3.如果不完整，需要通過乙個http協議請求後台伺服器傳回完整的地圖。

要解決這個問題，要了解以下問題：

1.正常的http請求流程。

2.http分段請求的原理。

1.http請求的流程

客戶端傳送的請求被封裝成請求報文。

請求報文的內容裡面包括請求方法，請求位址，http協議版本，請求首部。其中的請求方法就是所謂的get，post，put，header，delete，options，trace，connect這些。這裡我們無需詳細了解。

伺服器收到請求以後，會以響應報文的形式發回客戶端。響應報文裡面包括了http協議版本，狀態碼，狀態碼的原因短語，響應首部，請求的實體主體。

狀態碼會標記服務端是否正常處理，是個重要的引數。

因為是需要直接請求實體，當然是用get方法。另外只需要知道url就行。網路正常的情況下，服務端會返回狀態碼200。而返回的實體就是地**件，通常是乙個壓縮檔案.zip，用二進位制模式寫到乙個檔案，再用ziplib之類解壓。

2.http分段請求的原理

那麼斷點續傳怎麼做呢。在客戶端發起的請求報文裡，請求首部裡面有個可選引數range，用來標識只請求實體的一部分。

格式形如：range: bytes=500-999，請求500bytes到999bytes。range: bytes=500-，請求500bytes開始到結束的部分。

那麼斷點續傳其實就是知道上一次傳輸的終點，把它作為range引數的起點，發起請求。

如果請求首部帶有range引數，那麼伺服器正常情況會返回狀態碼206和請求的部分實體。

所以每次發起請求前，判斷是否需要斷點續傳，只需要判斷存不存在temp.zip即可。

1.首先用本地的md5檔案校驗地**件（很多檔案）是否完整。（中間有很多步驟，任何步驟失敗都認為地圖不完整）

2.如果完整直接使用本地地圖。

3.如果不完整，判斷是否存在temp.zip檔案。

4.如果存在，請求頭部帶有range引數，起點是temp檔案的大小。

5.如果不存在，預設的請求頭部，請求完整的檔案。

中間有一些細節問題。可能和具體的實現框架有關。想象一次研發測試流程：

2.把網接回，再啟動遊戲，判斷是否有temp.zip，有temp.zip，所以將temp.zip的檔案大小作為range引數的起點，發起部分請求。把收到的實體寫入temp.zip，但是這次的寫入起點是檔案的末尾。把檔案改名為map_id.zip。

這兩個情況都是寫在乙個函式裡的，那麼怎麼判斷temp.zip檔案是否已經是完整的地**件呢？要不要改名了呢？

我這邊的框架裡面，伺服器返回的實體res裡面有個error引數，通過這個引數就能知道本次返回的實體，是不是客戶端請求的全部實體（包括完整的請求和部分的請求）。

也就是說如果res裡面的error是true，那麼最後是不會走到改名那步的。下一次請求還是會走斷點續傳。反之error是false，那麼說明本次請求返回的實體已經完整，最後會走到改名那步。

另外乙個問題。如果伺服器上的檔案內容變更了，我們還從舊檔案的斷點位置請求，這樣就會出錯了。

這個問題，可以考慮請求首部的if-range引數和響應首部的etag引數。也就是說要客戶端記錄傳回檔案的etag，下一次請求把此etag作為if-range引數。那麼伺服器會根據etag判斷檔案是否更新。

也可以用其他方法，比如大家約定好，伺服器那邊地圖改變了，地圖就換乙個名字（用時間戳做地圖名字字尾），那麼客戶端這邊請求的名字就會變了。不需要考慮if-range引數。也不必在客戶端記錄etag。

引用：1.《**http》