今天主要總結的是Web服務器與代理。
先從Web服務器開始。
Web服務器是如何實現的？
Web服務器實現了HTTP和相關的TCP連接處理。負責管理Web服務器提供的資源，以及對Web服務器的配置、控制及擴展方面的管理。
Web服務器邏輯實現了HTTP協議，管理者Web資源，並負責提供Web服務器的管理功能。Web服務器邏輯和操作系統共同負責管理TCP連接。底層操作系統負責管理底層計算機的硬件細節，並提供TCP/IP網絡支持，負載裝載Web資源的文件系統以及控制當前計算活動的進程管理功能。
那麼實際中Web服務器會做些什麼呢？
1.建立連接——接受一個客戶端的連接，或者如果不希望與這個客戶端建立連接，就將其關閉。
2.接收請求——從網絡中讀取一條HTTP請求報文
3.處理請求——對請求報文進行解釋，並採取行動
4.訪問資源——訪問報文中指定的資源
5.構建響應——創建帶有正確首部的HTTP響應報文
6.發送響應——將響應回送給客戶端
7.記錄事務處理過程——將與已完成事務有關的內容記錄在一個日誌文件中。
下面進行各個步驟的詳細講解：
第一步：接收客戶端連接。如果客戶端已經打開了一條到服務器的持久連接，可以使用那條連接來發送它的請求。否則，客戶端需要打開一條新的到服務器的連接。
如何處理新連接？
客戶端請求一條到Web服務器的TCP連接時，Web服務器會建立連接，判斷連接的另一端是哪個客戶端，從TCP連接中將IP解析出來。一旦新連接建立起來並被接受，服務器就會將新連接添加到其現存Web服務器連接列表中，做好監視連接上數據傳輸的準備。
Web服務器可以隨意拒絕或立即關閉任意一條連接。有些Web服務器會因爲客戶端IP地址或主機名是未認證的，或者因爲它是已知的惡意客戶端而關閉連接。
客戶端主機名識別可以通過：1.反向DNS解析 2.通過ident協議確定客戶端用戶
第二步：接收請求報文。連接上有數據到達時，Web服務器會從網絡連接中讀取數據，並將請求報文中的內容解析出來。
解析請求報文時，Web服務器會：
1.解析請求行，查找請求方法，指定的資源標識符（URI）以及版本號，各項之間由一個空格分隔，並以一個回車換行（CRLF）序列作爲行的結束。
2.讀取以CRLF結尾的報文首部
3.檢測到以CRLF結尾的、標識首部結束的空行（如果有的話）
4.如果有的話（長度由Content-Length首部指定），讀取請求主體
解析請求報文時，Web服務器會不定期地從網絡上接收輸入數據。網絡連接可能隨時都會出現延遲，Web服務器需要從網絡中讀取數據，將部分報文數據臨時存儲在內存中，知道收到足以進行解析的數據並理解其意義。
高性能的Web服務器能夠同時支持數千條連接。每個客戶端都向服務器打開了一條或多條連接。下面列舉不同的Web服務器結構：
1.單線程Web服務器：一次只處理一個請求，直到其完成爲止。一個事務處理結束之後，纔去處理下一條連接，這種結構易於實現，但在處理過程中，所有其他的連接都會被忽略，這樣會造成嚴重的性能問題，只適用於低負荷的服務器。
2.多進程及多線程Web服務器：用多個進程，或更高效的線程同時對請求進行處理，但當服務器同時要處理成百上千，甚至數以萬計的連接時，需要的進程或線程數量可能會消耗太多的內存或系統資源。因此很多多線程Web服務器都會對線程/進程最大數量進行限制。
3.複用I/O的服務器：爲了支持大量的連接，很多Web服務器都採用了複用結構。在複用結構中，要同時監視所有連接上的活動。當連接的狀態發生變化時（比如有數據可用，或出現錯誤時），就對那條連接進行少量的處理，處理結束之後，將連接返回到開放連接列表中，等待下一次狀態變化。只有在有事情可做時纔會對連接進行處理，在空閒連接上等待的時候並不會綁定線程和進程。
4.複用的多線程Web服務器：將多線程和複用功能結合在一起，以利用計算機平臺上的多個CPU
第三步：處理請求。一旦服務器收到了請求，就可以根據方法、資源、首部和可選的主體部分來對請求進行處理。
第四步：對資源的映射及訪問。在Web服務器將內容傳送給客戶端之前，要將請求報文中的URI映射爲Web服務器上適當的內容或內容生成器，以識別出內容的源頭。
Web服務器支持各種不同類型的資源映射，但最簡單的資源映射形式就是用請求URI作爲名字來訪問Web服務器文件系統中的文件。Web服務器的文件系統中會有一個特殊的文件夾專門用於存放Web內容，這個文件夾被稱爲文檔的根目錄（docroot）。
當有一個/specials/saw-blade.gif的請求到達。服務器的根目錄爲/usr/local/httpd/files。Web服務器會返回文件/usr/local/httpd/files/specials/saw-blade.gif
服務器要注意，不能讓相對URL退到docroot之外，將文件系統的其餘部分暴露出來。比如查詢../。
下面講述虛擬託管的docroot。
虛擬託管的Web服務器會在同一臺Web服務器上提供多個Web站點，每個站點在服務器上都有自己獨有的文檔根目錄。虛擬託管Web服務器會根據URI或HOST首部的IP地址或主機名來識別要使用的正確文檔根目錄。
對常見的Apache Web服務器來說，需要爲每個虛擬Web站點配置一個VirtualHost塊，而且每個虛擬服務器都要包含DocumentRoot
docroot的另一種常見應用是在Web服務器上爲人們提供私有的Web站點。通常會把那些以斜槓和波浪號（/~）開始，後面跟着用戶名的URI映射爲此用戶的私有文檔根目錄。私有docroot通常都是用戶主目錄下那個名爲public_html的目錄，但也可以重新配置
Web服務器中的目錄列表：
Web服務器可以接受對目錄URL的請求，其路徑可以解析爲一個目錄，而不是文件。我們可以對大多數Web服務器進行配置，使其在客戶端請求目錄URL時採取不同的動作
1.返回一個錯誤
2.不返回目錄，返回一個特殊的默認“索引文件”
3.掃描目錄，返回一個包含目錄內容的HTML頁面
在Apache Web服務器上，可以用配置指令DirectoryIndex會按照優先順序列出所有可以作爲目錄索引文件使用的文件名，如：
DirectoryIndex index.html index.htm home.html home.htm index.cgi
如果用戶請求目錄URI時，沒有提供默認的索引文件，而且沒有禁止使用目錄索引，很多Web服務器都會自動返回一個HTML文件，此文件中會列出那個目錄裏的文件名，以及每個文件的大小和修改日期，還包括到每個文件的URI鏈接。可以通過以下Apache指令禁止自動生成目錄索引：
Options-Indexes
動態內容資源的映射：
Web服務器還可以將URI映射爲動態資源，Web服務器要能夠分辨出資源什麼時候是動態，動態內容生成程序位於何處，以及如何運行那個程序。
Apache允許用戶將URI路徑名組件映射爲可執行文件目錄。服務器收到一條帶有可執行路徑組件的對URI的請求時，會試着執行相應服務器目錄中的程序。例如，Apache配置指令就表明所有路徑以/cgi-bin/開頭的URI都應該執行在目錄/usr/local/etc/httpd/cgi-programs/中找到相應文件：
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-programs
Web服務器還可以爲特定資源進行訪問控制，有請求到達，要訪問受控資源時，Web服務器可以根據客戶端的IP地址進行訪問控制，也可以要求輸入密碼來訪問資源。
第五步：構建響應。一旦Web服務器識別出了資源，就執行請求方法中描述的動作，並返回響應報文。響應報文中包含有響應狀態碼、響應首部，如果生成了響應主體的話，還包括響應主體。
其中響應實體通常包括：
1.描述了響應主體MIME類型的Content-Type首部
2.描述了響應主體長度的Content-Length首部
3.實際報文的主體內容
Web服務器要負責確定響應主體的MIME類型，Web服務器可以用文件的擴展名來說明MIME類型。
有魔法分類:Apache Web服務器可以掃描每個資源的內容，並將其與一個已知模式表（被稱爲魔法文件）進行匹配，以決定每個文件的MIME類型，這樣做可能比較慢，但很方便，尤其是文件沒有標準擴展名的時候
顯示分類：可以對Web服務器進行配置，使其不考慮問價你的擴展名或內容，強制特定文件或目錄內容擁有某個MIME類型。
類型協商：有些Web服務器經過配置，可以以多種文檔格式來存儲資源。可以配置Web服務器，使其可以通過與用戶的協商來決定使用哪種格式。
Web服務器也可能返回重定向響應。重定向用於下列情況：
1.永久刪除的資源
2.臨時刪除的資源
3.URL增強
4.負載均衡
5.服務器關聯
6.規範目錄名稱
第六步：發送響應。Web服務器通過發送數據時也會面臨與接收數據一樣的問題。服務器可能有很多條到各個客戶端的連接。服務器要記錄連接的狀態，還要特別注意對持久連接的處理，連接可能仍保持打開狀態，要正確地計算Content-Length首部，不然客戶端就無法知道響應什麼時候結束了
第七部：記錄日誌。當事務結束時，Web服務器會在日誌文件中添加一個條目，來描述已執行的事務。
下面來介紹代理！
代理與網關的對比？
嚴格來說，代理連接的是兩個或多個使用相同協議的應用程序，而網關連接的則是兩個或多個使用不同協議的端點。
但實際上，代理和網關之間的區別很模糊。由於瀏覽器和服務器實現的是不同版本的HTTP，代理也經常要做一些協議轉換工作。而商業化的代理服務器也會實現網關的功能來支持SSL安全協議，SOCKS防火牆，FTP訪問，以及基於Web的應用程序。
那麼爲什麼使用代理？
代理服務器可以改善安全性，提高性能，節省費用。代理服務器可以看到並接觸到所有流過的HTTP流量，所以代理可以監視流量並對其進行修改，以實現很多增值Web服務。如：
1.兒童過濾器：可以利用過濾器來阻止學生訪問成人內容
2.文檔訪問控制：可以用代理服務器在大量Web服務器和Web資源之間實現統一的訪問控制策略，創建審覈跟蹤機制。如：
集中式訪問控制代理：
（1）.允許客戶端1無限制地訪問服務器A的新聞頁面
（2）.客戶端2可以無限制地訪問因特網
（3）.在允許客戶端3訪問服務器B之前，要求其輸入口令
3.安全防火牆：網絡安全工程師通常會使用代理服務器來提高安全性。代理服務器會在網絡中的單一安全節點上限制哪些應用層協議的數據可以流入或流出一個組織。還可以提供用來消除病毒的掛鉤程序。
4.Web緩存：代理緩存維護了常用文檔的本地副本，並將它們按需提供，以減少緩慢且昂貴的因特網通信。
5.反向代理：代理可以假扮Web服務器，接收發給Web服務器的真實請求，發起與其他服務器的通信，以便按需定位所請求的內容。
6.內容路由器：可以根據因特網流量狀況以及內容類型將請求導向特定的Web服務器
7.轉碼器：代理服務器在將內容發送給客戶端之前，可以修改內容的主體格式，轉碼代理可以再傳輸GIF圖片時，將其轉換成JPEG圖片，以減少尺寸等等。
8.匿名者：匿名者代理會主動從HTTP報文中刪除身份特性（比如客戶端IP地址、From首部、Referer首部、cookie、URI的會話ID），從而提高高度的私密性和匿名性。
代理會去往何處?
部署代理服務器的幾種方式：
1.出口代理：可以將代理固定在本地網絡的出口點，以便控制本地網絡與大型因特網之間的流向。可以在公司網絡中使用出口代理，提供針對公司外部惡意黑客的防火牆保護，或降低帶寬費用，提高因特網流量的性能。
2.訪問（入口）代理：代理長飛放在ISP（互聯網服務提供商）訪問點上，用以處理來自客戶的聚合請求。ISP使用緩存代理來存儲常用文檔的副本，以提高用戶（尤其是高速連接用戶）的下載速度，降低因特網帶寬耗費
3.反向代理：通常會被部署在網絡邊緣，在Web服務器之前。在那裏它們可以處理所有傳送給Web服務器的請求，並只在必要時向Web服務器請求資源。替代物可以提高Web服務器的安全特性，或者將快速的Web服務器緩存放在較慢的服務器之前，以提高性能。方向代理通常會直接毛用Web服務器的名字和IP地址，這樣所有的請求就會被髮送給代理而不是服務器了。
4.網絡交換代理：可以將具有足夠處理能力的代理放在網絡之間的因特網對等交換點上，通過緩存來減輕因特網節點的擁塞，並對流量進行監視。
代理的層次結構？
可以通過代理層次結構將代理級聯起來。如：
會將報文從一個代理傳給另一個代理，直到最終抵達原始服務器爲止。
Proxy層次結構中代理服務器被賦予了父和子的關係。靠近服務器被稱爲父代理，靠近客戶端被稱爲子代理。
代理層次結構不一定非得是靜態的。如：
如果所請求的對象屬於一個付費使用內容分發服務的Web服務器，代理就會將請求發送給附近的一個緩存服務器，這個服務器會返回已返回已緩存對象，或者如果它那沒有的話，它會去取回內容。
如果請求的是特定類型的圖片，訪問代理會將請求轉發給一個特定的壓縮代理，這個代理會去獲取圖片，然後對其進行壓縮，這樣通過客戶端的慢速Modem下載時，速度會更快一些。
還有幾個動態選擇父代理的列子：
1.負載均衡：子代理可能會根據當前父代理上的工作負載級別來決定如何選擇一個父代理，以均衡負載
2.地理位置附近的路由：子代理可能會選擇負責原始服務器所在物理區域的父代理
3.協議/類型路由：子代理可能會根據URI將報文轉發到不同的父代理和原始服務器上去。某些特定類型的URI可能要通過一些特殊的代理服務器轉發請求，以便進行特殊的協議處理。
4.基於訂購的路由：如果發佈者爲高性能服務額外付費了，它們的URI就會被轉發到大型緩存或壓縮引擎上去，以提高性能。
代理是如何獲取流量的？
有四種常見方式可以使客戶端流量流向代理：
1.修改客戶端：很多Web客戶端都支持手工和自動的代理配置。如果將客戶端配置爲使用代理服務器，客戶端就會將HTTP請求有意地直接發送給代理，而不是原始服務器。
2.修改網絡：網絡基礎設施可以通過若干種計數手段，在客戶端不知道，或沒有參與的情況下，攔截網絡流量並將其導入代理。這種攔截通常都依賴於監視HTTP流量的交換設備及路由設備，在客戶端毫不知情的情況下，對其進行攔截，並將流量導入一個代理。這種代理被稱爲攔截代理。
3.修改DNS的命名空間：放在Web服務器之前的代理服務器——替代物，會直接假扮Web服務器的名字和IP地址，這樣，所有的請求就會發送給這些替代物，而不是服務器了。要實現這一點，可以手工編輯DNS名稱列表，或者用特殊的動態DNS服務器根據需要來確定適當的代理或服務器。有時在安裝過程中，真實服務器的IP地址和名稱被修改了，替代物得到的會是之前的地址和名稱。
4.修改Web服務器：也可以將某些服務器配置爲向客戶端發送一條HTTP重定向命令，將客戶端請求重定向到一個代理上去。收到重定向命令後，客戶端會與代理進行通信。
客戶端的代理設置？
很多瀏覽器都提供了多種配置代理的方式，包括：
1.手工配置：顯式地設置要使用的代理
2.預先配置瀏覽器：瀏覽器廠商或發行商會在瀏覽器發送給其客戶之前預先對瀏覽器的代理設置進行手工設置
3.代理的自動配置：提供一個URI，指向一個用JavaScript語言編寫的代理自動配置文件；客戶端會取回這個JavaScript文件，並運行它以決定是否應該使用一個代理，如果是的話，應該使用哪個代理
4.WPAD的代理髮現：有些瀏覽器支持Web代理自動發現協議（WPAD），這個協議會自動檢測出瀏覽器可以從哪個“配置服務器”下載到一個自動配置文件
與代理請求有關的一些棘手問題？
代理URI和服務器URI的不同？
客戶端向Web服務器發送請求時，請求行中只包含部分URI（沒有方案、主機或端口）如：
GET /index.html HTTP/1.0
但當客戶端向代理髮送請求時，請求行中則包含完整的URI。如：
GET http://www.marys-antiques.com/index.html HTTP/1.0
爲什麼會有兩種不同的請求格式，一種用於代理，另一種用於服務器？在原始的HTTP設計中，客戶端會直接與單個服務器進行對話。不存在虛擬機，也沒有爲代理制定什麼規則。單個的服務器都知道自己的主機名和端口。所以爲了避免發送冗餘信息，客戶端只需發送部分URI即可，無需發送方案和主機以及端口。
代理出現之後，使用部分URI就有問題了。代理需要知道目標服務器的名稱，這樣它們才能建立自己與服務器的連接。基於代理的網關要知道URI的方案才能連接到FTP資源和其他方案上去。HTTP/1.0要求代理請求發送完整的URI，解決了這個問題，但它爲服務器請求保留部分URI的形式（已經有相當多的服務器都改爲支持完整URI）
因此，我們要將部分URI發送給服務器，將完整的URI發送給代理。
與虛擬主機一樣的問題？
虛擬主機Web服務器會在很多Web站點間共享同一個物理Web服務器。包含部分URI的請求到達時，虛擬主機Web服務器需要知道目的Web站點的主機名。與上一個問題相似，但是解決方法不同：
1.顯式的代理要求在請求報文中使用完整的URI來解決這個問題
2.虛擬主機Web服務器要求使用Host首部來承載主機和端口信息。
攔截代理會收到部分URI？
客戶端並不總是知道它是在和代理對話，因爲有些代理對客戶端是不可見的。客戶端的流量可能會經過替代物或攔截代理，在這兩種情況下，客戶端都會認爲它在與Web服務器進行對話，不會發送完整的URI。如：
如前所述，反向代理是一個用來取代原始服務器的代理服務器，它通常會通過假扮服務器的主機名和IP地址來做到這一點。它會收到Web服務器請求，可能會向真正的服務器提供緩存的響應或者代理請求。客戶端無法區別反向代理和Web服務器，因此它會發送部分URI
攔截代理是網絡流量中的代理服務器，它會攔截從客戶端發往服務器的請求，並提供一個緩存響應，或對其進行轉發。由於攔截代理攔截了從客戶端到服務器的流量，所以它會收到發送給Web服務器的部分URI
代理既可以處理代理請求，也可以處理服務器請求？
由於將流量重定向到代理服務器的方式有所不同，通用的代理服務器既應該支持請求報文中的完整URI，也應該支持部分URI。規則如下：
1.如果提供的是完整的URI，代理就應該使用這個完整的URI
2.如果提供的是部分URI，而且有Host首部，就應該用Host首部來確定原始服務器的名字和端口號。
3.如果提供的是部分URI，而且沒有Host首部，有三種方法：
（1）如果代理是代表原始服務器的替代物，可以用真實服務器的地址和端口號來配置代理
（2）如果流量被攔截了，而且攔截者也可以提供原始的IP地址和端口，代理就可以用攔截技術提供的IP地址和端口號。
（3）如果所有方法都失敗了，代理沒有足夠的信息來確定原始服務器，就必須返回一條錯誤報文
轉發過程中對URI的修改？
代理服務器要在轉發報文時修改請求URI的話，需要特別小心，對URI的微小修改，甚至是看起來無害的修改，都可能給下游服務器帶來一些互操作性的問題。
URI的客戶端自動擴展和主機名解析？
根據是否有代理，瀏覽器對請求URI的解析會有所不同。沒有代理時，瀏覽器如果沒有找到主機，很多瀏覽器都會嘗試提供某種主機名自動“擴展”機制。
代理時URI的解析？
使用顯式代理時，用戶的URI會直接發送給代理，所以瀏覽器就不再執行所有便捷的擴展功能了。
有攔截代理時URI的解析？
使用不可見的攔截代理時，對主機名的解析會略有不同，因爲對客戶端來說，是沒有代理的，這是瀏覽器會自動擴展主機名，直到DNS成功爲止。
在第（1）步中，用戶瀏覽器的URI地址窗口輸入oreilly。
在第（2a）步中，瀏覽器通過DNS查找主機oreilly，但DNS服務器失敗了，並回送響應說明主機爲止，如第（2b）步所示
在第（3a）步中，瀏覽器進行自動擴展，將oreilly轉換成www.oreilly.com。在第（3b）步中，DNS解析成功,將IP地址返回給了瀏覽器
在第（4a）步中，客戶端已經成功解析了主機名，並有了一張IP地址列表。有些IP地址可能已經停用了。所以通常客戶端會嘗試着連接每個IP地址，直到成功爲止。但對攔截代理來說，第一次連接請求就會被代理服務器攔截成功，不會連接到原始服務器上去，客戶端認爲它與Web服務器進行成功的對話，但那個Web服務器可能甚至都不處於活躍狀態
在第（5b）步，代理與真正原始服務器進行交互時。可能會發現那個IP地址實際指向的是一個已停用的服務器，爲了提供與瀏覽器相同級別的容錯機制，代理可以通過解析Host首部的主機名，也可以通過對IP地址的方向DNS查找來嘗試其他IP地址。對攔截和顯式代理實現來說，在DNS解析到已經停用的服務器時，提供容錯機制很重要。
追蹤報文？
很多公司都會用緩存代理服務器來訪問因特網。
隨着代理的逐漸流行，我們要能夠追蹤經過代理的報文流，以檢測出各種問題，其重要性就跟追蹤經過不同交換機和路由器傳輸的IP分組流一樣。
Via首部？
Via首部字段列出了與報文途徑的每個中間節點（代理或網關）有關的信息。報文每經過一個節點，都必須將這個中間節點添加到Via列表的末尾。如：
說明第一個代理名proxy-62.irenes-isp.net實現了HTTP/1.1協議，另一個是實現了HTTP/1.0
代理也可以用Via首部來檢測網絡中的路由循環。代理應該在發送一條請求之前，在Via首部插入一個與其自身有關的獨特字符串，並在輸入的請求中查找這個字符串，已檢測網絡中是否存在路由循環。
每個Via路標中最多包含4個組件：一個可選的協議名（默認爲HTTP）、一個必選的協議版本，一個必選的節點名和一個可選的描述性註釋
Via與網關？
有些代理會爲使用非HTTP協議的服務器提供網關的功能。Via首部記錄了這些協議的轉換。這樣HTTP應用程序就會了解代理鏈上各點的協議處理能力以及所做的協議轉換了。
Via的隱私和安全問題？
有時候我們並不希望在Via字符串中使用確切的主機名。除非顯式地允許這種行爲，否則當代理服務器作爲網絡防火牆的一部分使用時，是不應該轉發防火牆後面那些主機名的名字和端口號的。
如果不允許進行Via節點名轉發，作爲安全防線的一部分使用的代理就應該用適當的假名來取代那臺主機的名字。一般來說，即使隱藏了真實名稱，代理也應該嘗試着爲每臺代理服務器保留一個Via路標條目。
Trace方法？
通過HTTP/1.1的Trace方法，用戶可以跟蹤經代理鏈傳輸的請求報文，觀察報文。Trace對代理流的調試非常有用。
其中有一個max-forwards首部來限制trace和options請求所經過的代理跳數。Max-Forwards請求首部字段包含了一個整數，如果值爲0，那麼即使接受者不是原始服務器，它也必須將Trace報文回送給客戶端，而不應該繼續轉發，如果收到的值大於0，轉發的報文中就必須包含一個更新了的Max-Forwards字段，其值會被減一。
代理認證？
代理可以作爲訪問控制設備使用。HTTP定義了一種名爲代理認證的機制，這種機制可以組織對內容的請求，直到用戶向代理提供了有效的訪問權限證書爲止。
步驟如下:
1.對受限內容的請求到達一臺代理服務器時，代理服務器可以返回一個要求使用訪問證書的407Proxy Authorization Required狀態碼
2.客戶端收到407響應時，會嘗試着從本地數據庫或通過提示用戶來蒐集所需要的證書
3.只要獲得了證書，客戶端就會重新發送請求，在Proxy-Authorization首部字段中提供所要求的證書。
4.如果證書有效，代理就會將原始請求沿着傳輸鏈路向下傳送，否則就發送另一條407應答。
若傳輸鏈路中有多個代理，且每個代理都要進行認證時，代理認證通常無法很好的工作。人們建議，應該對HTTP進行升級，將認證證書與代理鏈中特定的路標聯繫起來，但這些升級措施並沒有得到廣泛實現。