在ASP.NET中跟蹤和恢複大檔案下載

asp.net|恢複|下載 在Web應用程式中處理大檔案下載的問題一直出了名的困難，因此對於大多數網站來說，如果使用者的下載被中斷了，它們只能說悲哀降臨到使用者的身上了。但是我們現在不必這樣了，因為你可以使自己的ASP.NET應用程式有能力支援可恢複（繼續）的大檔案下載。使用本文提供的方法的時候，你可以跟蹤下載的過程，這樣你就可以處理動態建立的檔案--而且要達到這個目標根本不需要舊式的ISAPI動態連結程式庫和非受控的（unmanaged）C++代碼。

　　為用戶端提供從互連網上下載檔案的服務最容易了，對嗎？僅僅只需要把可下載的檔案複製到你的Web應用程式目錄中，發布連結並讓IIS完成所有相關的工作。但是，檔案服務不應該比脖子上的疼痛還要多（還要麻煩），你不希望整個世界都能訪問自己的資料，你不希望伺服器被數百個靜態檔案塞滿了，你甚至於希望下載臨時檔案--只有當用戶端開始下載後的空閑時間才建立這些檔案。

　　不幸的是，使用IIS對下載請求的預設的響應是不可能達到這些效果的。因此在一般情況下，為了獲得對下載過程的控制權，開發人員需要連結到一個定製的.aspx頁面，在這個頁面中它們檢查使用者憑證（credential）、建立可以下載的檔案並使用下面的代碼把該檔案推送給用戶端：

Response.WriteFile
Response.End()
　　而這就是出現真正麻煩的地方。

　　有什麼問題？

　　WriteFile方法看起來非常完美，它使檔案的位元據流向用戶端。但是直到最近我們才知道，WriteFile方法是一個出名的記憶體佔用狂，它把整個檔案載入伺服器的RAM中來提供服務（實際上它甚至於會佔用檔案兩倍大小的空間）。對於大檔案，這會引起服務記憶體問題，並且可能重複ASP.NET過程。但是在2004年6月微軟發布了一個補丁解決了這個問題。這個補丁現在是.NET Framework 1.1補丁包（SP1）的一部分。

　　這個補丁引入了TransmitFile方法，它把一個磁碟檔案讀入到較小的記憶體緩衝區之後就開始傳輸該檔案。儘管這個方案解決了記憶體和迴圈的問題，但是它仍然不能令人滿意。你不能控制響應的生命週期。你無法知道下載是否正確地完成了，你沒有辦法知道下載是否被中斷了，並且（如果你建立了臨時檔案）你也不知道是否應該、以及什麼時候可以刪除這些檔案。更糟的是，如果下載的確失敗了，TransmitFile方法又從用戶端下次嘗試的檔案頭部開始下載。

　　其中一種可能的解決方案--實現背景智慧型傳送服務（BITS）對於多數網站來說是不可行的，因為這會毀掉維持用戶端瀏覽器和作業系統獨立性而作出的努力。

　　令人滿意的解決方案的基礎還是來自微軟用於解決WriteFile引起的記憶體混亂問題的第一次嘗試（見知識庫文章812406）。那篇文章示範了智能的大塊資料下載過程，它從檔案流中讀取資料。在伺服器把位元組塊發送給用戶端之前，它使用Response.IsClientConnected屬性檢查用戶端是否仍然保持著串連。如果仍然保持串連，它就繼續發送流位元組，否則就停止，以防止伺服器發送不必要的資料。
這就是我們採用的方法，特別是在下載臨時檔案的時候。在IsClientConnected返回False的情況下，你就知道下載過程被中斷了，你應該儲存檔案；反之，當這個過程成功完成的時候，你就刪除臨時檔案。此外，為了恢複中斷了的下載，你需要做的工作是從上次下載嘗試過程中用戶端串連失敗的檔案點開始下載。

　　HTTP協議和頭資訊（Header）支援

　　HTTP協議支援可以用於處理被中斷下載的頭資訊。使用少量的HTTP頭資訊，你可以增強自己的下載過程，使它完全遵循HTTP協議規範。這個規範與ranges一起提供恢複被中斷的下載所需要的一切資訊。

　　下面是它的工作方式。首先，如果伺服器支援用戶端斷點續傳，它就在初始的響應中發送Accept-Ranges頭資訊。伺服器還發送一個實體標籤（entity tag）頭資訊（ETag），它包含一個唯一的標識字串。

