文/陶剛
在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頭信息（如果請求提供了頭信息）執幸幌盜械難橹ぜ觳椤Ｋ衙恐旨觳槎擠庾霸谛⌒退接瀉校绻橹こ曬Φ幕熬頭禱豑rue。如果某個驗證檢查失敗了，響應會立即終止，並發送適當的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枚舉，它描述了下載請求的多種狀態：
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方法。
