談一談我所瞭解的HTTPS

前言

這篇文章我想寫好久了，原本想等應用用上https以後再進行闡述。可是時不我待，感受咱們的項目在需求的壓力下，暫時沒有人、精力來完善這一塊。可是我並不想我以前的研究白費，因此我就在這裏寫下，我所瞭解的https。

http協議

首先我並不會很深刻的去探討這個東西，即便我曾經花了很長的時間去研究這個東西。主要是我考慮到

一、 本身沒有系統的去學習這一塊的知識，講解的會比較的膚淺。

二、 就算是懂這個東西也不必定會爲諸位看官講清楚這個東西。

考慮到上面兩條，我決定關於http這一塊，我就重點來說：

一、http的基本概念

二、http的三次握手

三、http的四次揮手

四、經常使用的http方法

五、經常使用的http狀態碼

一、http的基本概念：

協議是指計算機通訊網絡中兩臺計算機之間進行通訊所必須共同遵照的規定或規則，超文本傳輸協議(HTTP)是一種通訊協議，它容許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。

http協議，即超文本傳輸協議。是一種詳細規定了瀏覽器和萬維網服務器之間互相通訊的規則，經過因特網傳送萬維網文檔的數據傳送協議。

http協議是用於從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。

http是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。

http協議永遠都是客戶端發起請求，服務器回送響應。這樣就限制了使用http協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。

http協議的主要特色可歸納以下：

一、支持客戶/服務器模式。支持基本認證和安全認證。

二、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有get、head、post。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲http協議簡單，使得http服務器的程序規模小，於是通訊速度很快。

三、靈活：http容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

四、http 0.9和1.0使用非持續鏈接：限制每次鏈接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。http 1.1使用持續鏈接：沒必要爲每一個web對象建立一個新的鏈接，一個鏈接能夠傳送多個對象，採用這種方式能夠節省傳輸時間。

五、無狀態：http協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。

二、http的三次握手

談到http一定就會談到的一個問題--http的三次握手，三次握手其實你真正明白這個問題了以後，這個東西會被你想的很簡單。首先你要明白三次揮手是用來幹嗎的？

在TCP/IP協議中，TCP協議提供可靠的鏈接服務，採用三次握手創建一個鏈接。以下圖所示

但願有大佬們推薦一個好用的畫圖軟件

首先明白上面的含義的時候，你必需要了解幾個狀態的含義：SYN(synchronous創建聯機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)。

結合上圖咱們將鏈接過程分爲三個過程：

（1）：首先是客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；

（2）：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

（3）：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與服務器開始傳送數據。

三、http的四次揮手

因爲TCP鏈接是全雙工的，所以每一個方向都必須單獨進行關閉。這個原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP鏈接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另外一方執行被動關閉。以下圖所示

結合上圖可知，咱們將關閉鏈接的過程劃分爲四個過程：

（1）客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送。

（2）服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1。和SYN同樣，一個FIN將佔用一個序號。

（3）服務器關閉與客戶端的鏈接，發送一個FIN給客戶端。

（4）客戶端發回ACK報文確認，並將確認序號設置爲收到序號加1。

四、經常使用的http方法與使用場景

http的方法有不少，大概有：

一、 GET：用於請求訪問已經被URL（統一資源標識符）識別的資源，能夠經過URL傳參給服務器。

二、 POST：用於傳輸信息給服務器，主要功能與Get方法相似，但通常推薦POST方式。

三、 PUT：傳輸文件，報文主體包含文件內容，保存到對應URL位置。

四、 HEAD：獲取報文首部，與GET方法相似，只是不返回報文主體，通常用於驗證URL是否有效。

五、 DELET：刪除文件，與PUT方法相反，刪除對應URL位置的文件。

六、 OPTIONS：查詢相應URL支持的HTTP方法。

可是我常用的仍是get加post，我在這裏就簡單的介紹一下get/post的區別吧：

（1） get請求通常用來得到數據，而post請求通常用來發送數據。人們指望，get請求不會對服務器形成任何影響，而post請求則可能會影響服務器端的數據。get請求消耗的資源較post請求而言，會少一些，但相對安全性較差。發送一樣大小的數據，get請求的效率最高能夠達到post請求的2倍。

（2）通常按照約定，使用get請求時，將數據經過url進行傳遞，而是用post請求時，將數據放在body裏。但這並不是硬性規定，由於method和data自己是正交的。post請求亦可將數據放在url中。

（3）就協議底層實現而言，在get請求中，只產生一個TCP數據包，瀏覽器會將header和data一併發送出去，等待服務器的迴應；而在post請求中，會產生2個TCP數據包。，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data。

