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

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

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

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

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

1.1 服務器端渲染

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

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

缺點 :

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

2.2 前后端分離

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

二、HTTP簡介

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

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

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

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

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

3.4 2.0

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

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

四、工作原理

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

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

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

特性：

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

五、運作方式

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

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

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

在這一過程中，在網(wǎng)絡上發(fā)送和接收的數(shù)據(jù)已經(jīng)被分成一個或多個數(shù)據(jù)包（packet），每個數(shù)據(jù)包包括：

• 要傳送的數(shù)據(jù)；
• 控制信息，即告訴網(wǎng)絡怎樣處理數(shù)據(jù)包。

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

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

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

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

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