應(yīng)用層 HTTP/HTTPS協(xié)議
1 定義
HTTP協(xié)議（超文本傳輸協(xié)議）用于從www服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議作谭，HTTP協(xié)議是應(yīng)用層協(xié)議谈截，由請求和響應(yīng)構(gòu)成烫止，HTTP默認端號80呻疹，HTTPS端口號為443
2 簡單的HTTP協(xié)議? ? ? ? ? ? ? ? ? ? ??
1击狮、簡單快速：客戶向服務(wù)器請求服務(wù)時话侧，只需傳送請求方法和路徑栗精。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快悲立。
2鹿寨、靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記薪夕。
3脚草、HTTP 0.9和1.0使用非持續(xù)連接：限制每次連接只處理一個請求，服務(wù)器處理完客戶的請求原献，并收到客戶的應(yīng)答后馏慨，即斷開連接。HTTP 1.1默認使用持續(xù)連接：不必為每個web對象創(chuàng)建一個新的連接姑隅，一個連接可以傳送多個對象写隶，采用這種方式可以節(jié)省傳輸時間，減輕服務(wù)器端的負載讲仰。
4慕趴、無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力鄙陡。缺少狀態(tài)意味著無法根據(jù)之前的狀態(tài)進行本次的請求處理冕房，如果后續(xù)處理需要前面的信息，則它必須重傳柔吼，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大毒费。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快愈魏。
5觅玻、支持B/S及C/S模式。
6培漏、管線化： 管線化技術(shù)可以做到同時并行發(fā)送多個請求溪厘，不需要一個接一個的等待響應(yīng)
2.1 HTTP工作流程 ? ? ? ? ? ? ? ? ?
一次HTTP操作稱為一個事務(wù)，其工作過程可分為四步：
1牌柄、首先客戶機與服務(wù)器需要建立連接畸悬。只要單擊某個超級鏈接，HTTP的工作開始珊佣。
2蹋宦、建立連接后，客戶機發(fā)送一個請求給服務(wù)器咒锻，請求方式的格式為：統(tǒng)一資源標(biāo)識符（URL）冷冗、協(xié)議版本號，后邊是MIME信息包括請求修飾符惑艇、客戶機信息和可能的內(nèi)容蒿辙。
3拇泛、服務(wù)器接到請求后，給予相應(yīng)的響應(yīng)信息思灌，其格式為一個狀態(tài)行俺叭，包括信息的協(xié)議版本號、一個成功或錯誤的代碼泰偿，后邊是MIME信息包括服務(wù)器信息熄守、實體信息和可能的內(nèi)容。
?4甜奄、客戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上柠横，然后客戶機與服務(wù)器斷開連接窃款。
如果在以上過程中的某一步出現(xiàn)錯誤课兄，那么產(chǎn)生錯誤的信息將返回到客戶端，有顯示屏輸出晨继。對于用戶來說烟阐，這些過程是由HTTP自己完成的，用戶只要用鼠標(biāo)點擊紊扬，等待信息顯示就可以了蜒茄。
2.2 HTTP之請求消息Request?
客戶端發(fā)送一個HTTP請求到服務(wù)器的請求消息包括以下格式：
??請求行、請求首部餐屎、空行和請求數(shù)據(jù)四個部分組成檀葛。
1、GET請求/POST請求
第一部分：請求行腹缩，用來說明請求類型屿聋、請求方法、要訪問的資源以及所使用的HTTP版本藏鹊。
GET說明請求類型為GET為要訪問的資源润讥，該行的最后一部分說明使用的是HTTP1.1版本。
第二部分：請求首部盘寡，緊接著請求行（即第一行）之后的部分楚殿，用來說明服務(wù)器要使用的附加信息，首部中的行以一個回車換行對結(jié)束
從第二行起為請求首部竿痰，HOST將指出請求的目的地脆粥。User-Agent，服務(wù)器端和客戶端腳本都能訪問它影涉，它是瀏覽器類型檢測邏輯的重要基礎(chǔ)变隔。該信息由你的瀏覽器來定義，并且在每個請求中自動發(fā)送等等常潮。
第三部分：空行弟胀，請求首部后面的空行是必須的
即使第四部分的請求數(shù)據(jù)為空，也必須有空行。
第四部分：請求數(shù)據(jù)也叫主體孵户，可以添加任意的其他數(shù)據(jù)萧朝。
2、請求首部
User-Agent：客戶端支持的瀏覽器類型和版本
Accept：告訴服務(wù)器客戶端可以處理的數(shù)據(jù)類型夏哭，而以x-開頭检柬，表示可以支持自由定義非標(biāo)準(zhǔn)的定制類型和子類型，可使用type/subtype這種形式竖配，一次指定多種媒體類型何址。可以設(shè)置權(quán)重值來為請求的資源類型設(shè)置優(yōu)先級进胯，用分號（用爪；）分隔。
Connection: 指定值為Keep-Alive胁镐，表示它希望重用一個Socket偎血，URL類默認地支持HTTP Keep-Alive
Authorization: 用來告知服務(wù)器，用戶代理的認證信息
Cookie: 該客戶端的Cookie信息
Cache-Control：用于指定緩存指令盯漂，緩存指令是單向的（響應(yīng)中出現(xiàn)的緩存指令在請求中未必會出現(xiàn)）颇玷，且是獨立的（一個消息的緩存指令不會影響另一個消息處理的緩存機制）
Host：請求的主機名，允許多個域名同處一個IP地址就缆，即虛擬主機
If-Modified-Since：告知服務(wù)器若該字段值早于資源的更新時間帖渠，則希望能處理該請求
Transfer-Encoding：告知接收端為了保證報文的可靠傳輸，對報文采用了什么編碼方式竭宰。
最后空郊，請求以一個空行結(jié)束，即包括兩個回車/換行對羞延，一旦服務(wù)器看到這個標(biāo)識渣淳，就會開始通過同一個連接向客戶端發(fā)送它的響應(yīng)。
2.3 HTTP之響應(yīng)消息Response
一般情況下伴箩，服務(wù)器接收并處理客戶端發(fā)過來的請求后會返回一個HTTP的響應(yīng)消息入愧。
HTTP響應(yīng)也由四個部分組成，分別是：狀態(tài)行嗤谚、消息報頭棺蛛、空行和響應(yīng)正文。
第一部分：狀態(tài)行巩步，由HTTP協(xié)議版本號旁赊， 狀態(tài)碼， 狀態(tài)消息 三部分組成椅野。
第二部分：消息報頭终畅，用來說明客戶端要使用的一些附加信息
第三部分：空行籍胯，消息報頭后面的空行是必須的
第四部分：響應(yīng)正文，服務(wù)器返回給客戶端的文本信息离福。
2杖狼、響應(yīng)首部
ETag：告知客戶端實體標(biāo)識，它是一種可將資源以字符串形式做唯一性標(biāo)識的方式妖爷，服務(wù)器會為每份資源分配對應(yīng)的ETag值蝶涩。ETag值有強ETag和弱ETag之分。
Location：用于重定向接受者到一個新的位置絮识，常用在更換域名的時候
Server：告知客戶端當(dāng)前服務(wù)器安裝的HTTP服務(wù)器應(yīng)用程序的信息绿聘，與User-Agent請求報頭是相對應(yīng)的
Retry_After：告知客戶端應(yīng)在多久之后再次發(fā)送請求
Set-Cookie：設(shè)置客戶端的管理狀態(tài)
WWW-Authenticate：用于HTTP訪問認證，告知客戶端適用于訪問請求URI所指定資源的認證方案次舌。
2.4 實體首部字段
實體首部字段是包含在請求報文和響應(yīng)報文中的實體部分所使用的首部熄攘，用于補充內(nèi)容的更新時間等與實體相關(guān)的信息。
Content-Type：發(fā)送給接收者的實體正文的媒體類型
Content-Lenght：正文的長度
Date：生成響應(yīng)的日期和時間垃它；
Content-Language：描述資源所用的自然語言鲜屏，沒有設(shè)置則該選項則認為實體內(nèi)容將提供給所有的語言閱讀
Content-Encoding：被用作媒體類型的修飾符烹看，它的值指示了已經(jīng)被應(yīng)用到實體正文的附加內(nèi)容的編碼国拇，因而要獲得Content-Type報頭域中所引用的媒體類型，必須采用相應(yīng)的解碼機制惯殊。
Content-MD5：該字段是一串MD5算法生成的值酱吝，用于檢查報文主體在傳輸過程中是否保持完整，以及確認傳輸?shù)竭_土思。
Last-Modified：指示資源的最后修改日期和時間
Expires：響應(yīng)過期的日期和時間
2.5 HTTP之狀態(tài)碼 ? ? ? ? ? ? ? ? ??
狀態(tài)代碼有三位數(shù)字組成务热，第一個數(shù)字定義了響應(yīng)的類別，共分五種類別:
1xx：指示信息--表示請求已接收己儒，正在處理
2xx：成功--表示請求已被成功接收崎岂、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)
5xx：服務(wù)器端錯誤--服務(wù)器未能實現(xiàn)合法的請求
常見狀態(tài)碼：
302 Found?重定向闪湾，新的URL會在response 中的Location中返回冲甘，瀏覽器將會自動使用新的URL發(fā)出新的Request
204 No Content 代表服務(wù)器接收的請求已成功處理，但返回的響應(yīng)報文中不含實體的主體部分
206 Partial Content 代表客戶端進行了范圍請求
301 Moved Permanently?代表永久性重定向途样，請求的資源已被分配了新的URI江醇，以后應(yīng)使用資源現(xiàn)在所指的URI
302 Found?代表臨時性重定向，請求的資源已被分配了新的URI何暇，希望用戶能使用新的URI訪問陶夜。和狀態(tài)碼301相似，但是302是指資源臨時被移動裆站，而301是永久
303 See Other?該狀態(tài)碼與302有著相同的功能条辟，但是303狀態(tài)碼明確表示客戶端應(yīng)當(dāng)采用GET方法獲取資源
304 Not Modified?代表上次的文檔已經(jīng)被緩存了黔夭， 還可以繼續(xù)使用
400 Bad Request?客戶端請求與語法錯誤，不能被服務(wù)器所理解
401 Unauthorized 請求未經(jīng)授權(quán)羽嫡，發(fā)送的請求需要有通過HTTP認證的認證信息纠修，當(dāng)瀏覽器初次接收到401響應(yīng)時會彈出認證對話窗口
403 Forbidden?服務(wù)器收到請求，但是訪問被服務(wù)器拒絕了
404 Not Found?請求資源不存在（輸錯了URL）
500 Internal Server Error?服務(wù)器發(fā)生了不可預(yù)期的錯誤
503 Server Unavailable?服務(wù)器當(dāng)前不能處理客戶端的請求厂僧，一段時間后可能恢復(fù)正常扣草。
2.6 HTTP請求方法 ? ? ? ? ? ? ? ? ?
根據(jù)HTTP標(biāo)準(zhǔn)，HTTP請求可以使用多種請求方法颜屠。
GET ?請求指定的資源信息辰妙，指定的資源經(jīng)服務(wù)器解析后返回響應(yīng)內(nèi)容
POST ?傳輸實體的主體
PUT? 用來傳輸文件，要求在請求報文的主體中包含文件內(nèi)容甫窟，然后保存到請求URI指定的位置密浑，但是HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件粗井，存在安全性問題尔破，因此一般的WEB網(wǎng)站不使用該方法。
GET和POST的區(qū)別
? ? ?1浇衬、GET提交的數(shù)據(jù)會放在URL之后懒构，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連耘擂，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中.
? ? ?2胆剧、GET提交的數(shù)據(jù)大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數(shù)據(jù)沒有限制.
? ? ?3醉冤、GET方式需要使用Request.QueryString來取得變量的值秩霍，而POST方式通過Request.Form來獲取變量的值。
? ? ?4蚁阳、GET方式提交數(shù)據(jù)铃绒，會帶來安全問題，比如一個登錄頁面螺捐，通過GET方式提交數(shù)據(jù)時颠悬，用戶名和密碼將出現(xiàn)在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器归粉，就可以從歷史記錄獲得該用戶的賬號和密碼椿疗。
HEAD??獲取報文首部，該方法和GET方法一樣糠悼，只是不返回報文主體部分届榄，用于確認URI的有效性及資源更新的日期時間等
DELETE??按請求URI刪除指定的資源，與PUT方法相反倔喂，該方法也不帶驗證機制
OPTIONS? 用來查詢針對請求URI指定的資源支持的方法
TRACE? 追蹤路徑铝条，讓W(xué)eb服務(wù)器端將之前的請求通信環(huán)回給客戶端的方法
CONNECT? ?要求在與代理服務(wù)器通信時建立隧道靖苇，實現(xiàn)用隧道協(xié)議進行TCP通信，將通信內(nèi)容用SSL和TLS協(xié)議加密后經(jīng)網(wǎng)絡(luò)隧道傳輸
2.7 Http缺點
1班缰、Http不具備加密的功能贤壁，所以通信使用明文，內(nèi)容可能會被竊聽埠忘；
2脾拆、Http協(xié)議中的請求和響應(yīng)不會對通信方進行確認，可能會遭遇偽裝莹妒；
3名船、Http無法證明報文的完整性，可能已遭篡改旨怠。
3 HTTPS
簡單地來說渠驼，是基于ssl的http協(xié)議，依托ssl協(xié)議鉴腻，https協(xié)議能夠確保整個通信是加密的迷扇，密鑰隨機產(chǎn)生，并且能夠通過數(shù)字證書驗證通信雙方的身份爽哎，以此來保障信息安全蜓席。所以說，HTTP + 加密 + 認證 + 完整性保護 就是HTTPS
3.1 Https協(xié)議棧
https協(xié)議在http協(xié)議和tcp協(xié)議之間增加一層安全層（SSL/TLS協(xié)議）倦青，所有請求和響應(yīng)的數(shù)據(jù)在網(wǎng)絡(luò)傳輸之前都會先進行加密瓮床，然后在進行傳輸。
SSL的全稱是Secure Socket Layer产镐，既安全套接層。SSL協(xié)議獨立于應(yīng)用層踢步，應(yīng)用層的http癣亚，ftp，ssh都可以建立在ssl之上获印。TLS全程是Transport Layer Security述雾，傳輸層安全協(xié)議，是基于SSL的通用化協(xié)議兼丰，同樣位于應(yīng)用層和傳輸層之間玻孟，正逐步接替SSL成為下一代網(wǎng)絡(luò)安全協(xié)議。
SSL/TLS分為兩層：
Record Protocol ?記錄協(xié)議：記錄協(xié)議建立在可靠的傳輸協(xié)議（TCP）之上鳍征，提供數(shù)據(jù)封裝黍翎，加密解密，數(shù)據(jù)壓縮艳丛，數(shù)據(jù)校驗等基本功能匣掸。
Handshake Protocol ?握手協(xié)議：建立在握手協(xié)議之上趟紊，在實際的數(shù)據(jù)傳輸開始前，進行加密算法的協(xié)商碰酝，通信密鑰的交換霎匈，通信雙方身份的認證。
針對HTTP協(xié)議的缺點送爸，HTTPS提供了一下服務(wù)確保安全性：
1铛嘱、利用通信加密和內(nèi)容加密的方式，防止數(shù)據(jù)被竊聽袭厂；
2弄痹、認證用戶和服務(wù)器，防止通信方被偽裝嵌器；
3肛真、對數(shù)據(jù)完整性保護，確保數(shù)據(jù)不被篡改
3.2 HTTPS安全通信機制
? ? ? ?前面講到爽航，SSL/TLS協(xié)議分為兩層蚓让，Handshake Protocol和Record Protocol。其中Handshake Protocol用來協(xié)商密鑰讥珍，協(xié)議的大部分內(nèi)容就是通信雙方如何利用它來安全的協(xié)商出一份密鑰历极。 Record Protocol則定義了傳輸?shù)母袷健?/p>
? ? ? ?HTTPS采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制，在交換密鑰環(huán)節(jié)使用公開密鑰加密方式衷佃，之后的建立通信交換報文階段則使用共享密鑰加密方式趟卸。
客戶端發(fā)出請求（ClientHello）
? ? ? ?如果客戶端想要請求，則會向服務(wù)器發(fā)送ClientHello氏义，由于不同客戶端對加密算法的支持程度不一樣锄列，但是SSL/TLS協(xié)議必須使用同一種加密算法進行加密，所以在SSL/TLS握手階段惯悠，客戶端需要將自己支持的算法（Cipher Suite）告訴服務(wù)端邻邮，除此之外，客戶端還要產(chǎn)生一個隨機數(shù)克婶，這個隨機數(shù)一方面需要在客戶端保存筒严，另一方面需要傳送給服務(wù)端，客戶端的隨機數(shù)需要跟服務(wù)端產(chǎn)生的隨機數(shù)結(jié)合起來產(chǎn)生后面要講到的會話密鑰Master Secret 情萤。
服務(wù)器響應(yīng)
? ? ? ?當(dāng)收到客戶端發(fā)送的請求后鸭蛙，服務(wù)器匹配ClientHello中的信息，從客戶端支持的加密算法中篩選出一個可行的加密算法筋岛，并將篩選結(jié)果通知給客戶端娶视；
? ? ? ?同時也會產(chǎn)生一個隨機數(shù)發(fā)送給客戶端，需要這兩個隨機數(shù)來產(chǎn)生會話密鑰泉蝌；
? ? ? ?服務(wù)器還需要向客戶端發(fā)送自己的證書歇万，用來服務(wù)器的身份認證揩晴。證書需要向?qū)ｉT的數(shù)字證書認證機構(gòu)（CA）申請，頒發(fā)證書的同時會產(chǎn)生一個私鑰和公鑰贪磺。私鑰由服務(wù)端自己保存硫兰，不可泄漏。公鑰則是附帶在證書的信息中寒锚，可以公開的劫映。證書本身也附帶一個證書電子簽名，這個簽名用來驗證證書的完整性和真實性刹前，可以防止證書被串改泳赋。另外，證書還有個有效期喇喉。
? ? ? ?如果服務(wù)器發(fā)送的證書中沒有提供足夠的信息時祖今，還會發(fā)送Server Key Exchange；
? ? ? ?同時拣技，如果是雙向驗證千诬，則需要驗證客戶端的身份，服務(wù)器會向客戶端發(fā)送身份驗證請求Cerficate Request 膏斤，要求客戶端發(fā)送證書進行合法性驗證徐绑；
? ? ? ?最后，服務(wù)器發(fā)送Server Hello Done消息給客戶端莫辨，ServerHello結(jié)束傲茄。
客戶端響應(yīng)
? ? ? ?客戶端收到驗證請求消息后，會向服務(wù)器發(fā)送自己的證書沮榜，讓服務(wù)器驗證自己的身份盘榨；
? ? ? ?隨后會對服務(wù)器的證書進行驗證，即利用CA機構(gòu)的公開密鑰驗證服務(wù)器證書上的數(shù)字簽名敞映，如果驗證有效较曼，取出服務(wù)器的公鑰，否則警告提示訪問者振愿；客戶端生成第三個隨機數(shù)，并用服務(wù)器的公鑰加密弛饭，然后發(fā)送給服務(wù)器Client Key Exchange冕末，這個加密的隨機數(shù)稱為Pre-master Secret，這樣侣颂，客戶端和服務(wù)器都同時有了三個隨機數(shù)档桃，雙方會使用之前協(xié)商好的加密算法，各自生成本次會話要使用的同一把“會話密鑰”憔晒，即對稱加密算法藻肄，
? ? ? ?接著蔑舞，客戶端發(fā)送ChangeCipherSpec，告知服務(wù)器嘹屯，客戶端已經(jīng)切換到之前協(xié)商好的加密套件的狀態(tài)攻询，此后的報文都會采用生成的會話密鑰加密；
? ? ? ?自此州弟，客戶端的握手過程結(jié)束钧栖，但會發(fā)送一段Encrypted Handshake Message報文，該報文包含連接至今所有報文的Hash校驗值婆翔，并用會話密鑰加密拯杠，用來供服務(wù)器校驗，如果服務(wù)器能夠正確校驗該報文啃奴，則認為握手成功潭陪。
服務(wù)器結(jié)束響應(yīng)
? ? ? ?服務(wù)器收到Client Key Exchange報文后，使用自己的密鑰對Pre-master Secret進行解密最蕾，然后根據(jù)三個隨機數(shù)和協(xié)商的加密算法依溯，計算出會話密鑰；
? ? ? ?服務(wù)器收到客戶端發(fā)來的Finished報文揖膜，用會話密鑰解密報文誓沸，并結(jié)合之前接收到所有報文生成的Hash值，對Finished報文進行驗證壹粟，并且也會以同樣的方式向客戶端發(fā)送ChangeCipherSpec和Encrypted Handshake Message報文拜隧，供客戶端驗證。
? ? ? ?根據(jù)之前的握手信息趁仙，如果客戶端和服務(wù)器都能對Finished報文驗證通過洪添，則說明握手通道建立成功，之后雙方使用之前協(xié)商好的加密方式進行通信雀费。
連接斷開
如果客戶端斷開連接干奢，會向服務(wù)器發(fā)送close_notify報文。
3.3 數(shù)據(jù)完整性驗證
?以上流程中盏袄，應(yīng)用層發(fā)送數(shù)據(jù)時忿峻，都會附加一個叫MAC（Message Authentication Code，消息認證碼算法）的報文摘要辕羽，MAC能查知報文是否遭到篡改逛尚，保證報文數(shù)據(jù)的完整性。MAC是含有密鑰的散列函數(shù)算法刁愿，兼容了MD和SHA算法的特性绰寞，并在此基礎(chǔ)上加入了密鑰。
4 要點解析?
4.1 Cookie
? ? ? ?用于在連接之間存儲持久的客戶端狀態(tài)，cookie在請求和響應(yīng)報文中寫入Cookie信息來控制客戶端的狀態(tài)滤钱，只能是非空白符的ASCII文本觉壶，不能包含逗號或分號
Set-Cookie/Cookie：設(shè)置Cookie，客戶端根據(jù)該字段信息來保存Cookie件缸，當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時铜靶，客戶端會自動在請求報文中加入Cookie值后發(fā)送出去。服務(wù)端收到Cookie后停团，會去檢查究竟是哪一個客戶端發(fā)送來的請求旷坦，然后對比記錄，得到之前的狀態(tài)信息佑稠。
Max-Age：設(shè)置Cookie經(jīng)過指定時間后過期秒梅，過期后，瀏覽器從緩存中刪除這個Cookie
4.2? 會話密鑰重用
SSL/TLS握手過程比較繁瑣舌胶，同時非對稱加解密性能比對稱密鑰要差得多捆蜀；如果每次重建連接時都需要進行一次握手會產(chǎn)生較大開銷，因此有必要實現(xiàn)會話的重用以提高性能幔嫂。
常用的方式包括：
SessionID(RFC 5246)：客戶端和服務(wù)端同時維護一個會話ID和會話數(shù)據(jù)狀態(tài)辆它；重建連接時雙方根據(jù)sessionID找到之前的會話密鑰實現(xiàn)重用；
SessionTicket(RFC?5077)：由服務(wù)端根據(jù)會話狀態(tài)生成一個加密的ticket履恩，并將key也發(fā)給客戶端保證兩端都可以對其進行解密锰茉。該機制相較sessionID的方式更加輕量級，服務(wù)端不需要存儲會話狀態(tài)數(shù)據(jù)切心，可減輕一定壓力
4.3?證書的校驗
校驗步驟：
1）檢查數(shù)字簽名：數(shù)字簽名通過數(shù)字摘要算法生成并通過私鑰加密傳輸飒筑，對端公鑰解密；
2）CA鏈?zhǔn)跈?quán)檢查
3）證書過期及激活時間檢查
數(shù)字摘要的計算圖示
參考：
https://www.cnblogs.com/qdhxhz/p/8468913.html
http://www.reibang.com/p/e634784e7b00
https://www.cnblogs.com/littleatp/p/6219630.html
