HTTP協定－－斷點續傳

要實作斷點續傳的功能，通常都需要用戶端記錄下目前的下載下傳進度，并在需要續傳的時候通知服務端本次需要下載下傳的内容片段。

HTTP1.1協定（RFC2616）中定義了斷點續傳相關的HTTP頭 Range和Content-Range字段，一個最簡單的斷點續傳實作大概如下：

  1.用戶端下載下傳一個1024K的檔案，已經下載下傳了其中512K

  2. 網絡中斷，用戶端請求續傳，是以需要在HTTP頭中申明本次需要續傳的片段：

       Range:bytes=512000-

    這個頭通知服務端從檔案的512K位置開始傳輸檔案

  3. 服務端收到斷點續傳請求，從檔案的512K位置開始傳輸，并且在HTTP頭中增加：

    Content-Range:bytes 512000-/1024000

    并且此時服務端傳回的HTTP狀态碼應該是206，而不是200。

但是在實際場景中，會出現一種情況，即在終端發起續傳請求時，URL對應的檔案内容在服務端已經發生變化，此時續傳的資料肯定是錯誤的。如何解決這個問題了？顯然此時我們需要有一個辨別檔案唯一性的方法。在RFC2616中也有相應的定義，比如實作Last-Modified來辨別檔案的最後修改時間，這樣即可判斷出續傳檔案時是否已經發生過改動。同時RFC2616中還定義有一個ETag的頭，可以使用ETag頭來放置檔案的唯一辨別，比如檔案的MD5值。

終端在發起續傳請求時應該在HTTP頭中申明If-Match 或者If-Modified-Since 字段，幫助服務端判别檔案變化。

另外RFC2616中同時定義有一個If-Range頭，終端如果在續傳是使用If-Range。If-Range中的内容可以為最初收到的ETag頭或者是Last-Modfied中的最後修改時候。服務端在收到續傳請求時，通過If-Range中的内容進行校驗，校驗一緻時傳回206的續傳回應，不一緻時服務端則傳回200回應，回應的内容為新的檔案的全部資料。