前言
??前面水了兩篇文章，下面開(kāi)始介紹應(yīng)用層另一個(gè)非常重要的協(xié)議——HTTP協(xié)議。
1 萬(wàn)維網(wǎng)
??萬(wàn)維網(wǎng)WWW（World Wide Web）是一個(gè)大規(guī)模的、聯(lián)機(jī)式的信息儲(chǔ)藏所。是無(wú)數(shù)網(wǎng)絡(luò)站點(diǎn)的集合额衙。
??萬(wàn)維網(wǎng)以客戶服務(wù)器方式工作∨挛猓客戶程序向服務(wù)器發(fā)出請(qǐng)求窍侧，服務(wù)器程序向客戶程序送回客戶所要的萬(wàn)維網(wǎng)文檔。在一個(gè)客戶程序主窗口上顯示出的萬(wàn)維網(wǎng)文檔稱為頁(yè)面（page）转绷。
??要實(shí)現(xiàn)上面的過(guò)程伟件，必須解決以下問(wèn)題：
??(1) 怎么標(biāo)志分布在整個(gè)互聯(lián)網(wǎng)上的萬(wàn)維網(wǎng)文檔——統(tǒng)一資源定位符URL。
??(2) 用什么樣的協(xié)議實(shí)現(xiàn)萬(wàn)維網(wǎng)上的各種連接——超文本傳送協(xié)議HTTP议经。
??(3) 怎樣使不同風(fēng)格的萬(wàn)維網(wǎng)文檔都能在互聯(lián)網(wǎng)上的主機(jī)上顯示——超文本標(biāo)記語(yǔ)言HTML斧账。
2 URL && URI
??2.1 URL
??統(tǒng)一資源定位符URL（Uniform Resources Locator）用來(lái)表示資源在互聯(lián)網(wǎng)上的位置和訪問(wèn)這些資源的方法谴返，并使每一個(gè)資源在整個(gè)互聯(lián)網(wǎng)范圍內(nèi)具有唯一的標(biāo)識(shí)符URL。即URL實(shí)際上就是在互聯(lián)網(wǎng)上資源的地址咧织。
??URL的一般形式
<協(xié)議>://<主機(jī)>:<端口>/<路徑>
??(1) 第一部分是最左邊的<協(xié)議>嗓袱。這里的<協(xié)議>是指用什么協(xié)議來(lái)獲取該萬(wàn)維網(wǎng)文檔。現(xiàn)在最常用的就是http（超文本傳送協(xié)議HTTP）习绢，其次是ftp（文件傳送協(xié)議FTP）渠抹。
??(2) 第二部分是<主機(jī)>，它指出這個(gè)萬(wàn)維網(wǎng)的文檔在哪臺(tái)主機(jī)上闪萄。<主機(jī)>就是指該主機(jī)在互連網(wǎng)上的域名梧却，如www.baidu.com。
??(3) 后面的<端口>和<路徑>有時(shí)可以省略败去。HTTP的默認(rèn)端口號(hào)是80篮幢，通常可省略为迈。路徑有時(shí)也可以省略，表示訪問(wèn)互聯(lián)網(wǎng)上的某個(gè)主頁(yè)缺菌。如訪問(wèn)www.baidu.com和訪問(wèn)www.baidu.com/idnex.html的效果是一樣的葫辐，都是訪問(wèn)百度的首頁(yè)。
??2.2 URI
??統(tǒng)一資源標(biāo)識(shí)符URI（Uniform Recourses Identifier）就是由某個(gè)協(xié)議方案表示的資源定位標(biāo)識(shí)符伴郁。協(xié)議方案是指訪問(wèn)資源所使用的協(xié)議類型名稱耿战。
乍一看，URI和URL似乎并沒(méi)有什么區(qū)別焊傅。但是URI強(qiáng)調(diào)的是給資源標(biāo)記命名剂陡，URL強(qiáng)調(diào)的是給資源定位（資源在互聯(lián)網(wǎng)上的具體位置）。URI只知道某個(gè)資源的存在狐胎，但是不知道如何找到該資源鸭栖；而URL不僅知道資源的存在，還知道如何去找到這個(gè)資源握巢，即它知道資源的位置晕鹊。
打個(gè)比喻，如果僅僅告訴你一個(gè)人的名字叫tom暴浦，你僅僅知道有這個(gè)叫tom的人溅话，但是你卻無(wú)法找到tom這個(gè)人，這個(gè)名字tom就相當(dāng)于URI「杞梗現(xiàn)在如果給了你tom這個(gè)人的名片（URL）飞几，上面有tom的住址，通過(guò)這個(gè)名片不僅僅知道tom這個(gè)人独撇，還能定位到tom所在的位置屑墨。詳細(xì)可以參考URI和URL的區(qū)別一文躁锁。
??顯然，URL所包含的信息比URI更多绪钥，URL是URI的子集灿里。
3 HTTP協(xié)議
??超文本傳送協(xié)議HTTP（HyperText Transfer Protocol）定義了瀏覽器（即萬(wàn)維網(wǎng)客戶進(jìn)程）向服務(wù)器請(qǐng)求Web頁(yè)面的方式，以及服務(wù)器向?yàn)g覽器傳送頁(yè)面的方式程腹。
??3.1 HTTP的特點(diǎn)
??(1) HTTP使用了面向連接的TCP作為傳輸層協(xié)議匣吊，保證了數(shù)據(jù)的可靠傳輸。HTTP客戶首先發(fā)起一個(gè)與服務(wù)器的TCP連接寸潦，一旦連接建立色鸳。該瀏覽器和服務(wù)器進(jìn)程就可以通過(guò)套接字接口訪問(wèn)TCP。
??(2) HTTP協(xié)議本身是無(wú)連接的见转。這就是說(shuō)命雀，雖然HTTP使用了TCP連接，但通信的雙方在交換HTTP報(bào)文之間不需要先建立HTTP連接斩箫。
??(3) HTTP協(xié)議是無(wú)狀態(tài)的吏砂。無(wú)狀態(tài)協(xié)議對(duì)于事務(wù)沒(méi)有記憶能力，HTTP服務(wù)器并不保存關(guān)于客戶的任何信息乘客。同一個(gè)客戶在短時(shí)間內(nèi)兩次請(qǐng)求同一個(gè)對(duì)象狐血，服務(wù)器會(huì)對(duì)這兩次請(qǐng)求作出兩次響應(yīng)，因?yàn)榉?wù)器并不記得曾經(jīng)這個(gè)客戶訪問(wèn)過(guò)易核，也不記得為這個(gè)客戶服務(wù)器過(guò)多少次匈织。
??HTTP協(xié)議設(shè)計(jì)成無(wú)狀態(tài)的原因：
??(1) 簡(jiǎn)化了服務(wù)器的設(shè)計(jì)，無(wú)狀態(tài)協(xié)議簡(jiǎn)單牡直，使服務(wù)器更容易支持大量并發(fā)的HTTP請(qǐng)求缀匕。
??(2) 有狀態(tài)的協(xié)議更加復(fù)雜，需要維護(hù)客戶端的狀態(tài)碰逸，并且如果客戶或服務(wù)器失效乡小，會(huì)產(chǎn)生狀態(tài)不一致，解決這種不一致的代價(jià)高饵史。
??(3) 不需保存客戶的狀態(tài)信息可以減少服務(wù)器的CPU及內(nèi)存的消耗劲件。
??3.2 持續(xù)連接和非持續(xù)連接
??在介紹這兩種連接方式之前，先看以下一個(gè)請(qǐng)求響應(yīng)報(bào)文需要傳輸?shù)臅r(shí)間约急。
??上圖表示從瀏覽器請(qǐng)求一個(gè)文檔所需的時(shí)間零远，HTTP協(xié)議首先和服務(wù)器建立TCP連接。這需要三次握手厌蔽，當(dāng)建立TCP連接的三次報(bào)文握手的前兩部分后（即經(jīng)過(guò)了一個(gè)RTT時(shí)間后）牵辣，客戶將把HTTP請(qǐng)求報(bào)文作為建立TCP連接的第三次握手的第三個(gè)報(bào)文的數(shù)據(jù)（前面介紹過(guò)三次握手中第三次握手客戶端可以攜帶數(shù)據(jù)），發(fā)送給服務(wù)器奴饮。服務(wù)器收到HTTP請(qǐng)求報(bào)文后纬向，就把所請(qǐng)求的文檔作為響應(yīng)報(bào)文返回給客戶择浊。
??從上面的過(guò)程可以看出，從服務(wù)器請(qǐng)求一個(gè)文檔的所需的時(shí)間就是該文檔傳輸時(shí)間加上兩倍的往返時(shí)間RTT逾条。
??非連續(xù)連接是指當(dāng)一系列請(qǐng)求到達(dá)服務(wù)器時(shí)琢岩，每個(gè)請(qǐng)求/響應(yīng)應(yīng)對(duì)是經(jīng)過(guò)一個(gè)單獨(dú)的TCP進(jìn)行的。如果使用瀏覽器瀏覽一個(gè)頁(yè)面师脂，這個(gè)頁(yè)面包含多個(gè)鏈接對(duì)象（如圖片）那么就需要進(jìn)行依次鏈接担孔，每一次鏈接都導(dǎo)致2 × RTT的開(kāi)銷。另一個(gè)開(kāi)銷就是服務(wù)器和客戶每一次建立新的TCP連接都要分配緩存和變量吃警。特別萬(wàn)維網(wǎng)服務(wù)器往往要同時(shí)服務(wù)器大量客戶請(qǐng)求糕篇，所以非持續(xù)連接會(huì)使萬(wàn)維網(wǎng)服務(wù)器負(fù)擔(dān)很重。
??下圖表示非連續(xù)連接的工作方式酌心，對(duì)于每一個(gè)請(qǐng)求都建立一個(gè)TCP連接拌消。
??為了解決非連續(xù)連接的問(wèn)題，HTTP 1.1使用持續(xù)連接（默認(rèn)）安券，所謂的持續(xù)連接是指服務(wù)器在發(fā)送響應(yīng)后仍然一段時(shí)間內(nèi)保持這條連接墩崩，使同一個(gè)客戶（瀏覽器）和該服務(wù)器可以繼續(xù)在這條鏈接上傳送后續(xù)的HTTP請(qǐng)求報(bào)文和響應(yīng)報(bào)文。
??下圖表示持續(xù)連接下的多次請(qǐng)求和響應(yīng)的交互侯勉。
??持久連接的好處在于減少了TCP連接的重復(fù)建立和斷開(kāi)所造成的額外開(kāi)銷泰鸡，減輕了服務(wù)器的負(fù)載。另外壳鹤，減少開(kāi)銷的那部分時(shí)間，使HTTP請(qǐng)求和響應(yīng)能更早的結(jié)束饰迹，這樣Web頁(yè)面的顯示速度也就提高了芳誓。
??HTTP/1.1協(xié)議的持續(xù)連接有兩種工作方式，即非流水線方式（without pipelining）和流水線方式（with pipelining）啊鸭。
??非流水線方式的工作特點(diǎn)：客戶在收到前一個(gè)響應(yīng)后才能發(fā)出下一個(gè)請(qǐng)求锹淌。因此，在TCP連接已建立后赠制，客戶每訪問(wèn)一次對(duì)象都要用去一個(gè)往返時(shí)間RTT赂摆。這比非持續(xù)連接要用去兩倍RTT的開(kāi)銷，節(jié)省了建立TCP所需的一個(gè)RTT時(shí)間钟些。上圖的持續(xù)連接方式就是非流水線方式烟号，這種方式的缺點(diǎn)是服務(wù)器在發(fā)送完一個(gè)對(duì)象后，其TCP連接就處于空閑狀態(tài)政恍，浪費(fèi)了服務(wù)器資源汪拥。
??流水線方式的工作特點(diǎn)：客戶在收到HTTP響應(yīng)報(bào)文之前就能夠接著發(fā)送新的請(qǐng)求報(bào)文。于是一個(gè)接著一個(gè)的請(qǐng)求報(bào)文到達(dá)服務(wù)器后篙耗，服務(wù)器就可以連續(xù)發(fā)回響應(yīng)報(bào)文迫筑。因此宪赶，使用流水線方式時(shí)，客戶訪問(wèn)所有的對(duì)象只需花費(fèi)一個(gè)RTT時(shí)間脯燃。流水線工作方式使TCP連接中的空閑時(shí)間減少搂妻，提高了文檔下載效率。
??3.3 Cookie
??前面介紹辕棚，HTTP 是無(wú)狀態(tài)協(xié)議欲主，即HTTP 協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。但是在狠多情況下需要保存用戶狀態(tài)坟募，例如用戶登錄到一家購(gòu)物網(wǎng)站岛蚤，即使他跳轉(zhuǎn)到該站的其他頁(yè)面后，也需要能繼續(xù)保持登錄狀態(tài)懈糯。針對(duì)這個(gè)實(shí)例涤妒，網(wǎng)站為了能夠掌握是誰(shuí)送出的請(qǐng)求，需要保存用戶的狀態(tài)赚哗。
??為了解決上面的問(wèn)題她紫，目前大多站點(diǎn)使用Cookie技術(shù)。Cookie是網(wǎng)站為了辨別用戶身份屿储，進(jìn)行會(huì)話跟蹤而存儲(chǔ)在客戶端上的數(shù)據(jù)贿讹。
??Cookie技術(shù)的4個(gè)組件：
(1) 在HTTP響應(yīng)報(bào)文中的一個(gè)cookie首部行。
(2) 在HTTP請(qǐng)求報(bào)文中的一個(gè)cookie首部行够掠。
(3) 在用戶端系統(tǒng)中保留一個(gè)cookie文件民褂，由用戶的瀏覽器進(jìn)行管理。
(4) 位于Web站點(diǎn)的一個(gè)后端數(shù)據(jù)庫(kù)疯潭。
??Cookie技術(shù)通過(guò)在請(qǐng)求和響應(yīng)報(bào)文中寫入Cookie信息來(lái)控制客戶端的狀態(tài)赊堪。其具體工作流程如下所示
(1) 當(dāng)用戶訪問(wèn)某個(gè)使用Cookie的網(wǎng)站時(shí)，該網(wǎng)站的服務(wù)器就為用戶產(chǎn)生一個(gè)唯一的識(shí)別碼竖哩，并以此作為索引在服務(wù)器的后端服務(wù)器數(shù)據(jù)庫(kù)中產(chǎn)生一個(gè)表項(xiàng)哭廉。
(2) 服務(wù)器在給用戶的HTTP響應(yīng)報(bào)文中添加一個(gè)叫做Set-Cookie的首部行。如Set-Cookie : 1234
(3) 當(dāng)用戶收到這個(gè)響應(yīng)時(shí)相叁，其瀏覽器就在它管理的特定的Cookie文件中添加一行遵绰，其中包括這個(gè)服務(wù)器主機(jī)名和Set-Cookie后面的給出的識(shí)別碼。當(dāng)用戶繼續(xù)瀏覽這個(gè)網(wǎng)站時(shí)增淹，每發(fā)送一個(gè)HTTP請(qǐng)求報(bào)文椿访，其瀏覽器就會(huì)從Cookie文件中取出這個(gè)網(wǎng)站的識(shí)別碼，并放到HTTP請(qǐng)求報(bào)文的Cookie首部行中虑润，即Coolkie : 1234赎离。
??于是，該網(wǎng)站就可以跟蹤用戶在該網(wǎng)站的活動(dòng)。服務(wù)器并不知道用戶的真實(shí)姓名以及其他信息梁剔，但是它知道用戶在什么時(shí)候訪問(wèn)了哪些頁(yè)面虽画，以及訪問(wèn)這些頁(yè)面的順序。例如荣病，如果用戶在網(wǎng)上購(gòu)物码撰，那么服務(wù)器可以為該用戶維護(hù)一個(gè)所購(gòu)物品的列表，使的用戶在購(gòu)物結(jié)束后一起支付个盆。
(4) 如果過(guò)段時(shí)間用戶再次訪問(wèn)該網(wǎng)站時(shí)脖岛，那么瀏覽器會(huì)在其請(qǐng)求報(bào)文中繼續(xù)使用首部行Cookie:1234，如果用戶在該網(wǎng)站上保存了姓名颊亮、電子郵件等信息柴梆，服務(wù)器可以使用Cookie來(lái)驗(yàn)證該用戶，因此以后用戶在網(wǎng)站購(gòu)物時(shí)就不必在重新輸入姓名等信息了终惑，對(duì)用戶顯然是很方便的绍在。
??下圖表示第一次訪問(wèn)該網(wǎng)站的響應(yīng)報(bào)文的響應(yīng)頭和請(qǐng)求報(bào)文的請(qǐng)求頭，只需要關(guān)注響應(yīng)頭中Set-Cookie字段雹有。
??下圖表示第二次訪問(wèn)某網(wǎng)站的響應(yīng)報(bào)文的響應(yīng)頭和請(qǐng)求報(bào)文的請(qǐng)求頭偿渡，在請(qǐng)求頭中可以看出首部字段中使用了Cookie字段。
4 緩存
??Web緩存器又稱代理服務(wù)器（proxy server）霸奕，它能夠?qū)⒆罱囊恍┱?qǐng)求和響應(yīng)暫存在本地磁盤中溜宽。當(dāng)新請(qǐng)求到達(dá)時(shí)，如果代理服務(wù)器中沒(méi)有這個(gè)請(qǐng)求质帅，那么就會(huì)從互聯(lián)網(wǎng)中訪問(wèn)該資源适揉，將其返回給代理服務(wù)器，代理服務(wù)器會(huì)保存一份資源的副本煤惩，之后將資源返回給客戶端嫉嘀。若代理服務(wù)器發(fā)現(xiàn)這個(gè)請(qǐng)求與暫時(shí)存放的請(qǐng)求相同，就返回暫存響應(yīng)盟庞，而不需按URL的地址再次去互聯(lián)網(wǎng)訪問(wèn)該資源。
上面第一幅圖表示代理服務(wù)器中沒(méi)有這個(gè)請(qǐng)求的資源汤善，第二幅圖表示客戶端再次請(qǐng)求相同的資源的情況什猖。
??緩存的好處：(1) 大大減少對(duì)客戶請(qǐng)求的響應(yīng)的時(shí)間。
??(2) 可以避免多次從源服務(wù)器轉(zhuǎn)發(fā)資源红淡，大大減少了一個(gè)機(jī)構(gòu)接入鏈路到因特網(wǎng)的通信量不狮，從而降低了費(fèi)用。
下圖表示沒(méi)有使用代理服務(wù)器的情況在旱，所有的計(jì)算機(jī)都通過(guò)這條2Mbit/s的鏈路與互聯(lián)網(wǎng)上的源點(diǎn)服務(wù)器建立TCP連接摇零。因此校園網(wǎng)各計(jì)算機(jī)訪問(wèn)互聯(lián)網(wǎng)的通信量往往會(huì)使這條鏈路過(guò)載，使得時(shí)延大大增加桶蝎。
下圖表示使用了代理服務(wù)器的情況驻仅，校園網(wǎng)中的計(jì)算機(jī)先和代理服務(wù)器建立TCP連接谅畅，如果代理服務(wù)器存放了請(qǐng)求的資源，則直接將請(qǐng)求的資源返回給計(jì)算機(jī)的瀏覽器（圖中的①）噪服。如果沒(méi)有請(qǐng)求的對(duì)象毡泻，那么代理服務(wù)器將與互聯(lián)網(wǎng)上的源點(diǎn)服務(wù)器建立TCP連接（圖中的②），并發(fā)送HTTP請(qǐng)求報(bào)文粘优，源點(diǎn)服務(wù)器將請(qǐng)求的資源返回給代理服務(wù)器仇味，代理服務(wù)器先將資源復(fù)制到自己的本地服務(wù)器中，然后在將該資源返回給請(qǐng)求的計(jì)算機(jī)雹顺。
??所以丹墨，在使用代理服務(wù)器的情況下，由于有相當(dāng)大一部分通信局限在校園網(wǎng)內(nèi)部嬉愧，因此鏈路上的通信量大大減少贩挣，因而減少了互聯(lián)網(wǎng)的時(shí)延。
5 條件GET方法
??盡管緩存能夠減少響應(yīng)時(shí)間英染，但是也引入了一個(gè)新的問(wèn)題——緩存的有效性問(wèn)題揽惹。
當(dāng)遇上服務(wù)器上的資源更新時(shí)，如果還是使用原來(lái)的緩存四康，那么就會(huì)出現(xiàn)緩存不一致的問(wèn)題搪搏。
??HTTP協(xié)議有一種機(jī)制，允許緩存證實(shí)它的對(duì)象是最新的闪金。這種機(jī)制就是條件GET方法疯溺。
??如果請(qǐng)求報(bào)文使用的是GET方法，并且請(qǐng)求報(bào)文中含一個(gè)“If-Modified-Since”首部行哎垦。那么囱嫩，這個(gè)HTTP請(qǐng)求就是一個(gè)條件GET請(qǐng)求報(bào)文。下面用一個(gè)例子說(shuō)明一下條件GET方法漏设。
??首先墨闲，一個(gè)代理服務(wù)器代表一個(gè)請(qǐng)求瀏覽器，向某個(gè)Web服務(wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文：
??其次郑口，該Web服務(wù)器向代理服務(wù)器發(fā)送具有被請(qǐng)求對(duì)象的響應(yīng)報(bào)文：
??代理服務(wù)器將該對(duì)象保存在本地磁盤中鸳碧。注意，響應(yīng)報(bào)文中的紅色部分犬性，表示該對(duì)象的最后修改日期瞻离。
??一段時(shí)間后，另一個(gè)用戶經(jīng)過(guò)緩存請(qǐng)求同一個(gè)對(duì)象乒裆，該對(duì)象仍在代理服務(wù)器中套利，由于過(guò)了一段時(shí)間了，Web服務(wù)器上的該對(duì)象可能已經(jīng)被修改過(guò)了，所以代理服務(wù)器通過(guò)發(fā)送一個(gè)條件GET執(zhí)行最新檢查肉迫。具體來(lái)說(shuō)验辞，該代理服務(wù)器發(fā)送：
??這里，請(qǐng)求報(bào)文中的If-Modified首部行的值和之前響應(yīng)報(bào)文中Last-Modified首部行的值一樣昂拂。這個(gè)條件GET報(bào)文告訴服務(wù)器受神，如果在指定日期后該對(duì)象被修改過(guò)，才發(fā)送該對(duì)象格侯。通俗來(lái)說(shuō)鼻听，就是代理服務(wù)器告訴服務(wù)器如果在2011年9月7日 09:23:24之后對(duì)該對(duì)象有修改過(guò)，那就把修改過(guò)的對(duì)象發(fā)送給我联四。
??假設(shè)該對(duì)象沒(méi)有被修改過(guò)撑碴，那么Web服務(wù)器向代理服務(wù)器發(fā)送一個(gè)響應(yīng)報(bào)文：
??304 響應(yīng)碼表示請(qǐng)求的對(duì)象沒(méi)有被修改。所以朝墩，響應(yīng)體的內(nèi)容是空沒(méi)有包含對(duì)象醉拓，由于對(duì)象沒(méi)有被修改，即代理服務(wù)器中的對(duì)象和Web服務(wù)器中的該對(duì)象是一致的收苏，所有Web服務(wù)器沒(méi)必要再傳送一次該對(duì)象亿卤，包含對(duì)象只會(huì)浪費(fèi)帶寬，并增加用戶的響應(yīng)時(shí)間鹿霸。
??未完待續(xù)....
6 小結(jié)
