你必需要知道的HTTP協議原理

1 基本概念

HTTP協議：基於TCP協議之上實現的無狀態、全文本的標準通訊協議。

客戶端：例如pc瀏覽器，移動應用端，第三方服務器等能發起http訪問的設備。

服務器：可以接受HTTP協議請求，而且一般可以正常返回響應結果給客戶端的設備。

 

 

 

HTTP協議其實提及來很簡單，它有兩個重要特性：純文本，無狀態。理解了這兩個特性，基本就掌握了HTTP的核心思想了。其它知識，無非是應該各類場景下制定的協議細節。

 

純文本：

TCP協議保證兩個計算機直接的穩定通訊，TCP報文傳輸的數據部分在HTTP協議裏面就存放的是HTTP純文本。

解決這個，最簡單的就是安裝一個抓包工具查看一下傳輸報文的格式，這裏咱們以Fiddler爲例子，抓取訪問知乎首頁的請求。你能夠很明顯的看出來，請求和響應所有都是以純文本方式交互。

 

 

無狀態：

這個特性說的是：只依賴協議自己的定義，服務器沒法區分連續的兩次請求是否屬於同一個客戶端。有點抽象，這個等到最後說session與cookie時候一塊兒說。

 

 

2 Get與Post請求的區別

 

這個問題老生常談了，我面試時候也常常會問。

從協議的角度來的，區別以下：

 

 

區別就是請求開頭第一行的標識符號，你是傳GET仍是POST，此外從傳輸角度來看沒有任何區別！！！

網上千篇一概的什麼URL傳參，BODY傳參，大小限制，安全限制之類的，基本都是各類框架、工具在具體工程實現上面的細節區分。

 

3 Json與Form表單，Content-Type請求頭

如今RESTFUL API大行其道，可是早幾年仍是表單提交的天下，不過在作項目的過程當中有時候仍是會碰到要求表單提交的api，例入某訊家的接口。

因此仍是有必要體會一下二者的不一樣，以下圖：

 

 

同時對應的Content-Type請求頭會有不一樣：

application/x-www-form-urlencoded

application/json

4 Cookie與Session

 

cookie：客戶端保存的關於特定域名的服務器相關聯數據。

session: 同一個客戶端，必定時間段內的請求過程。

 

前文咱們說過，無狀態特性決定了，只依賴協議自己的定義，服務器沒法區分連續的兩次請求是否屬於同一個客戶端。咱們先看圖：

 

 

服務器沒法區分兩個請求分別屬於誰的，雖然你看圖列子，兩個線是直接連接到不一樣的兩個客戶端的。可是，請注意關測HTTP請求的文本：

 

 

服務器收到像這樣的純文本，它如何從中推斷出，是哪一個客戶端發出的請求呢？

答案是判斷不了，條件不足。

聰明的你，可能已經想到了：在傳輸的文本中添加客戶端相關的信息，不就能夠識別特定客戶端了嗎？是的，工程界就是這麼實現的，一般會藉助於一個在客戶端存儲cookie來，近幾年localstorage存儲也大行其道，目的都是標識客戶端歸屬。

 

 

5 Https請求

上文中有說到，http是純文本，既然是純文本，那我若是在通訊過程當中，例如在某一個路由中攔截請求，直接就能夠看到全部明文，極爲不安全。因此纔有了SSL、TLS協議，給傳輸加個密。

這裏有一個誤區，SSL、TLS協議是直接在TCP傳輸層面作的加密，而不是在HTTP協議之上作封裝。另外，創建傳輸開始過程當中纔會作不對稱加密算法如RSA作證書驗證，而在傳輸過程當中，仍是使用的對稱加密算法如DES等。

 

 

6 1臺服務器能同時處理多少客戶端請求？

這個問題頗有意思，先說答案：取決於網絡帶寬與服務器內存。

首先要明確一點是，物理規律沒法打破。服務器與外界通訊只靠一根網線。

因此網絡帶寬會限制連接客戶端數量。

其次，每次創建一個鏈接，服務都會在內存中保持鏈接句柄，因此跟內存也會相關。