https的TLS的四次握手流程
四次握手是三次握手之後進行對http加入安全性引入的，在應用層和tcp層加入tls/ssl協議保證傳輸的安全性，這就需要四次握手。對稱加密不安全，容易被竊取，tls採用非對稱加密算法，服務端向ca機構申請證書，ca機構提供公鑰和私鑰，通過證書把公鑰傳給瀏覽器，瀏覽器使用公鑰加密最終生成密鑰給服務端，之後使用密鑰進行通信，保證安全性，ca機構生成數字簽名的算法可以保證原文內容被竊取更改可以被發現。
tls是對稱加密和非對稱加密一起使用，先非對稱後對稱，因爲ca提供的私鑰一直在服務端所以其他人無法解析公鑰加密後的數據，保證密鑰的安全性。
首先第一次握手客戶端會向服務端發送client hello信息，告訴服務端需要的tls版本信息，支持的加密算法有哪些，這些算法組成加密套件，然後是一個隨機數。
然後第二次握手服務端向客戶端發送一個Server hello，然後告訴客戶端服務端支持的確認支持的tls版本以及選擇的加密套件，也會生成一個隨機數告訴客戶端，然後服務器出示一個證書，這樣瀏覽器可以根據自己信任的證書列表來確認這個證書服務器是否可信，
然後把公鑰給客戶端，再發後一個結束信號，Server Hello Done
第三次握手會使用公鑰加密生成預主密鑰給服務端，服務端使用私鑰解密，接下來使用預祝密鑰和前兩個隨機數組成最終的密鑰進行密鑰通信，
第四次握手服務端發送一個信號對客戶端進行確認，加密通信開始。
CA機構在其中的作用
ca機構是第三方機構用來保證數據的可靠性，ca機構給服務端提供公鑰和私鑰，然後把公鑰安全的傳輸給客戶端，方便後面的對稱加密，那麼如何保證公鑰安全的給客戶端呢，因爲可以保證不能被篡改和更換
如何證明瀏覽器收到的公鑰一定是該網站的公鑰？
其實所有證明的源頭都是一條或多條不證自明的“公理”（可以回想一下數學上公理），由它推導出一切。比如現實生活中，若想證明某身份證號一定是小明的，可以看他身份證，而身份證是由政府作證的，這裏的“公理”就是“政府機構可信”，這也是社會正常運作的前提。
那能不能類似地有個機構充當互聯網世界的“公理”呢？讓它作爲一切證明的源頭，給網站頒發一個“身份證”？
它就是CA機構，它是如今互聯網世界正常運作的前提，而CA機構頒發的“身份證”就是數字證書。
數字證書
網站在使用HTTPS前，需要向CA機構申領一份數字證書，數字證書裏含有證書持有者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書裏獲取公鑰就行了，證書就如身份證，證明“該公鑰對應該網站”。而這裏又有一個顯而易見的問題，“證書本身的傳輸過程中，如何防止被篡改”？即如何證明證書本身的真實性？身份證運用了一些防僞技術，而數字證書怎麼防僞呢？解決這個問題我們就接近勝利了！
如何放防止數字證書被篡改？
我們把證書原本的內容生成一份“簽名”，比對證書內容和簽名是否一致就能判別是否被篡改。這就是數字證書的“防僞技術”，這裏的“簽名”就叫數字簽名：
數字簽名
這部分內容建議看下圖並結合後面的文字理解，圖中左側是數字簽名的製作過程，右側是驗證過程：
數字簽名的生成與驗證（https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/）
數字簽名的製作過程：
- CA機構擁有非對稱加密的私鑰和公鑰。
- CA機構對證書明文數據T進行hash。
- 對hash後的值用私鑰加密，得到數字簽名S。
明文和數字簽名共同組成了數字證書，這樣一份數字證書就可以頒發給網站了。
那瀏覽器拿到服務器傳來的數字證書後，如何驗證它是不是真的？（有沒有被篡改、掉包）
瀏覽器驗證過程：
- 拿到證書，得到明文T，簽名S。
- 用CA機構的公鑰對S解密（由於是瀏覽器信任的機構，所以瀏覽器保有它的公鑰。詳情見下文），得到S’。
- 用證書裏指明的hash算法對明文T進行hash得到T’。
- 顯然通過以上步驟，T’應當等於S‘，除非明文或簽名被篡改。所以此時比較S’是否等於T’，等於則表明證書可信。
爲何麼這樣可以保證證書可信呢？我們來仔細想一下。
中間人有可能篡改該證書嗎？
假設中間人篡改了證書的原文，由於他沒有CA機構的私鑰，所以無法得到此時加密後簽名，無法相應地篡改簽名。瀏覽器收到該證書後會發現原文和簽名解密後的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務器傳輸信息，防止信息泄露給中間人。
既然不可能篡改，那整個證書被掉包呢？
中間人有可能把證書掉包嗎？
假設有另一個網站B也拿到了CA機構認證的證書，它想劫持網站A的信息。於是它成爲中間人攔截到了A傳給瀏覽器的證書，然後替換成自己的證書，傳給瀏覽器，之後瀏覽器就會錯誤地拿到B的證書裏的公鑰了，這確實會導致上文“中間人攻擊”那裏提到的漏洞？
其實這並不會發生，因爲證書裏包含了網站A的信息，包括域名，瀏覽器把證書裏的域名與自己請求的域名比對一下就知道有沒有被掉包了。
backlog參數在握手中的作用
三次握手
TCP是面向連接的，無論哪一方向另一方發送數據之前，都必須先在雙方之間建立一條連接。在TCP/IP協議中，TCP協議提供可靠的連接服務，連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號並交換 TCP窗口大小信息。
爲什麼非要三次握手呢？謝希仁的《計算機網絡》中這樣說：爲了防止已失效的連接請求報文段突然又傳送到了服務端因而產生錯誤。
已失效的連接請求報文段的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段，但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以爲新的運輸連接已經建立，並一直等待client發來數據。這樣server的很多資源就白白浪費掉了。採用三次握手的辦法可以防止上述現象發生。例如剛纔那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。這就有效的防止了服務器端的一直等待而浪費資源。
2 backlog
backlog這個參數值和三次握手的概念有着密切關聯。backlog隊列大小 = 未完成三次握手隊列 + 已經完成三次握手隊列。
未完成三次握手隊列：服務器處於listen狀態時，收到客戶端syn報文（connect）時放入未完成隊列中。
已完成三次握手隊列：三次握手的第二個狀態即服務器syn+ack響應client後，此時第三個狀態ack報文到達前（客戶端對服務器syn的ack）一直保留在未完成連接隊列中。若三次握手完成，該條目將從未完成連接隊列搬到已完成連接隊列尾部。當server調用accept時，從已完成三次握手隊列中的頭部取出一個socket連接給進程
backlog參數設置既可在linux內核參數設置(修改文件/etc/sysctl相關參數)，也可在socket系統調用listen函數時設置(第二個參數)。這二者區別是前者爲全局性的，影響所有socket，後者爲局部性的，影響當前socket。
若backlog設置過小可能會出現以下情況：server的accpet速度跟不上，導致A、B隊列滿了，導致新的客戶端無法連接。
HTTPS和HTTP的區別主要如下：
https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。