前端學HTTP之Web主機託管

前面的話

　　對內容資源的儲存、協調以及管理的職責統稱為Web主機託管。主機託管是Web伺服器的主要功能之一。儲存並提供內容，記錄對內容的訪問以及管理內容都離不開伺服器。如果不想自行管理伺服器所需的軟硬體，就需要主機託管服務，即託管者。本文將詳細介紹Web主機託管

主機託管

　　在全球資訊網的早期，每個組織自行購買自己的計算機硬體，搭建自己的計算機房，申請自己的網路連線，並管理自己的Web伺服器軟體。隨著Web迅速成為主流，每人都想要一個網站，但很少有人有能力或時間來搭建帶空調的伺服器機房，註冊域名，或購買網路頻寬。為了滿足人們的迫切需求，出現了很多新的企業，提供了專業化管理的Web主機託管服務。服務級別有多種，從物理上的裝置管理(提供空間、空調以及線纜)到完整的Web主機託管，顧客只需要提供內容就行了

　　下面主要探討託管Web伺服器要提供什麼服務。網站運作需要的很多東西(例如，它支援不同語言的能力和進行安全的電子商務交易的能力)都取決於託管Web伺服器提供的功能

　　假設Joe的五金商店和Mary的古董拍賣店都需要網站。Irene網路服務提供商那裡有很多機架，機架上全是一樣的高效能Web伺服器，可以租給Joe和Maiy，這樣，他倆就不用自行購買自己的伺服器並管理伺服器軟體了

　　在下圖中，Joe和Mary都簽約使用Irene的網路服務提供商提供的專用Web託 管服務。Joe租了專用的Web伺服器，該伺服器是Irene網路服務提供商購買和維護的。Mary也從Irene網路服務提供商那裡租了另一個專用伺服器。Irene網路服務提供商大批量地購買伺服器硬體，它們選擇的硬體經久耐用且相對便宜。如果Joe或Mary的網站變得更受歡迎，Irene網路服務提供商可以立刻給Joe或Mary提供更多的伺服器

　　在這個例子中，瀏覽器向Joe伺服器的IP地址傳送對www.joes-hardware.com的HTTP請求，向Mary伺服器(不同於Joe)的IP地址傳送對www.marys-antiques.com的請求

虛擬主機託管

　　許多人想要在Web上展現自己，但他們的網站流量都不大。對這些人來說，使用專用的Web伺服器可能有點兒大材小用，因為他們每月花費數百美元租來的伺服器大部分時間都是空閒的

　　許多Web託管者通過讓一些顧客共享一臺計算機來提供便宜的Web主機託管服務。這稱為共享主機託管或虛擬主機託管。每個網站看起來是託管在不同的伺服器上，但實際上是託管在同一個物理伺服器上。從終端使用者的角度來看，被虛擬託管的網站應當和託管在專用伺服器上的網站沒什麼區別

　　從成本效益、空間以及管理方面考慮，提供虛擬主機託管的公司希望能在同一個伺服器上託管數十、上百，甚至上千個網站——但這不一定意味著上千個網站是用一臺PC機來提供服務的。託管者可以建立成排同樣的伺服器，稱為伺服器叢集(server farm)，把負載分攤在群裡的伺服器上。因為群裡的每臺伺服器都一樣，並且託管了許多虛擬網站，所以管理起來更加方便

　　當Joe和Mary剛開始商務運作時，他們可能會選擇虛擬主機託管，以節省費用，直到他們網站的流量規模達到值得使用專用伺服器的水平為止

【主機資訊】

　　不幸的是，HTTP/1.0中的一個設計缺陷會使虛擬主機託管者抓狂。HTTP/1.0規範中沒有為共享的Web伺服器提供任何方法來識別要訪問的是哪一個託管的網站

　　回想一下，HTTP/1.0請求在報文中只傳送了URL的路徑部分。如果要訪問http://www.joes-hardware.com/index.html，瀏覽器會連線到伺服器www.joes-hardware.com，但HTTP/1.0請求中只提到GET/index.html，沒有提到主機名。如果伺服器虛擬託管了多個站點，就沒有足夠的資訊能指出要訪問的是哪個虛擬網站

　　如果客戶端A試圖訪問http://www.joes-hardware.com/index.html，請求GET/index.html將被髮送到共享的Web伺服器

　　如果客戶端B試圖訪問http://www.marys-antiques.com/index.html，同樣的請求GET/index.html也將被髮送到共享的Web伺服器

　　就Web伺服器而言，沒有足夠的資訊可供其判斷究竟要訪問的是哪個網站。儘管請求的是完全不同的文件(來自不同的網站)，但這兩個請求看起來是一樣的，這是因為網站的主機資訊已經從請求中剝離了

