c# 斷點續(xù)傳的實現(xiàn)
作者:sparkdev
出處:http://www.cnblogs.com/sparkdev/
注意,本文所說的斷點續(xù)傳特指 HTTP 協(xié)議中的斷點續(xù)傳。本文主要聊聊思路和關(guān)鍵代碼,更多細(xì)節(jié)請參考本文附帶的 demo。
工作原理
HTTP 協(xié)議中定義了一些請求/響應(yīng)頭,通過組合使用這些頭信息。我們可以在一次 HTTP 請求中只請求一個文件中的一部分?jǐn)?shù)據(jù)。這樣我們就可以把已經(jīng)下載的數(shù)據(jù)存起來,下次只用請求剩余的數(shù)據(jù)即可,當(dāng)全部數(shù)據(jù)都下載到本地后再完成合并工作。
HTTP 協(xié)議指出,可以通過 HTTP 請求中的 Range 頭指定請求數(shù)據(jù)的范圍,Range 頭的使用也很簡單,只要指定下面的格式就可以了:
Range: bytes=500-999
它的意思是,只請求目標(biāo)文件的第 500 到第 999 這 500 個字節(jié)。
比如我有一個1000 bytes 大小的文件需要下載,第一次請求時不用指定 Range 頭,表示下載整個文件。但在下載完第 499 個字節(jié)后,下載被取消了。那么在下一次請求下載同一個文件時,只需要下載第 500 個字節(jié)至第 999 個字節(jié)的數(shù)據(jù)就可以了。原理看上去很簡單,但我們需要考慮下面幾個問題:
1. 是不是所有的 web 服務(wù)器都支持 Range 頭?
2. 多次請求之間可能會間隔很長的時間,服務(wù)器上的文件發(fā)生了變化怎么辦?
3. 如何保存下載的部分?jǐn)?shù)據(jù)和相關(guān)信息?
4. 當(dāng)我們通過字節(jié)操作把一個文件拼成原始大小后,如何驗證它和源文件一模一樣?
下面我們就帶著這些問題去探究斷點續(xù)傳的一些細(xì)節(jié)。
檢查服務(wù)器端對斷點續(xù)傳的支持
在服務(wù)器響應(yīng)我們的請求時,會在響應(yīng)頭中通過 Accept-Ranges 指明是否接受請求一個資源的一部分?jǐn)?shù)據(jù)。但這里似乎有個小小的陷阱,就是不同的服務(wù)器可能返回不同的值來指明自己能夠接受部分資源的請求。貌似比較統(tǒng)一的方法是,當(dāng)服務(wù)器不支持請求部分?jǐn)?shù)據(jù)時,都會返回 Accept-Ranges: none,我們只要判斷這個返回值是不是等于 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;
}
檢查服務(wù)器端文件是否變化
當(dāng)我們下載了一個文件的一部分之后,可能馬上就會接著下載,也可能會過一段時間再下載,也可能永遠(yuǎn)不會再接著下載了…
這里的問題是,當(dāng)下次要接著下載時,如何確定服務(wù)器上的文件還是當(dāng)初下載了一半的那個文件。如果服務(wù)器上的文件已經(jīng)更新了,那無論如何都需要重新從頭開始下載。只有在服務(wù)器上的文件沒有發(fā)生變化的情況下,斷點續(xù)傳才有意義。
對于這個問題,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)
簡單點說 ETag 就是一個標(biāo)識當(dāng)前請求內(nèi)容的字符串,當(dāng)請求的資源發(fā)生變化后,對應(yīng)的 ETag 也會變化。好了,最簡單的辦法是第一次請求時,把響應(yīng)頭中的 ETag 存下來,下次請求時做比較。代碼如下:
string newEtag = GetEtag(response);
// tempFileName指已經(jīng)下載到本地的部分文件內(nèi)容
// tempFileInfoName指保存了Etag內(nèi)容的臨時文件
if (File.Exists(tempFileName) && File.Exists(tempFileInfoName))
{
string oldEtag = File.ReadAllText(tempFileInfoName);
if (!string.IsNullOrEmpty(oldEtag) && !string.IsNullOrEmpty(newEtag) && newEtag == oldEtag)
{
// Etag沒有變化,可以斷點續(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 就是所請求的資源在服務(wù)器上的最后一次修改時間。使用方法和 ETag 大體相同。
個人感覺使用 ETag 和 Last-Modified 中的任何一個都能達(dá)到我們的目的。但是你也可以兩個都用,做 double check,誰知道web服務(wù)器的實現(xiàn)是不是嚴(yán)格遵循了 HTTP 協(xié)議!
保存中間結(jié)果
這里主要就是用 C# 進(jìn)行文件操作。大體思路是如果有未下載完的文件,就把新下載的字節(jié)添加到文件的末尾,不再啰嗦,有興趣的同學(xué)請直接看 demo 代碼。
驗證文件
在斷點續(xù)傳的過程中,我們以 byte 為單位下載、合并文件,如果整個過程中稍有沒有處理好的異常,可能最后得到的文件就和源文件不太一樣。因此最好是能夠?qū)ο螺d好的文件進(jìn)行一次校驗??蛇@也是最難、最不容易實現(xiàn)的。因為它需要服務(wù)器端的支持,比如服務(wù)器端在提供一個可下載文件的同時提供該文件的 MD5 hash。當(dāng)然,如果服務(wù)器端也是我們自己創(chuàng)建的,我們就可以去實現(xiàn)它。但我們又怎么能夠要求現(xiàn)存的 web 服務(wù)器都提供這樣的功能呢!
以上就是c# 斷點續(xù)傳的實現(xiàn)的詳細(xì)內(nèi)容,更多關(guān)于c# 斷點續(xù)傳的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
C#短時間內(nèi)產(chǎn)生大量不重復(fù)的隨機數(shù)
在C#編程中,經(jīng)常會碰到產(chǎn)生隨機數(shù)的情況,并且是在短時間內(nèi)產(chǎn)生一組隨機數(shù)。如果這組隨機數(shù)中有大量重復(fù)的,則達(dá)不到我們的要求2013-02-02

