一，什么是HTTP

我們在通過網絡進行傳輸數據時，我們要保證，我們在發送時構造的數據，在接收時也能夠解析出來，這本質上就是一種協議，是一種應用層協議，我們的程序員可以自定義這種協議，但實際上已經有大佬為我們寫出了更靠譜的協議，就是HTTP。其是一種超文本傳輸協議。

那么這種協議到底是什么呢？
當我們去訪問某個網頁時，其先是會將我們的請求通過HTTP請求的方式，發送給服務器，然后服務器再回復給客戶端對應的HTTP響應。

我們先來看HTTP請求中有什么。

其由首行+Header+Body組成。
我們先來看頭部：

它由方法+url+版本組成。
那么什么是方法呢？
下圖就是HTTP的方法

那么這些方法有什么區別呢？
我們以常用的GET和POST來說。GET請求的參數一般寫在url中。URL 規定只能支持 ASCII，所以 GET 請求的參數只允許 ASCII 字符 ，而且瀏覽器會對 URL 的長度有限制，通常為2048個字符。（HTTP協議本身對 URL長度并沒有做任何規定）。

POST 請求攜帶數據的位置一般是寫在報文 body 中，body 中的數據可以是任意格式的數據，只要客戶端與服務端協商好即可，而且瀏覽器不會對 body 大小做限制。

因為GET請求將參數放在URL中，所以容易泄漏信息，例如我們在網頁上就行用戶密碼登錄時，若用GET請求，就會將用戶名和密碼都顯式在URL中，從而暴露了我們的個人信息。

在 HTTP 協議里，所謂的「安全」是指請求方法不會「破壞」服務器上的資源。
所謂的「冪等」，意思是多次執行相同的操作，結果都是「相同」的。

如果從 RFC 規范定義的語義來看：
GET 方法就是安全且冪等的，因為它是「只讀」操作，無論操作多少次，服務器上的數據都是安全的，且每次的結果都是相同的。所以，可以對 GET 請求的數據做緩存，這個緩存可以做到瀏覽器本身上（徹底避免瀏覽器發請求），也可以做到代理上（如nginx），而且在瀏覽器中 GET 請求可以保存為書簽。

POST 因為是「新增或提交數據」的操作，會修改服務器上的資源，所以是不安全的，且多次提交數據就會創建多個資源，所以不是冪等的。所以，瀏覽器一般不會緩存 POST 請求，也不能把 POST 請求保存為書簽。

GET方法與POST方法的區別：

安全性：POST方法比GET方法更安全，因為它將數據作為請求主體發送，而不是明文暴露在URL中。
數據量：POST方法沒有數據量限制，而GET方法受到URL長度的限制。
數據類型：POST方法可以發送各種類型的數據，而GET方法主要用于發送文本數據。
緩存：POST方法不會被瀏覽器緩存，而GET方法可能會被緩存。

我們再來談談URL。
我們平時所說的網址就是URL，其包括這幾部分：

最后一個版本就是HTTP的版本，再進行通信時，不同的版本則應該對應用同一版本進行解析。

看完首行，我們再來看看Header部分

HTTP 是基于 TCP 傳輸協議進行通信的，而使用了 TCP 傳輸協議，就會存在一個“粘包”的問題，HTTP 協議通過設置回車符、換行符作為 HTTP header 的邊界，通過 Content-Length 字段作為 HTTP body的邊界，這兩個方式都是為了解決“粘包”的問題

看完了HTTP請求，我們再來看看HTTP的響應。

HTTP的響應包括：首行+Header+BODY.
我們來看首部：其包括版本號+狀態碼+狀態碼解釋。
版本號我們上面提到過，那么什么是狀態碼呢？

HTTP狀態碼

「200 OK」是最常見的成功狀態碼，表示一切正常。如果是非 HEAD 請求，服務器返回的響應頭都會有 body 數據。

「204 No Content」也是常見的成功狀態碼，與 200 OK 基本相同，但響應頭沒有 body 數據。

「206 Partial Content」是應用于 HTTP 分塊下載或斷點續傳，表示響應返回的 body數據并不是資源的全部，而是其中的一部分，也是服務器處理成功的狀態。

「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問。

「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭里使用字段 Location，指明后續要跳轉的 URL，瀏覽器會自動重定向新的 URL。

301 和 302 都會在響應頭里使用字段 Location，指明后續要跳轉的 URL，瀏覽器會自動重定向新的 URL。

「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，也就是告訴客戶端可以繼續使用緩存資源，用于緩存控制。

「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統的錯誤。

「403 Forbidden」表示服務器禁止訪問資源，并不是客戶端的請求出錯。

