前端學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主機託管服務。這稱爲共享主機託管或虛擬主機託管。每一個網站看起來是託管在不一樣的服務器上，但其實是託管在同一個物理服務器上。從最終用戶的角度來看，被虛擬託管的網站應當和託管在專用服務器上的網站沒什麼區別

　　從成本效益、空間以及管理方面考慮，提供虛擬主機託管的公司但願能在同一個服務器上託管數10、上百，甚至上千個網站——但這不必定意味着上千個網站是用一臺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種技術

　　一、經過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來進行虛擬主機託管是一個糟糕的解決方案，不多會用到

　　二、經過端口號進行主機託管

　　除了修改路徑名，還能夠在Web服務器上爲Joe和Mary的網站分配不一樣的端口號。再也不使用端口 80，而是採用其餘端口號，例如，Joe用82，Mary用83。但這個解決方案也有一樣的問題：終端用戶不會樂意在URL中指定非標準的端口號

　　三、經過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的主機託管存在消耗地址的問題，但它仍然獲得了普遍的運用

　　四、經過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請求判斷其所請求的資源時使用下列規則

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

　　二、若是HTTP請求報文中的URL沒有主機部分，而該請求帶有Host首部，則主機/端口的值就從Host首部中取

　　三、若是經過第(1)步或第(2)步都沒法得到有效的主機，就向客戶端返回400 Bad Request 響應

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

 

網站運做

　　在下面列出的這些時間段內，網站一般是沒法運做的：服務器宕機的時候；交通擁堵：忽然間不少人都要看某個特別的新聞廣播或涌向某個大甩賣網店。忽然的擁堵可使Web服務器過載，下降其響應速度，甚至使它完全停機；網絡中斷或掉線

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

【鏡像的服務器集羣】

　　服務器集羣是一排配置相同的Web服務器，互相能夠替換。每一個服務器上的內容能夠經過鏡像複製，這樣當某個服務器出問題的時候，其餘的能夠頂上

　　鏡像的服務器經常組成層次化的關係。某個服務器可能充當「內容權威」——它含有原始內容(可能就是內容做者上傳的那個服務器)。這個服務器稱爲主原始服務器(master origin server)。從主原始服務器接收內容的鏡像服務器稱爲複製原始服務器(replica origin server)。一種簡單的部署服務器集羣的方法是用網絡交換機把請求分發給服務器。託管在服務器上的每一個網站的IP地址就設置爲交換機的IP地址

　　下圖顯示的鏡像服務器集羣中，主原始服務器負責把內容發送給複製原始服務器。對集羣外部來講，內容所在的IP地址就是交換機的IP地址。交換機負責把請求發送到服務器上去

　　鏡像Web服務器能夠在不一樣的地點包含一樣內容的副本。下圖展現了4個鏡像服務器，其中主服務器在芝加哥，複製服務器在紐約，邁阿密和小石城。主服務器爲芝加哥地區的客戶端服務，並肩負把內容傳播給複製服務器的任務

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

　　一、HTTP重定向

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

　　二、DNS重定向

　　該內容的URL會解析到4個IP地址，DNS服務器能夠選擇發送給客戶端的IP地址

【內容分發網絡(CDN)】

　　簡單地說，內容分發網絡(CDN)就是對特定內容進行分發的專門網絡。這個網絡中的節點能夠是Web服務器、反向代理或緩存

　　一、CDN中的反向代理緩存

　　複製原始服務器能夠用反向代理(也稱爲替代物)緩存來代替。反向代理緩存能夠像鏡像服務器同樣接受服務器請求。它們表明原始服務器中的一個特定集合來接收服務器請求。根據內容所在的IP地址的廣告方式，原始服務器和反向代理緩存之間一般有協做關係，到特定的原始服務器的請求就由反向代理緩存來接收

　　反向代理和鏡像服務器之間的區別在於反向代理一般是需求驅動的。它們不會保存原始服務器的所有內容副本，它們只保存客戶端請求的那部份內容。內容在其髙速緩存中的分佈狀況取決於它們收到的請求，原始服務器不負責更新它們的內容。爲了更容易地訪問「熱點」內容(就是高請求率的內容)，有些反向代理具備「預取」特性，能夠在用戶請求以前就從服務器上載入內容

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

　　二、CDN中的代理緩存

　　與反向代理不一樣，傳統的代理緩存能收到發往任何Web服務器的請求。在代理緩存與原始服務器之間不須要有任何工做關係或IP地址約定。可是與反向代理比起來，代理緩存的內容通常都是按需驅動的，不能期望它是對原始服務器內容的精確複製。某些代理緩存也能夠預先載入熱點內容

　　按需驅動的代理緩存能夠部署在其餘環境中——尤爲是攔截環境，在這種狀況下，2層或3層設備(交換機或路由器)會攔截Web流量並將其發送給代理緩存

　　攔截環境依賴於在客戶端和服務器之間設置網絡的能力。這樣，全部合適的HTTP請求才能真正發送到緩存中去。根據收到的請求，將內容分佈在緩存中

【加速訪問】

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

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