最好對http協議有所了解，不需要太透徹，但是基本概念要知道。如果能懂一些tcp/ip 方面的東西就更好了。
還不知道tcp三次握手的同學，可以先自行搜尋一下相關知識。這裡為什麼要複習tcp三次握手，因為http鏈結是在這之上的， 任何乙個http鏈結，都需要tcp的三次握手的過程，https下面的加密層其實和這個有異曲同工之妙。況且通過這次複習，我們還能學習下wireshark的相關知識。掌握wireshark對我們弄懂https至關重要。 簡單貼一下，tcp 三次握手的流程：
到這裡，相信有基礎的同學應該都回憶起來這是怎麼回事了。我不做過多解釋，直接上工具wireshark。 我們隨便輸入乙個http的位址（注意不要訪問https的，有些**比如bat這種大**你輸入http也會直接轉成https所以我們還是 隨便選個小**確保是http的）
然後明顯能看出來是吧，有三次tcp的過程，然後才是http的鏈結。
細緻分析下這個三次握手的過程：
第一次握手：主機a傳送位碼為syn＝1,隨機產生seq number=0的資料報到伺服器，主機b由syn=1知道，a要求建立聯機；
第二次握手：主機b收到請求後要確認聯機資訊，向a傳送ack number=(主機a的seq+1),syn=1,ack=1,隨機產生seq=0的包
第三次握手：主機a收到後檢查ack number是否正確，即第一次傳送的seq number+1,以及位碼ack是否為1，若正確，主機a會再傳送ack number=(主機b的seq+1),ack=1，主機b收到後確認seq值與ack=1則連線建立成功。
完成三次握手，主機a與主機b開始傳送資料。
有的人可能會問，seq number不是隨機number嗎，你這裡怎麼都是0啊。
點開詳細：
這裡面告訴你了 是相對數字，方便你看。你當然可以選擇看實際數字 加深理解
在這個裡面把相對數字選項勾選掉，就可以看到真實的seq number了
怎麼樣這裡是不是就豁然開朗了，當然明白就好，平時最好還是勾選這個選項這樣理解的快一點。
這也是理解https的重要基礎之一。這裡涉及到很多複雜的演算法，我並不精通演算法和密碼學，所以這裡不講的太細。你們只要知道個大概即可：
對稱加密：加密和解密都用乙個金鑰，有點是速度快。缺點嗎，顯而易見的是 雙方要用這個通訊的話 必須得把金鑰告知對方， 但是這個金鑰一旦被截獲了，就可以隨便decode出來明文。實際上不夠安全。
非對稱加密：有一對金鑰，即有公鑰也有私鑰。公鑰隨便發，私鑰不會發出去 各自保管。用乙個加密的話，解密就只能用另外乙個。比如你向銀行請求乙個公鑰，銀行把公鑰發給你，你用公鑰加密一條資訊以後 再發給銀行，然後銀行用私鑰解密資訊。這個過程就算有人拿到公鑰，但是因為非對稱加密用乙個加密 只能用另外乙個解密，所以 拿到這公鑰也沒用，因為無法使用公鑰解密，能解密的私鑰還在銀行那裡，銀行當然不會傳出去，所以非對稱加密很安全。 但是這種非對稱加密非常消耗資源，速度極慢，所以要有限使用。不能無節制使用。
hash加密演算法：這個就好像md5這樣的加密方式，是不可逆的。
這個很好理解是吧，敏感資訊肯定要加密的，明文傳輸等於自殺。不過多解釋了。
這個很多人不理解，這是啥意思，按道理說我們用非對稱加密應該就完美了啊。但是謹記我們的資料報不是從a直接到b的。 中間要經過無數次的路由器**等等，這個中間一旦有人截獲了我們的資料報，換成自己的資料報，就很危險了。 所以我們還需要一種機制能校驗通訊雙方的身份。確保我是在和我老婆說話 而不是在我和丈母娘說話。
這個也不是很容易理解，按道理說tcp是能保證資料有序完整的到達對方的。但是不要忘記中間我們經過的無數次路由器**， 可能被劫持，被劫持以後可能會對資料報進行篡改，這個時候我們需要一種機制保護我們的資料不被篡改，即使被篡改 也能被我們察覺，確保我對我老婆寫的信能完整的讓我老婆看到，而不是只看到一半。
根據前面我們闡述的加密演算法和安全通訊三原則，為了保證我們的通訊能夠安全進行，可以試想出一種流程來保證通訊安全：
目前來看，這個思路是不是很完美。公鑰即使被中間人截獲以後也沒用，因為拿到公鑰也解密不出來到底雙方是用哪種演算法加密的。 但有個重大缺陷：
中間人可以將伺服器傳送的公鑰包進行掉包，客戶端怎麼知道這個公鑰是真的伺服器傳送的還是假的中間人給的非法公鑰呢？
可以看這張圖，基本上中間人攻擊就是這個圖所示的意思。
這個問題的解決辦法其實也很粗暴：
帶來的問題：
客戶端到哪去取第三方公鑰?
為什麼https的流程要放在最後再講，因為放在前面講，根本不會理解為啥要這麼做，很快就會忘記。有了前面的基礎 再來看這個流程，就會恍然大悟。
目標訪問位址就用github吧。 抓出來是這樣的。
注意看tlsv1的就可以了這個就是加密層。
下面就來逐步分析
注意到這裡伺服器和客戶端就有2個隨機數了。並且加密演算法也確定了。
這部分主要是傳送證書資訊的 點開以後 證書的詳細資訊都能看到 另外serverhellodone的意思就是伺服器的工作都完畢了。
可以看出來這裡一共有三個步驟，我們來依次分析 這三次動作都做了什麼
client key exchange
這個session ticket就是伺服器最後一步的時候傳給客戶端的乙個資料。 這個加密資料客戶端收到以後就可以儲存下來，這樣下一次再請求https的 時候，就可以把這個session ticket發過去，這樣可以省很多握手的時間和 資源消耗。（前面我們分析的4-5步其實已經相當複雜了，尤其是非對稱加密對服務端的資源消耗相當之大）
實際上對於多數瀏覽器來說，指向同乙個網域名稱的https連線，我們都會有意識的讓第乙個https連線完成握手之後再連線第n個 https。因為這樣 後續的https 就可以攜帶相關資訊，可以省很多資源
這個ticket實際上就有點類似cookie。
在筆者的這次訪問chrome-gitub的過程中，瀏覽器並沒有使用ticket技術 而是使用的seession id技術：
sessionid 實際上作用和ticket差不多，但是sessionid 無法做到伺服器之間同步，畢竟id 存在伺服器記憶體中，負載均衡帶來的狀態機同步是乙個大問題。
深入理解https
首先，我們來說一下http協議的缺點。主要有一下三條 1 通訊使用明文，內容可能會被竊聽。2 通訊方身份無法確認。3 收到的報文可能已經被修改。所以我們來採用https來解決以上問題。http 加密 認證 完整性保護 https tcp ip協議族分為四層 應用層，傳輸層，網路層，鏈路層。首先我們要...
深入理解HTTPS通訊原理
一 https簡介 二 https與http的區別 1 https的伺服器需要到ca申請證書，以證明自己伺服器的用途 2 http資訊是明文傳輸，https資訊是密文傳輸 3 http與https的埠不同，乙個是80埠，乙個是443埠 可以說http與https是完全不同的連線方式，https集合了...
TCP協議深入理解
tcp協議在能夠傳送資料之前就建立起了 連線 要實現這個連線，啟動tcp連線的那一方首先將傳送乙個syn資料報。這只是乙個不包含資料的資料報，然後，開啟syn標記。如果另一方同時在它收到syn標記的埠通話，它將發回乙個syn ack syn和ack標誌位都被開啟，並將ack 確認 編號字段設定為剛收...