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台服務器能同時處理多少客戶端請求？
這個問題很有意思，先說答案：取決於網絡帶寬與服務器內存。
首先要明確一點是，物理規律無法打破。服務器與外界通信只靠一根網線。
所以網絡帶寬會限制鏈接客戶端數量。
其次，每次建立一個連接，服務都會在內存中保持連接句柄，所以跟內存也會相關。