A. web前端三大主流框架
隨著互聯網的發展，web前端框架越來越重要。目前，web前端三大主流框架分別為React、Vue和Angular。React由Facebook開發，採用JSX的語扒檔法，使得開發者可以在JavaScript中編寫HTML。Vue由Evan You於2014年創建，其核心庫只關注視圖層，非常容易上手。Angular是由Google開發的，是一個完整的框架，包含很多功能，如依賴注入、指令、服務等。
React是一個非常爛派流行的框架，已經成為許多大型公司使用的首選框架。它具有高性能和靈活性，可以構建單頁面應用程序和復雜的用戶界面。React還有一個龐大的生態系統，包括許多支持庫和工具，使得開發者可以更加高效地構建應用程序。
Vue是一個輕量級框架，易於上手，因此成為了許多初學者的首選。Vue具有高度靈活性和可擴展性，並且支持組件化開發，可以有效地提高開發效率。Vue還擁有許多有用的功能，如指令、過濾器和混入等，使得開發者可以更加輕松地構建復雜的應用程序。
Angular是一個完整的框架，提供了許多功能，如依賴注入、模板語法、指令和服務等。它還支持TypeScript，這是一個強類型的JavaScript超集，可以在編譯時檢查類型錯誤。Angular還有一個龐大的社區和生態系統，使得開發者可以更加容易地解決問題和獲得支持。
總的來說，React、Vue和Angular都是非常優秀的前端框架，每個框架都有其獨特的優勢和適用場景。開發飢此賀者可以根據自己的需求和技能水平選擇適合自己的框架。在選擇框架時，還需要考慮到其生態系統、支持庫和工具等方面，以便更加高效地開發和維護應用程序。
B. 《High Performance Web Sites》txt下載在線閱讀全文,求百度網盤雲資源
《高性能網站建設指南》（Steve Souders）電子書網盤下載免費在線閱讀
鏈接: https://pan..com/s/1HEvyNhrIx09IVxcSMO7I-w
書名：高性能網站建設指南
作者：Steve Souders
譯者：劉彥博
豆瓣評分：8.5
出版社：電子工業出版社
出版年份：2008年
頁數：146 頁
內容簡介：
本書結合Web 2.0以來Web開發領域的最新形勢和特點，介紹了網站性能問題的現狀、產生的原因，以及改善或解決性能問題的原則、技術技巧和最佳實踐。重點關注網頁的行為特徵，闡釋優化Ajax、CSS、JavaScript、Flash和圖片處理等要素的技術，全面涵蓋瀏覽器端性能問題的方方面面。在《高性能網站建設指南》中，作者給出了14條具體的優化原則，每一條原則都配以範例佐證，並提供了在線支持。《高性能網站建設指南》內容豐富，主要包括減少HTTP請求、Edge Computing技術、Expires Header技術、Gzip組件、CSS和JavaScript最佳實踐、主頁內聯、Domain最小化、JavaScript優化、避免重定向的技巧、刪除重復JavaScript的技巧、關閉ETags的技巧、Ajax緩存技術和最小化技術等。《高性能網站建設指南》適合Web架構師、信息架構師、Web開發人員及產品經理閱讀和參考。
作者簡介：
Steve Souders在Yahoo!擔任Chief Performance。他於2000年加盟Yahoo!，在該公司的很多平台和產品團隊中工作過。在他到達今天這個位置之前，他就職於My Yahoo!開發團隊。.
作為Chief Performance Yahoo!，他開發了一系列優秀軟體，可以使網站訪問速度變得更快。他構建了用於進行性能分析的工具，並將這些優秀軟體和工具傳播到Yahoo!的各個產品團隊中。
在到Yahoo!之前，Steve就職於很多小型或中型公司，包括他和別人一起創辦的兩個公司——Helix Systems和CoolSync。
C. 我有一個網站是.NET做的,因為本人不懂.net就用ASP寫了個簡單的後台,結果經常出現'80004005' 錯誤
重要,因為顏色是整體風格的最集中的體現;如果顏色確定偏差將直接導致與所要表達風格的錯位,大大降低效果.本人常使用的顏色如下:
3. 依據功能確定整體框架;
整體框架確定的出發點是對功能展現的效果上,以及操作簡便性.
4. 統一風格,統一實現方式;
統一的目的是為了讓使用者在使用本系統時,不論操作到那個功能模塊,都感覺到本系統是一個統一融合的整體,就好像由一個人開發實現的;為什麼要這樣做呢?就好像一個人與一個人進行交流相對比較容易,只要清楚一個人的秉性就可以嫻熟的與其交流,如果讓這個人與十個人進行交流,並且在交流時經常更換人,可以想像這將是一件多麼痛苦的事情啊!
統一風格主要有顏色、字體、按鈕、列表、表單、報表等;
統一實現方式主要有添加、刪除、修改、查詢、分頁等.
5. 頁面細節決定系統專業程度;
經過對比以前系統和其他公司的系統,發現系統在細節上考慮的很是不足;分析比較專業的系統,發現其頁面的框架和風格與我公司系統幾乎差不說,但是在具體實現細節上,人家考慮的十分周到細致,這顯然是通過多個項目積累出來的,而我公司往往每做一個新項目時,都會更換一套新的頁面風格,給人新鮮感,其實經過幾個項目觀察下來其內部實現細節並沒有多少累積,所有本人覺得不是在十分必要的情況下,不易經常更換頁面的整體風格,而應該有一定的延續性,集中精力多從具體實現細節上下功夫,多從用戶的使用體驗上思考該如何實現,多完善實現的細節,最終實現一個非常專業的系統.
頁面的細節如按鈕大小、單元格寬度、列表大小、輸入框錄入位元組多少控制、表單錄入項的驗證等等.
6. 用戶體驗決定系統品質;
關於用戶體驗是本人一直在思考的問題,到底如何才能提高用戶體驗呢?應從使用者的視覺感觀、操作效果、思維過程等方面尋找答案,比如用紅色作為企業級應用的主體色,就要很慎重了,因為紅色是代表著激情、熱烈與企業級應用的要求差距較大,這樣就影響視覺效果;比如需要進行層次較多的選擇時,以前會先用一個列表選擇進去,再選擇其相應的子選項進行查詢、添加等操作,這樣操作效果就很差很羅嗦,對於這樣情況採用旁邊放顆樹進行選擇,不失為一個好的表現形式;比如要實現一些審核性、流程性、過程性的業務,可以考慮採用流程圖的形式,這樣非常直觀明了而且易操作;比如要常實現的添加、刪除、修改、查詢等操作時,如何在頁面上組織它們才能使用戶使用方便,這時就要考慮用戶通常的思維過程是如何的,據此實現,用戶使用起來就會方便舒心.
以上就是本人在項目開發過程中的幾點體會,一直想寫,今日終於完成,很是高興!本人是想想寫寫思路比較凌亂,希望大家多批評指教,謝謝!
你看上面的行嗎？
就你問題補充：
數據層性能 技巧 1 — 返回多個結果集 技巧 2 — 分頁的數據訪問 技巧 3 — 連接池 技巧 4 — ASP.NET 緩存 API 技巧 5 — 每請求緩存 技巧 6 — 後台處理 技巧 7 — 頁輸出緩存和代理伺服器 技巧 8 — 運行 IIS 6.0（只要用於內核緩存） 技巧 9 — 使用 Gzip 壓縮 技巧 10 — 伺服器控制項視圖狀態 小結 ==================================================== 使用 ASP.NET 編寫 Web 應用程序的簡單程度令人不敢相信。正因為如此簡單，所以很多開發人員就不會花時間來設計其應用程序的結構，以獲得更好的性能了。在本文中，我將講述 10 個用於編寫高性能 Web 應用程序的技巧。但是我並不會將這些建議僅局限於 ASP.NET 應用程序，因為這些應用程序只是 Web 應用程序的一部分。本文不作為對 Web 應用程序進行性能調整的權威性指南 — 一整本書恐怕都無法輕松講清楚這個問題。請將本文視作一個很好的起點。 成為工作狂之前，我原來喜歡攀岩。在進行任何大型攀岩活動之前，我都會首先仔細查看指南中的路線，閱讀以前遊客提出的建議。但是，無論指南怎麼好，您都需要真正的攀岩體驗，然後才能嘗試一個特別具有挑戰性的攀登。與之相似，當您面臨修復性能問題或者運行一個高吞吐量站點的問題時，您只能學習如何編寫高性能 Web 應用程序。 我的個人體驗來自在 Microsoft 的 ASP.NET 部門作為基礎架構程序經理的經驗，在此期間我運行和管理 ，幫助設計社區伺服器的結構，社區伺服器是幾個著名 ASP.NET 應用程序（組合到一個平台的 ASP.NET Forums、.Text 和 nGallery）。我確信有些曾經幫助過我的技巧對您肯定也會有所幫助。 您應該考慮將應用程序分為幾個邏輯層。您可能聽說過 3 層（或者 n 層）物理體系結構一詞。這些通常都是規定好的體系結構方式，將功能在進程和/或硬體之間進行了物理分離。當系統需要擴大時，可以很輕松地添加更多的硬體。但是會出現一個與進程和機器跳躍相關的性能下降，因此應該避免。所以，如果可能的話，請盡量在同一個應用程序中一起運行 ASP.NET 頁及其相關組件。 因為代碼分離以及層之間的邊界，所以使用 Web 服務或遠程處理將會使得性能下降 20% 甚至更多。 數據層有點與眾不同，因為通常情況下，最好具有專用於資料庫的硬體。然而進程跳躍到資料庫的成本依然很高，因此數據層的性能是您在優化代碼時首先要考慮的問題。 在深入應用程序的性能修復問題之前，請首先確保對應用程序進行剖析，以便找出具體的問題所在。主要性能計數器（如表示執行垃圾回收所需時間百分比的計數器）對於找出應用程序在哪些位置花費了其主要時間也非常有用。然而花費時間的位置通常非常不直觀。 本文講述了兩種類型的性能改善：大型優化（如使用 ASP.NET 緩存），和進行自身重復的小型優化。這些小型優化有時特別有意思。您對代碼進行一點小小的更改，就會獲得很多很多時間。使用大型優化，您可能會看到整體性能的較大飛躍。而使用小型優化時，對於某個特定請求可能只會節省幾毫秒的時間，但是每天所有請求加起來，則可能會產生巨大的改善。 數據層性能 談到應用程序的性能調整，有一個試紙性的測試可用來對工作進行優先順序劃分：代碼是否訪問資料庫？如果是，頻率是怎樣的？請注意，這一相同測試也可應用於使用 Web 服務或遠程處理的代碼，但是本文對這些內容未做講述。 如果某個特定的代碼路徑中必需進行資料庫請求，並且您認為要首先優化其他領域（如字元串操作），則請停止，然後執行這個試紙性測試。如果您的性能問題不是非常嚴重的話，最好花一些時間來優化一下與資料庫、返回的數據量、進出資料庫的往返頻率相關的花費時間。 了解這些常規信息之後，我們來看一下可能會有助於提高應用程序性能的十個技巧。首先，我要講述可能會引起最大改觀的更改。 =============================== 技巧 1 — 返回多個結果集 仔細查看您的資料庫代碼，看是否存在多次進入資料庫的請求路徑。每個這樣的往返都會降低應用程序可以提供的每秒請求數量。通過在一個資料庫請求中返回多個結果集，可以節省與資料庫進行通信所需的總時間長度。同時因為減少了資料庫伺服器管理請求的工作，還會使得系統伸縮性更強。 雖然可以使用動態 SQL 返回多個結果集，但是我首選使用存儲過程。關於業務邏輯是否應該駐留於存儲過程的問題還存在一些爭議，但是我認為，如果存儲過程中的邏輯可以約束返回數據的話（縮小數據集的大小、縮短網路上所花費時間，不必篩選邏輯層的數據），則應贊成這樣做。 使用 SqlCommand 實例及其 ExecuteReader 方法填充強類型的業務類時，可以通過調用 NextResult 將結果集指針向前移動。圖 1 顯示了使用類型類填充幾個 ArrayList 的示例會話。只從資料庫返回您需要的數據將進一步減少伺服器上的內存分配。 ================================== 技巧 2 — 分頁的數據訪問 ASP.NET DataGrid 具有一個很好的功能：數據分頁支持。在 DataGrid 中啟用分頁時，一次會顯示固定數量的記錄。另外，在 DataGrid 的底部還會顯示分頁 UI，以便在記錄之間進行導航。該分頁 UI 使您能夠在所顯示的數據之間向前和向後導航，並且一次顯示固定數量的記錄。 還有一個小小的波折。使用 DataGrid 的分頁需要所有數據均與網格進行綁定。例如，您的數據層需要返回所有數據，那麼 DataGrid 就會基於當前頁篩選顯示的所有記錄。如果通過 DataGrid 進行分頁時返回了 100,000 個記錄，那麼針對每個請求會放棄 99,975 個記錄（假設每頁大小為 25 個記錄）。當記錄的數量不斷增加時，應用程序的性能就會受到影響，因為針對每個請求必須發送越來越多的數據。 要編寫性能更好的分頁代碼，一個極佳的方式是使用存儲過程。圖 2 顯示了針對 Northwind 資料庫中的 Orders 表進行分頁的一個示例存儲過程。簡而言之，您此時要做的只是傳遞頁索引和頁大小。然後就會計算合適的結果集，並將其返回。 在社區伺服器中，我們編寫了一個分頁伺服器控制項，以完成所有的數據分頁。您將會看到，我使用的就是技巧 1 中討論的理念，從一個存儲過程返回兩個結果集：記錄的總數和請求的數據。 返回記錄的總數可能會根據所執行查詢的不同而有所變化。例如，WHERE 子句可用來約束返回的數據。為了計算在分頁 UI 中顯示的總頁數，必須了解要返回記錄的總數。例如，如果總共有 1,000,000 條記錄，並且要使用一個 WHERE 子句將其篩選為 1000 條記錄，那麼分頁邏輯就需要了解記錄的總數才能正確呈現分頁 UI。 ============================== 技巧 3 — 連接池 在 Web 應用程序和 SQL Server™ 之間設置 TCP 連接可能是一個非常消耗資源的操作。Microsoft 的開發人員到目前為止能夠使用連接池已經有一段時間了，這使得他們能夠重用資料庫連接。他們不是針對每個請求都設置一個新的 TCP 連接，而是只在連接池中沒有任何連接時才設置新連接。當連接關閉時，它會返回連接池，在其中它會保持與資料庫的連接，而不是完全破壞該 TCP 連接。 當然，您需要小心是否會出現泄漏連接。當您完成使用連接時，請一定要關閉這些連接。再重復一遍：無論任何人對 Microsoft?.NET Framework 中的垃圾回收有什麼評論，請一定要在完成使用連接時針對該連接顯式調用 Close 或 Dispose。不要相信公共語言運行庫 (CLR) 會在預先確定的時間為您清除和關閉連接。盡管 CLR 最終會破壞該類，並強制連接關閉，但是當針對對象的垃圾回收真正發生時，並不能保證。 要以最優化的方式使用連接池，需要遵守一些規則。首先打開連接，執行操作，然後關閉該連接。如果您必須如此的話，可以針對每個請求多次打開和關閉連接（最好應用技巧 1），但是不要一直將連接保持打開狀態並使用各種不同的方法對其進行進出傳遞。第二，使用相同的連接字元串（如果使用集成身份驗證的話，還要使用相同的線程標識）。如果不使用相同的連接字元串，例如根據登錄的用戶自定義連接字元串，那麼您將無法得到連接池提供的同一個優化值。如果您使用集成身份驗證，同時還要模擬大量用戶，連接池的效率也會大大下降。嘗試跟蹤與連接池相關的任何性能問題時，.NET CLR 數據性能計數器可能非常有用。 每當應用程序連接資源時，如在另一個進程中運行的資料庫，您都應該重點考慮連接該資源所花時間、發送或檢索數據所花時間，以及往返的數量，從而進行優化。優化應用程序中任何種類的進程跳躍都是獲得更佳性能的首要一點。 應用層包含了連接數據層、將數據轉換為有意義類實例和業務流程的邏輯。例如社區伺服器，您要在其中填充Forums 或 Threads集合，應用業務規則（如許可權）；最重要的是要在其中執行緩存邏輯。 ================================ 技巧 4 — ASP.NET 緩存 API 編寫應用程序代碼行之前，一個首要完成的操作是設計應用層的結構，以便最大化利用 ASP.NET 緩存功能。 如果您的組件要在 ASP.NET 應用程序中運行，則只需在該應用程序項目中包括一個 System.Web.dll 引用。當您需要訪問該緩存時，請使用 HttpRuntime.Cache 屬性（通過 Page.Cache 和 HttpContext.Cache 也可訪問這個對象）。 對於緩存數據，有幾個規則。首先，如果數據可能會多次使用時，則這是使用緩存的一個很好的備選情況。第二，如果數據是通用的，而不特定於某個具體的請求或用戶時，則也是使用緩存的一個很好的備選情況。如果數據是特定於用戶或請求的，但是壽命較長的話，仍然可以對其進行緩存，但是這種情況可能並不經常使用。第三，一個經常被忽略的規則是，有時可能您緩存得太多。通常在一個 x86 計算機上，為了減少內存不足錯誤出現的機會，您會想使用不高於 800MB 的專用位元組運行進程。因此緩存應該有個限度。換句話說，您可能能夠重用某個計算結果，但是如果該計算採用 10 個參數的話，您可能要嘗試緩存 10 個排列，這樣有可能給您帶來麻煩。一個要求 ASP.NET 的最常見支持是由於過度緩存引起的內存不足錯誤，尤其是對於大型數據集。 圖 3 ASP.NET緩存 緩存有幾個極佳的功能，您需要對它們有所了解。首先，緩存會實現最近最少使用的演算法，使得 ASP.NET 能夠在內存運行效率較低的情況下強制緩存清除 － 從緩存自動刪除未使用過的項目。第二，緩存支持可以強制失效的過期依賴項。這些依賴項包括時間、密鑰和文件。時間經常會用到，但是對於 ASP.NET 2.0，引入了一個功能更強的新失效類型：資料庫緩存失效。它指的是當資料庫中的數據發生變化時自動刪除緩存中的項。有關資料庫緩存失效的詳細信息，請參閱 MSDN?Magazine 2004 年 7 月的 Dino Esposito Cutting Edge 專欄。要了解緩存的體系結構，請參閱圖 3。 ======================= 技巧 5 — 每請求緩存 在本文前面部分，我提到了經常遍歷代碼路徑的一些小改善可能會導致較大的整體性能收益。對於這些小改善，其中有一個絕對是我的最愛，我將其稱之為「每請求緩存」。 緩存 API 的設計目的是為了將數據緩存較長的一段時間，或者緩存至滿足某些條件時，但每請求緩存則意味著只將數據緩存為該請求的持續時間。對於每個請求，要經常訪問某個特定的代碼路徑，但是數據卻只需提取、應用、修改或更新一次。這聽起來有些理論化，那麼我們來舉一個具體的示例。 在社區伺服器的論壇應用程序中，頁面上使用的每個伺服器控制項都需要個性化的數據來確定使用什麼外觀、使用什麼樣式表，以及其他個性化數據。這些數據中有些可以長期緩存，但是有些數據卻只針對每個請求提取一次，然後在執行該請求期間對其重用多次，如要用於控制項的外觀。 為了達到每請求緩存，請使用 ASP.NET HttpContext。對於每個請求，都會創建一個 HttpContext 實例，在該請求期間從 HttpContext.Current 屬性的任何位置都可訪問該實例。該 HttpContext 類具有一個特殊的 Items 集合屬性；添加到此 Items 集合的對象和數據只在該請求持續期間內進行緩存。正如您可以使用緩存來存儲經常訪問的數據一樣，您也可以使用 HttpContext.Items 來存儲只基於每個請求使用的數據。它背後的邏輯非常簡單：數據在它不存在的時候添加到 HttpContext.Items 集合，在後來的查找中，只是返回 HttpContext.Items 中的數據。 ===================== 技巧 6 — 後台處理 通往代碼的路徑應該盡可能快速，是嗎？可能有時您會覺得針對每個請求執行的或者每 n 個請求執行一次的任務所需資源非常多。發送電子郵件或者分析和驗證傳入數據就是這樣的一些例子。 剖析 ASP.NET Forums 1.0 並重新構建組成社區伺服器的內容時，我們發現添加新張貼的代碼路徑非常慢。每次添加新張貼時，應用程序首先需要確保沒有重復的張貼，然後必須使用「壞詞」篩選器分析該張貼，分析張貼的字元圖釋，對張貼添加標記並進行索引，請求時將張貼添加到合適的隊列，驗證附件，最終張貼之後，立即向所有訂閱者發出電子郵件通知。很清楚，這涉及很多操作。 經研究發現，大多數時間都花在了索引邏輯和發送電子郵件上。對張貼進行索引是一個非常耗時的操作，人們發現內置的 System.Web.Mail 功能要連接 SMYP 伺服器，然後連續發送電子郵件。當某個特定張貼或主題領域的訂閱者數量增加時，執行 AddPost 功能所需的時間也越來越長。 並不需要針對每個請求都進行電子郵件索引。理想情況下，我們想要將此操作進行批處理，一次索引 25 個張貼或者每五分鍾發送一次所有電子郵件。我們決定使用以前用於對數據緩存失效進行原型設計的代碼，這個失效是用於最終進入 Visual Studio® 2005 的內容的。 System.Threading 命名空間中的 Timer 類非常有用，但是在 .NET Framework 中不是很有名，至少對於 Web 開發人員來說是這樣。創建之後，這個 Timer 類將以一個可配置的間隔針對 ThreadPool 中的某個線程調用指定的回調。這就表示，您可以對代碼進行設置，使其能夠在沒有對 ASP.NET 應用程序進行傳入請求的情況下得以執行，這是後台處理的理想情況。您還可以在此後台進程中執行如索引或發送電子郵件之類的操作。 但是，這一技術有幾個問題。如果應用程序域卸載，該計時器實例將停止觸發其事件。另外，因為 CLR 對於每個進程的線程數量具有一個硬性標准，所以可能會出現這樣的情形：伺服器負載很重，其中計時器可能沒有可在其基礎上得以完成的線程，在某種程度上可能會造成延遲。ASP.NET 通過在進程中保留一定數量的可用線程，並且僅使用匯流排程的一部分用於請求處理，試圖將上述情況發生的機會降到最低。但是，如果您具有很多非同步操作時，這可能就是一個問題了。 這里沒有足夠的空間來放置該代碼，但是您可以下載一個可以看懂的示例，網址是 。請了解一下 Blackbelt TechEd 2004 演示中的幻燈片和演示。 ========================= 技巧 7 — 頁輸出緩存和代理伺服器 ASP.NET 是您的表示層（或者說應該是您的表示層）；它由頁、用戶控制項、伺服器控制項（HttpHandlers 和 HttpMoles）以及它們生成的內容組成。如果您具有一個 ASP.NET 頁，它會生成輸出（HTML、XML、圖像或任何其他數據），並且您針對每個請求運行此代碼時，它都會生成相同的輸出，那麼您就擁有一個可用於頁輸出緩存的絕佳備選內容。 將此行內容添加頁的最上端 <%@ Page OutputCache VaryByParams="none" Duration="60" %> 就可以高效地為此頁生成一次輸出，然後對它進行多次重用，時間最長為 60 秒，此時該頁將重新執行，輸出也將再一次添加到 ASP.NET 緩存。通過使用一些低級程序化 API 也可以完成此行為。對於輸出緩存有幾個可配置的設置，如剛剛講到的 VaryByParams 屬性。VaryByParams 剛好被請求到，但還允許您指定 HTTP GET 或 HTTP POST 參數來更改緩存項。例如，只需設置 VaryByParam="Report" 即可對 default.aspx?Report=1 或 default.aspx?Report=2 進行輸出緩存。通過指定一個以分號分隔的列表，還可以指定其他參數。 很多人都不知道何時使用輸出緩存，ASP.NET 頁還會生成一些位於緩存伺服器下游的 HTTP 標頭，如 Microsoft Internet Security and Acceleration Server 或 Akamai 使用的標頭。設置了 HTTP 緩存標頭之後，可以在這些網路資源上對文檔進行緩存，客戶端請求也可在不必返回原始伺服器的情況下得以滿足。 因此，使用頁輸出緩存不會使得您的應用程序效率更高，但是它可能會減少伺服器上的負載，因為下游緩存技術會緩存文檔。當然，這可能只是匿名內容；一旦它成為下游之後，您就再也不會看到這些請求，並且再也無法執行身份驗證以阻止對它的訪問了。 ======================== 技巧 8 — 運行 IIS 6.0（只要用於內核緩存） 如果您未運行 IIS 6.0 (Windows Server? 2003)，那麼您就錯過了 Microsoft Web 伺服器中的一些很好的性能增強。在技巧 7 中，我討論了輸出緩存。在 IIS 5.0 中，請求是通過 IIS 然後進入 ASP.NET 的。涉及到緩存時，ASP.NET 中的 HttpMole 會接收該請求，並返回緩存中的內容。 如果您正在使用 IIS 6.0，就會發現一個很好的小功能，稱為內核緩存，它不需要對 ASP.NET 進行任何代碼更改。當請求由 ASP.NET 進行輸出緩存時，IIS 內核緩存會接收緩存數據的一個副本。當請求來自網路驅動程序時，內核級別的驅動程序（無上下文切換到用戶模式）就會接收該請求，如果經過了緩存，則會將緩存的數據刷新到響應，然後完成執行。這就表示，當您將內核模式緩存與 IIS 和 ASP.NET 輸出緩存一起使用時，就會看到令人不敢相信的性能結果。在 ASP.NET 的 Visual Studio 2005 開發過程中，我一度是負責 ASP.NET 性能的程序經理。開發人員完成具體工作，但是我要看到每天進行的所有報告。內核模式緩存結果總是最有意思的。最常見的特徵是網路充滿了請求/響應，而 IIS 運行時的 CPU 使用率只有大約 5%。這太令人震驚了！當然使用 IIS 6.0 還有一些其他原因，但是內核模式緩存是其中最明顯的一個。 =========================== 技巧 9 — 使用 Gzip 壓縮 雖然使用 gzip 並不一定是伺服器性能技巧（因為您可能會看到 CPU 使用率的提高），但是使用 gzip 壓縮可以減少伺服器發送的位元組數量。這就使人們覺得頁速度加快了，並且還減少了帶寬的用量。根據所發送數據、可以壓縮的程度以及客戶端瀏覽器是否支持（IIS 只會向支持 gzip 壓縮的客戶端發送經過 gzip 壓縮的內容，如 Internet Explorer 6.0 和 Firefox），您的伺服器每秒可以服務於更多的請求。實際上，幾乎每當您減少所返回數據的數量時，都會增加每秒請求數。 Gzip 壓縮已經內置到 IIS 6.0 中，並且其性能比 IIS 5.0 中使用的 gzip 壓縮要好的多，這是好消息。但不幸的是，當嘗試在 IIS 6.0 中打開 gzip 壓縮時，您可能無法在 IIS 的屬性對話中找到該設置。IIS 小組在該伺服器中置入了卓越的 gzip 功能，但是忘了包括一個用於啟用該功能的管理 UI。要啟用 gzip 壓縮，您必須深入到 IIS 6.0 的 XML 配置設置內部（這樣不會引起心臟虛弱）。順便提一句，這歸功於 OrcsWeb 的 Scott Forsyth，他幫助我提出了在 OrcsWeb 上宿主的 伺服器的這個問題。 本文就不講述步驟了，請閱讀 Brad Wilson 的文章，網址是 IIS6 Compression。還有一篇有關為 ASPX 啟用壓縮的知識庫文章，網址是 Enable ASPX Compression in IIS。但是您應該注意，由於一些實施細節，IIS 6.0 中不能同時存在動態壓縮和內核緩存。 ============================== 技巧 10 — 伺服器控制項視圖狀態 視圖狀態是一個有趣的名稱，用於表示在所生成頁的隱藏輸出欄位中存儲一些狀態數據的 ASP.NET。當該頁張貼回伺服器時，伺服器可以分析、驗證、並將此視圖狀態數據應用回該頁的控制項樹。視圖狀態是一個非常強大的功能，因為它允許狀態與客戶端一起保持，並且它不需要 cookie 或伺服器內存即可保存此狀態。很多 ASP.NET 伺服器控制項都使用視圖狀態來保持在與頁元素進行交互期間創建的設置，例如保存對數據進行分頁時顯示的當前頁。 然而使用視圖狀態也有一些缺點。首先，服務或請求頁時，它都會增加頁的總負載。對張貼回伺服器的視圖狀態數據進行序列化或取消序列化時，也會發生額外的開銷。最後，視圖狀態會增加伺服器上的內存分配。 幾個伺服器控制項有著過度使用視圖狀態的趨勢，即使在並不需要的情況下也要使用它，其中最著名的是 DataGrid。ViewState 屬性的默認行為是啟用，但是如果您不需要，則可以在控制項或頁級別關閉。在控制項內，只需將 EnableViewState 屬性設置為 false，或者在頁中使用下列設置即可對其進行全局設置： <%@ Page EnableViewState="false" %> 如果您不回發頁，或者總是針對每個請求重新生成頁上的控制項，則應該在頁級別禁用視圖狀態。 ============================== 小結 我為您講述了一些我認為在編寫高性能 ASP.NET 應用程序時有所幫助的技巧。正如我在本文前面部分提到的那樣，這是一個初步指南，並不是 ASP.NET 性能的最後結果。（有關改善 ASP.NET 應用程序性能的信息，請參閱 Improving ASP.NET Performance。）只有通過自己的親身體驗才能找出解決具體性能問題的最好方法。但是，在您的旅程中，這些技巧應該會為您提供一些好的指南。在軟體開發中，幾乎沒有絕對的東西；每個應用程序都是唯一的。 請參閱提要欄「Common Performance Myths」。 Rob Howard 是 Telligent Systems 的創始人，專門從事高性能 Web 應用程序、知識庫管理和協作系統方面的工作。Rob 以前受雇於 Microsoft，他在那裡幫助設計了 ASP.NET 1.0、1.1 和 2.0 的基礎結構。要聯系 Rob，請訪問 [email protected]。
D. 求推薦幾本書。關於互聯網運營和通過互聯網盈利的一些方面的書籍
a.行業了解
《沸騰十五年》
《浪潮之巔》
《互聯網之達芬奇密碼》
《不一樣的平台，移動互聯網時代的商業模式創新》
《電商的戰國》
《我看電商》
《改變中國互聯網未來的六大力量》
《信息規則 ：網路經濟的策略指導》
《超級數字天才：為什麼用數字思考是變聰明的新方法》
b.產品了解
《人人都是產品經理》
《結網》
《設計溝通十器》
《產品經理手冊》
《神一樣的產品經理》
《啟示錄》
《軟體工程：實踐者的研究方法》
《手機研發流程與質量管理》
c.交互設計、用戶體驗
《About Face3交互設計精髓 》
《觸動人心》
《SNS網站構建》
《社交網站界面設計》
《web信息架構，設計大型網站》
《web導航設計》
《web設計禁忌》
《移動應用UI設計模式》
築巢引鳳、簡約至上、見微知著
《yes 產品經理》
d.創業數據，理解商業思維
《精益創業》
《精益創業實戰》
《創業四步法》這本書早於《精益創業》）《創業者聖經》
《豐田汽車案例：精益製造的14項管理原則》
《創業三十六條軍規》
《精益六西格瑪-精益生產與六西格瑪的完美整合》
《平台戰略》
《電子商務管理視角》
《營銷管理》
《運營管理》（這里的運營是企業運營管理的意思）
《項目管理知識體系指南》
《量化，大數據時代的企業管理》
2.消得人憔悴：依據所處職位的職責，尋求最優解決之道
a.數據分析
基礎書籍：
《網站分析基礎教程》
《網站分析實戰：如何以數據驅動決策，提升網站價值》
《流量的秘密:Google Analytics網站分析與優化技巧》第二版
技能進階：
《精通Web Analytics 2.0：用戶中心科學與在線統計藝術》
數據呈現：
《誰說菜鳥不會數據分析》2013最新版
《Excel商務圖表應用與技巧108例（雙色版）》
《鮮活的數據：數據可視化指南》
拓展訓練：
《大數據時代》
《R語言實戰》
具體主題分析
搜索《精通搜索分析》
淘寶《玩法變了:淘寶賣家運贏弱品牌時代》
社交網站《社交網站的數據挖掘與分析》（懂技術才能讀）
性能優化（粗讀）
《構建高性能web站點》
《網站性能監測與優化》
《大規模web服務開發技術》
《高性能網站建設進階指南》
b.流量（用戶推廣）
網路營銷
《錦囊妙計，網站推廣101招》《網路營銷推廣實戰寶典》問題查找即可
《正在爆發的營銷革命-社會化網路營銷指南》
《濕營銷》
《行動的召喚》《等待貓吠》
《SEO實戰密碼》《SEO藝術》
《搜索引擎營銷-網站流量大提速》
《搜索引擎優化：每天一小時》《搜索引擎優化寶典》
內容營銷
《內容營銷，網路營銷的殺手級武器》
c.留存
內容
《勝於言傳：網站內容制勝寶典》
《與五十位主編面對面》
《web內容策略指南》
活動
《商品促銷實戰技巧一本全》
作者：
王志綱《找魂》《推手》。。。
熊大尋《江山入劃》
葉茂中《想》與《做》？想與做？
d.轉化
《網站轉化率優化之道》
《數據掘金，電子商務運營突圍》
《landing page優化權威指南》
《淘寶賣家秘笈》
《提高轉化率! : 網頁A/B測試與多變數測試實戰指南》
《啤酒與尿布》
《顧客為什麼購買》
三、尋他千網路：驀然回首，佳麗原來在後宮
生活興趣書籍，從生活中感悟。
社區運營：《裸猿》、《人類動物園》和《親密行為》社區機制
用戶行為：《會賺錢的行為經濟學》《流行性物慾症》《後物慾時代的來臨》
廣告策劃：《廣告武林秘笈》《廣告文案傳真》《大量流出》
商業：《商戰》《戰爭論》
值得精度的書：
《數據化管理》
《超級富豪就是超級創意》
《數據挖掘與數據化運營實戰》
《精益創業實戰》
《數據分析，企業的賢內助》
《微力無邊》
《淘寶產品十年事》
《推薦系統實踐》
《設計搜索體驗》
《深入理解網站優化》
2014新書推薦：
《騰訊方法 : 一個市值1500億美元公司的產品真經》
《顛覆式創新：移動互聯網時代的生存法則》
《從門外漢到BAT產品經理有多遠》
《締造企鵝 : 產品經理是這樣煉成的》
《九敗一勝 : 美團創始人王興創業十年》
《第二次機器革命 : 數字化技術將如何改變我們的經濟與社會》
《參與感 : 小米口碑營銷內部手冊》
《周鴻禕自述 : 我的互聯網方法論》
《再看電商》
《新經濟，新規則》
《社交紅利（修訂升級版）》
《互聯網創業原創精品-互聯網創業密碼》
《風吹江南之互聯網金融》
《谷歌和亞馬遜如何做產品》
《數據之巔:大數據革命》
《微管理》
《O2O進化論: 數據商業時代的全景圖》
《互聯網思維的企業》
《有的放矢:NISI創業指南》
《翻轉課堂的可汗學院:互聯時代的教育革命》
《矽谷百年史:偉大的科技創新與創業歷程(1900-2013)》
《創業時, 我們在知乎聊什麼?》
《孵化Twitter:從蠻荒到IPO的狂野旅程》
E. 怎麼寫好Java(或者Java web)代碼
作為一個Java開發攻城獅（lao si ji），我可以負責任地告訴你，多看多寫~
首先，鑒於題主你說你是剛接觸地階段，我並不推薦你你上來就要寫工業級或者企業級的代碼，當下的話應該是迅速積累項目經驗，快速掌握java web的開發流程為主，可以網上看看什麼視頻教程，有些還是能學到規范的。
分享一下我的經歷吧~
讀大學的時候我接一些外包【朋友介紹】，一開始也很虛啊，覺得這里不對，那裡不對的。寫得多了，慢慢理解整個開發流程後，就覺得也就是增刪改查嘛，沒什麼的。每次都要寫，好麻煩啊，既然這樣，不如自己造一些輪子，後來就是項目多了，又造了一些輪子，然後做了系列的封裝。期間穿插讀了 重構和effective java兩本書，代碼方法保持整潔，但一些代碼上還是不規范。
再後來，學習了java的一些高級特性，反射、自省【提高了寫代碼250%的效率】以及參考了部分阿里的規范，感覺逐漸能寫出比以前看上去優雅的代碼了。
接下來的一段時間，因為興趣的原因，研究了一下三大框架，自己強行擼了三個閹割版。回去看源碼的時候，發現spring寫得真的太優雅了，然後又小小改了一下風格。
最後，出來工作了，哦謝特~ 大家寫得什麼鬼啊~ 什麼規范都不參照~ 簡直內心爆炸，一萬點傷害~ 好吧，我還是照著我原先的思路，搞一搞~
所以說，工業級、企業級代碼不是每個公司都有，但是對自身有要求是好事啊~ 你也別急，慢慢寫，也能逐漸規范起來~ 只是現在，不合適~ 加油~
還有問題的話，歡迎聯系我~
F. 學習Web前端應先看什麼書
如果你是真心想學習web前端、以後想朝著這個方向發展，那麼你一定要來這個企鵝裙，前面前面是二9六，中間是5九一，最後面就是二九零，來這里可以這里學習經驗，得到專人解答，這樣你可以成長的更快！！！
我在學習javascript的時候，我基本把圖書館基本能借的javascript書都借了，主要是圖靈和博文視點出版的書。例如《JavaScript核心技術》，《精通JavaScript
》，《JAVASCRIPT語言精髓與編程實踐》，《JavaScript設計模式 》，《JavaScript語言精粹》，《JavaScript
DOM編程藝術》，《ppk談JavaScript》，《高性能網站建設指南
》等，還有其他很多js的書，如果借不到，就直接在圖書館七樓看，例如權威指南；也有一些一般的書，這里沒有提到，這些書，我並不是全部都會認真看過，因為初學階段這樣學習效率不高。權威指南我現在還沒看完，但是如果要全面深入學習的話，看兩本還是不夠的。但我喜歡以集中在兩本書以內學習作為切入點，這樣能使我將精力集中在，並且發現問題。
我在上面提到的書，都是比較好的書，適合不同的階段，例如《JavaScript語言精粹》這本書是屬於很精華的讀物，入門的時候看可能會比較吃力，當你對JS有一定的駕馭能力的時候，可能就會發現其中的奧妙。我當時花精力看的主要是《精通JavaScript
》，《JAVASCRIPT語言精髓與編程實踐》，《JavaScript核心技術》也花了不少時間，感覺收獲不是很大，可能當時理解不夠深刻，權威指南也是後來才看。《JavaScript核心技術》給我的幫助沒想像中大，但裡面說的知識我是很認真在看，可能不適合入門吧，但很多事情冥冥之中的聯系誰又能說得清楚呢，早期花時間在《JavaScript核心技術》上未必就是壞事。
《精通JavaScript
》是偏實踐型一類的書，作者是JQuery之父，書中有很多非常好的例子，還有jS的相關技巧，兼容瀏覽器的方法等。有很多例子都是作者處理問題的總結，我當時幾乎把裡面的每個例子都測試了一遍，受益匪淺，當然，書中也有不少瑕疵，不知道是我借的那本書印刷問題還是怎麼的，有些代碼運行並不兼容，也有些函數方法並不能成功運行。到後半部分的示例也比較繁瑣，我只是粗略看了一番。實際到後來我看網上的評論，這本書適合進階的人看，現在回頭看，感覺確實有jQuery源碼分析的感覺，而且部分內容並不適合初學者閱讀。但是書中的第三部分確實是很有用的。
上面說了很多關於個人在學習JS上的一些心得，無非也就是想說明一點，有時候並不能找到一本真正適合初學者的書，或者教程。有些書確實不錯，未必就適合你，有時候我們也會走錯路，但學習不應就此止步。
我接下來會寫一些自己讀過的書，並且覺得好的書推薦給大家，希望對大家有用：
HTML相關：
《Web標准實戰》 比較簡單，適合入門
《Web標准設計》
《深入淺出HTML》
CSS相關
《CSS設計徹底研究》 視頻教程很好，書本我並沒有詳細研究，不好說建議。
《CSS網站布局實錄》 CSS的書我看得比較少，這本算是看得比較全了，聽說第二版不錯。
javascript相關：
《精通JavaScript》 第三部分非常好
《JAVASCRIPT語言精髓與編程實踐》 這本書對原型和繼承做了非常精闢的解釋，網上大部分關於原型的文章都是參考此書的。
《悟透javascript》 這本書第一章是介紹原型和繼承的，第三章也介紹了跨域的一個解決方法，還有就是作者對程序和人生的理解哲學很有深度。
《JavaScript權威指南》 這本書就不用說了
《高性能網站建設指南 》 這類書有兩本不同版本，都是關於web性能優化的
《JavaScript語言精粹》 進階的好書
《JavaScript設計模式 》 進階的好書
SEO;
《SEO教程：搜索引擎優化入門與進階》 這本書有些地方我認為說得不大確切，但是總體還不錯。
G. 第五章：Web伺服器
5.1各種形狀和尺寸的Web伺服器
Web伺服器會對HTTP請求進行處理並提供響應。術語「Web伺服器」可以用來表示Web伺服器的軟體，也可以用來表示提供Web頁面的特定設備或計算機。
Web伺服器有著不同的風格、形狀和尺寸。有普通的10行Perl腳本的Web伺服器、50MB的安全商用引擎以及極小的卡上伺服器。但不管功能有何差異，所有的 Web伺服器都能夠接收請求資源的 HTTP請求，將內容回送給客戶端（參見圖1-5)。
5.1.1Web伺服器的實現
Web伺服器實現了HTTP和相關的TCP連接處理。負責管理Web伺服器提供的資源,以及對Web伺服器的配置、控制及擴展方面的管理。
Web伺服器邏輯實現了HTTP 協議、管理著Web資源，並負責提供Web伺服器的管理功能。Web伺服器邏輯和操作系統共同負責管理TCP連接。底層操作系統負責管理底層計算機系統的硬體細節，並提供了TCP/IP網路支持、負責裝載Web資源的文件系統以及控制當前計算活動的進程管理功能。
5.3實際的Web伺服器會做些什麼
例5-1顯示的 Perl伺服器是一個Web伺服器的小例子。最先進的商用Web伺服器要比它復雜得多，但它們確實執行了幾項同樣的任務，如圖5-3所示。
(1)建立連接一—接受一個客戶端連接，或者如果不希望與這個客戶端建立連接，就
將其關閉。
(2)接收請求——從網路中讀取一條HTTP請求報文。(3)處理請求——對請求報文進行解釋，並採取行動。(4)訪問資源-———訪問報文中指定的資源。
(5)構建響應——創建帶有正確首部的 HTTP響應報文。(6)發送響應——將響應回送給客戶端。
(7)記錄事務處理過程—-將與已完成事務有關的內容記錄在一個日誌文件中。
5.4第一步——接受客戶端連接
如果客戶端已經打開了一條到伺服器的持久連接，可以使用那條連接來發送它的請求。否則，客戶端需要打開一條新的到伺服器的連接（回顧第4章，復習一下HTTP的連接管理技術)。
5.4.1處理新連接
客戶端請求一條到Web伺服器的TCP連接時，Web伺服器會建立連接，判斷連接的另一端是哪個客戶端，從TCP連接中將IP地址解析出來。'一旦新連接建立起來
並被接受，伺服器就會將新連接添加到其現存Web伺服器連接列表中，做好監視連接上數據傳輸的准備。
Web伺服器可以隨意拒絕或立即關閉任意一條連接。有些Web伺服器會因為客戶端IP地址或主機名是未認證的，或者因為它是已知的惡意客戶端而關閉連接。Web伺服器也可以使用其他識別技術。
5.4.2客戶端主機名識別
可以用「反向 DNS」對大部分Web伺服器進行配置，以便將客戶端IP地址轉換成客戶端主機名。Web伺服器可以將客戶端主機名用於詳細的訪問控制和日誌記錄。但要注意的是，主機名查找可能會花費很長時間，這樣會降低Web事務處理的速度。很多大容量Web伺服器要麼會禁止主機名解析，要麼只允許對特定內容進行解析。
可以用配置指令HostnameLookups啟用Apache的主機查找功能。比如，例5-2中的Apache配置指令就只打開了HTML和CGI資源的主機名解析功能。
例5-2配置Apache,為 HTML和CGI資源查找主機名
HostnameLookups off
<Files ~" - 《html |htmlcgi)$">
HostnameLookups on
</Files>
5.5第二步—接收請求報文
連接上有數據到達時，Web伺服器會從網路連接中讀取數據，並將請求報文中的內容解析出來（參見圖5-5)。
解析請求報文時，Web伺服器會:
·解析請求行，查找請求方法、指定的資源標識符（URI)以及版本號，3各項之
間由一個空格分隔，並以一個回車換行(CRLF)序列作為行的結束,「
·讀取以CRLF結尾的報文首部;
檢測到以CRLF結尾的、標識首部結束的空行（如果有的話)﹔
·如果有的話（長度由content-Length首部指定)，讀取請求主體。
解析請求報文時，Web伺服器會不定期地從網路上接收輸入數據。網路連接可能隨時都會出現延遲。Web伺服器需要從網路中讀取數據，將部分報文數據臨時存儲在內存中,直到收到足以進行解析的數據並理解其意義為止。
5.5.1 報文的內部表示法
有些Web伺服器還會用便於進行報文操作的內部數據結構來存儲請求報文。比如，數據結構中可能包含有指向請求報文中各個片段的指針及其長度，這樣就可以將這些首部存放在一個快速查詢表中，以便快速訪問特定首部的具體值了（參見圖5-6)。
5.5.2連接的輸入/輸出處理結構
高性能的 Web伺服器能夠同時支持數千條連接。這些連接使得伺服器可以與世界各地的客戶端進行通信，每個客戶端都向伺服器打開了一條或多條連接。某些連接可能在快速地向Web伺服器發送請求，而其他一些連接則可能在慢慢發送，或者不經常發送請求,還有一些可能是空閑的，安靜地等待著將來可能出現的動作。
因為請求可能會在任意時刻到達，所以Web伺服器會不停地觀察有無新的Web請求。不同的Web伺服器結構會以不同的方式為請求服務，如圖5-7所示。
·單線程Web伺服器(參見圖5-7a)
單線程的Web伺服器一次只處理一個請求，直到其完成為止。一個事務處理結束之後，才去處理下一條連接。這種結構易於實現，但在處理過程中，所有其他連接都會被忽略。這樣會造成嚴重的性能問題，只適用於低負荷的伺服器，以及type-o-serve這樣的診斷工具。
·多進程及多線程Web伺服器(參見圖5-7b)
多進程和多線程Web伺服器用多個進程,或更高效的線程同時對請求進行處理。3可以根據需要創建，或者預先創建一些線程/進程。°有些伺服器會為每條連接分配一個線程/進程，但當伺服器同時要處理成百、上千，甚至數以萬計的連接時，需要的進程或線程數量可能會消耗太多的內存或系統資源。因此，很多多線程Web伺服器都會對線程/進程的最大數量進行限制。
·復用I/O的伺服器(參見圖5-7c)
為了支持大量的連接，很多Web伺服器都採用了復用結構。在復用結構中，要同時監視所有連接上的活動。當連接的狀態發生變化時（比如，有數據可用，或出現錯誤時)，就對那條連接進行少量的處理，處理結束之後，將連接返回到開放連接列表中，等待下一次狀態變化。只有在有事情可做時才會對連接進行處理,在空閑連接上等待的時候並不會綁定線程和進程。
·復用的多線程Web伺服器（參見圖5-7d)
有些系統會將多線程和復用功能結合在一起，以利用計算機平台上的多個CPU.多個線程（通常是一個物理處理器）中的每一個都在觀察打開的連接(或打開的連接中的一個子集)，並對每條連接執行少量的任務。
5.6第三步———處理請求
一旦Web伺服器收到了請求，就可以根據方法、資源、首部和可選的主體部分來對請求進行處理了。
有些方法（比如POST)要求請求報文中必須帶有實體主體部分的數據。其他一些方法（比如OPTIONS）允許有請求的主體部分，也允許沒有。少數方法（比如GET)禁止在請求報文中包含實體的主體數據。
這里我們並不對請求的具體處理方式進行討論，因為本書其餘大多數章節都在討論這個問題。
5.7第四步——-對資源的映射及訪問
Web 伺服器是資源伺服器。它們負責發送預先創建好的內容，比如HTML頁面或JPEG 圖片，以及運行在伺服器上的資源生成程序所產生的動態內容。
5.7.1 docroot
Web伺服器支持各種不同類型的資源映射，但最簡單的資源映射形式就是用請求URI作為名字來訪問Web伺服器文件系統中的文件。通常，Web伺服器的文件系統中會有一個特殊的文件夾專門用於存放Web內容。這個文件夾被稱為文檔的根目錄(document root，或docroot)。Web伺服器從請求報文中獲取URI，並將其附加在文檔根目錄的後面。
在圖5-8中，有一條對/specials/saw-blade.gif 的請求到達。這個例子中Web伺服器的文檔根目錄為/us/local/httpd/files。Web伺服器會返迴文件/usr/local/httpd/files/specials/saw-blade.gif。
在配置文件httpd.conf中添加一個 DocumentRoot行就可以為Apache Web伺服器設置文檔的根目錄了:
DocumentRoot /usr/ local/httpd/files
伺服器要注意，不能讓相對URL退到docroot之外，將文件系統的其餘部分暴露出來。比如，大多數成熟的Web伺服器都不允許這樣的URI看到Joe的五金商店文檔根目錄上一級的文件:
http://www.joes-hardware.com/ ..
5.8.3重定向
Web伺服器有時會返回重定向響應而不是成功的報文。Web伺服器可以將瀏覽器重定向到其他地方來執行請求。重定向響應由返回碼3XX說明。Location響應首部包含了內容的新地址或優選地址的URI。重定向可用於下列情況。
·永久刪除的資源
資源可能已經被移動到了新的位置，或者被重新命名，有了一個新的URL。Web伺服器可以告訴客戶端資源已經被重命名了，這樣客戶端就可以在從新地址獲取資源之前，更新書簽之類的信息了。狀態碼301 Moved Permanently就用於此類重定向。·臨時刪除的資源
如果資源被臨時移走或重命名了，伺服器可能希望將客戶端重定向到新的位置上去。但由於重命名是臨時的，所以伺服器希望客戶端將來還可以回頭去使用老的URL，不要對書簽進行更新。狀態碼303 See Other以及狀態碼307 TemporaryRedirect就用於此類重定向。