五、經常使用的http狀態碼

總的來講，我如今項目有用到的：

200 OK 請求正常處理完畢

204 No Content 請求成功處理，沒有實體的主體返回

304 Not Modified 發送的附帶條件請求未知足

400 Bad Request 請求報文語法錯誤或參數錯誤

401 Unauthorized 須要經過HTTP認證，或認證失敗

403 Forbidden 請求資源被拒絕

404 Not Found 沒法找到請求資源（服務器無理由拒絕）

500 Internal Server Error 服務器故障或Web應用故障

503 Service Unavailable 服務器超負載或停機維護

http概念

https呢？能夠理解爲HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，所以加密的詳細內容就須要 SSL，用於安全的 HTTP 數據傳輸。衆所周知，咱們在使用http協議的時候，數據的交換都是明文，這樣就會帶來很大的信息安全因而引入了https。

我在這裏呢？主要是講述https的對稱加密和非對稱加密。後面我在真正開始寫算法章節的時候，會重點來說一講我研究的幾個加密算法。

一、對稱加密

對稱加密呢？打個不切當的比方，小明和小紅在上學的時候互生情愫，可是又懼怕被父母發現。因而他們想到了一個辦法，就是他們在一個大樹下面放了一個箱子，而且用鎖鎖起來。若是小紅給小明寫了信，就通知小明拿着鑰匙去去放在箱子裏面的信。小明取信也是如此。

小明和小紅的鑰匙就比如對稱加密中數據傳輸雙方的公鑰，數據能夠經過公鑰加密後，經過他們僅有他們知道的公鑰去解密。這種加密方法必定程度上面作到加密的效果。這樣作的好處主要有：對稱加密算法的優勢是算法公開、計算量小、加密速度快、加密效率高。可是若是小明和小紅的鑰匙遺失也就是保密雙方的公鑰丟失，或者小明、小紅的鑰匙被泄漏也就是公鑰解密方式被泄漏 這樣也就達不到加密的效果了。

我這裏有一個不恰當的動畫

背景：小明和小紅買了一個箱子，一把鎖。兩我的揣着兩把鎖的鑰匙，想經過這個來傳遞書信。

一回目 小明：小紅，我給你寫了一封信。（對稱加密）

二回目 小紅拿出箱子的鑰匙，打開箱子讀取小明寄來的書信。（對稱解密）

三回目 小紅：小明，我給你回信了，（對稱加密）

四回目 小明拿出箱子的鑰匙，打開箱子讀取小紅回寄的書信。（對稱解密）

二、非對稱加密

既然對稱加密方式存在很大程度上的缺陷。因而聰明的計算機先輩們就發明了非對稱加密。關於非對稱加密呢？其運行的方式：

首先乙方生成一對密鑰（公鑰和私鑰）並將公鑰向其它方公開。而後獲得該公鑰的甲方使用該密鑰對機密信息進行加密後再發送給乙方。最後乙方再用本身保存的另外一把專用密鑰（私鑰）對加密後的信息進行解密。乙方只能用其專用密鑰（私鑰）解密由對應的公鑰加密後的信息。反之也同樣。

這樣作的話，即便在傳輸過程當中攻擊者截獲了傳輸的密文，並獲得了乙的公鑰，也沒法破解密文，由於只有乙的私鑰才能解密密文。這種方式在必定程度增強了數據的安全性。可是一樣非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少許數據進行加密。

一樣我在這裏也畫了一個動畫。

背景：被雙方媽媽掌握鑰匙的小男女，因而雙方都買了一個未上鎖的箱子

一回目 小紅拿着未上鎖的箱子跟小明說：小明，若是你想跟我寫信，就放在這個箱子裏面。

二回目 小明將寫好的書信，放在箱子裏面，而且鎖好，並跟小紅說：小紅，我給你寫信了。

三回目 小紅拿出箱子的鑰匙，將箱子裏面的書信取出來，開心的讀了起來並感慨：小明真有趣。

最後說點https和http

一、 基本概念：

HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從萬維網服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。

HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

二、 http與https有什麼區別

一、https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。

二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

三、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

說在最後

這篇文章其實早就該寫出來了，可是本身挨都今天才去發表 講道理仍是比較拖延癌的前兆的。其實這篇文章並非我研究的所有，可是我這篇文章的目的是讓各位看官大體的認識到https和http。好了，最近提倡早睡、早起 就不繼續寫下去了。準備手繪幾張對稱/非對稱圖來加深你們對這個的理解。若是有好的畫圖工具能夠跟我說一哈，否則我本身都看不下去個人手繪了。

若是您以爲不錯，請別忘了轉發、分享、點贊讓更多的人去學習