為什么前端要了解HTTP協(xié)議，當(dāng)你和后端進(jìn)行合作的時(shí)候，需要訪問(wèn)后端的數(shù)據(jù)接口，這時(shí)候和后端進(jìn)行接口對(duì)接就有兩個(gè)必要了解的要點(diǎn)：HTTP協(xié)議和AJAX技術(shù)。
AJAX是一種技術(shù)，訪問(wèn)服務(wù)器數(shù)據(jù)的一種技術(shù)。
HTTP協(xié)議：是一種規(guī)定約成，我們前端使用AJAX技術(shù)訪問(wèn)后端數(shù)據(jù)時(shí)時(shí)要采用HTTP協(xié)議去請(qǐng)求信息，所以HTTP和AJAX是由非常緊密的關(guān)系。
下面讓我們來(lái)了解一下HTTP協(xié)議。
一、前端開發(fā)發(fā)展歷程
1.1 服務(wù)器端渲染
服務(wù)器端渲染（SSR，server side render）: 早期的網(wǎng)頁(yè)都是通過(guò)后端渲染來(lái)完成的。
- 客戶端發(fā)出請(qǐng)求；
- 服務(wù)端接收請(qǐng)求并返回相應(yīng)HTML文檔；
- 頁(yè)面刷新，客戶端加載新的HTML文檔。
缺點(diǎn) :
- 當(dāng)用戶點(diǎn)擊頁(yè)面中的某個(gè)按鈕向服務(wù)器發(fā)送請(qǐng)求時(shí)，頁(yè)面本質(zhì)上只是一些數(shù)據(jù)發(fā)生了變化，而此時(shí)服務(wù)器卻要將重繪的整個(gè)頁(yè)面再返回給瀏覽器加載，這顯然有悖于程序員的“DRY（ Don‘t repeat yourself ）”原則；
- 而且明明只是一些數(shù)據(jù)的變化卻迫使服務(wù)器要返回整個(gè)HTML文檔，這本身也會(huì)給網(wǎng)絡(luò)帶寬帶來(lái)不必要的開銷。
2.2 前后端分離
前端只需要獨(dú)立編寫客戶端代碼，后端也只需要獨(dú)立編寫服務(wù)端代碼提供數(shù)據(jù)接口， 前端通過(guò)AJAX請(qǐng)求來(lái)訪問(wèn)后端的數(shù)據(jù)接口，將Model展示到View中即可。
二、HTTP簡(jiǎn)介
HTTP協(xié)議：超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）。
- 是一個(gè)簡(jiǎn)單的請(qǐng)求-響應(yīng)協(xié)議；
- 它通常運(yùn)行在TCP之上；
- 它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)；
- 請(qǐng)求和響應(yīng)消息的頭以ASCII形式給出，而消息內(nèi)容則具有一個(gè)類似MIME的格式。
- 這個(gè)簡(jiǎn)單模型是早期Web成功的有功之臣，因?yàn)樗归_發(fā)和部署非常地直截了當(dāng)。
三、發(fā)展階段
3.1 0.9
0.9協(xié)議是適用于各種數(shù)據(jù)信息的簡(jiǎn)潔快速協(xié)議，是一個(gè)交換信息的無(wú)序協(xié)議，僅僅限于文字。由于無(wú)法進(jìn)行內(nèi)容的協(xié)商，在雙發(fā)的握手和協(xié)議中，并沒(méi)有規(guī)定雙發(fā)的內(nèi)容是什么，也就是圖片是無(wú)法顯示和處理的。只支持get請(qǐng)求。
3.2 1.0
支持POST、HEAD等請(qǐng)求方法，支持請(qǐng)求頭、響應(yīng)頭等，支持更多種數(shù)據(jù)類型(不再局限于文本數(shù)據(jù))，但是瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，請(qǐng)求處理完成后立即斷開TCP連接，每次建立連接增加了性能損耗。
3.3 1.1(目前使用最廣泛的版本)
在1.0協(xié)議中，雙方規(guī)定了連接方式和連接類型，這已經(jīng)極大擴(kuò)展了HTTP的領(lǐng)域， 增加了PUT、DELETE等請(qǐng)求方法，采用持久連接(Connection: keep-alive)，多個(gè)請(qǐng)求可以共用同一個(gè)TCP連接。
3.4 2.0
HTTP2.0的前身是HTTP1.0和HTTP1.1。雖然之前僅僅只有兩個(gè)版本，但這兩個(gè)版本所包含的協(xié)議規(guī)范之龐大，足以讓任何一個(gè)有經(jīng)驗(yàn)的工程師為之頭疼。
網(wǎng)絡(luò)協(xié)議新版本并不會(huì)馬上取代舊版本。實(shí)際上，1.0和1.1在之后很長(zhǎng)的一段時(shí)間內(nèi)一直并存，這是由于網(wǎng)絡(luò)基礎(chǔ)設(shè)施更新緩慢所決定的。
四、工作原理
HTTP是基于客戶/服務(wù)器模式，且面向連接的。
典型的HTTP事務(wù)處理有如下的過(guò)程：
- 客戶與服務(wù)器建立連接；
- 客戶向服務(wù)器提出請(qǐng)求；
- 服務(wù)器接受請(qǐng)求，并根據(jù)請(qǐng)求返回相應(yīng)的文件作為應(yīng)答；
- 客戶與服務(wù)器關(guān)閉連接。
特性：
- 客戶與服務(wù)器之間的HTTP連接是一種一次性連接。它限制每次連接只處理一個(gè)請(qǐng)求，當(dāng)服務(wù)器返回本次請(qǐng)求的應(yīng)答后便立即關(guān)閉連接，下次請(qǐng)求再重新建立連接。這種一次性連接主要考慮到WWW服務(wù)器面向的是Internet中成千上萬(wàn)個(gè)用戶，且只能提供有限個(gè)連接，故服務(wù)器不會(huì)讓一個(gè)連接處于等待狀態(tài)，及時(shí)地釋放連接可以大大提高服務(wù)器的執(zhí)行效率。
- HTTP是一種無(wú)狀態(tài)協(xié)議，即服務(wù)器不保留與客戶交易時(shí)的任何狀態(tài)。這就大大減輕了服務(wù)器記憶負(fù)擔(dān)，從而保持較快的響應(yīng)速度。HTTP是一種面向?qū)ο蟮膮f(xié)議。允許傳送任意類型的數(shù)據(jù)對(duì)象。它通過(guò)數(shù)據(jù)類型和長(zhǎng)度來(lái)標(biāo)識(shí)所傳送的數(shù)據(jù)內(nèi)容和大小，并允許對(duì)數(shù)據(jù)進(jìn)行壓縮傳送。當(dāng)用戶在一個(gè)HTML文檔中定義了一個(gè)超文本鏈后，瀏覽器將通過(guò)TCP/IP協(xié)議與指定的服務(wù)器建立連接。
- HTTP支持持久連接，在HTTP / 0.9和1.0中，連接在單個(gè)請(qǐng)求/響應(yīng)對(duì)之后關(guān)閉。在HTTP / 1.1中，引入了保持活動(dòng)機(jī)制，其中連接可以重用于多個(gè)請(qǐng)求。這樣的持久性連接可以明顯減少請(qǐng)求延遲，因?yàn)樵诎l(fā)送第一個(gè)請(qǐng)求之后，客戶端不需要重新協(xié)商TCP 3-Way-Handshake連接。另一個(gè)積極的副作用是，通常，由于TCP的緩慢啟動(dòng)機(jī)制，連接隨著時(shí)間的推移而變得更快。
五、運(yùn)作方式
HTTP是基于請(qǐng)求/響應(yīng)范式的。
一個(gè)客戶機(jī)與服務(wù)器建立連接后，發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為，統(tǒng)一資源標(biāo)識(shí)符、協(xié)議版本號(hào)，后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可能的內(nèi)容。服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。
其實(shí)簡(jiǎn)單說(shuō)就是任何服務(wù)器除了包括HTML文件以外，還有一個(gè)HTTP駐留程序，用于響應(yīng)用戶請(qǐng)求。你的瀏覽器是HTTP客戶，向服務(wù)器發(fā)送請(qǐng)求，當(dāng)瀏覽器中輸入了一個(gè)開始文件或點(diǎn)擊了一個(gè)超級(jí)鏈接時(shí)，瀏覽器就向服務(wù)器發(fā)送了HTTP請(qǐng)求，此請(qǐng)求被送往由IP地址指定的URL。駐留程序接收到請(qǐng)求，在進(jìn)行必要的操作后回送所要求的文件。
在這一過(guò)程中，在網(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ì)知道信息被分成用于傳輸和再重新組合起來(lái)的許多小塊。
許多HTTP通訊是由一個(gè)用戶代理初始化的并且包括一個(gè)申請(qǐng)?jiān)谠捶?wù)器上資源的請(qǐng)求。最簡(jiǎn)單的情況可能是在用戶代理（UA）和源服務(wù)器（O）之間通過(guò)一個(gè)單獨(dú)的連接來(lái)完成。
當(dāng)一個(gè)或多個(gè)中介出現(xiàn)在請(qǐng)求/響應(yīng)鏈中時(shí)，情況就變得復(fù)雜一些。
中介有三種：代理（Proxy）、網(wǎng)關(guān)（Gateway）和通道（Tunnel）。
- 一個(gè)代理根據(jù)URI的絕對(duì)格式來(lái)接受請(qǐng)求，重寫全部或部分消息，通過(guò)URI的標(biāo)識(shí)把已格式化過(guò)的請(qǐng)求發(fā)送到服務(wù)器。
- 網(wǎng)關(guān)是一個(gè)接收代理，作為一些其它服務(wù)器的上層，并且如果必須的話，可以把請(qǐng)求翻譯給下層的服務(wù)器協(xié)議。
- 一個(gè)通道作為不改變消息的兩個(gè)連接之間的中繼點(diǎn)。當(dāng)通訊需要通過(guò)一個(gè)中介（例如：防火墻等）或者是中介不能識(shí)別消息的內(nèi)容時(shí)，通道經(jīng)常被使用。
