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臺伺服器能同時處理多少客戶端請求？
這個問題很有意思，先說答案：取決於網路頻寬與伺服器記憶體。
首先要明確一點是，物理規律無法打破。伺服器與外界通訊只靠一根網線。
所以網路頻寬會限制連結客戶端數量。
其次，每次建立一個連線，服務都會在記憶體中保持連線控制程式碼，所以跟記憶體也會相關。