前言
??前面水了兩篇文章，下面開始介紹應(yīng)用層另一個非常重要的協(xié)議——HTTP協(xié)議。
1 萬維網(wǎng)
??萬維網(wǎng)WWW（World Wide Web）是一個大規(guī)模的、聯(lián)機式的信息儲藏所。是無數(shù)網(wǎng)絡(luò)站點的集合。
??萬維網(wǎng)以客戶服務(wù)器方式工作。客戶程序向服務(wù)器發(fā)出請求，服務(wù)器程序向客戶程序送回客戶所要的萬維網(wǎng)文檔。在一個客戶程序主窗口上顯示出的萬維網(wǎng)文檔稱為頁面（page）。
??要實現(xiàn)上面的過程，必須解決以下問題：
??(1) 怎么標(biāo)志分布在整個互聯(lián)網(wǎng)上的萬維網(wǎng)文檔——統(tǒng)一資源定位符URL。
??(2) 用什么樣的協(xié)議實現(xiàn)萬維網(wǎng)上的各種連接——超文本傳送協(xié)議HTTP。
??(3) 怎樣使不同風(fēng)格的萬維網(wǎng)文檔都能在互聯(lián)網(wǎng)上的主機上顯示——超文本標(biāo)記語言HTML。
2 URL && URI
??2.1 URL
??統(tǒng)一資源定位符URL（Uniform Resources Locator）用來表示資源在互聯(lián)網(wǎng)上的位置和訪問這些資源的方法，并使每一個資源在整個互聯(lián)網(wǎng)范圍內(nèi)具有唯一的標(biāo)識符URL。即URL實際上就是在互聯(lián)網(wǎng)上資源的地址。
??URL的一般形式
<協(xié)議>://<主機>:<端口>/<路徑>
??(1) 第一部分是最左邊的<協(xié)議>。這里的<協(xié)議>是指用什么協(xié)議來獲取該萬維網(wǎng)文檔?，F(xiàn)在最常用的就是http（超文本傳送協(xié)議HTTP），其次是ftp（文件傳送協(xié)議FTP）。
??(2) 第二部分是<主機>，它指出這個萬維網(wǎng)的文檔在哪臺主機上。<主機>就是指該主機在互連網(wǎng)上的域名，如www.baidu.com。
??(3) 后面的<端口>和<路徑>有時可以省略。HTTP的默認端口號是80，通常可省略。路徑有時也可以省略，表示訪問互聯(lián)網(wǎng)上的某個主頁。如訪問www.baidu.com和訪問www.baidu.com/idnex.html的效果是一樣的，都是訪問百度的首頁。
??2.2 URI
??統(tǒng)一資源標(biāo)識符URI（Uniform Recourses Identifier）就是由某個協(xié)議方案表示的資源定位標(biāo)識符。協(xié)議方案是指訪問資源所使用的協(xié)議類型名稱。
乍一看，URI和URL似乎并沒有什么區(qū)別。但是URI強調(diào)的是給資源標(biāo)記命名，URL強調(diào)的是給資源定位（資源在互聯(lián)網(wǎng)上的具體位置）。URI只知道某個資源的存在，但是不知道如何找到該資源；而URL不僅知道資源的存在，還知道如何去找到這個資源，即它知道資源的位置。
打個比喻，如果僅僅告訴你一個人的名字叫tom，你僅僅知道有這個叫tom的人，但是你卻無法找到tom這個人，這個名字tom就相當(dāng)于URI?，F(xiàn)在如果給了你tom這個人的名片（URL），上面有tom的住址，通過這個名片不僅僅知道tom這個人，還能定位到tom所在的位置。詳細可以參考URI和URL的區(qū)別一文。
??顯然，URL所包含的信息比URI更多，URL是URI的子集。
3 HTTP協(xié)議
??超文本傳送協(xié)議HTTP（HyperText Transfer Protocol）定義了瀏覽器（即萬維網(wǎng)客戶進程）向服務(wù)器請求Web頁面的方式，以及服務(wù)器向瀏覽器傳送頁面的方式。
??3.1 HTTP的特點
??(1) HTTP使用了面向連接的TCP作為傳輸層協(xié)議，保證了數(shù)據(jù)的可靠傳輸。HTTP客戶首先發(fā)起一個與服務(wù)器的TCP連接，一旦連接建立。該瀏覽器和服務(wù)器進程就可以通過套接字接口訪問TCP。
??(2) HTTP協(xié)議本身是無連接的。這就是說，雖然HTTP使用了TCP連接，但通信的雙方在交換HTTP報文之間不需要先建立HTTP連接。
??(3) HTTP協(xié)議是無狀態(tài)的。無狀態(tài)協(xié)議對于事務(wù)沒有記憶能力，HTTP服務(wù)器并不保存關(guān)于客戶的任何信息。同一個客戶在短時間內(nèi)兩次請求同一個對象，服務(wù)器會對這兩次請求作出兩次響應(yīng)，因為服務(wù)器并不記得曾經(jīng)這個客戶訪問過，也不記得為這個客戶服務(wù)器過多少次。
??HTTP協(xié)議設(shè)計成無狀態(tài)的原因：
??(1) 簡化了服務(wù)器的設(shè)計，無狀態(tài)協(xié)議簡單，使服務(wù)器更容易支持大量并發(fā)的HTTP請求。
??(2) 有狀態(tài)的協(xié)議更加復(fù)雜，需要維護客戶端的狀態(tài)，并且如果客戶或服務(wù)器失效，會產(chǎn)生狀態(tài)不一致，解決這種不一致的代價高。
??(3) 不需保存客戶的狀態(tài)信息可以減少服務(wù)器的CPU及內(nèi)存的消耗。
??3.2 持續(xù)連接和非持續(xù)連接
??在介紹這兩種連接方式之前，先看以下一個請求響應(yīng)報文需要傳輸?shù)臅r間。
??上圖表示從瀏覽器請求一個文檔所需的時間，HTTP協(xié)議首先和服務(wù)器建立TCP連接。這需要三次握手，當(dāng)建立TCP連接的三次報文握手的前兩部分后（即經(jīng)過了一個RTT時間后），客戶將把HTTP請求報文作為建立TCP連接的第三次握手的第三個報文的數(shù)據(jù)（前面介紹過三次握手中第三次握手客戶端可以攜帶數(shù)據(jù)），發(fā)送給服務(wù)器。服務(wù)器收到HTTP請求報文后，就把所請求的文檔作為響應(yīng)報文返回給客戶。
??從上面的過程可以看出，從服務(wù)器請求一個文檔的所需的時間就是該文檔傳輸時間加上兩倍的往返時間RTT。
??非連續(xù)連接是指當(dāng)一系列請求到達服務(wù)器時，每個請求/響應(yīng)應(yīng)對是經(jīng)過一個單獨的TCP進行的。如果使用瀏覽器瀏覽一個頁面，這個頁面包含多個鏈接對象（如圖片）那么就需要進行依次鏈接，每一次鏈接都導(dǎo)致2 × RTT的開銷。另一個開銷就是服務(wù)器和客戶每一次建立新的TCP連接都要分配緩存和變量。特別萬維網(wǎng)服務(wù)器往往要同時服務(wù)器大量客戶請求，所以非持續(xù)連接會使萬維網(wǎng)服務(wù)器負擔(dān)很重。
??下圖表示非連續(xù)連接的工作方式，對于每一個請求都建立一個TCP連接。
??為了解決非連續(xù)連接的問題，HTTP 1.1使用持續(xù)連接（默認），所謂的持續(xù)連接是指服務(wù)器在發(fā)送響應(yīng)后仍然一段時間內(nèi)保持這條連接，使同一個客戶（瀏覽器）和該服務(wù)器可以繼續(xù)在這條鏈接上傳送后續(xù)的HTTP請求報文和響應(yīng)報文。
??下圖表示持續(xù)連接下的多次請求和響應(yīng)的交互。
??持久連接的好處在于減少了TCP連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器的負載。另外，減少開銷的那部分時間，使HTTP請求和響應(yīng)能更早的結(jié)束，這樣Web頁面的顯示速度也就提高了。
??HTTP/1.1協(xié)議的持續(xù)連接有兩種工作方式，即非流水線方式（without pipelining）和流水線方式（with pipelining）。
??非流水線方式的工作特點：客戶在收到前一個響應(yīng)后才能發(fā)出下一個請求。因此，在TCP連接已建立后，客戶每訪問一次對象都要用去一個往返時間RTT。這比非持續(xù)連接要用去兩倍RTT的開銷，節(jié)省了建立TCP所需的一個RTT時間。上圖的持續(xù)連接方式就是非流水線方式，這種方式的缺點是服務(wù)器在發(fā)送完一個對象后，其TCP連接就處于空閑狀態(tài)，浪費了服務(wù)器資源。
??流水線方式的工作特點：客戶在收到HTTP響應(yīng)報文之前就能夠接著發(fā)送新的請求報文。于是一個接著一個的請求報文到達服務(wù)器后，服務(wù)器就可以連續(xù)發(fā)回響應(yīng)報文。因此，使用流水線方式時，客戶訪問所有的對象只需花費一個RTT時間。流水線工作方式使TCP連接中的空閑時間減少，提高了文檔下載效率。
??3.3 Cookie
??前面介紹，HTTP 是無狀態(tài)協(xié)議，即HTTP 協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進行保存。但是在狠多情況下需要保存用戶狀態(tài)，例如用戶登錄到一家購物網(wǎng)站，即使他跳轉(zhuǎn)到該站的其他頁面后，也需要能繼續(xù)保持登錄狀態(tài)。針對這個實例，網(wǎng)站為了能夠掌握是誰送出的請求，需要保存用戶的狀態(tài)。
??為了解決上面的問題，目前大多站點使用Cookie技術(shù)。Cookie是網(wǎng)站為了辨別用戶身份，進行會話跟蹤而存儲在客戶端上的數(shù)據(jù)。
??Cookie技術(shù)的4個組件：
(1) 在HTTP響應(yīng)報文中的一個cookie首部行。
(2) 在HTTP請求報文中的一個cookie首部行。
(3) 在用戶端系統(tǒng)中保留一個cookie文件，由用戶的瀏覽器進行管理。
(4) 位于Web站點的一個后端數(shù)據(jù)庫。
??Cookie技術(shù)通過在請求和響應(yīng)報文中寫入Cookie信息來控制客戶端的狀態(tài)。其具體工作流程如下所示
(1) 當(dāng)用戶訪問某個使用Cookie的網(wǎng)站時，該網(wǎng)站的服務(wù)器就為用戶產(chǎn)生一個唯一的識別碼，并以此作為索引在服務(wù)器的后端服務(wù)器數(shù)據(jù)庫中產(chǎn)生一個表項。
(2) 服務(wù)器在給用戶的HTTP響應(yīng)報文中添加一個叫做Set-Cookie的首部行。如Set-Cookie : 1234
(3) 當(dāng)用戶收到這個響應(yīng)時，其瀏覽器就在它管理的特定的Cookie文件中添加一行，其中包括這個服務(wù)器主機名和Set-Cookie后面的給出的識別碼。當(dāng)用戶繼續(xù)瀏覽這個網(wǎng)站時，每發(fā)送一個HTTP請求報文，其瀏覽器就會從Cookie文件中取出這個網(wǎng)站的識別碼，并放到HTTP請求報文的Cookie首部行中，即Coolkie : 1234。
??于是，該網(wǎng)站就可以跟蹤用戶在該網(wǎng)站的活動。服務(wù)器并不知道用戶的真實姓名以及其他信息，但是它知道用戶在什么時候訪問了哪些頁面，以及訪問這些頁面的順序。例如，如果用戶在網(wǎng)上購物，那么服務(wù)器可以為該用戶維護一個所購物品的列表，使的用戶在購物結(jié)束后一起支付。
(4) 如果過段時間用戶再次訪問該網(wǎng)站時，那么瀏覽器會在其請求報文中繼續(xù)使用首部行Cookie:1234，如果用戶在該網(wǎng)站上保存了姓名、電子郵件等信息，服務(wù)器可以使用Cookie來驗證該用戶，因此以后用戶在網(wǎng)站購物時就不必在重新輸入姓名等信息了，對用戶顯然是很方便的。
??下圖表示第一次訪問該網(wǎng)站的響應(yīng)報文的響應(yīng)頭和請求報文的請求頭，只需要關(guān)注響應(yīng)頭中Set-Cookie字段。
??下圖表示第二次訪問某網(wǎng)站的響應(yīng)報文的響應(yīng)頭和請求報文的請求頭，在請求頭中可以看出首部字段中使用了Cookie字段。
4 緩存
??Web緩存器又稱代理服務(wù)器（proxy server），它能夠?qū)⒆罱囊恍┱埱蠛晚憫?yīng)暫存在本地磁盤中。當(dāng)新請求到達時，如果代理服務(wù)器中沒有這個請求，那么就會從互聯(lián)網(wǎng)中訪問該資源，將其返回給代理服務(wù)器，代理服務(wù)器會保存一份資源的副本，之后將資源返回給客戶端。若代理服務(wù)器發(fā)現(xiàn)這個請求與暫時存放的請求相同，就返回暫存響應(yīng)，而不需按URL的地址再次去互聯(lián)網(wǎng)訪問該資源。
上面第一幅圖表示代理服務(wù)器中沒有這個請求的資源，第二幅圖表示客戶端再次請求相同的資源的情況。
??緩存的好處：(1) 大大減少對客戶請求的響應(yīng)的時間。
??(2) 可以避免多次從源服務(wù)器轉(zhuǎn)發(fā)資源，大大減少了一個機構(gòu)接入鏈路到因特網(wǎng)的通信量，從而降低了費用。
下圖表示沒有使用代理服務(wù)器的情況，所有的計算機都通過這條2Mbit/s的鏈路與互聯(lián)網(wǎng)上的源點服務(wù)器建立TCP連接。因此校園網(wǎng)各計算機訪問互聯(lián)網(wǎng)的通信量往往會使這條鏈路過載，使得時延大大增加。
下圖表示使用了代理服務(wù)器的情況，校園網(wǎng)中的計算機先和代理服務(wù)器建立TCP連接，如果代理服務(wù)器存放了請求的資源，則直接將請求的資源返回給計算機的瀏覽器（圖中的①）。如果沒有請求的對象，那么代理服務(wù)器將與互聯(lián)網(wǎng)上的源點服務(wù)器建立TCP連接（圖中的②），并發(fā)送HTTP請求報文，源點服務(wù)器將請求的資源返回給代理服務(wù)器，代理服務(wù)器先將資源復(fù)制到自己的本地服務(wù)器中，然后在將該資源返回給請求的計算機。
??所以，在使用代理服務(wù)器的情況下，由于有相當(dāng)大一部分通信局限在校園網(wǎng)內(nèi)部，因此鏈路上的通信量大大減少，因而減少了互聯(lián)網(wǎng)的時延。
5 條件GET方法
??盡管緩存能夠減少響應(yīng)時間，但是也引入了一個新的問題——緩存的有效性問題。
當(dāng)遇上服務(wù)器上的資源更新時，如果還是使用原來的緩存，那么就會出現(xiàn)緩存不一致的問題。
??HTTP協(xié)議有一種機制，允許緩存證實它的對象是最新的。這種機制就是條件GET方法。
??如果請求報文使用的是GET方法，并且請求報文中含一個“If-Modified-Since”首部行。那么，這個HTTP請求就是一個條件GET請求報文。下面用一個例子說明一下條件GET方法。
??首先，一個代理服務(wù)器代表一個請求瀏覽器，向某個Web服務(wù)器發(fā)送一個請求報文：
??其次，該Web服務(wù)器向代理服務(wù)器發(fā)送具有被請求對象的響應(yīng)報文：
??代理服務(wù)器將該對象保存在本地磁盤中。注意，響應(yīng)報文中的紅色部分，表示該對象的最后修改日期。
??一段時間后，另一個用戶經(jīng)過緩存請求同一個對象，該對象仍在代理服務(wù)器中，由于過了一段時間了，Web服務(wù)器上的該對象可能已經(jīng)被修改過了，所以代理服務(wù)器通過發(fā)送一個條件GET執(zhí)行最新檢查。具體來說，該代理服務(wù)器發(fā)送：
??這里，請求報文中的If-Modified首部行的值和之前響應(yīng)報文中Last-Modified首部行的值一樣。這個條件GET報文告訴服務(wù)器，如果在指定日期后該對象被修改過，才發(fā)送該對象。通俗來說，就是代理服務(wù)器告訴服務(wù)器如果在2011年9月7日 09:23:24之后對該對象有修改過，那就把修改過的對象發(fā)送給我。
??假設(shè)該對象沒有被修改過，那么Web服務(wù)器向代理服務(wù)器發(fā)送一個響應(yīng)報文：
??304 響應(yīng)碼表示請求的對象沒有被修改。所以，響應(yīng)體的內(nèi)容是空沒有包含對象，由于對象沒有被修改，即代理服務(wù)器中的對象和Web服務(wù)器中的該對象是一致的，所有Web服務(wù)器沒必要再傳送一次該對象，包含對象只會浪費帶寬，并增加用戶的響應(yīng)時間。
??未完待續(xù)....
6 小結(jié)
