aspnet訪問慢

① 請問一個asp,net的問題

我想通過例子你很快就會明白了:

<?xml version="1.0"?>
<!--
注意: 除了手動編輯此文件以外，您還可以使用
Web 管理工具來配置應用程序的設置。可以使用 Visual Studio 中的
「網站」->「Asp.Net 配置」選項。
設置和注釋的完整列表在
machine.config.comments 中，該文件通常位於
\Windows\Microsoft.Net\Framework\v2.x\Config 中
-->
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<connectionStrings>
<add name="NorthwindConnectionString" connectionString="Data Source=8G4K5AU68FMJYV2\sqlEXPRESS;Initial Catalog=Northwind;Persist Security Info=True;User ID=sa;Password=123456"
providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
<anonymousIdentification enabled="true"/>

</system.web>
</configuration>

這個配置文件的內容很少,但是包括非常重要的一節:configuration ->connectionStrings>.請注意,Web.Config文件是以XML 格式存儲的,因此里邊的信息採用"樹型結構",就那上面來看,<connectionStrings />存儲於<configuration />結,因此<connectionStrings />就是<configuration />所要表述的成員之一,也就是說每一個結點都存儲應用程序的一些信息,而它們都是用過XML 屬性結構歸類的.我們要實現ASP.NET的應用程序的靈活性,很大程度上依賴了這些配置文件.舉一個簡單的例子:當我們在.ASPX文件中連接數據源時,需要先定義連接字元串,但是一套完整的應用程序包括很多數據源,也包括很多連接數據源的代碼,因此你必須考慮把這些連接字元串統一的管理,統一的調用,就像定義了一個"全局變數",隨時隨地,任何時間任何地點(程序集)都可以調用出來,當我們需要更改連接字元的時候,也只需要在"全局變數"中修改即可.呵呵,有沒有發現這個ASP.NET中最令人興奮的技術呢?那麼你就試試吧,下面是間單的例子:

class OleDb
{
public static void ConnectionDleDb()
{

using (OleDbConnection conn = new OleDbConnection(GetConnSring()))
{
OleDbCommand command = conn.CreateCommand();
command.CommandText = GetCommandString();
try
{
conn.Open();
OleDbDataReader reader = command.ExecuteReader();
while (reader.Read())
{
Console.Write("/t{0}/t{1}",reader[0],reader[1]);
Console.WriteLine("/n");
}
}
catch (Exception e)
{
Console.WriteLine(e.Message);
throw;
}
}
}
private static string GetConnSring()
{
ConnectionStringSettings settings =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
return (settings.ConnectionString);
}
private static string GetCommandString()
{
return (@"SELECT CategoryID, CategoryName FROM dbo.Categories;");
}
}

在這里,我們正好用到了Web.Config配置文件中的NorthwindConnectionString項,它存儲了我們定義的一個連接字元串,在類OleDb中,方法GetConnSring使用ConfigurationManager類將Web.Config配置文件中的值取出,ConfigurationManager類則是.NET公開所的,提供給程序員的Web.Config文件操作類,在.NET類庫中包含了很多實現類似功能的類,比如"成員資格提供程序","角色提供程序",它們與Web.Config配置文件配合組成了非常高效的應用程序管理機制.

以下是MSDN的相關文章:

---------------------------------------------------
使用 ASP.NET 配置系統的功能，可以配置整個伺服器上的所有 ASP.NET 應用程序、單個 ASP.NET 應用程序、各個頁面或應用程序子目錄。可以配置各種功能，如身份驗證模式、頁緩存、編譯器選項、自定義錯誤、調試和跟蹤選項等等。

以下各節描述了 ASP.NET 配置系統的功能。

有關配置 .NET Framework 客戶端應用程序的信息，請參見配置應用程序。

注意
ASP.NET 配置系統的功能僅適用於 ASP.NET 資源。例如，Forms 身份驗證僅限制對 ASP.NET 文件的訪問，而不限制對靜態文件或 ASP（傳統型）文件的訪問，除非這些資源映射到 ASP.NET 文件擴展名。要配置非 ASP.NET 資源，應使用 Internet 信息服務 (IIS) 的配置功能。有關信息，請參見 Working with the IIS Metabase（使用 IIS 元資料庫）和 IIS Metabase Property Reference（IIS 元資料庫屬性參考）。

