二、tcp的三次握手
通過流程圖可以看出(也可以看圖1 的19368到19370這三個編號)，首先客戶端向服務端發起一個SYN的請求，序號(Seq)為0，確認號(ACK)也為0，這代表是本次是由客戶端發起的首次請求。本次請求的數據長度為0
然后服務端給客戶端響應，此時服務端的Seq也是0，代表這是服務端的第一次回應，并且給客戶端說，你的請求我已經收到了(ACK=1)，
最后返還給客戶端以后，客戶端的序號 1，并且對服務端的響應做出確認，最后回給服務端，此時ACK=1，Seq=1
tcp的握手過程建立成功。
三、ssl連接的建立
通過以上可以看出，SSL也是建立在TCP的基礎上的，經過tcp的三次握手，接下來才是加密信道的建立。
客戶端和服務端建立安全連接大致經過以下幾個步驟
客戶端：ClientHello 服務端：Server Hello，Server certificate，Server Exchange，Server Hello Done 客戶端：client Exchange 客戶端：Application Data 服務端：New Session 服務端：Application Data
接下來看這幾個步驟中具體的每一個步驟傳輸的內容
ClientHello
client首先給服務端打招呼，對服務端說hello
應用層沒什么特別的
客戶端向服務端發送202個字節的數據，并且客戶端此時的 seq num 為1 ，tcp三次握手已經通過了，所以客戶端ack num 確認的是服務端的tcp的最后一次信息。由于這次發送的長度是202個字節，所以給服務端說，下一個字節序列號是從203開始的。
標志位為ACK和PSH
但是這次多了一個 Secure Socket layer層。協議使用的時候，用的是Handshake Protocol，給服務端發消息ClientHello
詳細的信息如下：
Secure Socekts layer層使用的是版本是TLS 1.0
HandShake Type的類型，是客戶端打招呼 client hello
HandShake protocol 協議使用的是TLS 1.2
發送的信息還有客戶端在本地生成的隨機碼(Random)
然后客戶端聲明自己所支持的加密套件(Cipher Suites)這個客戶端支持15種加密套件
加密套件中表明了使用的對稱加密算法，非對稱加密算法，摘要算法以及使用的是TLS或者是SSL
還有一些其他的信息
第一行指明是否進行了壓縮以及使用的壓縮算法，第二行null表明未進行壓縮，以及選用相關的壓縮算法或者壓縮工具
剩下的就是一些擴展的字段了
總結下來，客戶端向服務端第一次打招呼(client Hello)的時候實際上主要發送了以下主要的信息
客戶端的隨機數
客戶端所支持的加密套件
以及客戶端和服務器之間的sessionId
接下來就是服務端對客戶端Hello的第一次回應，也就是編號19372
可以看到 服務端使用的是443端口，序列號(Sequence number)也是1 ，并且回應客戶端說我已經確認收到你的202個自己的數據(203-1)，Flags表明本次是服務端反饋給客戶端請求的應答(藍色的文字也寫出來了，這是一個隊19371編號的應答)
可以看出這是一個TCP連接
Server Hello
接下來不等客戶端反應，服務端又給客戶端發送了19373的數據，而這個數據就是使用了TLS1.2協議了。
摘要信息中說明了這是服務端的的hello,Server hello,服務端秘鑰交換，服務端hello done。接下來看服務端發過來的具體都有什么。
傳輸控制層(transmission control protocol)和上面一樣，主要是一些Flags，端口以及數據長度的確認等等，主要看一下安全套接字層的東西(Secure Sockets Layer)中的東西。
通過上圖，可以看出服務端主要返回四種內容。
Server Hello 服務端的回應客戶端的hello信息 Certificate 服務端證書 Server key Exchange 服務器秘鑰交換 Server Hello Done 服務器信息發送完畢
詳細看一下各個Record layer中的具體內容
Server Hello
在Server Hello中，服務器返回的服務端的隨機數，所選用的TLS 版本，以及服務器最終選用的客戶端和服務端交互的加密套件(TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030))，最終選用的加密套件是RSA非對稱加密算法以及AES對稱加密算法，用的是SHA384做摘要，注意，這個值必須是客戶端發給服務端的列表中選出來的。實際上如果客戶端只能支持版本和安全性比較低的加密套件，這樣服務端選擇和客戶端交互的時候也被迫只能使用低版本的加密套件，其安全性就會降低。除了以上這些，服務端Server Hello時發送回來的還有是否使用了壓縮以及一些其他的擴展字段
Certificate
Server Hello以后，服務端會發送公鑰證書給客戶端
Certificates (953 bytes) Certificate Length: 950 Certificate: 308203b23082029aa003020102020101300d06092a864886… (id-at-commonName=www.wtf.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN) signedCertificate version: v3 (2) serialNumber: 1 signature (sha256WithRSAEncryption) Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) issuer: rdnSequence (0) rdnSequence: 7 items (pkcs-9-at-emailAddress=iloveme313@163.com,id-at-commonName=wangtengfei,id-at-organizationalUnitName=section,id-at-organizationName=JD,id-at-localityName=BJ,id-at-stateOrProvinceName=BJ,id-at-countryName=CN) RDNSequence item: 1 item (id-at-countryName=CN) RDNSequence item: 1 item (id-at-stateOrProvinceName=BJ) RDNSequence item: 1 item (id-at-localityName=BJ) RDNSequence item: 1 item (id-at-organizationName=JD) RDNSequence item: 1 item (id-at-organizationalUnitName=section) RDNSequence item: 1 item (id-at-commonName=wangtengfei) RDNSequence item: 1 item (pkcs-9-at-emailAddress=iloveme313@163.com) validity notBefore: utcTime (0) utcTime: 16-11-22 06:38:18 (UTC) notAfter: utcTime (0) utcTime: 17-11-22 06:38:18 (UTC) subject: rdnSequence (0) rdnSequence: 4 items (id-at-commonName=www.wtf.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN) RDNSequence item: 1 item (id-at-countryName=CN) RDNSequence item: 1 item (id-at-stateOrProvinceName=BJ) RDNSequence item: 1 item (id-at-organizationName=JD) RDNSequence item: 1 item (id-at-commonName=www.wtf.com) subjectPublicKeyInfo algorithm (rsaEncryption) Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption) subjectPublicKey: 3082010a0282010100be56d1a2b725cf5d6fa1997c83b221… modulus: 0x00be56d1a2b725cf5d6fa1997c83b221de8452658b1e7c86… publicExponent: 65537 extensions: 4 items algorithmIdentifier (sha256WithRSAEncryption) Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) Padding: 0 encrypted: 41bfd96f86c44a731d6ff7af7e9e666703c744aa8c691d38…
1中有證書的指紋，以及證書的簽名信息
Certificate:308203b23082029aa003020102020101300d06092a864886…(id-at-commonName=www.wtf.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)
看以看出，這個證書是針對www.wtf.com這個域名簽發的，然后就是一些簽發機構信息等。
2 證書的過期時間(validity)，可以看出證書的過期時間為1年，從16年11月22日 6點38分18秒(not Before)到從17年11月22日 6點38分18秒(not After)
3 證書簽發的主體(subject)
4 公鑰證書的key.
當然這證書下放以后，服務端會把簽發的證書的hash也發送過來，以證明此證書在傳遞過程中沒有被修改。
可以看出使用的sha256算法做的摘要。
證書我們也能在瀏覽器中用可視化的方法查看。
我會把證書導出，可以自行查看
接下來就是秘鑰交換了
Server key Exchange
這個就是服務端公鑰的key
HelloDone
最后就是服務端發送一個HelloDone標示本次內容全部發放完畢。
總結一下 在客戶端向服務端打招呼以后，服務端主要發送了那些內容。首先是發送服務端自己的隨機數給客戶端，然后下發服務端公鑰證書和下發公鑰的key，最后服務端用hellodone標示此次內容全部發送完畢。以上發送過程我們都可以看得到，也就是說在這個過程中，客戶端和服務端交互使用的都還是明文。
Client keyExchange
客戶端接收到服務端的這些證書信息以后，解析來會進行回應服務端。可以看19374編號
查看傳輸層，傳輸層中明確寫明了這是對19373的一個回應。
重點還是查看安全套接字層，具體來看回應的是什么
主要包含了如下幾個方面
Client key exchange
包含了pre-master secret。這是在握手過程中生成的第三個隨機數。分別是client hello階段客戶端的隨機數，然后在server hello 階段服務端的隨機數。這一次是客戶端接收到服務端的證書以后，生成的一個預加密因子(供對稱加密使用)。
Change cipher spec
客戶端通知服務端接下來就要使用加密的方式來進行通信了。
然后在19375中，客戶端發送給服務端一段加密后的內容(就是在這一步，數據的交互從明文開始轉化為密文)，并且把本次會話信息中的所有細節做摘要發給服務端，以證明在本次過程中雙方達成一致，未受到其他干擾
服務端確認客戶端加密請求
然后服務端會在19376和19377中，服務端對客戶端的發送的內容進行確認(19374)，提供新的Session Ticket，然后發送了一段內容，并且對所有握手內容做摘要，發給客戶端來驗證通信過程是否被篡改。
最后在19378中，客戶端對服務端發送的內容進行做確認
注意一下，這時候內容發送的協議已經不是SSL了，已經重新更改為了TCP
接下來就是在此加密信道上開始正常的業務數據傳輸過程。
(tcp.stream eq 296)
小結：
本文大概的跟蹤了以下https建立安全鏈接的過程，并未提到常用的加密算法什么的用到什么地方，在本文的最后提一下，https過程的建立，實際上就是一次一密，根本目的是為了協商出雙方使用哪種對稱加密算法，然后加密因子是多少，為了達到這個目的，雙方使用了非對稱加密進行協商，拿到雙方的隨機數，然后進行相關的計算得到一個隨機對稱加密的加密因子。為了確保客戶端正在和真正的不是冒牌的服務器在協商，這個就用到了證書，由于是證書是可以自簽名的，自簽名是不可信的，所以就需要就需要找一個大家都信任的機構進行簽名，例如CA。這樣瀏覽器才會認可這個證書。還有就是為了保證在協商的過程中不受干擾，在協商的每一步都會把本次會話的信息做摘要傳遞給雙方，用以校驗。
當然了本文只是一個極其粗略的https流程的簡介，https還涉及到很多其他的內容，例如一些https加密信道的重用，由于https的建立比較慢，所以google就發明了一種更快的協議QUIC。
由于作者水平有限，畢竟會有些疏漏以及理解不到位的地方，希望讀者給予指正，以使其他人不被誤解。
附：
https://git.oschina.net/tofu.wang/wireshark-https/tree/master
從這個里面可以下載到本次模擬的證書以及具體用wireshark抓包過來的包，然后打開wireshark進行導入，過濾器寫ip.addr==114.215.88.85 即可
更多關于云服務器，域名注冊，虛擬主機的問題，請訪問三五互聯官網：www.shinetop.cn