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