配置文件
ASP.NET 配置數據存儲在全部命名為 Web.config 的 XML 文本文件中，Web.config 文件可以出現在 ASP.NET 應用程序的多個目錄中。使用這些文件，可以在將應用程序部署到伺服器上之前、期間或之後方便地編輯配置數據。可以通過使用標準的文本編輯器、ASP.NET MMC 管理單元、網站管理工具或 ASP.NET 配置 API 來創建和編輯 ASP.NET 配置文件。

ASP.NET 配置文件將應用程序配置設置與應用程序代碼分開。通過將配置數據與代碼分開，可以方便地將設置與應用程序關聯，在部署應用程序之後根據需要更改設置，以及擴展配置架構。

有關如何對 ASP.NET 配置文件中的數據進行組織的更多信息，請參見 ASP.NET 配置文件。ASP.NET 配置設置 中描述了可用的配置設置。

配置文件層次結構和繼承
每個 Web.config 文件都將配置設置應用於它所在的目錄以及它下面的所有子目錄。可以選擇用子目錄中的設置重寫或修改父目錄中指定的設置。通過在 location 元素中指定一個路徑，可以選擇將 Web.config 文件中的配置設置應用於個別文件或子目錄。

ASP.NET 配置層次結構的根為 systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\Web.config 文件，該文件包括應用於所有運行某一具體版本的 .NET Framework 的 ASP.NET 應用程序的設置。由於每個 ASP.NET 應用程序都從根 Web.config 文件那裡繼承默認配置設置，因此只需為重寫默認設置的設置創建 Web.config 文件。

注意
根 Web.config 文件從 Machine.config 文件那裡繼承一些基本配置設置，這兩個文件位於同一個目錄中。其中的某些設置不能在 Web.config 文件中被重寫。有關更多信息，請參見 ASP.NET 配置文件層次結構和繼承。

運行時，ASP.NET 使用 Web.config 文件按層次結構為傳入的每個 URL 請求計算唯一的配置設置集合。這些設置只計算一次，隨後將緩存在伺服器上。ASP.NET 檢測對配置文件進行的任何更改，然後自動將這些更改應用於受影響的應用程序，而且大多數情況下會重新啟動應用程序。只要更改層次結構中的配置文件，就會自動計算並再次緩存分層配置設置。除非 processModel 節已更改，否則 IIS 伺服器不必重新啟動，所做的更改即會生效。

有關 ASP.NET 配置層次結構的工作原理的更多信息，請參見 ASP.NET 配置文件層次結構和繼承和 ASP.NET 配置方案。

直接編輯配置文件
可以使用文本編輯器或 XML 編輯器來直接編輯配置文件。有關正確的語法，請參見 ASP.NET 配置設置和 常規配置設置 (ASP.NET) 中有關配置節的參考主題。有關更多信息，請參見編輯 ASP.NET 配置文件。

配置工具
使用 ASP.NET 配置系統所提供的工具來配置應用程序比使用文本編輯器簡單，因為這些工具包括錯誤檢測功能。

ASP.NET MMC 管理單元
用於 ASP.NET 的 Microsoft 管理控制台 (MMC) 管理單元提供一種在本地或遠程 Web 伺服器上的所有級別操作 ASP.NET 配置設置的方便途徑。ASP.NET MMC 管理單元使用 ASP.NET 配置 API，但是它通過提供一個圖形用戶界面 (GUI) 來簡化配置設置的編輯過程。另外，該工具還支持多個 ASP.NET 配置 API 功能，這些功能控制 Web 應用程序是否可以繼承設置，並管理配置層次結構各級別之間的依賴性。

注意
若要使用 ASP.NET MMC 管理單元，必須使用具有管理許可權的帳戶登錄到計算機。

ASP.NET MMC 管理單元在虛擬目錄的屬性頁上顯示為「ASP.NET」選項卡。

有關更多信息，請參見 ASP.NET MMC 管理單元。

