我一細想，這個問題壓根不需要通過改變現有介面提供更多的資料來做.下面從原理實現上簡單說下：
關鍵點：
對於斷點續傳，關鍵點是兩個：
檔案變化感知：
前置業務介面方案：
對於關鍵點1，對於決定大部分產品的業務場景，可以通過前置業務介面解決；這裡簡單介紹一下：
htpp 標準etag方案：
etag原理：如果url上的資源內容改變，乙個新的不一樣的etag就會被分配。用這種方法使用etag即類似於指紋
，並且他們能夠被快速地被比較，以確定兩個版本的資源是否相同。etag的比較只對同乙個url有意義——不同url上的資源的etag值可能相同也可能不同，從他們的etag的比較中無從推斷。
etag是http的乙個可選字段，且沒有規範他的實現；實際上業內用的比較多的就是使用md5簽名的方式來生成(linux shell md5sum)
典型用法：
server端： nginx >1.3.3 自帶有etag的module , 當然同時也可以在業務**裡setheaders加乙個etag欄位
client端：
第一次請求時：
第二次請求（斷點續傳時）：
如果etag值匹配，這就意味著資源沒有改變，伺服器便會傳送回乙個極短的響應，包含http 「304 未修改」的狀態。304狀態告訴客戶端，它的快取版本是最新的，並應該使用它。
然而，如果etag的值不匹配，這就意味著資源很可能發生了變化，那麼，乙個完整的響應就會被返回，包括資源的內容，就好像etag沒有被使用。這種情況下，客戶端可以用新返回的資源和新的etag替代先前的快取版本。
續傳支援：
對於乙個c/c++程式設計師，第一時間會得出乙個系統級實現方案：
1. 客戶端傳當前的offset
2. server端seek到檔案特定的offset開始讀取往http connection吐資料
不過我們深處在乙個開放方案和標準不斷完善的時代，不需要自己實現乙個（這也是像我這樣的c/c++研發工程師越來越沒落的原因）,來看看http協議是怎麼解決這個問題的：
http頭range欄位：
來個簡單粗暴的例子
衍生閱讀：
使用etags減少web應用頻寬和負載
HTTP斷點續傳原理
作為一名程式媛我也想快點進步，希望慢慢積累吧。給自己加加油。1.斷點續傳的必要性 2.了解斷點續傳之前，了解下http協議。http hyper text transfer protocol 協議是用於從全球資訊網 www 伺服器傳輸超文字到本地瀏覽器的傳送協議。它是基於tcp ip協議來傳遞資料的...
http斷點續傳原理
這周完成了乙個斷點續傳的功能。我們的遊戲裡載入地圖的邏輯簡化而言是這樣 1.首先用本地的md5檔案校驗地 件 很多檔案 是否完整。中間有很多步驟，任何步驟失敗都認為地圖不完整 2.如果完整，直接載入地圖。3.如果不完整，需要通過乙個http協議請求後台伺服器傳回完整的地圖。要解決這個問題，要了解以下...
HTTP的斷點續傳原理
accept ranges 由server傳送給client時需要的關鍵字。表明是否支援斷點續傳。accept ranges none 表示不支援斷點續傳 accept ranges bytes 表示支援以bytes為單位進行傳輸 content ranges 由server傳送給client時需要...