注意，本文所說的斷點(diǎn)續(xù)傳特指 HTTP 協(xié)議中的斷點(diǎn)續(xù)傳。本文主要聊聊思路和關(guān)鍵代碼，更多細(xì)節(jié)請(qǐng)參考本文附帶的 demo。
“專業(yè)、務(wù)實(shí)、高效、創(chuàng)新、把客戶的事當(dāng)成自己的事”是我們每一個(gè)人一直以來堅(jiān)持追求的企業(yè)文化。 成都創(chuàng)新互聯(lián)是您可以信賴的網(wǎng)站建設(shè)服務(wù)商、專業(yè)的互聯(lián)網(wǎng)服務(wù)提供商! 專注于成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、軟件開發(fā)、設(shè)計(jì)服務(wù)業(yè)務(wù)。我們始終堅(jiān)持以客戶需求為導(dǎo)向，結(jié)合用戶體驗(yàn)與視覺傳達(dá)，提供有針對(duì)性的項(xiàng)目解決方案，提供專業(yè)性的建議，創(chuàng)新互聯(lián)建站將不斷地超越自我，追逐市場(chǎng)，引領(lǐng)市場(chǎng)！
HTTP 協(xié)議中定義了一些請(qǐng)求/響應(yīng)頭，通過組合使用這些頭信息。我們可以在一次 HTTP 請(qǐng)求中只請(qǐng)求一個(gè)文件中的一部分?jǐn)?shù)據(jù)。這樣我們就可以把已經(jīng)下載的數(shù)據(jù)存起來，下次只用請(qǐng)求剩余的數(shù)據(jù)即可，當(dāng)全部數(shù)據(jù)都下載到本地后再完成合并工作。
HTTP 協(xié)議指出，可以通過 HTTP 請(qǐng)求中的 Range 頭指定請(qǐng)求數(shù)據(jù)的范圍，Range 頭的使用也很簡(jiǎn)單，只要指定下面的格式就可以了：
Range: bytes=500-999
它的意思是，只請(qǐng)求目標(biāo)文件的第 500 到第 999 這 500 個(gè)字節(jié)。
比如我有一個(gè)1000 bytes 大小的文件需要下載，第一次請(qǐng)求時(shí)不用指定 Range 頭，表示下載整個(gè)文件。但在下載完第 499 個(gè)字節(jié)后，下載被取消了。那么在下一次請(qǐng)求下載同一個(gè)文件時(shí)，只需要下載第 500 個(gè)字節(jié)至第 999 個(gè)字節(jié)的數(shù)據(jù)就可以了。原理看上去很簡(jiǎn)單，但我們需要考慮下面幾個(gè)問題：
1． 是不是所有的 web 服務(wù)器都支持 Range 頭？
2． 多次請(qǐng)求之間可能會(huì)間隔很長(zhǎng)的時(shí)間，服務(wù)器上的文件發(fā)生了變化怎么辦？
3． 如何保存下載的部分?jǐn)?shù)據(jù)和相關(guān)信息？
4． 當(dāng)我們通過字節(jié)操作把一個(gè)文件拼成原始大小后，如何驗(yàn)證它和源文件一模一樣？
下面我們就帶著這些問題去探究斷點(diǎn)續(xù)傳的一些細(xì)節(jié)。
在服務(wù)器響應(yīng)我們的請(qǐng)求時(shí)，會(huì)在響應(yīng)頭中通過 Accept-Ranges 指明是否接受請(qǐng)求一個(gè)資源的一部分?jǐn)?shù)據(jù)。但這里似乎有個(gè)小小的陷阱，就是不同的服務(wù)器可能返回不同的值來指明自己能夠接受部分資源的請(qǐng)求。貌似比較統(tǒng)一的方法是，當(dāng)服務(wù)器不支持請(qǐng)求部分?jǐn)?shù)據(jù)時(shí)，都會(huì)返回 Accept-Ranges: none，我們只要判斷這個(gè)返回值是不是等于 none 就行了。代碼如下：
重慶分公司
重慶分公司
private static bool IsAcceptRanges(WebResponse res)
{ if (res.Headers["Accept-Ranges"] != null)
{ string s = res.Headers["Accept-Ranges"]; if (s == "none")
{ return false;
}
} return true;
}
當(dāng)我們下載了一個(gè)文件的一部分之后，可能馬上就會(huì)接著下載，也可能會(huì)過一段時(shí)間再下載，也可能永遠(yuǎn)不會(huì)再接著下載了…
這里的問題是，當(dāng)下次要接著下載時(shí)，如何確定服務(wù)器上的文件還是當(dāng)初下載了一半的那個(gè)文件。如果服務(wù)器上的文件已經(jīng)更新了，那無論如何都需要重新從頭開始下載。只有在服務(wù)器上的文件沒有發(fā)生變化的情況下，斷點(diǎn)續(xù)傳才有意義。
對(duì)于這個(gè)問題，HTTP 響應(yīng)頭為我們提供了不同的選擇。ETag 和 Last-Modified 都能完成任務(wù)。
先看 ETag：
The ETag response-header field provides the current value of the entity tag for the requested variant. (引自RFC2616 14.19 ETag)
簡(jiǎn)單點(diǎn)說 ETag 就是一個(gè)標(biāo)識(shí)當(dāng)前請(qǐng)求內(nèi)容的字符串，當(dāng)請(qǐng)求的資源發(fā)生變化后，對(duì)應(yīng)的 ETag 也會(huì)變化。好了，最簡(jiǎn)單的辦法是第一次請(qǐng)求時(shí)，把響應(yīng)頭中的 ETag 存下來，下次請(qǐng)求時(shí)做比較。代碼如下：
string newEtag = GetEtag(response);// tempFileName指已經(jīng)下載到本地的部分文件內(nèi)容// tempFileInfoName指保存了Etag內(nèi)容的臨時(shí)文件if (File.Exists(tempFileName) && File.Exists(tempFileInfoName))
{ string oldEtag = File.ReadAllText(tempFileInfoName); if (!string.IsNullOrEmpty(oldEtag) && !string.IsNullOrEmpty(newEtag) && newEtag == oldEtag)
{ // Etag沒有變化，可以斷點(diǎn)續(xù)傳
resumeDowload = true;
}
}else{ if (!string.IsNullOrEmpty(newEtag))
{
File.WriteAllText(tempFileInfoName, newEtag);
}
}private static string GetEtag(WebResponse res)
{ if (res.Headers["ETag"] != null)
{ return res.Headers["ETag"];
} return null;
}
再來看看 Last-Modified：
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified. (引自RFC2616 14.29 Last-Modified)
Last-Modified 就是所請(qǐng)求的資源在服務(wù)器上的最后一次修改時(shí)間。使用方法和 ETag 大體相同。
個(gè)人感覺使用 ETag 和 Last-Modified 中的任何一個(gè)都能達(dá)到我們的目的。但是你也可以兩個(gè)都用，做 double check，誰知道web服務(wù)器的實(shí)現(xiàn)是不是嚴(yán)格遵循了 HTTP 協(xié)議！
這里主要就是用 C# 進(jìn)行文件操作。大體思路是如果有未下載完的文件，就把新下載的字節(jié)添加到文件的末尾，不再啰嗦，有興趣的同學(xué)請(qǐng)直接看 demo 代碼。
在斷點(diǎn)續(xù)傳的過程中，我們以 byte 為單位下載、合并文件，如果整個(gè)過程中稍有沒有處理好的異常，可能最后得到的文件就和源文件不太一樣。因此最好是能夠?qū)ο螺d好的文件進(jìn)行一次校驗(yàn)?？蛇@也是最難、最不容易實(shí)現(xiàn)的。因?yàn)樗枰?wù)器端的支持，比如服務(wù)器端在提供一個(gè)可下載文件的同時(shí)提供該文件的 MD5 hash。當(dāng)然，如果服務(wù)器端也是我們自己創(chuàng)建的，我們就可以去實(shí)現(xiàn)它。但我們又怎么能夠要求現(xiàn)存的 web 服務(wù)器都提供這樣的功能呢！
