asp.net裡提供了多種方式，從伺服器端向客戶端寫檔案流，實現客戶端下載檔案。這種技術在做防下載系統時比較有用處。
主些技術主要有：WriteFile、TransmitFile和BinaryWrite
其中WriteFilet和BinaryWrite出現得比較早，對檔案流的輸出可以啟動作用，但由於都是將整個檔案讀到記憶體後再往客戶端寫，因此會佔用大量的記憶體資源，特別是要下載的檔案比較大時，影響asp.net應用的穩定執行。
TransmitFile是為了彌補WriteFile和BinaryWrite的不足才出現的方法，比WriteFile和BinaryWrite更加的穩定強大，對大檔案的支援也不錯。但其也有不足之處，對斷點續傳的支援不行

那麼一個對效能影響小、支援大檔案下載、支援斷點續傳甚至是多執行緒下載程式還是需要自己來寫的。其實BinaryWrite和WriteFile之所以會影響效能，是因為將整個檔案讀到記憶體後再往客戶端寫，那麼我們可以控制他的輸出方式，一次只讀一塊內容到記憶體，再往客戶端寫，這些就可以自定義下載的和個細節了。下面提供一個相對不錯的下載函式供大家參考。

        

///  3        /// 下載檔案，支援大檔案、續傳、速度限制。支援續傳的響應頭Accept-Ranges、ETag，請求頭Range 。
  4        

/// Accept-Ranges：響應頭，向客戶端指明，此程序支援可恢復下載.實現後臺智慧傳輸服務（BITS），值為：bytes；
  5        /// ETag：響應頭，用於對客戶端的初始（200）響應，以及來自客戶端的恢復請求，
  6        /// 必須為每個檔案提供一個唯一的ETag值（可由檔名和檔案最後被修改的日期組成），這使客戶端軟體能夠驗證它們已經下載的位元組塊是否仍然是最新的。
  7        /// Range：續傳的起始位置，即已經下載到客戶端的位元組數，值如：bytes=1474560- 。
  8        /// 另外：UrlEncode編碼後會把檔名中的空格轉換中+（+轉換為+），但是瀏覽器是不能理解加號為空格的，所以在瀏覽器下載得到的檔案，空格就變成了加號；

  9        /// 解決辦法：UrlEncode 之後, 將 "+" 替換成 " "，因為瀏覽器將 轉換為空格
 10        /// 11        ///當前請求的HttpContext 12        ///下載檔案的物理路徑，含路徑、檔名 13        ///下載速度：每秒允許下載的位元組數 14        ///true下載成功，false下載失敗

        

{
 17            httpContext.Response.Clear();
 18            bool ret =true;
 19            try 20            {
 21                --驗證：HttpMethod，請求的檔案是否存在#region 37
 38                定義區域性變數#region 定義區域性變數 51
 52                --驗證：檔案是否太大，是否是續傳，且在上次被請求的日期之後是否被修改過 69
 70                try 71                {
 72                    -------新增重要響應頭、解析請求頭、相關驗證109
110                    -------向客戶端傳送資料塊-------------------120                }121                catch122                {
123                    ret =false;
124                }125                finally126                {
127                    br.Close();
128                    myFile.Close();
129                }130            }131            catch132            {
133                ret =false;
134            }135            return ret;
136        }