　　下面的代碼顯示了IIS發送給用戶端的用於響應一個初始下載請求的一些頭資訊，它向用戶端傳遞了被請求的檔案的詳細資料。

HTTP/1.1 200 OK
Connection: close
Date: Tue, 19 Oct 2004 15:11:23 GMT
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "47febb2cfd76c41:2062"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2844011
　　在接收這些頭資訊之後，如果下載被中斷了，IE瀏覽器在後來的下載請求中會把Etag值和Range頭資訊發送回伺服器。下面的代碼顯示了嘗試恢複被中斷下載時IE發送給伺服器的一些頭資訊。

GET http://192.168.100.100/download.zip HTTP/1.0
Range: bytes=822603-
Unless-Modified-Since: Sun, 26 Sep 2004 15:52:45 GMT
If-Range: "47febb2cfd76c41:2062"
　　這些頭資訊表明IE緩衝了IIS提供的實體標籤，並在If-Range頭資訊中把它發送回伺服器了，這是確保下載從準確相同的檔案恢複的一種途徑。不幸的是，並非所有的瀏覽器的工作方式都相同。用戶端發送的用於驗證檔案的其它HTTP頭資訊可能是If-Match、If-Unmodified-Since或者Unless-Modified-Since。很明顯，該規範對於用戶端軟體必須支援哪些頭資訊，或者必須使用哪些頭資訊沒有明確的規定。因此，有些用戶端根本就沒有使用頭資訊，而IE只使用If-Range和Unless-Modified-Since。你最好用代碼檢查這些資訊。採用這種方式的時候，你的應用程式可以在非常高的層次遵循HTTP規範，並可以使用多種瀏覽器。Range頭資訊指明了被請求的位元組範圍--在例子中它是伺服器應該恢複檔案流的起始點。

　　當IIS接收到恢複下載的請求類型時，它發回包含下面的頭資訊的響應資訊：

HTTP/1.1 206 Partial Content
Content-Range: bytes 822603-2844010/2844011
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "47febb2cfd76c41:2062"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2021408
　　請注意上面的代碼與最初的下載請求的HTTP響應有點差別--恢複下載的請求是206而最初下載的請求是200。這表明通過線路傳遞進來的內容是部分檔案。這一次Content-Range頭資訊指出了被傳遞位元組的精確數量和位置。

　　IE對於這些頭資訊是很挑剔的。如果最初的響應沒有包含Etag頭資訊，IE永遠不會嘗試恢複下載。我測試過的其它用戶端不使用ETag頭資訊，它們簡單得依賴於檔案名稱、請求範圍，並使用Last-Modified頭資訊（如果它們試圖驗證該檔案）。

　　深入瞭解HTTP協議

　　前面的部分中顯示的頭資訊對於使恢複下載的解決方案運行來說是足夠的，但是它沒有完全覆蓋HTTP規範。

　　在單個請求中，Range頭資訊可以詢問多個範圍，這種特性稱為"多部分範圍（multipart ranges）"。請不要與分段下載（segmented downloading）混淆，幾乎所有的下載工具都使用分段下載來提高下載速度。這些工具聲稱通過開啟兩個或多個並發的串連（每個串連請求檔案的不同範圍）提高了下載速度。

　　多部分範圍的想法並沒有開啟多個串連，但是它可以使用戶端軟體可以在單個請求/響應周期中請求某個檔案的最前面的十個和最後面的十個位元組。

　　誠實地說，我從來都沒有找到使用這種特性軟體片斷。但是我拒絕在代碼聲明中寫入"它並不是完全的HTTP相容的"。略去這個特性必定會觸犯墨菲法則（Murphy's Law）。無論如何，多部分範圍還是被用於電子郵件傳輸中，把頭資訊、普通文本和附件分開。



範例程式碼

　　我們知道了用戶端和伺服器如何交換頭資訊以保證可恢複的下載，把這些知識與檔案塊流的思想結合起來，你就可以給自己的ASP.NET應用程式增加可靠的下載管理能力了。

　　擷取下載過程的控制權的方法是從用戶端截取下載請求、讀取頭資訊並適當地響應。在.NET之前，你必須編寫ISAPI（Internet伺服器API）應用程式來實現這種功能，但是.NET架構組件提供了一個IHttpHandler介面，在類中實現的時候，它允許你僅僅使用.NET代碼就能夠截取和處理請求。這意味著你的應用程式對於下載過程有完全控制權和響應性，再也不會涉及或使用IIS的自動化函數。