網站管理工具
對網站具有管理許可權的任何人都可以使用網站管理工具來管理該網站的配置設置。網站管理工具旨在為各個網站中最常用的配置設置提供一個用戶友好的圖形編輯工具。由於網站管理工具使用基於瀏覽器的界面，因此它允許您遠程更改網站設置，這對於管理已經部署到成品 Web 伺服器的站點（如承載的網站）非常有用。

網站管理工具與 ASP.NET MMC 管理單元在若干方面存在不同。例如，ASP.NET MMC 管理單元最適於管理員級別的配置，因為它提供對 Web 伺服器上的整個配置文件層次結構的訪問，而不是提供對單個網站的配置設置的訪問。此外，您還必須是管理員才能使用 ASP.NET MMC 管理單元，而網站管理工具只允許各個網站所有者在他們具有管理許可權的站點的根目錄中配置 Web.config 文件。最後，您不能使用 ASP.NET MMC 管理單元來遠程管理 IIS，但是，網站管理工具的瀏覽器界面允許遠程配置 IIS 6.0 和更高版本的 IIS。

網站管理工具包括一個選項卡式界面，該界面在下列選項卡上對相關的配置設置進行分組：

「安全」選項卡，其中包含有助於保護 Web 應用程序資源並管理用戶帳戶和角色的設置。

「配置文件」選項卡，其中包含用來管理網站如何收集訪問者信息的設置。

「應用程序」選項卡，其中包含用來管理影響 ASP.NET 應用程序的配置元素的設置。

「提供程序」選項卡，其中包含用來添加、編輯、刪除、測試或分配應用程序提供程序的設置。

網站管理工具是隨 .NET Framework 2.0 版自動安裝的。有關該工具如何工作的信息，請參見 ASP.NET 網站管理工具。

命令行工具
.NET Framework 包括幾個執行特定配置操作的命令行工具。例如，使用 Aspnet_regiis.exe 工具，可以指定將哪個版本的 .NET Framework 應用於 ASP.NET 應用程序。有關更多信息，請參見 .NET Framework 工具。

ASP.NET 配置 API
ASP.NET 配置系統提供一個完整的託管介面，使用該介面，可以通過編程方式配置 ASP.NET 應用程序，而不必直接編輯 XML 配置文件。另外，ASP.NET 配置 API 還執行下列任務：

通過為配置層次結構中所有級別的數據提供一個集成視圖來簡化管理任務。

支持部署任務，包括創建配置和用一個腳本配置多台計算機。

為構建 ASP.NET 應用程序、控制台應用程序和腳本、基於 Web 的管理工具和 MMC 管理單元的開發人員提供單一的編程介面。

防止開發人員和管理員進行無效的配置設置。

允許您擴展配置架構。您可以定義新配置參數並編寫配置節處理程序以對它們進行處理。

提供從當前正在運行的應用程序獲取配置信息的靜態方法，以及從單獨的應用程序獲取配置信息的非靜態方法。使用靜態方法可以提高應用程序的運行速度，但是這些方法只能從您要獲取其配置數據的應用程序內部使用。

有關更多信息，請參見 ASP.NET 配置 API。

配置安全性
ASP.NET 配置系統有助於防止未經授權的用戶訪問配置文件。ASP.NET 將 IIS 配置為拒絕任何瀏覽器訪問 Machine.config 或 Web.config 文件。對於試圖直接請求配置文件的任何瀏覽器，都返回 HTTP 訪問錯誤 403（禁止）。

另外，將禁止一個 ASP.NET 應用程序中的配置文件訪問其他 ASP.NET 應用程序中的配置設置，除非您的配置應用程序在完全信任模式下以對其他應用程序中的配置文件具有讀取許可權的帳戶運行。

有關更多信息，請參見保證 ASP.NET 配置的安全和使用受保護的配置加密配置信息。

② c#如何使用緩存提高程序效率

緩存的技術應用應該是非廣泛的。而它的作用也是為了提高系統或者網站的執行效率。下面是四種常見的緩存技術：
一.OutputCaching
由於IIS的一些特性，默認情況下OutputCache是打開的，但是要對某些請求進行緩存，還需要開發者進行定製，而且默認情況下，Output Cache 會被緩存到硬碟上，我們可以通過修改DiskCacheable的屬性來設置其是否緩存，還可以通過Web config里配置緩存文件的大小。

