692-詳解HTTP和HTTPS協議

HTTP協議簡介

HTTP是請求應答式協議：客戶端發給請求的訊息是請求訊息，服務器回傳給客戶端的是回應訊息，請求訊息和回應訊息是成對的
服務器不會主動發訊息給客戶端，請求訊息都是客戶端發給服務器，服務器都是被動回應的，

tcp建立的是一條傳輸的通道，通道上傳輸的內容是由http協議定義的

我們舉個例子：

網址的第一部分是http或者https協議名
第二部分是命名
第三部分是請求部分的頁面的相對地址
我們輸入域名，客戶端會把域名資訊發送給DNS服務器決議，對域名決議出對應的IP地址，回傳給客戶端，客戶端拿到IP之后，向IP所在的服務器請求，請求服務器把頁面的資源資訊回傳給客戶端，

HTTP協議的特點

長連接的報文的頭部表示：

意味著請求和回應處理完之后，TCP通道不需要關閉，

短連接的報文的頭部表示：
connection close
表示請求得到回應后，就關閉TCP的通道

無狀態：http不知道當前的請求和之前的請求是來自同一個客戶端的

現在，我們訪問的基本都是動態的網頁，有互動性，后面的請求對前面的請求有依賴性， http協議在1.0 1.1版本后，服務器回應的時候會添加一個session資訊，客戶端的下一次請求會把session資訊加上，發給服務器，

HTTP協議的訊息結構

我們登錄一個頁面，看看登錄的請求訊息結構：

上圖中藍色的部分是請求頭（header）

因為剛才請求的是登錄的資訊，賬戶密碼之間是通過&區分的

我們現在看看回應的訊息結構：

回應的頭部資訊如下：

然后是空行，然后就是物體：服務器回傳html頁面的內容：


為什么上圖顯示的是這樣，是因為圖片和其他資源是根據其他的請求來去獲取的，

舉個例子：我們客戶端在瀏覽器輸入的只是一個網址，但是實際上背后和服務器之間，一個頁面是有多少個請求，是取決于這個頁面上有多少個資源，一個頁面很有可能是多個資源：圖片的資源，html檔案，CSS格式，文本，程式處理結果，它們各自都需要一個請求和回應，
客戶端會把多次服務器回應的結果合在一起顯示出來，所以我們看到的是完整的頁面

HTTP各個版本演變程序

HTTP協議請求方法

第一部分的POST是請求的方法
每一個部分之間用空格隔開
第二部分是URL的地址：（統一資源定位：請求的這個資源，頁面，圖片，是在服務器上的哪個位置）

第三部分是：HTTP請求和版本

請求方法：

打開首頁：用的是GET方法：

HEAD：


回應的只有頭部資訊，沒有body回應體資訊了，
PUT：更新，客戶端向服務器指定位置更新內容

DELETE：客戶端請求服務器洗掉掉我URL所標識的資源，比如說洗掉服務器某個位置的圖片，但是這個方法存在不安全性，會被有的站點禁用，


沒有權限洗掉服務器上的圖片，這個方法被禁用了，

TRACE：測驗診斷
CONNECT：把串行的形式改成管道或者代理服務器的方式，在1.1版本后開始的，比如說，一個長連接，有很多請求過去，是串行的，第一個請求沒有處理完，第二個請求是沒有辦法發出去的，如果是改成管道的方式，那么第一個請求沒處理完，其他請求也可以過去，

OPTIONS：可以去查這個URL資源在服務器上是支持哪些方法

GET和POST的區別：

1、功能不一樣
GET方法是：客戶端從服務器某個位置獲取資源資料，比如說打開首頁，獲取首頁的資源到客戶端，
POST方法是：客戶端提交資料給服務器，比如說，登錄，注冊，提交表單資料給服務器，
2、引數
GET方法的引數是放在URL地址中的：

登錄也可以使用PUT方法：實作的時候引數在URL中的：

POST方法的引數在報文中的body部分傳過去的：

POST方法的安全性更高，不通過抓包工具是看不到的，而且可以加密的
GET方法：引數是用戶可見的，安全性較低

3、傳送的資料量
GET請求傳送的資料量比較小：不超過2KB
POST請求傳送的資料量比較大：原則上沒有限制，和web服務器的版本有關系，IF4的最大限制資料大小是80KB，IF5的最大限制請求資料的大小是100KB

HTTP協議常見請求首部欄位

請求頭可以包含很多資訊：

這部分往往是通過客戶端header告訴服務器我客戶端的情況

我們現在訪問百度：

Host變成是域名了，

服務器想知道當前請求和之前的請求有沒有關系，可以發送Cookie給客戶端，客戶端可以把這個資訊加到請求訊息中，服務器就可以進行判斷了
http本身不加密，我們通過自己的應用程式的手段去加密

HTTP協議回應狀態碼

回應頭：補充回應的附加的資訊，包括服務器的資訊，服務器對客戶端的附加要求，

我們來抓包看看：


第一行是狀態行，包括很多部分，以空格隔開，
HTTP/1.1是協議的版本號
200是狀態碼
OK是狀態描述

藍色部分是回應頭
然后是空行
然后是回應報文的內容（頁面回傳資訊），

回應的狀態碼：