「404 Not Found」表示請求的資源在服務器上不存在或未找到，所以無法提供給客戶端。

「500 Internal Server Error」與 400 類型，是個籠統通用的錯誤碼，服務器發生了什么錯誤，我們并不知道。

「501 Not Implemented」表示客戶端請求的功能還不支持，類似“即將開業，敬請期待”的意思。

「502 Bad Gateway」通常是服務器作為網關或代理時返回的錯誤碼，表示服務器自身工作正常，訪問后端服務器發生了錯誤。

「503 Service Unavailable」表示服務器當前很忙，暫時無法響應客戶端，類似“網絡服務正忙，請稍后重試”的意思

HTTP的優缺點

對于一些具有重復性的 HTTP 請求，比如每次請求得到的數據都一樣的，我們可以把這對「請求-響應」的數據都緩存在本地，那么下次就直接讀取本地的數據，不必在通過網絡獲取服務器的響應了，這樣的話 HTTP/1.1 的性能肯定肉眼可見的提升。

所以，避免發送 HTTP 請求的方法就是通過緩存技術，HTTP 設計者早在之前就考慮到了這點，因此 HTTP 協議的頭部有不少是針對緩存的字段。

HTTP 緩存有兩種實現方式，分別是強制緩存和協商緩存。

HTTP的優點：
簡單，易擴展，跨平臺性。

缺點：
HTTP是無狀態的，也就是說，對于一些網頁來說，像是淘寶，我們的每一次請求都要進行用戶驗證，這樣對用戶顯然是不友好的，所以就有了cookie的出現。
我們先來看第一種情形：我們在網頁登錄后，若用POST請求，則我們的登錄信息則會填寫到請求的body中，服務器讀到后，會與其數據庫中的信息進行校驗，成功后才會返回對應的信息，這時我們的瀏覽器中也會對我們的登錄信息進行保存，保存在cookie中，當要繼續訪問時發送請求時，則填認證信息的過程則由瀏覽器幫助我們去做了，這樣看似方便了，但是是有問題的，當有人在我們的電腦中植入木馬，對我們的cookie進行掃描時，我們的信息是不是就泄漏啦。（cookie存儲在本地）。那么有什么辦法嗎？有的！
我們在登錄之后不再直接用密碼進行驗證不就可以了。
當我們的客戶端將用戶名，密碼通過請求發送到服務器上時，在服務器中，會有一個哈希表的東西，其內容是，我們的登錄信息和服務器為我們分配的一個session id，這兩個值是一一映射的關系，然后服務器將這個id返回給客戶端，此時瀏覽器保存的就是我們的id了，當再要進行驗證時，就通過id直接與服務器進行驗證。我們的信息也就不會泄露了，但是！仍然是不安全的，因為我們的HTTP是明文傳輸的，黑客可以通過抓包，從而拿到我們的id從而登錄我們的賬號。
有什么辦法解決嗎？有的！HTTPS。

HTTPS

因為http的內容是明?傳輸的，明?數據會經過路由器、wifi熱點、通信服務運營商、代理服務器等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙?察覺，這就是 中間?攻擊 ，所以我們才需要對信息進?加密。

那么它是怎么進行加密的呢？
我們的加密有對稱加密和非對稱加密。
我們來看一種最接近我們HTTPS加密方式的加密方法。
非對稱加密+對稱加密
客戶端發送連接請求給服務器，服務器發送公鑰給客戶端，客戶端用公鑰加密密鑰R（R進行的是對稱加密）發送給服務器，然后服務器用私鑰解密，最后兩個主機通過對稱密鑰R進行通信，但是改方法是有問題的，要是有中間人在開始時就進行攻擊，即在向客戶端發送公鑰時就進行攻擊，將公鑰換成自己的公鑰給客戶端，從而就拿到了客戶端的密鑰R。那么怎么解決呢？本質就是將服務器傳給客戶端的公鑰保護起來。
我們利用CA證書對公鑰進行保護。
先是服務端向CA機構申請，CA機構有一把公鑰和私鑰，其先是用對證書的信息進行哈希，形成摘要，然后對該摘要用私鑰加密，形成數字簽名，在建立連接時，服務器發送帶簽名的證書給客戶端，該證書中包含服務器的公鑰和網站信息，所以要是有中間人進行攻擊時，由于其只要對證書的內容進行更改，客戶端在收到證書，對其進行哈希形成摘要，再用CA機構的公鑰對簽名進行解密，若摘要不匹配，則是不合法的，這就避免了上述的中間人攻擊的場景。服務器的公鑰就得到了保護，然后用該公鑰加密客戶端的密鑰R，給服務器后，兩主機就進行對稱加密從而通信了。