使用HttpWebRequest和HttpWebResponse在后臺進(jìn)行文件的提交，可以替代使用前臺form提交的方式，HttpWebRequest用來測試某網(wǎng)頁的速度是500多毫秒，而IE速度很快只有不到100毫秒，如何才能提高HttpWebRequest的響應(yīng)速度？
------解決方案--------------------------------------------------------
看看服務(wù)器是否支持壓縮，如果服務(wù)器支持壓縮可能是因為IE接收的是壓縮數(shù)據(jù)，你的程序時接收未壓縮數(shù)據(jù)，所以比IE慢。
Httpwebrequest 的速度應(yīng)該比IE快才對， 它不用渲染，HttpWebRequest是經(jīng)過層層封裝后得到的東西，IE應(yīng)該是直接調(diào)用系統(tǒng)底層的方法，所以會比較快。
我使用過程中遇到的最大挑戰(zhàn)是以下幾個問題：
a. 如何處理chunked的頁面
b. 如何處理gzip過的頁面
c. 如何自動判斷文本編碼
d. 如何使用CookieContainer
我們一個一個來，先從第一個開始。chunked是常用的web服務(wù)器設(shè)置，也經(jīng)常與gzip一起使用，
a. 如何處理chunked的頁面
(fiddler的Response Header視圖截圖)
chunked的好處最主要的是頁面優(yōu)化，瀏覽器通常會在接收完第一個chunked塊之后開始解析頁面，而不是等到整個頁面加載完成。關(guān)于chunked的傳輸細(xì)節(jié)有興趣的朋友可以繼續(xù)閱讀以下兩篇文章http 《chunked傳輸》
《HTTP chunked+gzip及瀏覽器兼容測試》
由于頁面的chunked，我們必須通過stream方式來獲得數(shù)據(jù)，且由于之后要對獲得的Stream進(jìn)行g(shù)zip解密，所以我們需要把Stream暫時保存到MemoryStream中，如下所示：
MemoryStream memory = null;
int length = 0;
if (res.ContentLength > 0)
{
length = (int)res.ContentLength;
}
else
{
length = 8000;
}
memory = new MemoryStream(length);
Byte[] buf = new byte[4096];
Stream resStream = res.GetResponseStream();
int count = 0;
do
{
count = resStream.Read(buf, 0, buf.Length);
if (count != 0)
{
memory.Write(buf, 0, count);
}
} while (count > 0);
這里利用ContentLength獲取實際大小，但在有些情況下，ContentLength取不到，就會有個默認(rèn)大小8000。當(dāng)然這只是MemoryStream初始，如果Write的時候超過，它會自動增加大�。ㄎ矣浀檬悄J(rèn)大小的兩倍）。
b. 如何處理gzip
gzip的好處想必不用我說了吧，自然是傳輸大小更小，動態(tài)壓縮，目前大部分門戶都會打開這個選項，其平均壓縮效果可以達(dá)到不開之前的40%左右，以下是處理gzip的代碼：
Stream responseStream = null;
//handle gzip or deflate stream
if (res.ContentEncoding.ToLower().Contains("gzip"))
{
responseStream = new GZipStream(memory, CompressionMode.Decompress);
}
else if (res.ContentEncoding.ToLower().Contains("deflate"))
{
responseStream = new DeflateStream(memory, CompressionMode.Decompress);
}
else
{
responseStream = memory;
}
壓縮方式可以通過ContentEncoding屬性獲得，這里同時也處理了deflate的壓縮方式，不過目前我沒遇到過這種網(wǎng)站，這代碼是拷貝過來的，呵呵。
c. 如何自動判斷文本編碼
編碼問題往往是讓人頭疼的問題，因為某些情況你拿到的數(shù)據(jù)會變成亂碼，這就表示編碼沒有處理好。頁面的實際編碼是保存在ContentType中的，如下所示
(fiddler的Response Header視圖截圖)
這里的charset就是我們需要的編碼信息，編碼的自動選擇全靠它了，編碼的真正作用發(fā)生在我們把剛才的responseStream轉(zhuǎn)換為string，代碼如下所示：
int charsetPos = res.ContentType.IndexOf("charset=");
string encoding = "UTF-8";
if (charsetPos >= 0)
{
int semicolonPos = res.ContentType.IndexOf(";", charsetPos);
encoding = res.ContentType.Substring(charsetPos + 8, semicolonPos > 0 ? semicolonPos - charsetPos - 8 : res.ContentType.Length - charsetPos - 8);
}
var oEncoding = Encoding.GetEncoding(encoding);
using (StreamReader sr = new StreamReader(responseStream, oEncoding))
{
content = sr.ReadToEnd();
}
我這邊用了比較原始的方法，沒有用正則表達(dá)式，如果你覺得這個方法很挫，你可以換成正則表達(dá)式�？吹�?jīng)]，StreamReader通過oEncoding得知該用哪種編碼來把byte[]轉(zhuǎn)換為String。
（這里牽扯到幾年前我做過的一道面試題：String和byte[]如何進(jìn)行轉(zhuǎn)換？說說你的經(jīng)驗。這道題雖然很多公司不面，但我倒覺得這道題是可以深入的，因為encoding其實是個很不錯的面試話題，也很考基礎(chǔ)知識。）
d. 如何使用CookieContainer
通常呢，稍微有點防御的網(wǎng)站都會驗cookie，或者放個身份認(rèn)證的cookie，如何在請求中放cookie呢，自然是靠CookieContainer（其實也可以通過AddHttpHeader，但本文只討論CookieContainer，好處等會兒說，先賣個關(guān)子。）CookieContainer的接口有點搞，因為既有Add，也有SetCookie，我一開始就上了老當(dāng)，用了Add，結(jié)果沒有效果。SetCookies才是正確的方法，這個方法即可以一次性設(shè)置完所有的cookie，也可以一個一個設(shè)置，如下：
CookieContainer cookieContainer = new CookieContainer();
cookieContainer.SetCookies(new Uri(hostname), new Cookie("aaa", "98d4c408-7923-443a-ba3f-99df3bea7792", "/", "a.com").ToString());
cookieContainer.SetCookies(new Uri(hostname), new Cookie("bbb", "0", "/", "a.com").ToString());
cookieContainer.SetCookies(new Uri(hostname), new Cookie("ccc", "0", "/", "a.com").ToString());
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
req.Headers.Add(HttpRequestHeader.AcceptEncoding, "gzip,deflate");
req.AllowAutoRedirect = true;
req.Accept = "text/html, application/xhtml+xml, */*";
req.Timeout = 50000;
req.Method = "GET";
req.CookieContainer = cookieContainer;
var response = (HttpWebResponse)req.GetResponse();
這里使用Cookie而非直接用字符串是出于安全考慮，因為Cookie對象的ToString自動幫我們把encoding做掉了，所以這么寫會比直接用字符串來的安全，SetCookies是需要指定Url的，不過通常對于同一個網(wǎng)站host應(yīng)該是一樣的，比如www.a.com，不過目前還沒遇到過跨域問題，等遇到了我單獨寫一篇討論，跨域可又是另外一個頭疼的問題了。
這里要說一下CookieContainer和AddHttpHeader的區(qū)別，首先這兩個不能同時使用，只能用一個，其次CookieContainer畢竟是容器，所以理論上可以把另外一個請求的cookie一起帶過來，然后實現(xiàn)cookie傳遞邏輯，而AddHttpHeader做不到這一點，這是最大的區(qū)別。
先寫到這，大家有什么關(guān)于HttpWebRequest的其他心得可以發(fā)在回復(fù)中，我會整理后更新這個帖子。
喜歡 
頂
難過
囧
圍觀
無聊
