前言
這篇文章我想寫很久了，本來想等應用用上https之后再進行闡述。但是時不我待，感覺我們的項目在需求的壓力下，暫時沒有人、精力來完善這一塊。但是我并不想我之前的研究白費，所以我就在這里寫下，我所了解的https。
http協(xié)議
首先我并不會很深入的去探討這個東西，即使我曾經(jīng)花了很長的時間去研究這個東西。主要是我考慮到
1、 自己沒有系統(tǒng)的去學習這一塊的知識，講解的會比較的膚淺。
2、 就算是懂這個東西也不一定會為諸位看官講清楚這個東西。
考慮到上面兩條，我決定關于http這一塊，我就重點來講：
1、http的基本概念
2、http的三次握手
3、http的四次揮手
4、常用的http方法
5、常用的http狀態(tài)碼
1、http的基本概念：
協(xié)議是指計算機通信網(wǎng)絡中兩臺計算機之間進行通信所必須共同遵守的規(guī)定或規(guī)則，超文本傳輸協(xié)議(HTTP)是一種通信協(xié)議，它允許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。
http協(xié)議，即超文本傳輸協(xié)議。是一種詳細規(guī)定了瀏覽器和萬維網(wǎng)服務器之間互相通信的規(guī)則，通過因特網(wǎng)傳送萬維網(wǎng)文檔的數(shù)據(jù)傳送協(xié)議。
http協(xié)議是用于從萬維網(wǎng)服務器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。
http是一個應用層協(xié)議，由請求和響應構成，是一個標準的客戶端服務器模型。
http協(xié)議永遠都是客戶端發(fā)起請求，服務器回送響應。這樣就限制了使用http協(xié)議，無法實現(xiàn)在客戶端沒有發(fā)起請求的時候，服務器將消息推送給客戶端。
http協(xié)議的主要特點可概括如下：
1、支持客戶/服務器模式。支持基本認證和安全認證。
2、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有get、head、post。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同。由于http協(xié)議簡單，使得http服務器的程序規(guī)模小，因而通信速度很快。
3、靈活：http允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標記。
4、http 0.9和1.0使用非持續(xù)連接：限制每次連接只處理一個請求，服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。http 1.1使用持續(xù)連接：不必為每個web對象創(chuàng)建一個新的連接，一個連接可以傳送多個對象，采用這種方式可以節(jié)省傳輸時間。
5、無狀態(tài)：http協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。
2、http的三次握手
談到http必定就會談到的一個問題--http的三次握手，三次握手其實你真正明白這個問題了之后，這個東西會被你想的很簡單。首先你要明白三次揮手是用來干嘛的？
在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務，采用三次握手建立一個連接。如下圖所示
希望有大佬們推薦一個好用的畫圖軟件
首先明白上面的含義的時候，你必須要了解幾個狀態(tài)的含義：SYN(synchronous建立聯(lián)機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)。
結合上圖我們將連接過程分為三個過程：
（1）：首先是客戶端發(fā)送syn包(syn=j)到服務器，并進入SYN_SEND狀態(tài)，等待服務器確認；
（2）：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態(tài)；
（3）：客戶端收到服務器的SYN＋ACK包，向服務器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務器進入ESTABLISHED狀態(tài)，完成三次握手。 完成三次握手，客戶端與服務器開始傳送數(shù)據(jù)。
3、http的四次揮手
由于TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的數(shù)據(jù)發(fā)送任務后就能發(fā)送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數(shù)據(jù)流動，一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。首先進行關閉的一方將執(zhí)行主動關閉，而另一方執(zhí)行被動關閉。如下圖所示
結合上圖可知，我們將關閉連接的過程劃分為四個過程：
（1）客戶端發(fā)送一個FIN，用來關閉客戶到服務器的數(shù)據(jù)傳送。
（2）服務器收到這個FIN，它發(fā)回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將占用一個序號。
（3）服務器關閉與客戶端的連接，發(fā)送一個FIN給客戶端。
（4）客戶端發(fā)回ACK報文確認，并將確認序號設置為收到序號加1。
4、常用的http方法與使用場景
http的方法有很多，大概有：
1、 GET：用于請求訪問已經(jīng)被URL（統(tǒng)一資源標識符）識別的資源，可以通過URL傳參給服務器。
2、 POST：用于傳輸信息給服務器，主要功能與Get方法類似，但一般推薦POST方式。
3、 PUT：傳輸文件，報文主體包含文件內(nèi)容，保存到對應URL位置。
4、 HEAD：獲取報文首部，與GET方法類似，只是不返回報文主體，一般用于驗證URL是否有效。
5、 DELET：刪除文件，與PUT方法相反，刪除對應URL位置的文件。
6、 OPTIONS：查詢相應URL支持的HTTP方法。
但是我經(jīng)常使用的還是get加post，我在這里就簡單的介紹一下get/post的區(qū)別吧：
（1） get請求一般用來獲得數(shù)據(jù)，而post請求一般用來發(fā)送數(shù)據(jù)。人們期望，get請求不會對服務器造成任何影響，而post請求則可能會影響服務器端的數(shù)據(jù)。get請求消耗的資源較post請求而言，會少一些，但相對安全性較差。發(fā)送同樣大小的數(shù)據(jù)，get請求的效率最高可以達到post請求的2倍。
（2）一般按照約定，使用get請求時，將數(shù)據(jù)通過url進行傳遞，而是用post請求時，將數(shù)據(jù)放在body里。但這并非硬性規(guī)定，因為method和data本身是正交的。post請求亦可將數(shù)據(jù)放在url中。
（3）就協(xié)議底層實現(xiàn)而言，在get請求中，只產(chǎn)生一個TCP數(shù)據(jù)包，瀏覽器會將header和data一并發(fā)送出去，等待服務器的回應；而在post請求中，會產(chǎn)生2個TCP數(shù)據(jù)包。，瀏覽器先發(fā)送header，服務器響應100 continue，瀏覽器再發(fā)送data。
5、常用的http狀態(tài)碼
總的來說，我現(xiàn)在項目有用到的：
200 OK 請求正常處理完畢
204 No Content 請求成功處理，沒有實體的主體返回
304 Not Modified 發(fā)送的附帶條件請求未滿足
400 Bad Request 請求報文語法錯誤或參數(shù)錯誤
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，因此加密的詳細內(nèi)容就需要 SSL，用于安全的 HTTP 數(shù)據(jù)傳輸。眾所周知，我們在使用http協(xié)議的時候，數(shù)據(jù)的交換都是明文，這樣就會帶來很大的信息安全于是引入了https。
我在這里呢？主要是講述https的對稱加密和非對稱加密。后面我在真正開始寫算法章節(jié)的時候，會重點來講一講我研究的幾個加密算法。
1、對稱加密
對稱加密呢？打個不切當?shù)谋确剑∶骱托〖t在上學的時候互生情愫，但是又害怕被父母發(fā)現(xiàn)。于是他們想到了一個辦法，就是他們在一個大樹下面放了一個箱子，并且用鎖鎖起來。如果小紅給小明寫了信，就通知小明拿著鑰匙去去放在箱子里面的信。小明取信也是如此。
小明和小紅的鑰匙就好比對稱加密中數(shù)據(jù)傳輸雙方的公鑰，數(shù)據(jù)可以通過公鑰加密后，通過他們僅有他們知道的公鑰去解密。這種加密方法一定程度上面做到加密的效果。這樣做的好處主要有：對稱加密算法的優(yōu)點是算法公開、計算量小、加密速度快、加密效率高。但是如果小明和小紅的鑰匙遺失也就是保密雙方的公鑰丟失，或者小明、小紅的鑰匙被泄漏也就是公鑰解密方式被泄漏 這樣也就達不到加密的效果了。
我這里有一個不恰當?shù)膭赢?/p>
背景：小明和小紅買了一個箱子，一把鎖。兩個人揣著兩把鎖的鑰匙，想通過這個來傳遞書信。
一回目 小明：小紅，我給你寫了一封信。（對稱加密）
二回目 小紅拿出箱子的鑰匙，打開箱子讀取小明寄來的書信。（對稱解密）
三回目 小紅：小明，我給你回信了，（對稱加密）
四回目 小明拿出箱子的鑰匙，打開箱子讀取小紅回寄的書信。（對稱解密）
2、非對稱加密
既然對稱加密方式存在很大程度上的缺陷。于是聰明的計算機先輩們就發(fā)明了非對稱加密。關于非對稱加密呢？其運行的方式：
首先乙方生成一對密鑰（公鑰和私鑰）并將公鑰向其它方公開。然后得到該公鑰的甲方使用該密鑰對機密信息進行加密后再發(fā)送給乙方。最后乙方再用自己保存的另一把專用密鑰（私鑰）對加密后的信息進行解密。乙方只能用其專用密鑰（私鑰）解密由對應的公鑰加密后的信息。反之也一樣。
這樣做的話，即使在傳輸過程中攻擊者截獲了傳輸?shù)拿芪?，并得到了乙的公鑰，也無法破解密文，因為只有乙的私鑰才能解密密文。這種方式在一定程度加強了數(shù)據(jù)的安全性。但是同樣非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量數(shù)據(jù)進行加密。
同樣我在這里也畫了一個動畫。
背景：被雙方媽媽掌握鑰匙的小男女，于是雙方都買了一個未上鎖的箱子
一回目 小紅拿著未上鎖的箱子跟小明說：小明，如果你想跟我寫信，就放在這個箱子里面。
二回目 小明將寫好的書信，放在箱子里面，并且鎖好，并跟小紅說：小紅，我給你寫信了。
三回目 小紅拿出箱子的鑰匙，將箱子里面的書信取出來，開心的讀了起來并感慨：小明真有趣。
最后說點https和http
1、 基本概念：
HTTP：是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從萬維網(wǎng)服務器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡傳輸減少。
HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內(nèi)容就需要SSL。HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩涣硪环N就是確認網(wǎng)站的真實性。
2、 http與https有什么區(qū)別
1、https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比http協(xié)議安全。
說在最后
這篇文章其實早就該寫出來了，但是自己挨都今天才去發(fā)表 講道理還是比較拖延癌的前兆的。其實這篇文章并不是我研究的全部，但是我這篇文章的目的是讓各位看官大致的認識到https和http。好了，最近提倡早睡、早起 就不繼續(xù)寫下去了。準備手繪幾張對稱/非對稱圖來加深大家對這個的理解。如果有好的畫圖工具可以跟我說一哈，不然我自己都看不下去我的手繪了。
如果您覺得不錯，請別忘了轉(zhuǎn)發(fā)、分享、點贊讓更多的人去學習，順便再給大家推薦一個架構交流群：617434785，里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務架構的原理，JVM性能優(yōu)化這些成為架構師必備的知識體系。還能領取免費的學習資源。相信對于已經(jīng)工作和遇到技術瓶頸的碼友，在這個群里會有你需要的內(nèi)容。
