為什么前端要了解HTTP協(xié)議，當(dāng)你和后端進行合作的時候，需要訪問后端的數(shù)據(jù)接口，這時候和后端進行接口對接就有兩個必要了解的要點：HTTP協(xié)議和AJAX技術(shù)。

AJAX是一種技術(shù)，訪問服務(wù)器數(shù)據(jù)的一種技術(shù)。

HTTP協(xié)議：是一種規(guī)定約成，我們前端使用AJAX技術(shù)訪問后端數(shù)據(jù)時時要采用HTTP協(xié)議去請求信息，所以HTTP和AJAX是由非常緊密的關(guān)系。 

下面讓我們來了解一下HTTP協(xié)議。

一、前端開發(fā)發(fā)展歷程

1.1 服務(wù)器端渲染

服務(wù)器端渲染（SSR，server side render）: 早期的網(wǎng)頁都是通過后端渲染來完成的。

• 客戶端發(fā)出請求；
• 服務(wù)端接收請求并返回相應(yīng)HTML文檔；
• 頁面刷新，客戶端加載新的HTML文檔。

缺點 :

• 當(dāng)用戶點擊頁面中的某個按鈕向服務(wù)器發(fā)送請求時，頁面本質(zhì)上只是一些數(shù)據(jù)發(fā)生了變化，而此時服務(wù)器卻要將重繪的整個頁面再返回給瀏覽器加載，這顯然有悖于程序員的“DRY（ Don‘t repeat yourself ）”原則；
• 而且明明只是一些數(shù)據(jù)的變化卻迫使服務(wù)器要返回整個HTML文檔，這本身也會給網(wǎng)絡(luò)帶寬帶來不必要的開銷。

2.2 前后端分離

前端只需要獨立編寫客戶端代碼，后端也只需要獨立編寫服務(wù)端代碼提供數(shù)據(jù)接口， 前端通過AJAX請求來訪問后端的數(shù)據(jù)接口，將Model展示到View中即可。

二、HTTP簡介

HTTP協(xié)議：超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）。

• 是一個簡單的請求-響應(yīng)協(xié)議；
• 它通常運行在TCP之上；
• 它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)；
• 請求和響應(yīng)消息的頭以ASCII形式給出，而消息內(nèi)容則具有一個類似MIME的格式。
• 這個簡單模型是早期Web成功的有功之臣，因為它使開發(fā)和部署非常地直截了當(dāng)。

三、發(fā)展階段

3.1 0.9

0.9協(xié)議是適用于各種數(shù)據(jù)信息的簡潔快速協(xié)議，是一個交換信息的無序協(xié)議，僅僅限于文字。由于無法進行內(nèi)容的協(xié)商，在雙發(fā)的握手和協(xié)議中，并沒有規(guī)定雙發(fā)的內(nèi)容是什么，也就是圖片是無法顯示和處理的。只支持get請求。

3.2 1.0

支持POST、HEAD等請求方法，支持請求頭、響應(yīng)頭等，支持更多種數(shù)據(jù)類型(不再局限于文本數(shù)據(jù))，但是瀏覽器的每次請求都需要與服務(wù)器建立一個TCP連接，請求處理完成后立即斷開TCP連接，每次建立連接增加了性能損耗。

3.3 1.1(目前使用最廣泛的版本)

在1.0協(xié)議中，雙方規(guī)定了連接方式和連接類型，這已經(jīng)極大擴展了HTTP的領(lǐng)域， 增加了PUT、DELETE等請求方法，采用持久連接(Connection: keep-alive)，多個請求可以共用同一個TCP連接。

3.4 2.0

HTTP2.0的前身是HTTP1.0和HTTP1.1。雖然之前僅僅只有兩個版本，但這兩個版本所包含的協(xié)議規(guī)范之龐大，足以讓任何一個有經(jīng)驗的工程師為之頭疼。