<%@ OutputCacheDuration="3600" VaryByParam="state" DiskCacheable="true" %>
一般用硬碟緩存是考慮到頁面送顯的數據比較大，相對內存緩存來說，它的容量大，但是訪問速度慢點，如果把周期設太短，使用硬碟緩存的效率就不大好。對於Output Cache的定製，有兩種方法，一種是基於底層的API技術，一種是基於高層的@OutputCaching：

1.基於高層的@OutputCaching

A.由參數改變緩存內容：有些時候我們需要根據用戶的請求來生成頁面，但是用戶的請求只有有限的幾種組合，這個時候就可以根據用戶請求來生成幾種緩存頁面，來進行緩存。

<%@ OutputCache Duration ="60" VaryByParam = "state" %>
<asp:SqlDataSourceID="SqlDataSource1" runat="server">
<SelectParameters>
<asp:QueryStringParameter Name="state"QueryStringField="state" DefaultValue="CA" />
</SelectParameters>
</asp:SqlDataSource>
B.回調緩存：可以針對每個請求在頁面中插入動態的部分，以彌補單獨使用靜態緩存的不足：
動態的部分用Substitution控制項，Substitution控制項是一個容器

<asp:SubstitutionID="Substitution1" runat="server" MethodName =""/>
MethodName 裡面放入要調用的方法內容。
2. 使用API定製緩存：
通過設置System.Web.HttpCachePolicy屬性來進行配置

<%@ OutputCache Duration="60"VaryByParam="none" %>
就可以寫成

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);

二.FragmentCaching
作為Output的緩存的附加功能，還提供一種緩存技術，專門用於緩存用戶控制項。在用戶控制項中設置：

<%@ OutputCache Duration="60"VaryByParam="none" %>

但在引用用戶控制項的頁面不設置緩存。這樣的話，頁面中除了用戶控制項是靜態的，其他都是動態的。
緩存用戶空間同樣還可以使用控制項作為參數來源。通過指定控制項作為緩存控制項的數據來源，可以達到緩存控制項數據的目的，和上面一樣。

三.DataCaching
Asp.net提供了一種非常快捷的方法進行資料庫緩存，用戶可以非常簡單方便的對頁面變數進行緩存。並以此提高程序效率。一個頁面變數的緩存生命周期與應用程序的緩存生命周期相同
實現是把數據放在Cache中，如：

source = new DataView(ds);
Cache("MyCache") = source;

MyCache這個變數其實就是一個XML文件。

四.SQL Caching
通過配置資料庫連接池，只有當資料庫數據被改變的時候，緩存才會改變。
開個DOS窗口：
C:\>dir aspnet_regsql.exe/s ——這個文件是專門注冊SQL連接池的，它對SQLSever 7.0以上都有專門的支持，我們通過寫一些專門的語句來配置這個注冊連接池，可以把連接池和本地的應用程序（Asp.net伺服器，即IIS）做一個連接。連接池只能監視有限的幾個庫，不然連接池的負載太大。使用SQL Caching：
先注冊，如： aspnet_regsql.exe-S".\SQLExpress"-E-d"pubs"-ed
aspnet_regsql.exe-S".\SQLExpress"-E-d"pubs"-et-t"authors"
其中：- S".\SQLExpress" 表示要使用的SQL Server實例為".\SQLExpress"。-E 表示使用當前windows憑證進行身份驗證。-d"pubs"表示用於應用程序服務的資料庫名稱叫"pubs"。-ed表示為SQL 緩存依賴項啟用資料庫。-et 表示為SQL 緩存依賴項啟用表。-t"authors"表的名稱為"authors"。
然後頁面上：
<%@ OutputCacheDuration="99999999" VaryByParam="none"SqlDependency="Pubs.Authors" %>
就OK了。

③ 如何在伺服器上部署asp.net網站

對於許多新手來說，如何在伺服器上部署網站並不了解，這個教程希望對新手有幫助。

1、IIS伺服器

2、.Net Framework3.5 (方便起見，我們這里Framework說的都是指的這個版本)

這兩個軟體都需要我們自己手動操作安裝到伺服器裡面。那到底是先裝哪一個呢，為了方便起見，一般我們都先安裝IIS伺服器，然後再安裝Framework。

當然偶也遇到過幾次部署人員先安裝了Framework再安裝IIS伺服器的，這樣的操作步驟就會導致Framework不會被注冊進IIS伺服器裡面。就是說在網站屬性的ASP.NET選項卡上面不會出現下面這樣的版本選擇框

然後一直下一步就可以完成IIS的安裝了。

安裝Framework沒有什麼好說的，雙擊安裝文件一直下一步就可以了。

等兩個軟體都安裝完成後，就可以通過

右擊我的電腦-->管理 打開計算機管理窗口

可以看到裡面有一項應用程序伺服器的選項，不錯，就是剛才安裝的那個東西。

點開它，會看到一個 Internet 信息服務(IIS)管理器，就是要在這個東西裡面操作，其他的不用去管。

打開，會發現有三個子菜單：

1、應用程序池

2、網站

3、Web服務擴展

什麼是應用程序池？太專業了，不去管他，為了保險起見，偶每建立一個網站都要創建一個應用程序池來管理，至於這個池的配置，一切默認啦，微軟都已經幫做好了。

來創建一個應用程序池：

右鍵應用程序池-->

然後展開這個應用程序池的菜單，就可以看到剛才新建的Test的應用程序池了。

接下來左鍵單擊 Web服務擴展 菜單打開.net2.0的擴展

接下來就可以新建一個網站了，右鍵 網站

直接單擊下一步

輸入網站的名字 Test ，下一步

選擇埠，如果需要綁定IP和主機頭，需要在這里綁定，沒有需要，就不做了（打個比方，網站的訪問路徑是http://192.168.1.150:2000，這里的2000就是需要的埠號）

接下來要選定網站的物理路徑，就是這個網站的文件到底放在了電腦的那個地方，C盤？D盤？還是哪，反正就是網站所在的文件夾的路徑

選定文件夾後再點擊下一步

接下來要配合網站的訪問許可權，由於網站需要些文件操作的功能，所以一般都把寫入許可權加上

單擊下一步後，網站就算是創建成功了.

④ 用DRMER WEAVER做的網頁,已做完,也有上傳工具,請問到底如何上傳到INTRNET上,這裡面前奏和具體步驟怎麼做

網站上傳方法匯總，製作好網頁後，如何把網頁上傳到申請的空間呢？為初學者做一個匯總。

上傳的定義

上傳就是將信息從個人計算機（本地計算機）傳遞到中央計算機（遠程計算機）系統上，讓網路上的人都能看到。將製作好的網頁、文字、圖片等發布到互聯網上去，以便讓其他人瀏覽、欣賞。這一過程稱為上傳。

上傳的來源

上傳一詞來自英文（upload），拆開來「up」為「上」，「load」為「載」，故上傳也叫上載，與下載（download）是逆過程。 網頁教學網

上傳的分類 Webjx.Com

上傳分為Web上傳和Ftp上傳，前者直接通過點擊網頁上的鏈接即可操作，後者需要專用的FTP工具。

上傳小知識
網頁教學網

在上傳主頁之前，讓我們先來認識Internet上一個基本的概念———FTP。它是英文「File Transfer Protocol」(文件傳輸協議)的縮寫，不過我們今天已經把它看成了一個動詞，意思是說在計算機和計算機之間傳輸文件。把自己製作好的主頁上傳到伺服器上，就要用到FTP。

有許多種方法可以把主頁文件上傳到Internet伺服器上，下面是常見的五種方法。

1、使用FTP軟體上傳主頁文件

這是最常用、最方便也是功能最為強大的主頁上傳方法。現在網上這類軟體很多，像CuteFtp、WS-Ftp已經廣受網友歡迎。這類軟體除了可以完成文件傳輸的功能以外，還可以通過它們完成站點管理、遠程編輯伺服器文件等工作，一些常用的FTP軟體還有斷點續傳、任務管理、狀態監控等功能，可以讓你的上傳工作變得非常輕松。

2、使用「兼職」的FTP軟體上傳主頁文件

所謂兼職的 FTP軟體，是指軟體本身並不是專門用來完成FTP功能的，主頁上傳只是其編外任務。例如我們常用的FrontPage、Dreamweaver、東方主頁王Ⅱ等都有主頁上傳、發布的功能。使用這類軟體的好處是可以在編輯主頁的同時就上傳到伺服器上查看主頁效果，省去了啟動軟體、登錄、設置等諸多麻煩。但是，這種方法往往上傳速度較慢，且難以對伺服器上的文件進行管理。

3、使用Web頁面上傳主頁文件

和前面兩種方法相比，這種方法不但沒有什麼明顯的優點，而且速度緩慢、操作麻煩、不支持斷點續傳。但是，如果你恰恰申請了一個這樣的不支持FTP的免費主頁空間，那麼就只能使用這種笨拙的方法了！

4、通過命令上傳主頁文件

在很久很久以前，Unix系統上的FTP程序是基於命令行的，現在的Window95／98／NT／2000／Me仍然有基於命令行的FTP程序(進入 DOS模式，輸入FTP就可以了)。使用這種方法首先要掌握幾十條命令不說，而且屏幕上通常只能顯示25或50行文字，很不方便。圖形界面的FTP軟體流行之後，這種方法已經被大多數網友拋棄了，只供少數骨灰級的網蟲練習他們的指法。

5、通過E-mail上傳

這種方法要求你把主頁文件通過E-mail發給系統管理員，然後再由系統管理員把它們放到伺服器上。這是最簡單也是最復雜的方法，隨著網路條件的提高，這種方法已逐漸銷聲匿跡了。

大文件上傳
Webjx.Com

以前也做過文件上傳，但都是些小文件，不超過2M。 這次要求上傳100M以上的東西。沒辦法找來資料研究了一下。基於WEB的文件上傳可以使用FTP和HTTP兩種協議，用FTP的話雖然傳輸穩定，但安全性是個嚴重的問題，而且FTP伺服器讀用戶庫獲取許可權，這樣對於用戶使用來說還是不太方便。剩下只有HTTP。在HTTP中有3種方式，PUT、WEBDAV、RFC1867，前2種方法不適合大文件上傳，目前我們使用的web上傳都是基於 RFC1867標準的HTML中基於表單的文件上傳。

一、先簡要介紹一下RFC1867（Form-based File Upload in HTML）標准：

1．帶有文件提交功能的HTML表單

現有的HTML規范為INPUT元素的TYPE屬性定義了八種可能的值，分別是：CHECKBOX， HIDDEN，MAGE，PASSWORD，RADIO，RESET，SUBMIT，TEXT。另外，當表單採用POST方式的時候，表單默認的具有「application/x-www-form-urlencoded」的ENCTYPE屬性。

RFC1867標准對HTML做出了兩處修改：

（1）為INPUT元素的TYPE屬性增加了一個FILE選項。

（2）INPUT標記可以具有ACCEPT屬性，該屬性能夠指定可被上傳的文件類型或文件格式列表。

另外，本標准還定義了一種新的MIME類型：multipart/form-data，以及當處理一個帶有ENCTYPE="multipart /form-data" 並且/或含有<INPUT type="file">的標記的表單時所應該採取的行為。

舉例來說，當HTML表單作者想讓用戶能夠上傳一個或更多的文件時，他可以這么寫：

<FORM ENCTYPE="multipart/form-data" ACTION="_URL_" METHOD=POST>

File to process:
<INPUT NAME="userfile1" TYPE="file">

<INPUT TYPE="submit" VALUE="Send File">

</FORM>

HTML DTD里所需要做出的改動是為InputType實體增加一個選項。此外，我們也建議用一系列用逗號分隔的文件類型來作為INPUT標記的ACCEPT屬性。

... (其他元素) ...

<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |

RADIO | SUBMIT | RESET |

網頁教學網

IMAGE | HIDDEN | FILE )">

<!ELEMENT INPUT - 0 EMPTY>

<!ATTLIST INPUT

TYPE %InputType TEXT

NAME CDATA #IMPLIED -- required for all but submit and reset

VALUE CDATA #IMPLIED

SRC %URI #IMPLIED -- for image inputs --

CHECKED (CHECKED) #IMPLIED

SIZE CDATA #IMPLIED --like NUMBERS,

but delimited with comma, not space

MAXLENGTH NUMBER #IMPLIED Webjx.Com

ALIGN (top|middle|bottom) #IMPLIED

ACCEPT CDATA #IMPLIED --list of content types

>

... (其他元素) ...

2.文件傳輸延遲

在某些情況下，在確實准備接受數據前，伺服器先對表單數據中的某些元素（比如說用戶名，賬號等）進行驗證是推薦的做法。但是，經過一定的考慮後，我們認為如果伺服器想這樣做的話，最好是採用一系列的表單，並將前面所驗證過的數據元素作為「隱藏」欄位傳回給客戶端，或者是通過安排表單使那些需要驗證的元素先顯示出來。這樣的話，那些需要做復雜的應用的伺服器可以自己維持事務處理的狀態，而那些簡單的應用的則可以實現得簡單些。

HTTP協議可能需要知道整個事務處理中的內容總長度。即使沒有明確要求，HTTP客戶端也應該提供上傳的所有文件的內容總長度，這樣一個繁忙的伺服器就能夠判斷文件的內容是否是過大以至於將不能完整地處理，從而返回一個錯誤代碼並關閉該連接，而不用等到接受了所有的數據才進行判斷。目前一些現有的 CGI應用對所有的POST事務都需要知道內容總長度。

如果INPUT標記含有一個MAXLENGTH屬性，客戶端可以將這個屬性值看作是伺服器端所能夠接受的傳送文件的最大位元組數。在這種情況下，伺服器能夠在上傳開始前，提示客戶端在伺服器上有多少空間可以用來進行文件上傳。但是應該引起注意的是，這僅僅是一個提示，在表單被創建後和文件上傳前，伺服器的實際需求可能會發生改變。

在任何情況下，如果接受的文件過大的話，任何一個HTTP伺服器都有可能在文件傳輸的過程中中斷傳輸。

3.傳輸二進制數據的其他解決辦法

有些人曾經建議使用一種新的MIME類型"aggregate"，比如說aggregate/mixed 或是content-transfer-encoding "包"來描述那些不確定長度的二進制數據，而不是靠分解為多個部分來表示。雖然我們並不反對這么做，但這需要增加額外的設計和標准化工作來讓大家接受並理解"aggregate"。從另一方面來說，"分解為多部分"的機制工作得很好，能夠非常簡單的在客戶發送端和伺服器接受端加以實現，而且能像其他一些綜合處理二進制數據的方式一樣高效率地工作。

4.例子
Webjx.Com

假設伺服器段提供的是如下的HTML：

<FORM ACTION="http://server.dom/cgi/handle"

ENCTYPE="multipart/form-data"

METHOD=POST>

What is your name? <INPUT TYPE=TEXT NAME=submitter>

What files are you sending? <INPUT TYPE=FILE NAME=pics>

</FORM>

用戶在「姓名」欄位裡面填寫"Joe Blow"，對問題'What files are you sending?'，用戶選擇

了一個文本文件"file1.txt"。

客戶段可能發送回如下的數據：

Content-type: multipart/form-data, boundary=AaB03x

--AaB03x

content-disposition: form-data; name="field1" 網頁教學網

Joe Blow

--AaB03x

content-disposition: form-data; name="pics"; filename="file1.txt"

Content-Type: text/plain

... file1.txt 的內容...

--AaB03x--

如果用戶同時還選擇了另一個圖片文件"file2.gif"，那麼客戶端可能發送的數據將是：

Content-type: multipart/form-data, boundary=AaB03x

--AaB03x

content-disposition: form-data; name="field1"

Joe Blow

--AaB03x

content-disposition: form-data; name="pics"

Content-type: multipart/mixed, boundary=BbC04y

--BbC04y

Content-disposition: attachment; filename="file1.txt"

Content-Type: text/plain

... file1.txt 的內容...

--BbC04y

Content-disposition: attachment; filename="file2.gif"

Content-type: image/gif

Content-Transfer-Encoding: binary

... file2.gif的內容...

--BbC04y--

--AaB03x--

二、利用RFC1867標准處理文件上傳的兩種方式：

Webjx.Com

1．一次性得到上傳的數據，然後分析處理。

看了N多代碼之後發現，目前無組件程序和一些COM組件都是使用Request.BinaryRead方法。一次性得到上傳的數據，然後分析處理。這就是為什麼上傳大文件很慢的原因了，IIS超時不說，就算幾百M文件上去了，分析處理也得一陣子。

2．一邊接收文件，一邊寫硬碟。

了解了一下國外的商業組件，比較流行的有Power- Web，AspUpload,ActiveFile,ABCUpload,aspSmartUpload,SA-FileUp。其中比較優秀的是 ASPUPLOAD和SA-FILE，他們號稱可以處理2G的文件(SA-FILE EE版甚至沒有文件大小的限制)，而且效率也是非常棒，難道編程語言的效率差這么多?查了一些資料,覺得他們都是直接操作文件流。這樣就不受文件大小的制約。但老外的東西也不是絕對完美，ASPUPLOAD處理大文件後,內存佔用情況驚人。1G左右都是稀鬆平常。至於SA-FILE雖然是好東西但是破解難尋。然後發現2款.NET上傳組件，Lion.Web.UpLoadMole和AspnetUpload也是操作文件流。但是上傳速度和CPU佔用率都不如老外的商業組件。

做了個測試，LAN內傳1G的文件。ASPUPLOAD上傳速度平均是4.4M/s，CPU佔用10-15，內存佔用700M。SA-FILE也差不多這樣。而AspnetUpload最快也只有1.5M/s，平均是700K/s，CPU佔用15-39，測試環境: PIII800,256M內存,100M LAN。我想AspnetUpload速度慢是可能因為一邊接收文件，一邊寫硬碟。資源佔用低的代價就是降低傳輸速度。但也不得不佩服老外的程序，CPU 佔用如此之低.....。

三、ASP.NET上傳文件遇到的問題

我們在用ASP.NET上傳大文件時都遇到過這樣或那樣的問題。設置很大的maxRequestLength值並不能完全解決問題，因為ASP.NET 會block直到把整個文件載入內存後，再加以處理。實際上，如果文件很大的話，我們經常會見到Internet Explorer顯示 "The page cannot be displayed - Cannot find server or DNS Error"，好像是怎麼也catch不了這個錯誤。為什麼？因為這是個client side錯誤，server side端的Application_Error是處理不到的。

四、ASP.NET大文件上傳解決方案

解決的方法是利用隱含的HttpWorkerRequest，用它的GetPreloadedEntityBody 和 ReadEntityBody方法從IIS為ASP.NET建立的pipe里分塊讀取數據。Chris Hynes為我們提供了這樣的一個方案(用HttpMole)，該方案除了允許你上傳大文件外，還能實時顯示上傳進度。

Lion.Web.UpLoadMole和AspnetUpload 兩個.NET組件都是利用的這個方案。

方案原理：
Webjx.Com

利用HttpHandler實現了類似於ISAPI Extention的功能，處理請求(Request)的信息和發送響應(Response)。

方案要點：

1． httpHandler or HttpMole
a.在asp.net進程處理request請求之前截獲request對象
b.分塊讀取和寫入數據
c.實時跟蹤上傳進度更新meta信息

2． 利用隱含的HttpWorkerRequest用它的GetPreloadedEntityBody 和 ReadEntityBody方法處理文件流
IServiceProvider provider = (IServiceProvider) HttpContext.Current;
HttpWorkerRequest wr = (HttpWorkerRequest) provider.GetService(typeof(HttpWorkerRequest));
byte[] bs = wr.GetPreloadedEntityBody();
....
if (!wr.IsEntireEntityBodyIsPreloaded())
{
int n = 1024;
byte[] bs2 = new byte[n];
while (wr.ReadEntityBody(bs2,n) >0)
{ 網頁教學網
.....
}
}

3． 自定義Multipart MIME 解析器。
自動截獲MIME分割符。
將文件分塊寫如臨時文件。
實時更新Appliaction 狀態（ReceivingData, Error, Complete） 。