萬盛學電腦網

 萬盛學電腦網 >> Windows xp教程 >> Server如何簡化?iis設置幫你忙

Server如何簡化?iis設置幫你忙

作者:佚名    責任編輯:admin    更新時間:    2015-10-13 14:18:05

  WindowsServer具有可靠性、可用性、可伸縮性和安全性,這使其成為高度可靠的平台。也因為它操作的簡便,使用浏覽器來上傳文件還是成為被廣泛接受的文件傳輸方式。雖然這種方式被廣泛接受,但它並不能保證不出錯。一個確認的微軟IIS問題就是在處理大於48K的上傳文件時會出現一個超時報錯。有時這只是一次上傳的失敗,但其它時候這會讓浏覽器進入一個不停嘗試重新發送數據的死循環。因為對於浏覽器來說,沒有一種針對這種特定情況的標准響應。

  這種掛起的原因是IIS使用一種如ASP的應用程序來處理客戶端數據的上傳。當客戶端開始提交數據時,IIS將第一個48K的數據讀入緩沖區,然後將其傳遞給應用程序進行處理。任何超出這48K的數據會處於等待狀態直到應用程序請求傳輸,通常通過類似Request.BinaryRead(Request.TotalBytes)的命令來執行。如果應用程序沒有請求,這些數據則處於等待連接狀態。這是一個典型的413報錯:請求實體過大。

  通常,按照上述規則進行良好的編碼可以避免此類問題,但某些情況下可能需要使用特定的屬性設置。例如,如果你的某個站點的上傳是由第三方的ISAPI擴展來處理的,它沒有遵循這種做法,此時就需要進行一些調整來克服48K的限制。這個限制不是一成不變的,它通過一個名為UploadReadAheadSize的IIS元數據(metabase)屬性來定義。默認值為49152K,最高可以設為4GB。如果需要的話,你可以對一個單獨的站點進行設置也可以設定整個IIS服務。

  這可能不是唯一需要設置的屬性。你可能還需要修改maxRequestLength(在IIS6)或maxAllowedContentLength(在IIS7 +)的屬性值來允許大型數據的上傳,盡管它們的默認值也較大。

  在某些情況下,將UploadReadAheadSize的值設為零會很有幫助。這會強制IIS將提交的內容直接流向ISAPI擴展應用來處理該請求。這可能是在解決這個問題時首先值得嘗試的方法,但是你也應該注意到關閉IIS應用程序(不處理預讀緩沖區)可能帶來的副作用。

  最後,請記住,增加UploadReadAheadSize的值會產生一個攻擊面。如果這個值設置得很高,並且有人想利用通過上傳文件來耗費帶寬的方式攻擊你的系統,他們將很容易得手。為了避免攻擊,使用一個能夠體現用戶實際使用的值,並盡可能地堅持使用身份驗證的方式,以確保上傳者的身份值得信賴。

copyright © 萬盛學電腦網 all rights reserved