摘要：通過請求和響應(yīng)的交換達(dá)成通信協(xié)議中已經(jīng)規(guī)定了請求是從客戶端發(fā)出，最后由服務(wù)端響應(yīng)這個(gè)請求并返回。隨后的字符串指明了請求訪問的資源對象。協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存，也就是說這個(gè)級別。從前發(fā)送請求后需等待并受到響應(yīng)。

http協(xié)議和TCP/IP協(xié)議族內(nèi)的其他眾多協(xié)議相同，用于客戶端和服務(wù)器之間的通信。
那么問題來個(gè)如果兩臺服務(wù)器之間一臺服務(wù)器向另一臺服務(wù)器進(jìn)行接口請求那誰是客戶端呢？所以這里的客戶端和服務(wù)端是相對的概念，如果一端擔(dān)任客戶端的角色，另一端就需要擔(dān)任服務(wù)器端的角色不是絕對的概念。

http協(xié)議中已經(jīng)規(guī)定了請求是從客戶端發(fā)出，最后由服務(wù)端響應(yīng)這個(gè)請求并返回。
下面來看一個(gè)請求中的報(bào)文，

GET /index.html HTTP/1.1
Host: baidu.cn

起始行的開頭的GET表示請求訪問服務(wù)器的類型，成為方法（method）對于前后端的同學(xué)最熟悉不過了。
隨后的字符串index.html指明了請求訪問的資源對象。也叫請求的URI，最后HTTP/1.1就是我們http的版本號，用來告訴客戶端使用的http協(xié)議功能。

HTTP是一種不保存狀態(tài)，即無狀態(tài)協(xié)議。HTTP協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存，也就是說HTTP這個(gè)級別。協(xié)議對于發(fā)送過的請求或者響應(yīng)都不做持久化處理。

所以在使用http協(xié)議的時(shí)候，每當(dāng)有新的請求發(fā)送時(shí)，就會(huì)有對應(yīng)的新的響應(yīng)產(chǎn)生，協(xié)議本身并不保留之前一切的請求或響應(yīng)報(bào)文信息。這是為了更快的處理大量食物，確保協(xié)議的可伸縮性，而特意把http協(xié)議設(shè)計(jì)成如此簡單的。
但是隨著web的發(fā)展，因?yàn)闆]有轉(zhuǎn)態(tài)在某些業(yè)務(wù)場景下因?yàn)闊o狀態(tài)導(dǎo)致業(yè)務(wù)變得棘手了，例如，現(xiàn)在的電商平臺，即時(shí)他在別的頁面進(jìn)行瀏覽商品的時(shí)候我們也需要保持該用戶的登錄狀態(tài)，所以為了實(shí)現(xiàn)這個(gè)需求，http協(xié)議引入了Cookie技術(shù)。稍后會(huì)有詳解。

HTTP協(xié)議使用URI定位互聯(lián)網(wǎng)上的資源，正是應(yīng)為URI的特定功能，在互聯(lián)網(wǎng)上任意位置的資源能訪問到。

1、GET:獲取資源
get方法用來請求訪問已被URI識別的資源，指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。如果請求的是文本。那就保持原樣返回。
2、POST:傳輸實(shí)體
POST方法用來傳輸實(shí)體的主體。
雖然用GET方法也可以傳輸實(shí)體的主體，但是一般不用GET方法進(jìn)行傳輸，而是用POST方法。雖說POST和GET很相似。但是POST的主要目的不是獲取響應(yīng)的主題內(nèi)容。
3、PUT:傳輸文件
PUT方法用來傳輸文件，就像FTP協(xié)議的文件上傳一樣。要求在請求報(bào)文的主題中包含文件內(nèi)容。然后保存到請求URI指定的位置去。
4、HEAD:獲取報(bào)文首部
HEAD方法和GET方法一樣，只是不返回報(bào)文主體的部分。用于確認(rèn)URI的有效性及更新日期等等。
5、DELETE:刪除文件
DELET方法用來刪除文件，是與PUT相反的方法。
DELET方法安請求URI刪除指定的資源。
6、OPTIONS:詢問支持得方法
OPTIONS方法用來查詢針對URI指定的資源支持得方法。

