前幾天一個同事跑過來找我說,我們在廣告素材視頻這塊想做斷點續傳,就是這次某個視頻緩存到一半,下次不用重頭開始,可以在原來停留得位置開始繼續下載.以提供更好的用戶體驗。 同時說需要我們支持吐素材地址的業務介面告訴終端最後修改時間/文件簽名(md5),用這個用來判斷我當前要下的文件有沒有變化,同時告訴終 ...
前幾天一個同事跑過來找我說,我們在廣告素材視頻這塊想做斷點續傳,就是這次某個視頻緩存到一半,下次不用重頭開始,可以在原來停留得位置開始繼續下載.以提供更好的用戶體驗。
同時說需要我們支持吐素材地址的業務介面告訴終端最後修改時間/文件簽名(md5),用這個用來判斷我當前要下的文件有沒有變化,同時告訴終端文件的Size大小.
我一細想,這個問題壓根不需要通過改變現有介面提供更多的數據來做.下麵從原理實現上簡單說下:
關鍵點:
對於斷點續傳,關鍵點是兩個:
1. 終端知道當前的文件和上一次載入的文件是不是內容發生了變化,如果有變化,需要重新從offset 0 的位置開始下載
2. 終端記錄好上次成功下載到的offset,告訴server端,server端支持從特定的offset 開始吐數據
文件變化感知:
前置業務介面方案:
對於關鍵點1,對於決定大部分產品的業務場景,可以通過前置業務介面解決;這裡簡單介紹一下:
對於非下載工具類的產品,如視頻APP(奇藝,優酷),視頻播放前會請求相關業務的信息,主要返回片子叫什麼名字,主要演員等等一些列信息,同時會返回一個對於播放最重要的信息——播放地址。
播放地址就是我們可以做文章的地方,如果《太子妃第一集》這個片子更新了(被廣電要求減掉某個污的畫面),可以後端系統讓這個業務介面吐不同的播放地址/一個不同的url參數(?ver=1.1)/位置參數(#ver1.1)。這樣純天然的URL變化能純天然的讓終端認為不是同一個片子,而需要重新載入。
HTPP 標準ETAG方案:
沒有業務介面的下載工具類的如何解決呢?
下載工具類的沒有前置介面,可以使用HTTP 的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端:
第一次請求時:
String etag = httpURLConnection.getHeaderField("ETag");
ETag: "b428eab9654aa7c87091e"
第二次請求(斷點續傳時):
httpURLConnection.setRequestProperty(“If-None-Match”, "b428eab9654aa7c87091e");
If-None-Match: "b428eab9654aa7c87091e"
如果ETag值匹配,這就意味著資源沒有改變,伺服器便會發送回一個極短的響應,包含HTTP “304 未修改”的狀態。304狀態告訴客戶端,它的緩存版本是最新的,並應該使用它。
然而,如果ETag的值不匹配,這就意味著資源很可能發生了變化,那麼,一個完整的響應就會被返回,包括資源的內容,就好像ETag沒有被使用。這種情況下,客戶端可以用新返回的資源和新的ETag替代先前的緩存版本。
續傳支持:
對於一個C/C++程式員,第一時間會得出一個系統級實現方案:
1. 客戶端傳當前的offset
2. server端seek到文件特定的offset開始讀取往http connection吐數據
不過我們深處在一個開放方案和標準不斷完善的時代,不需要自己實現一個(這也是像我這樣的C/C++研發工程師越來越沒落的原因),來看看HTTP協議是怎麼解決這個問題的:
HTTP頭Range欄位:
Range : 用於客戶端到伺服器端的請求,可通過該欄位指定下載文件的某一段大小,及其單位。典型的格式如:
Range: bytes=0-499 下載第0-499位元組範圍的內容
Range: bytes=500-999 下載第500-999位元組範圍的內容
Range: bytes=-500 下載最後500位元組的內容
Range: bytes=500- 下載從第500位元組開始到文件結束部分的內容
來個簡單粗暴的例子
curl --header "Range: bytes=0-20000" xxx.com/memcache.pdf -o part1
curl --header "Range: bytes=20001-223651" xxx.com/memcache.pdf -o part2
cat part1 part2 >> a.pdf
衍生閱讀: