摘要：通過請求和響應的交換達成通信協議中已經規定了請求是從客戶端發出，最后由服務端響應這個請求并返回。隨后的字符串指明了請求訪問的資源對象。協議自身不對請求和響應之間的通信狀態進行保存，也就是說這個級別。從前發送請求后需等待并受到響應。

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

http協議中已經規定了請求是從客戶端發出，最后由服務端響應這個請求并返回。
下面來看一個請求中的報文，

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

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

HTTP是一種不保存狀態，即無狀態協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存，也就是說HTTP這個級別。協議對于發送過的請求或者響應都不做持久化處理。

所以在使用http協議的時候，每當有新的請求發送時，就會有對應的新的響應產生，協議本身并不保留之前一切的請求或響應報文信息。這是為了更快的處理大量食物，確保協議的可伸縮性，而特意把http協議設計成如此簡單的。
但是隨著web的發展，因為沒有轉態在某些業務場景下因為無狀態導致業務變得棘手了，例如，現在的電商平臺，即時他在別的頁面進行瀏覽商品的時候我們也需要保持該用戶的登錄狀態，所以為了實現這個需求，http協議引入了Cookie技術。稍后會有詳解。

HTTP協議使用URI定位互聯網上的資源，正是應為URI的特定功能，在互聯網上任意位置的資源能訪問到。

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

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

之前我們提過HTTP是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理，不可否認，無狀態協議當然有它的優點。由于不必保存狀態，自然可以減少服務器的CPU及內存資源的消耗。從另一個側面來說，也正是因為HTTP協議本身是非常的簡單，所以才會被應用在各種場景。

為了解決這個問題，Cookie出現了，Cookie會根據從服務器端發送的響應報文內的一個叫做Set-Cookie的首部字段，通知客戶端保存Cookie,下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie之后發送出去。
服務器端發現客戶端發送過來的Cookie后，回去檢查究竟是從哪一個客戶端發送來的請求，然后對比服務器上的記錄，最后得到之前的轉態信息。

前端必知必會HTTP請求系列（一）了解Web及網絡基礎
前端必知必會HTTP請求系列（二）簡單一點的HTTP協議
前端必知必會HTTP請求系列（三）HTTP，報文內部的HTTP信息
前端必知必會HTTP請求系列（四）返回結果的HTTP狀態碼
前端必知必會HTTP請求系列（五）與HTTP協作的web服務器
前端必知必會HTTP請求系列（六）HTTP的首部
前端必知必會HTTP請求系列（七）確保Web安全的HTTPS
前端必知必會HTTP請求系列（八）確認訪問用戶身份的認證
前端必知必會HTTP請求系列（九）基于HTTP的功能追加協議
前端必知必會HTTP請求系列（十）構建Web內容的技術
前端必知必會HTTP請求系列（十一）Web攻擊技術
有什么問題可以到評論區留言，持續關注，不斷更新！