　　範例程式碼在HttpHandler.vb檔案中包含了一個自訂的HttpHandler類（ZIPHandler）。ZipHandler實現了IhttpHandler介面，並且處理對所有.zip檔案的請求。

　　為了測試範例程式碼，你需要在IIS中建立一個新的虛擬目錄，並把源檔案複製到那兒。在該目錄中建立一個叫做download.zip的檔案（請注意IIS和ASP.NET不能處理大於2GB的下載，因此要確保你的檔案沒有超過該限制）。配置你的IIS虛擬目錄，通過aspnet_isapi.dll映射.zip副檔名。

　　HttpHandler類：ZIPHandler

　　在ASP.NET中映射了.zip副檔名之後，用戶端每次向伺服器請求.zip檔案的時候，IIS調用ZipHandler類的ProcessRequest方法（見下載代碼）。

　　ProcessRequest方法首先建立自訂的FileInformation類（見下載代碼）的一個執行個體，它封裝了下載的狀態（例如進行中、被中斷了等等）。樣本把download.zip樣本檔案的路徑寫入程式碼到代碼中了。如果把這段代碼應用於你自己的應用程式，需要修改它來開啟被請求的檔案。

' 使用objRequest檢測請求了哪個檔案，用該檔案開啟objFile。
' 例如objFile = New Download.FileInformation(<完整檔案名稱>)
objFile = New Download.FileInformation( _
objContext.Server.MapPath("~/download.zip"))
　　接下來，程式使用描述的HTTP頭資訊（如果請求提供了頭資訊）執行一系列的驗證檢查。它把每種檢查都封裝在小型私人函數中，如果驗證成功的話就返回True。如果某個驗證檢查失敗了，響應會立即終止，並發送適當的StatusCode值。

If Not objRequest.HttpMethod.Equals(HTTP_METHOD_GET) Or Not
objRequest.HttpMethod.Equals(HTTP_METHOD_HEAD) Then
　' 目前只支援GET和HEAD方法
　objResponse.StatusCode = 501 ' 沒有執行
ElseIf Not objFile.Exists Then
　' 無法找到被請求的檔案
　objResponse.StatusCode = 404 ' 沒有找到
ElseIf objFile.Length > Int32.MaxValue Then
　' 檔案太大了
　objResponse.StatusCode = 413 ' 請求實體太大
ElseIf Not ParseRequestHeaderRange(objRequest, alRequestedRangesBegin, alRequestedRangesend, _
objFile.Length, bIsRangeRequest) Then
　' Range請求中包含無用的實體
　objResponse.StatusCode = 400 ' 無用的請求
ElseIf Not CheckIfModifiedSince(objRequest,objFile) Then
　' 實體沒有被修改過
　objResponse.StatusCode = 304 ' 沒有被修改過
ElseIf Not CheckIfUnmodifiedSince(objRequest,objFile) Then
　' 實體在上次被請求的日期之後被修改過
　objResponse.StatusCode = 412 ' 預先處理失敗
ElseIf Not CheckIfMatch(objRequest, objFile) Then
　' 實體與請求不匹配
　objResponse.StatusCode = 412 ' 預先處理失敗
ElseIf Not CheckIfNoneMatch(objRequest, objResponse,objFile) Then
　' 實體的確與none-match請求匹配。
　' 響應代碼位於CheckIfNoneMatch函數中
Else
　' 初步檢查成功
　　這些初步檢查的函數中的ParseRequestHeaderRange（見下載代碼）檢查用戶端是否請求了檔案範圍（這意味著是一個局部下載）。如果被請求的範圍是無效的（無效範圍指超越檔案大小或包含不合理數位範圍數值），該方法把bIsRangeRequest設定為True。如果請求了範圍，CheckIfRange方法會驗證IfRange頭資訊。

　　如果被請求的範圍是有效，代碼會計算響應資訊的大小。如果用戶端請求了多個範圍，響應資訊大小的數值會包含多部分頭部資訊長度的數值。

　　如果不能確定某個發送的頭部資訊值，程式將把這個下載請求作為最初請求而不是部分下載來處理，從檔案的頂部開始發送一個新的下載流。

If bIsRangeRequest AndAlso CheckIfRange(objRequest, objFile) Then
　' 這是範圍請求
　' 如果Range數組包含多個實體，它還是一個多部分範圍請求
　bMultipart = CBool(alRequestedRangesBegin.GetUpperBound(0)>0)
　' 進入每個範圍來擷取整個響應長度
　For iLoop = alRequestedRangesBegin.GetLowerBound(0) To alRequestedRangesBegin.GetUpperBound(0)
　　' 內容的長度(這個範圍的)
　　iResponseContentLength += Convert.ToInt32(alRequestedRangesend( _
iLoop) - alRequestedRangesBegin(iLoop)) + 1
　　If bMultipart Then
　　　' 如果是多部分範圍請求，計算出將發送的中間頭資訊的長度
　　　iResponseContentLength += MULTIPART_BOUNDARY.Length
　　　iResponseContentLength += objFile.ContentType.Length
　　　iResponseContentLength += alRequestedRangesBegin(iLoop).ToString.Length
　　　iResponseContentLength += alRequestedRangesend(iLoop).ToString.Length
　　　iResponseContentLength += objFile.Length.ToString.Length
　　　' 49是多部分下載中換行和其它必要的字元的長度
　　　iResponseContentLength += 49
　　End If
　Next iLoop