網(wǎng)絡(luò)協(xié)議新版本并不會馬上取代舊版本。實際上，1.0和1.1在之后很長的一段時間內(nèi)一直并存，這是由于網(wǎng)絡(luò)基礎(chǔ)設(shè)施更新緩慢所決定的。

四、工作原理

HTTP是基于客戶/服務(wù)器模式，且面向連接的。

典型的HTTP事務(wù)處理有如下的過程：

• 客戶與服務(wù)器建立連接；
• 客戶向服務(wù)器提出請求；
• 服務(wù)器接受請求，并根據(jù)請求返回相應(yīng)的文件作為應(yīng)答；
• 客戶與服務(wù)器關(guān)閉連接。

特性：

• 客戶與服務(wù)器之間的HTTP連接是一種一次性連接。它限制每次連接只處理一個請求，當(dāng)服務(wù)器返回本次請求的應(yīng)答后便立即關(guān)閉連接，下次請求再重新建立連接。這種一次性連接主要考慮到WWW服務(wù)器面向的是Internet中成千上萬個用戶，且只能提供有限個連接，故服務(wù)器不會讓一個連接處于等待狀態(tài)，及時地釋放連接可以大大提高服務(wù)器的執(zhí)行效率。
• HTTP是一種無狀態(tài)協(xié)議，即服務(wù)器不保留與客戶交易時的任何狀態(tài)。這就大大減輕了服務(wù)器記憶負(fù)擔(dān)，從而保持較快的響應(yīng)速度。HTTP是一種面向?qū)ο蟮膮f(xié)議。允許傳送任意類型的數(shù)據(jù)對象。它通過數(shù)據(jù)類型和長度來標(biāo)識所傳送的數(shù)據(jù)內(nèi)容和大小，并允許對數(shù)據(jù)進行壓縮傳送。當(dāng)用戶在一個HTML文檔中定義了一個超文本鏈后，瀏覽器將通過TCP/IP協(xié)議與指定的服務(wù)器建立連接。
• HTTP支持持久連接，在HTTP / 0.9和1.0中，連接在單個請求/響應(yīng)對之后關(guān)閉。在HTTP / 1.1中，引入了保持活動機制，其中連接可以重用于多個請求。這樣的持久性連接可以明顯減少請求延遲，因為在發(fā)送第一個請求之后，客戶端不需要重新協(xié)商TCP 3-Way-Handshake連接。另一個積極的副作用是，通常，由于TCP的緩慢啟動機制，連接隨著時間的推移而變得更快。

五、運作方式

HTTP是基于請求/響應(yīng)范式的。

一個客戶機與服務(wù)器建立連接后，發(fā)送一個請求給服務(wù)器，請求方式的格式為，統(tǒng)一資源標(biāo)識符、協(xié)議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內(nèi)容。服務(wù)器接到請求后，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行包括信息的協(xié)議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。

其實簡單說就是任何服務(wù)器除了包括HTML文件以外，還有一個HTTP駐留程序，用于響應(yīng)用戶請求。你的瀏覽器是HTTP客戶，向服務(wù)器發(fā)送請求，當(dāng)瀏覽器中輸入了一個開始文件或點擊了一個超級鏈接時，瀏覽器就向服務(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）之間通過一個單獨的連接來完成。

當(dāng)一個或多個中介出現(xiàn)在請求/響應(yīng)鏈中時，情況就變得復(fù)雜一些。

中介有三種：代理（Proxy）、網(wǎng)關(guān)（Gateway）和通道（Tunnel）。

• 一個代理根據(jù)URI的絕對格式來接受請求，重寫全部或部分消息，通過URI的標(biāo)識把已格式化過的請求發(fā)送到服務(wù)器。
• 網(wǎng)關(guān)是一個接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請求翻譯給下層的服務(wù)器協(xié)議。
• 一個通道作為不改變消息的兩個連接之間的中繼點。當(dāng)通訊需要通過一個中介（例如：防火墻等）或者是中介不能識別消息的內(nèi)容時，通道經(jīng)常被使用。