　　[注意]HTTP替代物(反向代理)和攔截代理也都需要明確的站點資訊

　　缺失的主機資訊是原始HTTP規範的疏忽，它錯誤地假設了每個Web伺服器上只託管了一個網站。HTTP的設計者沒有為進行虛擬主機託管的共享伺服器提供支援。正因為如此，URL中的主機名資訊被當作冗餘資訊剝離了，只要求傳送路徑部分

　　因為早期的規範沒有考慮到虛擬主機託管，Web託管者需要開發變通的方案和約定來支援共享的虛擬主機託管。這個問題本可以通過要求所有HTTP清求報文傳送完整的URL而不只是路徑部分來簡單地解決。而HTTP/1.1的確要求伺服器能夠處理HTTP報文請求行上的完整URL，但將現存的應用程式都升級到這個規範還需要很長時間。在此期間，湧現了以下4種技術

　　1、通過URL路徑進行虛擬主機託管

　　可以通過分配不同的URL路徑，用這種笨方法把共享伺服器上的虛擬站點隔離開。例如，可以給每個邏輯網站一個專門的路徑字首

　　Joe的五金商店可以是：http://www.joes-hardware.com/joe/index.html

　　Mary的古董拍賣店可以是：http://www.marys-antiques.com/mary/index.html

　　當請求到達伺服器時，其中並沒有主機名資訊，但伺服器可以通過路徑來區分它們

　　請求Joe的五金商店的網址是GET /joe/index.html

　　請求Mary的古董拍賣店的網址是GET /mary/index.html

　　這不是一個好辦法。/joe和/mary這樣的字首是多餘的(主機名中已經提到joe了)

　　更糟的是，描述主頁連結的常見約定：http://www.joes-hardware.com或http://www. joes-hardware.com/index.html 都不能用了

　　總之，按URL來進行虛擬主機託管是一個糟糕的解決方案，很少會用到

　　2、通過埠號進行主機託管

　　除了修改路徑名，還可以在Web伺服器上為Joe和Mary的網站分配不同的埠號。不再使用埠 80，而是採用其他埠號，例如，Joe用82，Mary用83。但這個解決方案也有同樣的問題：終端使用者不會樂意在URL中指定非標準的埠號

　　3、通過IP地址進行主機託管

　　為不同的虛擬站點分配專門的IP地址，把這些地址都繫結到一臺單獨的機器上。這樣，Web伺服器就可以通過IP地址來識別網站名了

　　一個更常用的、更好的方法是通過IP地址進行虛擬化。每個虛擬網站都分配一個或多個唯一的IP地址。所有虛擬網站的IP地址都繫結到同一個共享的伺服器上。伺服器可以查詢HTTP連線的目的IP地址，並以此來判斷客戶端的目標網站

　　比方說，託管者把IP地址209.172.34.3分配給www.joes-hardware.com，把IP地址209.172.34.4分配給www.marys-antiques.com，把這兩個IP地址都繫結到同一個物理伺服器上。Web伺服器就能使用目的IP地址來識別使用者請求的是哪個虛擬站點了

　　客戶端A獲取http://www.joes-hardware_com/index.html；客戶端A査詢www.joes-hardware.com的IP地址，得到209.172.34.3；客戶端A開啟到共享伺服器的TCP連線，目的地址是209.172.34.3；客戶端A傳送請求，內容為GET/index.html HTTP/1.0；在Web伺服器提供響應之前，它注意到實際的目的IP地址(209.172.34.3)，判斷出這是Joe的五金網站的虛擬IP地址，就根據子目錄/joe來完成請求。返回的是檔案/joe/index.html

　　類似地，如果客戶端B請求http://www.marys-antiques.com/index.html。客戶端B査詢www.marys-antiques.com的IP地址，得到209.172.34.4；客戶端B開啟到Web伺服器的TCP連線，目的地址是209.172.34.4；客戶端B傳送請求，內容是GET/index.html HTTP/1.O；Web伺服器判斷出209.172.34.4是Mary的網站，根據/mary目錄來完成請求，返問的是檔案/mary/index.html

　　對大的託管者來說，虛擬IP的主機託管能夠工作，但它會帶來一些麻煩

　　a、在計算機系統上能繫結的虛擬IP地址通常是有限制的。想在共享的伺服器上託管成百上千的虛擬站點的服務商不一定能實現願望

　　b、IP地址是稀缺資源。有很多虛擬站點的託管者不一定能為被託管的網站獲取足夠多的IP地址