在HTTP協(xié)議的初始版本中，沒進(jìn)行一次HTTP通行就要斷開一次TCP鏈接。
以當(dāng)年的通信情況來說，因?yàn)槎际切﹥?nèi)容很小的文本傳輸，所以即使這樣也沒有多大問題。可隨著HTTP的普及。文檔中包含有大量的圖片的情況多了起來。
比如瀏覽器瀏覽一個(gè)包含多張圖片的HTML頁面時(shí)，在發(fā)送請求訪問HTML頁面資源的同時(shí)，也會(huì)請求HTML頁面里面包含的其他資源，因此每次請求都會(huì)造成無謂的TCP連接建立和斷開，增加通行量的開銷。
持久連接
為了解決上訴TCP連接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久連接，也稱為HTTP keep-alive的方法。持久連接的特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持TCP連接轉(zhuǎn)態(tài)。
HTTP/1.1中，所有的連接默認(rèn)都是持久連接，但是在HTTP/1.0中并沒有標(biāo)準(zhǔn)化。雖然有一部分服務(wù)器通過非標(biāo)準(zhǔn)手段實(shí)現(xiàn)了持久化連接。但服務(wù)器端不一定能夠支持持久化連接。毫無疑問，除了服務(wù)端，客戶端也需要支持持久化連接。
管線化
持久化連接使得多數(shù)請求以管線化方式發(fā)送成為可能。從前發(fā)送請求后需等待并受到響應(yīng)。才能發(fā)送下一個(gè)請求。管線化技術(shù)出現(xiàn)后。不用等待亦可直接發(fā)送下一個(gè)請求。
這樣就能夠做到同時(shí)并行發(fā)送多個(gè)請求。而不需要一個(gè)接一個(gè)地等待響應(yīng)。

之前我們提過HTTP是無狀態(tài)協(xié)議，它不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進(jìn)行管理，不可否認(rèn)，無狀態(tài)協(xié)議當(dāng)然有它的優(yōu)點(diǎn)。由于不必保存狀態(tài)，自然可以減少服務(wù)器的CPU及內(nèi)存資源的消耗。從另一個(gè)側(cè)面來說，也正是因?yàn)镠TTP協(xié)議本身是非常的簡單，所以才會(huì)被應(yīng)用在各種場景。

為了解決這個(gè)問題，Cookie出現(xiàn)了，Cookie會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做Set-Cookie的首部字段，通知客戶端保存Cookie,下次客戶端再往該服務(wù)器發(fā)送請求時(shí)，客戶端會(huì)自動(dòng)在請求報(bào)文中加入Cookie之后發(fā)送出去。
服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的Cookie后，回去檢查究竟是從哪一個(gè)客戶端發(fā)送來的請求，然后對比服務(wù)器上的記錄，最后得到之前的轉(zhuǎn)態(tài)信息。

前端必知必會(huì)HTTP請求系列（一）了解Web及網(wǎng)絡(luò)基礎(chǔ)
前端必知必會(huì)HTTP請求系列（二）簡單一點(diǎn)的HTTP協(xié)議
前端必知必會(huì)HTTP請求系列（三）HTTP，報(bào)文內(nèi)部的HTTP信息
前端必知必會(huì)HTTP請求系列（四）返回結(jié)果的HTTP狀態(tài)碼
前端必知必會(huì)HTTP請求系列（五）與HTTP協(xié)作的web服務(wù)器
前端必知必會(huì)HTTP請求系列（六）HTTP的首部
前端必知必會(huì)HTTP請求系列（七）確保Web安全的HTTPS
前端必知必會(huì)HTTP請求系列（八）確認(rèn)訪問用戶身份的認(rèn)證
前端必知必會(huì)HTTP請求系列（九）基于HTTP的功能追加協(xié)議
前端必知必會(huì)HTTP請求系列（十）構(gòu)建Web內(nèi)容的技術(shù)
前端必知必會(huì)HTTP請求系列（十一）Web攻擊技術(shù)
有什么問題可以到評論區(qū)留言，持續(xù)關(guān)注，不斷更新！