http協議和https協議

HTTP協議

1. 簡介

　　HTTP協議(Hyper Text Transfer Protocol超文本傳輸協議)，是一個基於請求-響應模式的，處於應用層的，創建在TCP上的無狀態鏈接，常基於C/S架構進行通訊。整個基本的工做流程是客戶端發送一個HTTP請求，說明客戶端想要訪問的資源和請求的動做，服務端收到請求以後，服務端開始處理請求，並根據請求作出相應的動做訪問服務器資源，最後經過發送HTTP響應把結果返回給客戶端。一個請求到一個響應的結束稱爲事務，當一個事務結束後還會在服務端添加一條日誌條目。簡單來說，http協議就是服務器和客戶端之間進行數據交互的一種形式，且形式多種多樣。若是要進行擬人化，那http協議就相似於server和client這兩兄弟之間指定的一種交流方式。

2. 經常使用的請求方式

GET：用於請求訪問已經被URI(統一資源標識符)識別的資源，能夠經過URL傳參給服務器。
POST：用於傳輸信息給服務器，主要功能與GET方法相似，多推薦使用POST方式。
PUT：主要用於傳輸文件，報文主題中包含文件內容，保存到對應的URI位置。
HEAD：獲取報文頭部，與GET方法相似，只是不返回報文主體，多用於驗證URI是否有效。
DELETE：刪除文件，與PUT方法相反，刪除對應的URI位置文件。
OPTIONS：查詢響應的URI支持的HTTP方法。

經常使用請求方式

GET方法和POST方法的區別：

　　(1) get重點在從服務器上獲取資源，post重點在向服務器發送數據；
　　(2) get傳輸數據是經過URL請求，以 field = value 的形式，放在url以後，並用"?"進行鏈接，多個請求數據間用"&"鏈接，好比http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的；
　　     post傳輸數據經過Http的post機制，將字段與對應值封存在請求實體中發送給服務器，這個過程對用戶是不可見的；
　　(3) Get傳輸的數據量小，主要受URL長度限制，但效率較高；
　　　  Post能夠傳輸大量數據，因此上傳文件時只能用Post方式；
　　(4) get是不安全的，由於url是可見的，可能會泄露私密信息，如密碼等；而post較get安全性較高；
　　(5) get方式只能支持ASCII字符，向服務器傳的中文字符可能會亂碼。而post支持標準字符集，能夠正確傳遞中文字符。

3. 狀態碼

1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操做
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現
5xx：服務器端錯誤--服務器未能實現合法的請求

200：請求被正常處理
204：請求被受理但沒有資源能夠返回
206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執行GET方法，相應報文中經過Content-Range指定範圍的資源。

301：永久性重定向
302：臨時重定向
303：與302狀態碼有類似功能，只是它但願客戶端在請求一個URI的時候，能經過GET方法重定向到另外一個URI上
304：發送附帶條件的請求時，條件不知足時返回，與重定向無關
307：臨時重定向，與302相似，只是強制要求使用POST方法

400：請求報文語法有誤，服務器沒法識別
401：請求須要認證
403：請求的對應資源禁止被訪問
404：服務器沒法找到對應資源

500：服務器內部錯誤
503：服務器正忙

4. 請求格式和響應格式

(1) 請求格式

請求格式包含三部份內容：

    請求行：請求方法 | URL路徑 | 協議版本 \r\n
    請求頭：頭部字段名：值 \r\n
　　 \r\n
    請求體(get請求沒有請求體)

(2) 響應格式

響應報文的三部份內容：

    狀態行：協議版本 | 狀態碼 | 狀態描述 \r\n
    響應頭：頭部字段名：值 \r\n
    \r\n
    響應體(HTML文本)

5. url

　　統一資源定位符，會從因特網獲取信息的五個基本元素包括在一個簡單的地址中

　　

 

 HTTPS協議

1. 簡介

　　HTTPS(Secure Hypertext Transfer Protocol)，是安全超文本協議，在HTTP上創建SSL加密層，對傳輸的數據進行加密

2.HTTPS加密技術

　　1. 對稱密鑰加密

        SSL採用的加密技術叫作「共享密鑰加密」，也叫做「對稱密鑰加密」，客戶端向服務器發送一條信息，客戶端會採用已知的算法對信息進行加密，在傳輸信息的過程當中密鑰也會進行加密發送，服務器接收到信息後會用傳遞過來的密鑰對數據進行解密。這種方式看起來安全，但仍有潛在危險，若是被竊聽或者信息被劫持，就有可能破解密鑰

　　2. 非對稱密鑰加密

　　非對稱密鑰加密須要使用兩把鎖，一個是私鑰，另外一個公鑰。使用非對稱密鑰加密時，服務器要預先給客戶端一個公鑰，讓客戶端按照這個公鑰對數據進行加密，在服務器接收到信息後再用本身的私鑰進行解密。這樣一來破解的密鑰是不會進行傳輸的，也就避免了被挾持的風險，但非對稱密鑰加密也有一些缺點：(1) 如何保證服務器向客戶端發出公開密鑰時，服務器確保收到的是預先要發送的；(2) 效率比較低，處理起來更爲複雜，有必定的效率問題會影響通訊速度

　　3. 證書密鑰加密

　　在對稱密鑰加密和非對稱密鑰加密兩種加密方式中，都會有必定的問題，這就引出了公開密鑰證書機制。數字證書認證機構是客戶端和服務器都相互信賴的第三方機構。

　　服務器的開發者攜帶公開密鑰，向數字證書認證機構提出公鑰的申請，數字證書認證機構審覈申請者的身份，審覈經過之後，會對開發者申請的公鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將密鑰放在證書裏面，綁定在一塊兒

　　服務器把這個數字證書發送給客戶端，由於客戶端也承認認證機構，客戶端能夠經過證書中的數字簽名來驗證公鑰的真僞，確保服務器傳過來的公鑰是真實的。在通常狀況下，證書的數字簽名很難被僞造，這取決於認證機構的公信力。一旦確認信息無誤以後，客戶端就會經過公鑰對報文進行加密發送，服務器接收到之後用本身的私鑰進行解密。