　If bMultipart Then
　　' 如果是多部分範圍請求，
　　' 我們還必須計算出將發送的最後一個中間頭資訊的長度
　　iResponseContentLength +=MULTIPART_BOUNDARY.Length
　　' 8 是破折號和分行符號的長度
　　iResponseContentLength += 8
　Else
　　' 不是多部分下載，因此我們必須說明初始HTTP頭資訊的響應範圍
　　objResponse.AppendHeader( HTTP_HEADER_CONTENT_RANGE, "bytes " & _
　　alRequestedRangesBegin(0).ToString & "-" & _
　　alRequestedRangesend(0).ToString & "/" & _
　　objFile.Length.ToString)
　　'End If
　　' 範圍響應
　　objResponse.StatusCode = 206 ' 局部響應
　Else
　　' 這不是範圍請求，或者被請求的範圍實體ID與當前的實體ID不匹配，
　　' 因此開始新的下載
　　' 指明檔案完成部分的大小等於內容的長度
　　iResponseContentLength =Convert.ToInt32(objFile.Length)
　　' 返回正常的OK狀態
　　objResponse.StatusCode = 200
　End If
　' 接下來伺服器必鬚髮送幾個重要的回應標頭資訊，例如內容長度、Etag、和檔案的內容類型：
　' 把內容長度寫入響應
　objResponse.AppendHeader( HTTP_HEADER_CONTENT_LENGTH,iResponseContentLength.ToString)
　' 把最後修改日期寫入響應
　objResponse.AppendHeader( HTTP_HEADER_LAST_MODIFIED,objFile.LastWriteTimeUTC.ToString("r"))
　' 告訴用戶端軟體我們接受了範圍請求
　objResponse.AppendHeader( HTTP_HEADER_ACCEPT_RANGES,HTTP_HEADER_ACCEPT_RANGES_BYTES)
　' 把檔案的實體標籤寫入響應（用引號括起來）
　objResponse.AppendHeader(HTTP_HEADER_ENTITY_TAG, """" & objFile.EntityTag & """")
　' 把內容類型寫入響應
　If bMultipart Then
　　' 多部分訊息有這種特殊的類型
　　' 在例子中檔案實際的mime類型在以後才寫入響應
　　objResponse.ContentType = MULTIPART_CONTENTTYPE
　Else
　　' 單個部分訊息擁有的檔案內容類型
　　objResponse.ContentType = objFile.ContentType
End If

　　下載所需要的一切都準備好了，可以開始下載檔案了。你將使用FileStream對象從檔案中讀取位元組塊。把FileInformation執行個體objFile的State屬性設定為fsDownloadInProgress。只要用戶端保持串連，伺服器就從檔案中讀取位元組塊並發送給用戶端。對於多部分下載，這段代碼會發送特定的頭資訊。如果用戶端中斷串連，伺服器就把檔案狀態設定為fsDownloadBroken。如果伺服器完成了被請求範圍的發送過程，它會把狀態設定為fsDownloadFinished（見下載代碼）。


FileInformation輔助類

　　在ZIPHandler部分中你會發現，FileInformation是一個輔助類，它封裝了下載狀態資訊（例如下載中、中斷等等）。

　　為了建立FileInformation的執行個體，你需要把被請求檔案的路徑傳遞給該類的建構函式：

Public Sub New(ByVal sPath As String)
　m_objFile = New System.IO.FileInfo(sPath)
End Sub
　　FileInformation使用System.IO.FileInfo對象來擷取檔案的資訊，這些資訊是作為該對象的屬性暴露的（例如檔案是否存在、檔案全名、大小等等）。這個類還暴露了一個DownloadState枚舉，它描述了下載請求的多種狀態：

<Flags()> Enum DownloadState
　' Clear：沒有下載過程，檔案可能在維護
　fsClear = 1
　' Locked：動態建立的檔案不能被更改
　fsLocked = 2
　' In Progress：檔案被鎖定了，下載過程進行中
　fsDownloadInProgress = 6
　' Broken：檔案被鎖定了，下載過程進行中，但是被取消了
　fsDownloadBroken = 10
　' Finished：檔案被鎖定了，下載過程完成了
　fsDownloadFinished = 18
End Enum
　　FileInformation還提供了EntityTag屬性值。範例程式碼中的這個值是硬式編碼，這是由於範例程式碼只使用了一個下載檔案，並且該檔案不會被改變，但是對於實際應用程式來說，你會提供多個檔案，甚至於動態地建立檔案，你的代碼必須為每個檔案提供一個唯一的EntityTag值。此外，每次改變或修改該檔案的時候，這個值也必須改變。這使用戶端軟體能夠驗證它們已經下載的位元組塊是否仍然是最新的。下面是範例程式碼中返回寫入程式碼EntityTag值的部分：

Public ReadOnly Property EntityTag() As String
　' EntityTag用於對用戶端的初始（200）響應，以及來自用戶端的恢複請求
　Get
　　' 為檔案建立唯一的字串。
　　' 注意，只要檔案沒有發生改變，該唯一碼就必須保留。
　　' 但是，如果檔案的確改變了或者被修改了，這個碼必須改變。
　　Return "MyExampleFileID"
　End Get
End Property
　　一個簡單的和大致足夠安全的EntityTag可能由檔案名稱和檔案最後被修改的日期組成。無論使用什麼方法，你都必須確保這個值是真的是唯一的，不會與其它檔案的EntityTag混淆。我希望在自己的應用程式中按照客戶、顧客和郵編索引來動態地替被建立的檔案命名，並把用作EntityTag的GUID儲存在資料庫中。

　　ZipFileHandler類讀取和設定公用的State屬性。在完成下載以後，它把State設定為fsDownloadFinished。這個時候你就可以刪除臨時檔案了。這兒一般需要調用Save方法來維持狀態。

Public Property State() As DownloadState
　Get
　　Return m_nState
　End Get
　Set(ByVal nState As DownloadState)
　　m_nState = nState
　　' 可選操作：這個時候你可以自動地刪除檔案。
　　' 如果狀態被設定為Finished ，你就再也不需要這個檔案了。
　　' If nState =DownloadState.fsDownloadFinished Then
　　　' Clear()
　　' Else
　　　' Save()
　　' End If
　　Save()
　End Set
End Property
　　在檔案狀態發生改變的任何時候ZipFileHandler都應該調用Save方法，儲存檔案的狀態，這樣在以後才能顯示給使用者。你還可以用它來儲存你自己建立的EntityTag。請不要把檔案的狀態和EntityTag值儲存在Application、Session或Cache中--你必須跨越所有的這些這些對象的生命週期來儲存資訊。

Private Sub Save()
　' 把該檔案下載的狀態儲存到資料庫或XML檔案中。
　' 當然，如果你並沒有動態地建立檔案，就不需要儲存這個狀態。
End Sub
　　前面提到，範例程式碼只處理一個已有的檔案（download.zip），但是你可以進一步增強這個程式，根據需要建立被請求的檔案。

　　測試範例程式碼的時候，你的本地系統或LAN可能太快了，以至於無法中斷下載過程，因此我推薦你使用慢速LAN串連（在IIS中減少網站的頻寬是一種類比的方法）或者把伺服器放到互連網上。

　　在用戶端上下載檔案仍然很艱難。ISP操作的不對的或配置錯誤的Web緩衝伺服器都可能使大檔案下載過程失敗，包括下載狀況惡化或早期對話終結。如果檔案大小超過了255MB，你就應該鼓勵顧客使用第三方下載管理軟體，儘管某些最新的瀏覽器內建了基本的下載管理員。
如果你希望進一步擴充範例程式碼，查閱一下HTTP規範是有益的。你可以為下載建立MD5校正值，使用Content-MD5頭資訊添加它們，提供一種驗證下載檔案完整性的途徑。範例程式碼除了GET和HEAD之外沒有涉及到其它的HTTP方法。