>完整計網總結：[三萬字計網知識點梳理](https://blog.csdn.net/qq_37205708/article/details/94126978) # 計算機網絡分層次的體系結構 [TOC]  | 層次 | 功能 | 常見協議/標準 | 協議數據單元（PDU） | | --- | --- |--- | --- | | 應用層 | 為應用軟件提供接口，使應用程序能夠使用網絡服務 | http(80)、ftp(20連接、21傳輸數據)、smtp(25)、telnet(23)、dns(53) | message（報文）) | | 表示層 | 負責數據的解碼和編碼、加密和解密、壓縮和解壓縮 | 常見標準如 ASCII JPEG | message| | 會話層 | 負責建立、管理和終止表示層實體之間的會話連接，在系統之間協調通信過程 | 提供 3 種通信方式：單工、半雙工、全雙工 | message | | 運輸層 | 負責建立端到端的連接，保證報文在端到端之間的傳輸 | TCP/UDP | segment（數據段）| | 網絡層 | 將分組從源端傳送到目的端，提供網絡互聯（路由選擇） | IP、ARP、ICMP、RIP、OSPF | packet（數據包） | | 數據鏈路層 | 將分組數據封裝成幀，提供節點到節點的傳輸方式 | PPP、CSMA/CD | frame（幀） | | 物理層 | 在媒體上傳輸比特，提供機械的和電氣的歸約 | \ | bit（比特） | 關于 TCP/IP 四層模型的網際層和網絡接口層的解釋： - **網際層** 對應 OSI 參考模型的 **網絡層**，主要解決主機到主機的通信問題 - **網絡接口層** 對應 OSI 參考模型的 **物理層** 和 **數據鏈路層**，負責監視數據在主機和網絡之間的交換 # 域名解析過程 一、主機向本地域名服務器的查詢一般都采用 **遞歸查詢（recursive query）**，遞歸查詢返回的查詢結果或者是所要查詢的 IP 地址，或者是報錯，表示無法查詢到所需的 IP 地址 二、本地域名服務器向根域名服務器的查詢通常是采用 **迭代查詢（iterative query）**，迭代查詢的結果要么是所要查詢的 IP 地址，要么是下一個要查詢的域名服務器的 IP 地址  域名服務器的分類  - 根域名服務器（root name server）：最高層次的域名服務器，所有的根域名服務器都知道 所有的頂級域名服務器的域名和 IP 地址 - 頂級域名服務器：負責管理在該頂級域名服務器注冊的所有二級域名，當收到 DNS 查詢請求時， 就給出相應的回答（可能是最后的結果，也可能是下一步應當找的域名服務器的 IP 地址） - 權限域名服務器：負責一個區的域名服務器，當一個權限域名服務器還不能給出最后的 查詢回答時，就會告訴發出查詢請求的 DNS 用戶，下一步應當找哪一個權限域名服務器 - 本地域名服務器（local name server）：當一臺主機發出 DNS 查詢請求時，這個查詢請求報文就發送給本地域名服務器，每一個互聯網服務提供者 ISP，或一個大學，都可以擁有一個本地域名服務器 # TCP&UDP ## TCP&UDP概述 TCP（Transmission Control Protocol） 又叫傳輸控制協議。 TCP 協議是 **面向連接的，可靠的，基于字節流的傳輸協議**。在基于 TCP 進行通信時，通信雙方需要先建立一個 TCP 連接，建立連接需要經過三次握手，斷開連接的時候需要經過四次揮手。 UDP（User Datagram Protocol） 又叫用戶數據報協議。 UDP 是一個 **無連接的、不可靠、基于數據報的傳輸協議**。UDP 只是報文的搬運工，不會對報文進行任何拆分和拼裝操作。 | 應用 | 應用層協議 | 運輸層協議 | | --- | --- | --- | | 名字轉換 | DNS（域名系統） | UDP | | 文件傳送 | TFTP（簡單文件傳送協議） | UDP | | 路由選擇協議 | RIP（路由信息協議） | UDP | | IP 地址配置 | DHCP（動態主機配置協議） | UDP | | 網絡管理 | SNMP（簡單網絡管理協議） | UDP | | 遠程文件服務器 | NFS（網絡文件系統） | UDP | | IP 電話 | 專用協議 | UDP | | 流式多媒體通信 | 專用協議 | UDP | | 多播 | IGMP（網際組管理協議） | UDP | | 電子郵件 | SMTP（簡單郵件傳送協議） | TCP | | 遠程終端接入 | TELNET（遠程終端協議） | TCP | | 萬維網 | HTTP（超文本傳送協議） | TCP | | 文件傳送 | FTP（文件傳送協議） | TCP | ## 三次握手與四次揮手 首先得明白 TCP 報文段首部格式  - 序號：4字節 \[0-2^32 – 1\] 序號增加到 2^32 – 1 后下一個序號又回到 0。TCP 是面向字節流的，在一個 TCP 連接中傳送的字節流中的每一個字節都按順序編號，整個要傳送的字節流的起始序號必須在連接建立時設置。例如，一個 segment 的序號字段值是 301，而攜帶的數據共有 100 字節，那么最后一個字節的序號是 400 - 確認號：期望收到對方下一個 segment（報文段）的第一個數據字節的序號 若確認號 = N，則表明到序號 N – 1 為止的所有數據都已經正確收到 ### 三次握手  1.客戶端發送 SYN 報文段請求建立連接；且初始化一個序號 seq = x 2.服務器收到連接請求報文段后，如果同意建立連接，則發送一個 SYN + ACK 報文段；且初始化一個序號 seq = y 3.客戶端收到服務器的確認后，還需要向服務器發送一個 ACK 報文段，至此連接已經建立。 ### 四次揮手  請求斷開連接的既可以是客戶端也可以是服務器，這里假設使客戶端請求斷開連接 1.客戶端發送一個標志位 FIN 為 1 的報文段 2.服務器收到后回一個 ACK，并檢查是否還有數據需要傳輸 3.服務器沒有數據需要傳輸了，則發送給客戶端一個 FIN + ACK 報文段 4.客戶端再回一個 ACK，經過 2MSL（最長報文段壽命）的等待后才會關閉連接，而服務器只要收到這個 ACK 就會馬上關閉連接；如果未收到則有一個超時重傳機制。 ## Questions <span style="font-size: 20px; font-family: 楷體; font-weight: bold;">1.為什么不能兩次握手建立連接？</span> Answer：3 次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。 ???????現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機 S 和 C 之間的通信，假定 C 給 S 發送一個連接請求分組，S 收到了這個分組，并發送了確認應答分組。按照兩次握手的協定，S 認為連接已經成功地建立了，可以開始發送數據分組。可是，C 在 S 的應答分組在傳輸中被丟失的情況下，將不知道 S 是否已準備好，不知道 S 建立什么樣的序列號，C 甚至懷疑 S 是否收到自己的連接請求分組。在這種情況下，C 認為連接還未建立成功，將忽略 S 發來的任何數據分組，只等待連接確認應答分組。而 S 在發出的分組超時后，重復發送同樣的分組。這樣就形成了死鎖。 <span style="font-size: 20px;font-family: 楷體; font-weight: bold;">2.為什么建立連接的時候是三次握手，而關閉連接是四次？</span> Answer：因為當 Server 端收到 Client 端的 SYN 連接請求報文后，可以直接發送 SYN+ACK 報文。其中 ACK 報文是用來應答的，SYN 報文是用來同步的。但是關閉連接時，當 Server 端收到 FIN 報文時，很可能并不會立即關閉 SOCKET，所以只能先回復一個 ACK 報文，告訴 Client 端，"你發的 FIN 報文我收到了"。只有等到我 Server 端所有的報文都發送完了，我才能發送 FIN 報文，因此不能一起發送。故需要四步揮手。 <span style="font-size: 20px;font-family: 楷體; font-weight: bold;">3.關閉連接時為什么要等待 2MSL？</span> Answer：保證 A 發送的最后一個 ACK 報文段能夠到達 B。 這個 ACK 報文段有可能丟失，從而使處在 LAST-ACK 狀態的 B 收不到對已發送的 FIN+ACK 報文段的確認。B 會超時重傳這個 FIN+ACK 報文段，而 A 就能在 2MSL 時間內收到這個重傳的 FIN+ACK 報文段。接著 A 重傳一次確認，重新啟動 2MSL 計時器。直到 A 和 B 都正常進入 CLOSED 狀態。 如果沒有 TIME-WAIT 狀態，B 收不到確認就無法按正常步驟進入 CLOSED 狀態。 <span style="font-size: 20px;font-family: 楷體; font-weight: bold;">4.如果已經建立了連接，但是客戶端出現了故障怎么辦？</span> Answer：除了等待計時器外，TCP 還設有一個保活計時器（keepalive timer）。設想有這樣的情況：客戶已主動與服務器建立了 TCP 連接，但后來客戶端的主機突然出現故障。顯然，服務器之后就不能再收到客戶發來的數據。因此就需要措施使服務器不白等。 服務器每收到一次客戶的數據，就重置保活計時器，時間的設置一般是兩小時。若兩小時沒有收到客戶的數據，服務器就發送一個探測報文段，以后每隔 75 秒發送一次，若一連發送 10 個探測報文段后仍無客戶的響應，服務器就認為客戶端出現了故障，接著就關閉這個連接。 ## TCP 擁塞控制 擁塞控制是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載，是一個全局性的過程。 TCP 進行擁塞控制的算法有四種：慢開始（slow-start）、擁塞避免（congestion avoidance）、快重傳（fast retransmit）、快恢復（fast recovery）。  cwnd（congestion window）：發送方維持一個叫做擁塞窗口的狀態變量，擁塞窗口的大小取決于網絡的擁塞程度，并且動態變化，發送方讓自己的發送窗口等于擁塞窗口。 <br /> 1、慢開始：為了防止擁塞窗口 cwnd 的增長引起網絡阻塞，還需要另外一個變量—慢開始門限 ssthresh. i.當 cwnd < ssthresh 時，使用上述慢開始算法； ii.當 cwnd > ssthresh 時，停止使用慢開始算法，改用擁塞避免算法； iii.當 cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞避免算法 慢開始的 “慢” 并不是指 cwnd 的增長速率慢，而是指在 TCP 開始發送報文段時先設置 cwnd = 1， 試探一下網絡，然后再逐漸增大 cwnd（每輪加倍） <br /> 2、擁塞避免：思路是使 cwnd 緩慢地增大，每經過一個往返時間 RTT 就把發送方的 cwnd 加 1，因此有 “加法增大” 的特點。 <br /> 3、快重傳：快重傳可以讓發送方盡早知道發生了個別報文段的丟失  快重傳算法要求接收方立即發送確認，而不是等自己發送數據時才捎帶確認（注意理解這句話）。 即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認。 比如圖中確認了 M1 和 M2 后，M3 沒有收到卻收到了 M4，按照快重傳算法，接收方必須立即發送對 M2 的重復確認，以便讓發送方及早知道接收方沒有收到報文段 M3。發送方接著發送 M5 和 M6，接收方收到后仍然要分別發出對 M2 的重復確認。這樣，發送方共收到了接收方的 4 個對 M2 的確認，其中后 3 個都是重復確認。快重傳算法規定，發送方只要一連收到 3 個重復確認，就應當立即重傳（即“快重傳”），這樣就不會出現超時，發送方也不就不會誤認為出現了網絡擁塞。 <br /> 4、快恢復：Reno 版本 當發送發連續接收到三個重復確認時，就執行 “乘法減小” 算法，把慢啟動開始門限（ssthresh）和 cwnd 減半，然后執行擁塞避免算法，使擁塞窗口緩慢增大。 # HTTP ## 狀態碼 **1XX 信息，服務器收到請求，需要請求者繼續執行操作** - 100 Continue，客戶端應繼續其請求 - 101 Switching Protocols， 服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到 HTTP 的新版本協議 **2XX 成功，操作被成功接收并處理** * 200 OK，表示從客戶端發來的請求在服務器端被正確處理 * 204 No content，表示請求成功，但響應報文不含實體的主體部分 * 205 Reset Content，表示請求成功，但響應報文不含實體的主體部分，但是與 204 響應不同在于要求請求方重置內容 * 206 Partial Content，進行范圍請求 **3XX 重定向，需要進一步的操作以完成請求** * 301 moved permanently，永久性重定向，表示資源已被分配了新的 URL * 302 found，臨時性重定向，表示資源臨時被分配了新的 URL * 303 see other，表示資源存在著另一個 URL，應使用 GET 方法獲取資源 * 304 not modified，所請求的資源未修改，可在緩存中讀取 * 307 temporary redirect，臨時重定向，和 302 含義類似，但是期望客戶端保持請求方法不變向新的地址發出請求 **4XX 客戶端錯誤，請求包含語法錯誤或無法完成請求** * 400 bad request，請求報文存在語法錯誤 * 401 unauthorized，表示發送的請求需要有通過 HTTP 認證的認證信息 * 403 forbidden，表示對請求資源的訪問被服務器拒絕 * 404 not found，表示在服務器上沒有找到請求的資源 **5XX 服務器錯誤，服務器在處理請求的過程中發生了錯誤** * 500 internal sever error，表示服務器端在執行請求時發生了錯誤 * 501 Not Implemented，表示服務器不支持當前請求所需要的某個功能 * 503 service unavailable，表明服務器暫時處于超負載或正在停機維護，無法處理請求 ## HTTP/1.1 與 HTTP/1.0 的區別 1. **緩存處理**，在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 來做為緩存判斷的標準，HTTP1.1 則引入了更多的緩存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供選擇的緩存頭來控制緩存策略。 2. **帶寬優化及網絡連接的使用**，HTTP1.0 中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，并且不支持斷點續傳功能， HTTP1.1 則在請求頭引入了 range 頭域，它允許只請求資源的某個部分，即返回碼是 206（Partial Content），這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接。 3. **錯誤通知的管理**，在 HTTP1.1 中新增了 24 個錯誤狀態響應碼，如 409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。 4. **Host 頭處理**，在 HTTP1.0 中認為每臺服務器都綁定一個唯一的 IP 地址，因此，請求消息中的 URL 并沒有傳遞主機名（hostname）。但隨著虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個 IP 地址。HTTP1.1 的請求消息和響應消息都應支持 Host 頭域，且請求消息中如果沒有 Host 頭域會報告一個錯誤（400 Bad Request）。 5. **長連接**，HTTP 1.1 支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個 TCP 連接上可以傳送多個 HTTP 請求和響應，減少了建立和關閉連接的消耗和延遲，在 HTTP1.1 中默認開啟 Connection： keep-alive，一定程度上彌補了 HTTP1.0 每次請求都要創建連接的缺點。 >網上的資料說各瀏覽器廠商一般都不會開啟 Pipelining，因為這項技術本身存在一些缺陷，比如隊頭阻塞。 ## HTTP2.0 [參考鏈接](https://github.com/InterviewMap/CS-Interview-Knowledge-Map/blob/master/Network/Network-zh.md) 在 HTTP 1.X 中，為了性能考慮，我們會引入雪碧圖、將小圖內聯、使用多個域名等等的方式。這一切都是因為瀏覽器限制了同一個域名下的請求數量，當頁面中需要請求很多資源的時候，**隊頭阻塞（Head of line blocking）** 會導致在達到最大請求數量時，剩余的資源需要等待其他資源請求完成后才能發起請求 我們來梳理下 HTTP 請求的幾種方式  * 圖中第一種請求方式，就是單次發送 request 請求，收到 response 后再進行下一次請求，顯示是很低效的。 * 于是 HTTP/1.1 提出了<span style="font-family:楷體;font-weight: 700;">管線化技術（pipelining）</span>，就是如圖中第二中請求方式，一次性發送多個 request 請求。 * 然而 pipelining 在接收 response 返回時，也必須依順序接收，如果前一個請求遇到了阻塞，后面的請求即使已經處理完畢了，仍然需要等待阻塞的請求處理完畢。這種情況就如圖中第三種，第一個請求阻塞后，后面的請求都需要等待，這也就是 <span style="font-family:楷體;font-weight: 700;">隊頭阻塞(Head of line blocking)</span> * 為了解決上述阻塞問題，HTTP/2.0 中提出了 <span style="font-family:楷體;font-weight: 700;">多路復用（Multiplexing）</span>技術，使得多個 HTTP 請求可以復用同一個 TCP 連接。其原理大致如下：將一個 TCP 連接分為若干個流（Stream），每個流中可以傳輸若干消息（Message），每個消息由若干最小的二進制幀（Frame）組成。也就是將每個 request-response 拆分為了細小的二進制幀 Frame，這樣即使一個請求被阻塞了，也不會影響其他請求，如圖中第四種情況所示。 ## 二進制傳輸 HTTP 2.0 中所有加強性能的核心點在于此。在之前的 HTTP 版本中，我們是通過文本的方式傳輸數據。在 HTTP 2.0 中引入了新的編碼機制，所有傳輸的數據都會被分割，并采用二進制格式編碼。  ## 多路復用（Multiplexing） 在 HTTP 2.0 中，有兩個非常重要的概念，分別是幀（frame）和流（stream）。 幀代表著最小的數據單位，每個幀會標識出該幀屬于哪個流，流也就是多個幀組成的數據流。 多路復用，就是在一個 TCP 連接中可以存在多條流。換句話說，也就是可以發送多個請求，對端可以通過幀中的標識知道屬于哪個請求。通過這個技術，可以避免 HTTP 舊版本中的隊頭阻塞問題，極大地提高傳輸性能。  ## Header 壓縮（Header Compression） 在 HTTP 1.X 中，我們使用文本的形式傳輸 header，在 header 攜帶 cookie 的情況下，可能每次都需要重復傳輸幾百到幾千的字節。 在 HTTP 2.0 中，使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減少了 header 的大小。并在兩端維護了索引表，用于記錄出現過的 header ，后面在傳輸過程中就可以傳輸已經記錄過的 header 的鍵名，對端收到數據后就可以通過鍵名找到對應的值。 ## 服務端 Push（Server Push） 在 HTTP 2.0 中，服務端可以在客戶端某個請求后，主動推送其他資源。 可以想象以下情況，某些資源客戶端是一定會請求的，這時就可以采取服務端 push 的技術，提前給客戶端推送必要的資源，這樣就可以相對減少一點延遲時間。當然在瀏覽器兼容的情況下你也可以使用 prefetch 。 # HTTPS http 默認采用 80 作為通訊端口，對于傳輸采用不加密的方式，https 默認采用 443，對于傳輸的數據進行加密傳輸。 ## 密碼學基礎 **明文**：明文指的是未被加密過的原始數據。 **密文**：明文被某種加密算法加密之后，會變成密文，從而確保原始數據的安全。密文也可以被解密，得到原始的明文。 **密鑰**：密鑰是一種參數，它是在明文轉換為密文或將密文轉換為明文的算法中輸入的參數。密鑰分為對稱密鑰與非對稱密鑰，分別應用在對稱加密和非對稱加密上。 ## 對稱加密 對稱加密又叫做私鑰加密，即信息的發送方和接收方使用同一個密鑰去加密和解密數據。對稱加密的特點是算法公開、加密和解密速度快，適合于對大數據量進行加密。 其加密過程如下：**明文 + 加密算法 + 私鑰 => 密文** 解密過程如下：**密文 + 解密算法 + 私鑰 => 明文** 對稱加密中用到的密鑰叫做私鑰，私鑰表示個人私有的密鑰，即該密鑰不能被泄露。 其加密過程中的私鑰與解密過程中用到的私鑰是同一個密鑰，這也是稱加密之所以稱之為“對稱”的原因。由于對稱加密的算法是公開的，所以一旦私鑰被泄露，那么密文就很容易被破解，所以對稱加密的缺點是密鑰安全管理困難。 ## 非對稱加密 非對稱加密也叫做公鑰加密。非對稱加密與對稱加密相比，其安全性更好。對稱加密的通信雙方使用相同的密鑰，如果一方的密鑰遭泄露，那么整個通信就會被破解。而非對稱加密使用一對密鑰，即公鑰和私鑰，且二者成對出現。私鑰被自己保存，不能對外泄露。公鑰指的是公共的密鑰，任何人都可以獲得該密鑰。用公鑰或私鑰中的任何一個進行加密，用另一個進行解密。 被公鑰加密過的密文只能被私鑰解密，過程如下： **明文 + 加密算法 + 公鑰 => 密文， 密文 + 解密算法 + 私鑰 => 明文** 被私鑰加密過的密文只能被公鑰解密，過程如下： **明文 + 加密算法 + 私鑰 => 密文， 密文 + 解密算法 + 公鑰 => 明文** 由于加密和解密使用了兩個不同的密鑰，這就是非對稱加密“非對稱”的原因。 非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量數據進行加密。 在非對稱加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（橢圓曲線加密算法）等。 ## HTTPS 通信過程 HTTPS 協議 = HTTP 協議 + SSL/TLS 協議，在 HTTPS 數據傳輸的過程中，需要用 SSL/TLS 對數據進行加密和解密，需要用 HTTP 對加密后的數據進行傳輸，由此可以看出 HTTPS 是由 HTTP 和 SSL/TLS 一起合作完成的。 >TLS（Transport Layer Security，安全傳輸層協議）可以認為就是 SSL（Secure Socket Layer，安全套階層）的標準化后的名稱，在傳輸層提供對網絡連接加密的功能 主要是它們所支持的加密算法不同，所以 TLS 與 SSL3.0 不能互操作。雖然 TLS 與 SSL3.0 在加密算法上不同，但是在我們理解 HTTPS 的過程中，我們可以把 SSL 和 TLS 看做是同一個協議。 **HTTPS 為了兼顧安全與效率，同時使用了對稱加密和非對稱加密**。數據是被對稱加密傳輸的，對稱加密過程需要客戶端的一個密鑰，為了確保能把該密鑰安全傳輸到服務器端，采用非對稱加密對該密鑰進行加密傳輸，總的來說，**對數據進行對稱加密，對稱加密所要使用的密鑰通過非對稱加密傳輸**  HTTPS在傳輸的過程中會涉及到三個密鑰： - 服務器端的公鑰和私鑰，用來進行非對稱加密 - 客戶端生成的隨機密鑰，用來進行對稱加密 一個 HTTPS 請求實際上包含了兩次 HTTP 傳輸，可以細分為 8 步。 1. 客戶端向服務器發起 HTTPS 請求，連接到服務器的 443 端口 2. 服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存著私鑰，不能將其泄露，公鑰可以發送給任何人。 3. 服務器將自己的公鑰發送給客戶端。 4. 客戶端收到服務器端的公鑰之后，會對公鑰進行檢查，驗證其合法性，如果發現發現公鑰有問題，那么 HTTPS 傳輸就無法繼續。嚴格的說，這里應該是驗證服務器發送的數字證書的合法性。如果公鑰合格，那么客戶端會生成一個隨機值，這個隨機值就是用于進行對稱加密的密鑰，我們將該密鑰稱之為 client key，即客戶端密鑰，這樣在概念上和服務器端的密鑰容易進行區分。然后用服務器的公鑰對客戶端密鑰進行非對稱加密，這樣客戶端密鑰就變成密文了，至此，HTTPS 中的第一次 HTTP 請求結束。 5. 客戶端會發起 HTTPS 中的第二個 HTTP 請求，將加密之后的客戶端密鑰發送給服務器。 6. 服務器接收到客戶端發來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對數據進行對稱加密，這樣數據就變成了密文。 7. 然后服務器將加密后的密文發送給客戶端。 8. 客戶端收到服務器發送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發送的數據。這樣 HTTPS 中的第二個 HTTP 請求結束，整個 HTTPS 傳輸完成。 ## SSL 協議的不足 1. 因為 SSL 協議設計初衷是對 Web 站點及網上交易進行安全性保護，使消費者明白正在和誰進行交易要比使商家知道誰正在付費更為重要，為了不致于由于安全協議的使用而導致網絡性能大幅下降， SSL 協議并不是默認地要求進行客戶鑒別，這樣做雖然有悖于安全策略，但卻促進了 SSL 的廣泛應用。 2. 針對這個問題，可在必要的時候配置 SSL 協議，使其選擇對客戶端進行認證鑒別。 3. SSL 協議需要在握手之前建立 TCP 連接，因此不能對 UDP 應用進行保護。如果要兼顧 UDP 協議層之上的安全保護，可以采用 IP 層的安全解決方案。 4. 由于 SSL 只對應用數據進行保護，數據包的 IP 頭和 TCP 頭仍然暴露在外，通過檢查沒有加密的 IP 源和目的地址以及 TCP 端口號或者檢查通信數據量，一個通信分析者依然可以揭示哪一方在使用什么服務，有時甚至揭露商業或私人關系的秘密。 5. 除非 SSL 的工程實現大部分駐留在硬件中，否則主密鑰將會存留在主機的主存儲器中，這就意味著任何可以讀取 SSL 進程存儲空間的攻擊者都能讀取主密鑰，因此，不可能面對掌握機器管理特權的攻擊者而保護 SSL 連接，這個問題要依靠用戶管理策略來解決。 # CDN 工作原理淺析 [參考鏈接1](https://blog.csdn.net/coolmeme/article/details/9468743) [參考鏈接2](https://www.jianshu.com/p/1dae6e1680ff)  使用了 CDN 緩存的網站的訪問流程如下： 1.用戶向瀏覽器輸入 `www.web.com` 這個域名，瀏覽器第一次發現本地沒有 dns 緩存，則向網站的 DNS 服務器請求； 2.網站的 DNS 域名解析器設置了 CNAME，指向了 `www.web.51cdn.com`，請求指向了 CDN 網絡中的智能 DNS 負載均衡系統； 3.智能 DNS 負載均衡系統解析域名，把對用戶響應速度最快的 IP 節點返回給用戶； 4.用戶向該 IP 節點（CDN 服務器）發出請求； 5.由于是第一次訪問，CDN 服務器會向原 web 站點請求，并緩存內容； 6.請求結果發給用戶。 CDN 網絡是在用戶和服務器之間增加 Cache 層，如何將用戶的請求引導到 Cache 上獲得源服務器的數據，主要是通過接管 DNS 實現，這就是 CDN 的最基本的原理。 <br> 每個 CDN 節點由兩部分組成:**負載均衡設備** 和 **高速緩存服務器** 負載均衡設備負責每個節點中各個 Cache 的負載均衡，保證節點的工作效率;同時，負載均衡設備還負責收集節點與周圍環境的信息，保持與全局負載 DNS 的通信，實現整個系統的負載均衡。 <br> CDN 的管理系統是整個系統能夠正常運轉的保證。它不僅能對系統中的各個子系統和設備進行實時監控，對各種故障產生相應的告警，還可以實時監測到系統中總的流量和各節點的流量，并保存在系統的數據庫中，使網管人員能夠方便地進行進一步分析。通過完善的網管系統，用戶可以對系統配置進行修改。 <br> 理論上，最簡單的 CDN 網絡有一個負責全局負載均衡的 DNS 和各節點一臺 Cache，即可運行。DNS 支持根據用戶源 IP 地址解析不同的 IP，實現就近訪問。為了保證高可用性等，需要監視各節點的流量、健康狀況等。一個節點的單臺 Cache 承載數量不夠時，才需要多臺 Cache，多臺 Cache 同時 工作，才需要負載均衡器，使 Cache 群協同工作。 >CDN 的就近策略是如何實現的？也許跟路由選擇算法有關，這就好像單源最短路徑問題，求各 CDN 節點到客戶端的最短距離 CDN 服務商在全國各個省份部署計算節點，CDN 加速將網站的內容緩存在網絡邊緣,不同地區的用戶就會訪問到離自己最近的相同網絡線路上的 CDN 節點，當請求達到 CDN 節點后，節點會判斷自己的內容緩存是否有效，如果有效，則立即響應緩存內容給用戶，從而加快響應速度。如果 CDN 節點的緩存失效，它會根據服務配置去我們的內容源服務器獲取最新的資源響應給用戶，并將內容緩存下來以便響應給后續訪問的用戶。**因此，一個地區內只要有一個用戶先加載資源，在 CDN 中建立了緩存，該地區的其他后續用戶都能因此而受益**。