　　c、託管者通過複製伺服器來增加容量時，IP地址短缺的問題就更嚴重了。隨負載均衡體系的不同，可能會要求每個複製的伺服器上有不同的虛擬IP地址，因此IP地址的需求量可能會隨複製伺服器的數量而倍增

　　儘管虛擬IP的主機託管存在消耗地址的問題，但它仍然得到了廣泛的運用

　　4、通過Host首部進行虛擬主機託管

　　為了避免過度的地址消耗和虛擬IP地址的限制，我們希望在虛擬站點間共享同一個IP地址，且仍能區分站點。但正如我們看到的那樣，因為大多數瀏覽器只是把URL的路徑發給伺服器，關鍵的虛擬主機名資訊被其丟掉了

　　為了解決這個問題，瀏覽器和伺服器的實現者擴充套件了HTTP，把原始的主機名提供給伺服器。不過，瀏覽器不能只傳送完整的URL，因為這會使許多隻能接收路徑的伺服器無法工作。替代的方法是，把主機名(和埠號)放在所有請求的Host擴充套件首部中傳送　　

　　下圖中，客戶端A和客戶端B都傳送了攜帶有要訪問的原始主機名的Host首部。當伺服器收到對/index.html的請求時，可以通過Host擴充套件首部來判斷要使用哪個資源

　　Host首部最早是在HTTP/1.0+中引入的，它是開發商實現的HTTP/1.0的擴充套件超集。遵循HTTP/1.1標準則必須支援Host首部。絕大多數現代瀏覽器和伺服器都支援Host首部，但仍有一些客戶端和伺服器(以及網路機器人)不支援它
 

Host首部

　　Host首部是HTTP/1.1的請求首部，定義在RFC 2068中。由於虛擬伺服器的流行，絕大多數HTTP客戶端(即使是不遵循HTTP/1.1的客戶端)，都實現了Host首部

　　Host首部描述了所請求的資源所在的因特網主機和埠號，和原始的URL中得到的一樣：

Host = "Host" ":" host [ ":" port ]

　　但要注意以下問題：如果Host首部不包含埠，就使用地址方案中預設的埠；如果URL中包含IP地址，Host首部就應當包含同樣的地址；如果URL中包含主機名，Host首部就必須包含同樣的名字；如果URL中包含主機名，Host首部就不應當包含URL中這個主機名對應的IP地址，因為這樣會擾亂虛擬主機託管伺服器的工作，它在同一個IP地址上堆疊了很多虛擬站點；如果URL中包含主機名，Host首部就不應當包含這個主機名的其他別名，因為這樣也會擾亂虛擬主機託管伺服器的工作；如果客戶端顯式地使用代理伺服器，客戶端就必須把原始伺服器，而不是代理伺服器的名字和埠放在Host首部中。以往，若干個Web客戶端在啟用客戶端代理設定時，錯誤地把發出的Host首部設定成代理的主機名。這種錯誤行為會使代理和原始伺服器都無法正常處理請求；Web客戶端必須在所有請求報文中包含Host首部；Web代理必須在轉發請求報文之前，新增Host首部；HTTP/1.1的Web伺服器必須用400狀態碼來響應所有缺少Host首部欄位的HTTP/1.1請求報文

　　下面是一段簡單的HTTP請求報文，用於獲取www.joes-hardware.com的主頁，其中帶有必須的Host首部欄位

　　有少量在用的老式瀏覽器不會傳送Host首部。如果某個虛擬主機託管伺服器使用Host首部來判斷所服務的是哪個網站，而報文中沒有出現Host首部的話，那它可能會把使用者導向某個預設的Web頁面(例如網路服務提供商的Web頁面)，也可能返回一個錯誤頁面建議使用者升級瀏覽器

　　對於沒有進行虛擬主機託管，而且不允許資源隨請求主機的不同而變化的原始伺服器來說，可以忽略Host首部欄位的值。但資源會隨主機名的不同而變化的原始伺服器，都必須在一條HTTP/1.1請求判斷其所請求的資源時使用下列規則

　　1、如果HTTP請求報文中的URL是絕對的(也就是說，包含方案和主機部分)，就忽略Host首部的值

　　2、如果HTTP請求報文中的URL沒有主機部分，而該請求帶有Host首部，則主機/埠的值就從Host首部中取

　　3、如果通過第(1)步或第(2)步都無法獲得有效的主機，就向客戶端返回400 Bad Request 響應

　　某些版本的瀏覽器傳送的Host首部不正確，尤其是配置使用代理的時候。例如，配置使用代理時，一些老版本的Apple和PointCast客戶端會錯誤地把代理的名字，而不是原始伺服器的名字放在Host首部裡傳送