范圍是：100-599
200只是代表客戶端的請求處理成功，不代表服務器對業務邏輯的處理是成功的，
比如說，登錄業務，登錄是成功還是失敗，服務器是不管的，都是回傳200，不管輸入密碼成功還是錯誤，

204：沒有物體部分的回傳，或者是不允許回傳物體部分的資訊，客戶端的頁面不會變更，還是跟原來的一樣，
206：回傳的部分的請求，客戶端在請求的時候在頭部資訊加請求的范圍，從多少位元組到多少位元組，服務器回傳的結果就是206，回傳的是客戶端指定要求的資訊，并不是回傳所有內容，

3xx：客戶端請求的資源很有可能存放的位置變更了，資源和URL地址變更了，要重新定位到另外一個地方：301：客戶端請求的資源資訊是永久的變更到那個地方了，比如說，客戶端是做標簽，存的是以前的URL資訊，301的回應，客戶端會把新的URL資訊給到這里：

把請求的head部分去掉

也可以處理，但是請求的頁面資訊存了301
用了新的地址替換了原來的地址：

加了個/
可以識別出來新的地址是什么，回傳301的錯誤，用新的地址替換原來的地址，而且這個新的地址還是永久性的，這個是目前存放資源的地址，永久性的重定向，

臨時性的重定向：

客戶端目前請求的資源只是臨時改變位置，以后還有可能變回原來的URL地址，客戶端如果做了標簽，臨時重定向是不需要改標簽的，

4XX：客戶端引起的錯誤，客戶端輸錯了地址，回傳4XX，
如果客戶端本身沒有權限去請求服務器的資源，要請求資源，更新資源，獲取資源，沒有權限，也是回傳4XX
400：客戶端的請求出現語法錯誤
403：客戶端請求資源的訪問是被服務器拒絕了，服務器不允許你訪問，不需要給出詳細的理由，服務器也可以在物體說明原因，
404：客戶端輸錯了資源的地址

請求打開一個頁面，但是沒有這個頁面，服務器找不到這個資源資訊，回傳404

5XX：服務器引起的錯誤，服務器沒有實作客戶端的請求造成的
500：服務器內部發生了不可預知的錯誤，或者服務器程式本身有bug
502：連接錯誤，有可能是服務器的服務關閉了，或者是服務器沒有打開或者在維護
503：服務沒有辦法提供給你

502：

狀態碼被表示的并不是完全真實的，有時候可以去自定義的，程式可以決定按什么狀態碼處理，

HTTP協議常見回應首部欄位

回應頭：附加資訊，服務器的資訊，服務器對客戶端的附加要求


location：表示請求的資源的新的URL地址，一般和3XX一起的，
1.1版本默認的是長連接，

HTTP協議的資料是不加密的

我們通過抓包，在請求報頭就可以看到賬戶密碼，都是明文傳輸，安全隱患大

HTTPS協議

https協議，會帶一把鎖的資訊

HTTPS：通過SSL協議來傳輸的HTTP協議

SSL協議（安全套接字協議，為網路通信提供安全，資料完整性的協議）是怎么實作安全性的？
SSL協議屬于應用層的協議，在傳輸層還是走的是TCP協議，


安全隱患：信的內容被第三方看到，信也有可能被掉包，被篡改，接收人是其他人冒充，
加密是可以防止資訊泄漏，別人即使截獲了，也看不到資訊內容，不知道明文是什么，
解決方法：每個接收人持有合法的證書才可以，和收郵件要出示身份證一樣，
完整性保護也是通過加密來實作的，

加密：對稱加密和非對稱加密
SSL是對稱加密+非對稱加密

此處關于對稱加密和非對稱加密可以看我的另外一篇博客：《資料明文傳輸的安全問題》
對稱加密：（加密的密鑰和解密的密鑰是同一個）

HTTPS在傳輸資料的時候采用的是對稱加密算的，
但是接收端和發送端都需要知道演算法和密鑰，演算法好知道，但是密鑰在網路傳輸中是會被第三方截獲，就可以對你的密文解密了，
所以密鑰的傳輸在HTTPS協議中采用的是非對稱加密演算法，

非對稱加密：
安全性非常高，但是比較復雜，操作繁雜，效率低，

加密：121x91=11011
解密：11011x11=121121 取前面一半的數字就是明文，
這樣，加密和解密的演算法不是互為冪函式，加密的密鑰和解密的密鑰不是一樣的，叫做非對稱加密，
加密的密鑰事先已經存在于服務端，然后客戶端的代碼上添加生成相應的加密的密鑰的代碼，客戶端編譯運行時自動生成對應的非對稱密鑰

非對稱加密：解密的密鑰是私鑰，加密的密鑰是公鑰，公鑰是開放給用戶的，可以公用的，

HTTPS在傳輸對稱加密的密鑰的時候，使用非對對稱加密對對稱密鑰加密，進行傳輸，既確保了安全性又保證了高效性，

HTTP和HTTPS的區別總結

正是因為HTTPS的效率和性能比HTTP低很多，而且HTTPS生成證書的時候是需要成本的，所以，很多站點：并不是說所有的資料傳輸都是用HTTPS協議，往往是HTTPS和HTTP相結合，對于敏感的資料的傳輸使用HTTPS協議，對于非敏感的資料的傳輸使用HTTP協議！