談一談我所瞭解的https
一、 http協議
首先我並不會很深入的去探討這個東西，即使我曾經花了很長的時間去研究這個東西。主要是我考慮到
1、 自己沒有系統的去學習這一塊的知識，講解的會比較的膚淺。
2、 就算是懂這個東西也不一定會為諸位看官講清楚這個東西。
考慮到上面兩條，我決定關於http這一塊，我就重點來講：
1、http的基本概念
2、http的三次握手
3、http的四次揮手
4、常用的http方法
5、常用的http狀態碼
1、http的基本概念：
協議是指計算機通訊網路中兩臺計算機之間進行通訊所必須共同遵守的規定或規則，超文字傳輸協議(HTTP)是一種通訊協議，它允許將超文字標記語言(HTML)文件從Web伺服器傳送到客戶端的瀏覽器。
http協議，即超文字傳輸協議。是一種詳細規定了瀏覽器和全球資訊網伺服器之間互相通訊的規則，通過因特網傳送全球資訊網文件的資料傳送協議。
http協議是用於從全球資訊網伺服器傳輸超文字到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示(如文字先於圖形)等。
http是一個應用層協議，由請求和響應構成，是一個標準的客戶端伺服器模型。
http協議永遠都是客戶端發起請求，伺服器回送響應。這樣就限制了使用http協議，無法實現在客戶端沒有發起請求的時候，伺服器將訊息推送給客戶端。
http協議的主要特點可概括如下：
2、簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有get、head、post。每種方法規定了客戶與伺服器聯絡的型別不同。由於http協議簡單，使得http伺服器的程式規模小，因而通訊速度很快。
3、靈活：http允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
4、http 0.9和1.0使用非持續連線：限制每次連線只處理一個請求，伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。http 1.1使用持續連線：不必為每個web物件建立一個新的連線，一個連線可以傳送多個物件，採用這種方式可以節省傳輸時間。
2、tcp的三次握手
談到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狀態，完成三次握手。 完成三次握手，客戶端與伺服器開始傳送資料。
3、tcp的四次揮手
由於TCP連線是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。如下圖所示：
結合上圖可知，我們將關閉連線的過程劃分為四個過程：
（1）客戶端傳送一個FIN，用來關閉客戶到伺服器的資料傳送。
（2）伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將佔用一個序號。
（3）伺服器關閉與客戶端的連線，傳送一個FIN給客戶端。
（4）客戶端發回ACK報文確認，並將確認序號設定為收到序號加1。
4、常用的http方法與使用場景
http的方法有很多，大概有：
1、 GET：用於請求訪問已經被URL（統一資源識別符號）識別的資源，可以通過URL傳參給伺服器。
2、 POST：用於傳輸資訊給伺服器，主要功能與Get方法類似，但一般推薦POST方式。
3、 PUT：傳輸檔案，報文主體包含檔案內容，儲存到對應URL位置。
4、 HEAD：獲取報文首部，與GET方法類似，只是不返回報文主體，一般用於驗證URL是否有效。
5、 DELET：刪除檔案，與PUT方法相反，刪除對應URL位置的檔案。
6、 OPTIONS：查詢相應URL支援的HTTP方法。（OPTIONS請求方法的主要用途有兩個：1、獲取伺服器支援的HTTP請求方法；也是黑客經常使用的方法。2、用來檢查伺服器的效能。例如：AJAX進行跨域請求時的預檢，需要向另外一個域名的資源傳送一個HTTP OPTIONS請求頭，用以判斷實際傳送的請求是否安全。）
但是我經常使用的還是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。
5、常用的http狀態碼
| 狀態碼 | 響應類別 | 原因短語 |
|---|---|---|
| 1XX | 資訊性狀態碼（Informational） | 伺服器正在處理請求 |
| 2XX | 成功狀態碼（Success） | 請求已正常處理完畢 |
| 3XX | 重定向狀態碼（Redirection） | 需要進行額外操作以完成請求 |
| 4XX | 客戶端錯誤狀態碼（Client Error） | 客戶端原因導致伺服器無法處理請求 |
| 5XX | 伺服器錯誤狀態碼（Server Error） | 伺服器原因導致處理請求出錯 |
總的來說，我現在專案有用到的：
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 伺服器超負載或停機維護
二、 https概述
什麼是https呢？可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL，用於安全的 HTTP 資料傳輸。眾所周知，我們在使用http協議的時候，資料的交換都是明文，這樣就會帶來很大的資訊保安於是引入了https。
我在這裡呢？主要是講述https的對稱加密和非對稱加密。後面我在真正開始寫演算法章節的時候，會重點來講一講我研究的幾個加密演算法。
1、對稱加密
什麼是對稱加密呢？打個不切當的比方，小明和小紅在上學的時候互生情愫，但是又害怕被父母發現。於是他們想到了一個辦法，就是他們在一個大樹下面放了一個箱子，並且用鎖鎖起來。如果小紅給小明寫了信，就通知小明拿著鑰匙去去放在箱子裡面的信。小明取信也是如此。
小明和小紅的鑰匙就好比對稱加密中資料傳輸雙方的公鑰，資料可以通過公鑰加密後，通過他們僅有他們知道的公鑰去解密。這種加密方法一定程度上面做到加密的效果。這樣做的好處主要有：對稱加密演算法的優點是演算法公開、計算量小、加密速度快、加密效率高。但是如果小明和小紅的鑰匙遺失也就是保密雙方的公鑰丟失，或者小明、小紅的鑰匙被洩漏也就是公鑰解密方式被洩漏 這樣也就達不到加密的效果了。
我這裡有一個不恰當的動畫：
背景：小明和小紅買了一個箱子，一把鎖。兩個人揣著兩把鎖的鑰匙，想通過這個來傳遞書信。
一回目小明：小紅，我給你寫了一封信。（對稱加密）
二回目小紅拿出箱子的鑰匙，開啟箱子讀取小明寄來的書信。（對稱解密）
三回目小紅：小明，我給你回信了，（對稱加密）
四回目小明拿出箱子的鑰匙，開啟箱子讀取小紅回寄的書信。（對稱解密）
2、非對稱加密
既然對稱加密方式存在很大程度上的缺陷。於是聰明的計算機先輩們就發明了非對稱加密。關於非對稱加密呢？其執行的方式：
首先乙方生成一對金鑰（公鑰和私鑰）並將公鑰向其它方公開。然後得到該公鑰的甲方使用該金鑰對機密資訊進行加密後再發送給乙方。最後乙方再用自己儲存的另一把專用金鑰（私鑰）對加密後的資訊進行解密。乙方只能用其專用金鑰（私鑰）解密由對應的公鑰加密後的資訊。反之也一樣。
這樣做的話，即使在傳輸過程中攻擊者截獲了傳輸的密文，並得到了乙的公鑰，也無法破解密文，因為只有乙的私鑰才能解密密文。這種方式在一定程度加強了資料的安全性。但是同樣非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量資料進行加密。
（
另一種理解方式：https://www.cnblogs.com/mujian/p/7665952.html：
非對稱加密在這個時候就發揮作用了，來看看怎麼回事：Bob擁有兩把鑰匙，一把叫做公鑰，一把叫做私鑰。公鑰是公開讓全社會都知道，沒關係，Bob告訴所有人，你們要傳遞資料給我的時候請先用這個金鑰(公鑰)去加密一下你們的資料，加密後的資料只能通過Bob私自藏著的私鑰才能解密。
回到剛剛例子，Bob先發給保險櫃（Bob公鑰）給Alice，接著Alice把自己的保險櫃（Alice公鑰）放到Bob的保險櫃(即使用Bob的公鑰加密Alice的公鑰)裡邊發還給Bob，接著Bob拿到Alice的資料包後，用自己的私鑰解開了外層保險櫃(Bob的公鑰)，拿到了裡邊Alice保險櫃(Alice的公鑰)。此時Alice跟Bob都有了各自的公鑰(並且都有他們自己的私鑰)，接著只要保證每次互相傳遞資料的時候，把資料放在對方的保險櫃裡邊即可(即每次都用對方的公鑰加密資料)，這樣無論如何，H都無法解開保險櫃（因為只有各自的私鑰才能解開各自的保險櫃）。
）
同樣我在這裡也畫了一個動畫：
背景：被雙方媽媽掌握鑰匙的小男女，於是雙方都買了一個未上鎖的箱子
一回目小紅拿著未上鎖的箱子跟小明說：小明，如果你想跟我寫信，就放在這個箱子裡面。
二回目小明將寫好的書信，放在箱子裡面，並且鎖好，並跟小紅說：小紅，我給你寫信了。
三回目小紅拿出箱子的鑰匙，將箱子裡面的書信取出來，開心的讀了起來並感慨：小明真有趣。
三、 最後說點https和http
1、 基本概念：
HTTP：是網際網路上應用最為廣泛的一種網路協議，是一個客戶端和伺服器端請求和應答的標準（TCP），用於從全球資訊網伺服器傳輸超文字到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少。
HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。HTTPS協議的主要作用可以分為兩種：一種是建立一個資訊保安通道，來保證資料傳輸的安全；另一種就是確認網站的真實性。
2、 http與https有什麼區別
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文字傳輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。
4、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。
轉載於:https://my.oschina.net/JKOPERA/blog/1922222