網站運作

　　在下面列出的這些時間段內，網站通常是無法運作的：伺服器當機的時候；交通擁堵：突然間很多人都要看某個特別的新聞廣播或湧向某個大甩賣網店。突然的擁堵可以使Web伺服器過載，降低其響應速度，甚至使它徹底停機；網路中斷或掉線

　　下面會展示一些預判和處理這些常見問題的方法

【映象的伺服器叢集】

　　伺服器叢集是一排配置相同的Web伺服器，互相可以替換。每個伺服器上的內容可以通過映象複製，這樣當某個伺服器出問題的時候，其他的可以頂上

　　映象的伺服器常常組成層次化的關係。某個伺服器可能充當“內容權威”——它含有原始內容(可能就是內容作者上傳的那個伺服器)。這個伺服器稱為主原始伺服器(master origin server)。從主原始伺服器接收內容的映象伺服器稱為複製原始伺服器(replica origin server)。一種簡單的部署伺服器叢集的方法是用網路交換機把請求分發給伺服器。託管在伺服器上的每個網站的IP地址就設定為交換機的IP地址

　　下圖顯示的映象伺服器叢集中，主原始伺服器負責把內容傳送給複製原始伺服器。對叢集外部來說，內容所在的IP地址就是交換機的IP地址。交換機負責把請求傳送到伺服器上去

　　映象Web伺服器可以在不同的地點包含同樣內容的副本。下圖展示了4個映象伺服器，其中主伺服器在芝加哥，複製伺服器在紐約，邁阿密和小石城。主伺服器為芝加哥地區的客戶端服務，並肩負把內容傳播給複製伺服器的任務

　　在上圖的場景中，有以下兩種方法把客戶端的請求導向特定的伺服器

　　1、HTTP重定向

　　該內容的URL會解析到主伺服器的IP地址，然後它會傳送重定向到複製伺服器

　　2、DNS重定向

　　該內容的URL會解析到4個IP地址，DNS伺服器可以選擇傳送給客戶端的IP地址

【內容分發網路(CDN)】

　　簡單地說，內容分發網路(CDN)就是對特定內容進行分發的專門網路。這個網路中的節點可以是Web伺服器、反向代理或快取

　　1、CDN中的反向代理快取

　　複製原始伺服器可以用反向代理(也稱為替代物)快取來代替。反向代理快取可以像映象伺服器一樣接受伺服器請求。它們代表原始伺服器中的一個特定集合來接收伺服器請求。根據內容所在的IP地址的廣告方式，原始伺服器和反向代理快取之間通常有協作關係，到特定的原始伺服器的請求就由反向代理快取來接收

　　反向代理和映象伺服器之間的區別在於反向代理通常是需求驅動的。它們不會儲存原始伺服器的全部內容副本，它們只儲存客戶端請求的那部分內容。內容在其髙速快取中的分佈情況取決於它們收到的請求，原始伺服器不負責更新它們的內容。為了更容易地訪問“熱點”內容(就是高請求率的內容)，有些反向代理具有“預取”特性，可以在使用者請求之前就從伺服器上載入內容

　　CDN中帶有反向代理時，可能會由於存在代理的層次關係而增加其複雜性

　　2、CDN中的代理快取

　　與反向代理不同，傳統的代理快取能收到發往任何Web伺服器的請求。在代理快取與原始伺服器之間不需要有任何工作關係或IP地址約定。但是與反向代理比起來，代理快取的內容一般都是按需驅動的，不能指望它是對原始伺服器內容的精確複製。某些代理快取也可以預先載入熱點內容

　　按需驅動的代理快取可以部署在其他環境中——尤其是攔截環境，在這種情況下，2層或3層裝置(交換機或路由器)會攔截Web流量並將其傳送給代理快取

　　攔截環境依賴於在客戶端和伺服器之間設定網路的能力。這樣，所有合適的HTTP請求才能真正傳送到快取中去。根據收到的請求，將內容分佈在快取中

【加速訪問】

　　上面提到的很多技術也能幫助網站更快地載入。伺服器叢集和分散式代理快取或反向代理伺服器分散了網路流量，可以避免擁塞。分發內容使之更靠近終端使用者，這樣從伺服器到客戶端的傳輸時間就更短了。請求和響應穿過因特網，在客戶端和伺服器間傳輸的方式是影響資源訪問速度最主要的因素

　　加速網站訪問的另一種方法是對內容進行編碼以便更快地傳輸。比如，對內容進行壓縮，但前提是接收的客戶端能夠把內容解壓縮