0.90.9協(xié)議是適用于各種數(shù)據(jù)信息的簡潔快速協(xié)議，但是遠(yuǎn)不能滿足日益發(fā)展的各種應(yīng)用的需要。0.9協(xié)議就是一個(gè)交換信息的無序協(xié)議，僅僅限于文字。由于無法進(jìn)行內(nèi)容的協(xié)商，在雙發(fā)的握手和協(xié)議中，并有規(guī)定雙發(fā)的內(nèi)容是什么，也就是圖片是無法顯示和處理的。
1.0到了1.0協(xié)議階段，也就是在1982年，Tim Berners-Lee提出了HTTP/1.0。在此后的不斷豐富和發(fā)展中，HTTP/1.0成為最重要的面向事務(wù)的應(yīng)用層協(xié)議。該協(xié)議對(duì)每一次請求/響應(yīng)建立并拆除一次連接。其特點(diǎn)是簡單、易于管理，所以它符合了大家的需要，得到了廣泛的應(yīng)用。
1.1在1.0協(xié)議中，雙方規(guī)定了連接方式和連接類型，這已經(jīng)極大擴(kuò)展了HTTP的領(lǐng)域，但對(duì)于互聯(lián)網(wǎng)最重要的速度和效率，并沒有太多的考慮。畢竟，作為協(xié)議的制定者，當(dāng)時(shí)也沒有想到HTTP會(huì)有那么快的普及速度。 [3] 關(guān)于HTTP1.1協(xié)議的具體內(nèi)容可以參考RFC 2616。
2.0HTTP2.0的前身是HTTP1.0和HTTP1.1。雖然之前僅僅只有兩個(gè)版本，但這兩個(gè)版本所包含的協(xié)議規(guī)范之龐大，足以讓任何一個(gè)有經(jīng)驗(yàn)的工程師為之頭疼。網(wǎng)絡(luò)協(xié)議新版本并不會(huì)馬上取代舊版本。實(shí)際上，1.0和1.1在之后很長的一段時(shí)間內(nèi)一直并存，這是由于網(wǎng)絡(luò)基礎(chǔ)設(shè)施更新緩慢所決定的。關(guān)于HTTP2.0協(xié)議的具體內(nèi)容可以參考RFC 7540。
HTTP誕生之初主要是應(yīng)用于WEB端內(nèi)容獲取，那時(shí)候內(nèi)容還不像現(xiàn)在這樣豐富，排版也沒那么精美，用戶交互的場景幾乎沒有。對(duì)于這種簡單的獲取網(wǎng)頁內(nèi)容的場景，HTTP表現(xiàn)得還算不錯(cuò)。但隨著互聯(lián)網(wǎng)的發(fā)展和WEB2.0的誕生，更多的內(nèi)容開始被展示(更多的圖片文件)，排版變得更精美(更多的CSS)，更復(fù)雜的交互也被引入(更多的JS)。用戶打開一個(gè)網(wǎng)站首頁所加載的數(shù)據(jù)總量和請求的個(gè)數(shù)也在不斷增加。今天絕大部分的門戶網(wǎng)站首頁大小都會(huì)超過2M，請求數(shù)量可以多達(dá)100個(gè)。另一個(gè)廣泛的應(yīng)用是在移動(dòng)互聯(lián)網(wǎng)的客戶端app，不同性質(zhì)的app對(duì)HTTP的使用差異很大。對(duì)于電商類app，加載首頁的請求也可能多達(dá)10多個(gè)。對(duì)于微信這類IM，HTTP請求可能僅限于語音和圖片文件的下載，請求出現(xiàn)的頻率并不算高。
在WWW中，“客戶”與“服務(wù)器”是一個(gè)相對(duì)的概念，只存在于一個(gè)特定的連接期間，即在某個(gè)連接中的客戶在另一個(gè)連接中可能作為服務(wù)器?；贖TTP的客戶/服務(wù)器模式的信息交換過程，它分四個(gè)過程：建立連接、發(fā)送請求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。
HTTP是基于請求/響應(yīng)范式的。一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請求給服務(wù)器，請求方式的格式為，統(tǒng)一資源標(biāo)識(shí)符、協(xié)議版本號(hào)，后邊是MIME信息包括請求修飾符、客戶機(jī)信息和可能的內(nèi)容。服務(wù)器接到請求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。其實(shí)簡單說就是任何服務(wù)器除了包括HTML文件以外，還有一個(gè)HTTP駐留程序，用于響應(yīng)用戶請求。你的瀏覽器是HTTP客戶，向服務(wù)器發(fā)送請求，當(dāng)瀏覽器中輸入了一個(gè)開始文件或點(diǎn)擊了一個(gè)超級(jí)鏈接時(shí)，瀏覽器就向服務(wù)器發(fā)送了HTTP請求，此請求被送往由IP地址指定的URL。駐留程序接收到請求，在進(jìn)行必要的操作后回送所要求的文件。在這一過程中，在網(wǎng)絡(luò)上發(fā)送和接收的數(shù)據(jù)已經(jīng)被分成一個(gè)或多個(gè)數(shù)據(jù)包(packet)，每個(gè)數(shù)據(jù)包包括：要傳送的數(shù)據(jù);控制信息，即告訴網(wǎng)絡(luò)怎樣處理數(shù)據(jù)包。TCP/IP決定了每個(gè)數(shù)據(jù)包的格式。如果事先不告訴你，你可能不會(huì)知道信息被分成用于傳輸和再重新組合起來的許多小塊。許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請?jiān)谠捶?wù)器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源服務(wù)器(O)之間通過一個(gè)單獨(dú)的連接來完成。當(dāng)一個(gè)或多個(gè)中介出現(xiàn)在請求/響應(yīng)鏈中時(shí)，情況就變得復(fù)雜一些。中介有三種：代理(Proxy)、網(wǎng)關(guān)(Gateway)和通道(Tunnel)。一個(gè)代理根據(jù)URI的絕對(duì)格式來接受請求，重寫全部或部分消息，通過URI的標(biāo)識(shí)把已格式化過的請求發(fā)送到服務(wù)器。網(wǎng)關(guān)是一個(gè)接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請求翻譯給下層的服務(wù)器協(xié)議。一個(gè)通道作為不改變消息的兩個(gè)連接之間的中繼點(diǎn)。當(dāng)通訊需要通過一個(gè)中介(例如：防火墻等)或者是中介不能識(shí)別消息的內(nèi)容時(shí)，通道經(jīng)常被使用。
下載文檔
