表示層是SSL協議所發揮作用的這一層，通過握手、發送祕鑰、告警
TLS安全密碼套件解讀：怎麼保證明文被加密的
對稱加密
1>如何實現的？
其中異或有一個對稱的特點，把密文和密鑰同樣做異或操作，就可以得到明文，所以說性能非常的好。只要遍歷一次得到最終密文，解密也是一樣的
非對稱加密
信息加密：根據數學原理生成一堆密鑰，包含公鑰和私鑰，同一份明文文檔只有公鑰加密了，私鑰才能解密，如果文檔用私鑰加密，只有用公鑰才能解密。公鑰和私鑰還有第二種用法，身份驗證，Alice用私鑰加密一段信息，發送給Bob，Bob拿到Alice公鑰，公鑰本來就是公開的，如果成功解開這個密文，證明這段密文確實由Alice發出的
CA是如何辨別證書和證書過期的
從上面得知Alice和Bob進行通信的前提條件，Alice必須知道Bob就是Bob，也就是收到的信息必須是Bob發的，所以這樣的通信必須在多方通訊中有一個通信機構，CA機構
站定維護者==證書訂閱者，CA是生成一堆公鑰和私鑰，公鑰會在CA的證書內保存着，然後網站維護者會部署到Nginx，然後客戶端請求，Nginx會將網站信息和公鑰證書發給瀏覽器，瀏覽器驗證證書是不是有效合法的，CA會把過期的證書放在CRL服務器裏面，這個服務器會把所有證書形成一個鏈表，所以性能比較差，所以有推出來一個OCSP，可以就一個證書查詢是否過期，所以瀏覽器會直接查詢OCSP，但是OCSP響應速度還不是太高，但是我們Nginx有個OCSP開關，當打開開關後，Nginx會主動去OCSP裏去查詢，這樣大量的客戶端通過NGINX就可以獲取到證書是否有效
證書類型：
DV：只能驗證域名的歸屬是否正確，往往是免費的
OV：會去驗證我們填寫的機構，企業名稱是否正確，比較難
EV：做了更加嚴格的認證，所以大多數瀏覽器會對其顯示非常友好，會把我們在申請證書的機構名稱在瀏覽器地址欄最左側顯示出來
如何生效的呢？ 瀏覽器從安全角度來看對DV、OV、EV證書效果一樣，唯一驗證的是證書鏈
證書鏈
目前我們所有站點的組證書都是由根證書，二級證書，組證書，因爲根證書的驗證是非常謹慎的，像windows、安卓等操作系統每次只有一次纔會更新根證書庫，所以一個新的根證書庫是很難加入操作系統或者瀏覽器（大多數瀏覽器是使用操作系統的根證書），所以瀏覽器在驗證證書是否有效的時候除了驗證是否過期，最主要是驗證根證書是不是有效的，是不是被跟證書庫認可的，而我們nginx在向瀏覽器發送證書的時候需要發兩個證書，不是三個，因爲根證書是被瀏覽器或者操作系統內置的，必須要發送，
根據抓包可以看出，nginx向瀏覽器發送證書先發送組證書，接下來發送二級證書，瀏覽器會自動自動驗證二級證書的簽發機構根證書是否有效
TLS通訊過程：
因爲瀏覽器是多樣性的，所以瀏覽器首先跟服務器協商自己支持的加密算法，然後服務器就加密算法有一個鏈，然後選擇自己更傾向於那種加密套件，發送給客戶端，如果希望一天的斷開連接的端不用再次協商密碼，那麼打開session cache，然後NGINX發送給瀏覽器他的公鑰，這個是包含證書鏈的，然後瀏覽器可以根據證書鏈查詢到根證書，從而判斷證書是否有效，這個時候在第三部和第四部之間需要把橢圓算法的參數發送給客戶端，以方便再第六步生成進行加密的密鑰，然後第五步，瀏覽器根據橢圓曲線公共參數生成自己私鑰，然後把公鑰發送給服務器，這個時候服務器根據自己的私鑰和客戶端的公鑰生成雙方加密的密鑰，這個是第六步，然後客戶端根據服務器的公鑰和自己的私鑰可以也生成密鑰，兩者生成的密鑰是相同的，這個是根據非對稱加密算法保證，然後根據生成的密鑰進行加密和通訊
Nginx握手性能
這裏Nginx主要看橢圓加密算法和非對稱加密算法這兩個性能，這裏可以看出，握手是主要影響性能的指標，對於大文件可以考慮對稱加密算法，對於nginx而言，如果小文件主要考慮nginx非對稱加密性能，如果是大文件主要對稱加密算法性能，如果小文件過多的時候我們可以優化橢圓曲線算法，如果是大文件的時候我們可以調整aes算法，或者看是否有別的算法可以代替