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

AJAX是一種技術，訪問服務器數據的一種技術。

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

下面讓我們來了解一下HTTP協議。

一、前端開發發展歷程

1.1 服務器端渲染

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

• 客戶端發出請求；
• 服務端接收請求并返回相應HTML文檔；
• 頁面刷新，客戶端加載新的HTML文檔。

缺點 :

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

2.2 前后端分離

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

二、HTTP簡介

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

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

三、發展階段

3.1 0.9

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

3.2 1.0

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

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

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

3.4 2.0

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

網絡協議新版本并不會馬上取代舊版本。實際上，1.0和1.1在之后很長的一段時間內一直并存，這是由于網絡基礎設施更新緩慢所決定的。

四、工作原理

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

典型的HTTP事務處理有如下的過程：

• 客戶與服務器建立連接；
• 客戶向服務器提出請求；
• 服務器接受請求，并根據請求返回相應的文件作為應答；
• 客戶與服務器關閉連接。

特性：

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

五、運作方式

HTTP是基于請求/響應范式的。

一個客戶機與服務器建立連接后，發送一個請求給服務器，請求方式的格式為，統一資源標識符、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。服務器接到請求后，給予相應的響應信息，其格式為一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。

其實簡單說就是任何服務器除了包括HTML文件以外，還有一個HTTP駐留程序，用于響應用戶請求。你的瀏覽器是HTTP客戶，向服務器發送請求，當瀏覽器中輸入了一個開始文件或點擊了一個超級鏈接時，瀏覽器就向服務器發送了HTTP請求，此請求被送往由IP地址指定的URL。駐留程序接收到請求，在進行必要的操作后回送所要求的文件。

在這一過程中，在網絡上發送和接收的數據已經被分成一個或多個數據包（packet），每個數據包包括：

• 要傳送的數據；
• 控制信息，即告訴網絡怎樣處理數據包。

TCP/IP決定了每個數據包的格式。如果事先不告訴你，你可能不會知道信息被分成用于傳輸和再重新組合起來的許多小塊。

許多HTTP通訊是由一個用戶代理初始化的并且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理（UA）和源服務器（O）之間通過一個單獨的連接來完成。

當一個或多個中介出現在請求/響應鏈中時，情況就變得復雜一些。

中介有三種：代理（Proxy）、網關（Gateway）和通道（Tunnel）。

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