【面試】計算機網路

網路協議

計算機網路體系結構劃分：

各體系中的協議分布：

每一層的體系如下：

• 物理層：RJ45、CLOCK、IEEE802.3（中繼器、集線器）
• 資料鏈路層：PPP、FR、HDLC、VLAN、MAC（網橋、交換機）
• 網路層：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP（交換機）
• 傳輸層：TCP、UDP、SPX
• 會話層：NFS、SQL、NETBIOS、RPC
• 表示層：JPEG、MPEG、ASII
• 應用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

TCP中的三握四揮

TCP連接

• 建立TCP連接，三次握手：第一次握手是客戶端向服務器發送一個報文；第二次握手是服務器收到請求報文之后發送一個應答報文給客戶端；第三次握手是客戶端收到應答報文之后再發送一個報文給服務器，三次握手就算成功，

• 為什么是三次握手？兩次握手不行嗎？【需要雙方都確認各自的發送接收正常】
  • 要想建立一個TCP連接，需要共同確認客戶端服務端的發送、接收功能正常，
  • 第一次握手：客戶端向服務端發送請求，服務器收到，服務器得知：服務器接收正常、客戶端發送正常
  • 第二次握手：服務端發送應答給客戶端，客戶端收到，客戶端得知：客戶端發送接收正常、服務器發送接受正常
  • 第三次握手：客戶端發送請求給服務端，服務端收到，服務端得知：服務器發送接受正常，客戶端發送接收正常
  • 因此，至少三次握手雙方才能確認對方和己方的發送接收均正常，其中，第三次握手可以攜帶資料，前兩次不可以，

TCP釋放

• TCP連接釋放，四次揮手，【全雙工通信，需要雙方都關閉各自的發送和接收】
• 第一次揮手，客戶端發出連接釋放報文段，停止發送資料，主動關閉TCP連接，進入終止狀態1【客戶端關閉發送】
• 第二次揮手，服務端收到連接釋放報文段之后即刻向客戶端發送確認報文段，服務器進入關閉等待狀態，此時客戶端到服務器端的連接釋放，客戶端收到服務器發的確認之后進入終止狀態2【服務端關閉接收】
• 第三次揮手，服務端發出連接釋放報文段，進入最后確認狀態，等待客戶端的確認，【服務端關閉發送】
• 第四次揮手，客戶端收到連接釋放報文段，發出確認報文段，客戶端進入時間等待狀態，TCP未釋放，經過2倍最大生存時間MSL，客戶端關閉，【客戶端關閉接收】

為什么要等待2MSL才關閉客戶端？

• MSL，Maximum Segment Lifetime，最大報文段存活時間，
• ①保證客戶端發送的最后一個ACK報文段能夠到達服務端：最后一個ACK有可能丟失，在超時重傳機制下，服務端會重傳至客戶端的FIN+ACK報文段，客戶端再次接收到該報文段，重啟2MSL計時器，這個程序可以保證連接的正常釋放，這個程序中，超時和重傳至客戶端最大可能各自都需要花費2MSL時間，所以應該是2MSL而不是1MSL，
• ②防止“已失效的連接請求報文段”出現在下次連接中：經過了2倍的最大存活時間，所有報文都會消失，

輸入網址到網站加載的程序

DNS：獲取域名對應IP，DNS決議程序
TCP（傳輸控制協議）：與服務器建立連接
IP協議：建立TCP連接時，使用IP協議在網路層發送資料
OPSF（開放式最短路徑優先）：IP資料包在路由器之間進行路由選擇
ARP（地址決議協議）：路由器在與服務器通信時，將IP地址轉換為MAC地址
HTTP（超文本傳輸協議）：TCP建立完成后，使用HTTP協議訪問網頁

• DNS決議
  • DNS決議的程序就是尋找哪臺機器上有需要的資源的程序，尋找程序：①尋找瀏覽器快取中是否存在對應域名的IP地址；②尋找本機系統快取中是否存在域名對應的IP；③向本地域名決議服務器發起域名決議請求；④本地域名決議服務器向根域名決議服務器發起域名決議請求，回傳請求的頂級域名地址（gTLD）；⑤本地域名決議服務器向gTLD域名決議服務器發起請求，找到對應的域名服務器；⑥ Name Server服務器回傳IP地址給本地服務器；⑦本地域名服務器快取決議結果；⑧回傳結果給主機
• TCP連接
  • 建立TCP連接，三次握手：第一次握手是客戶端向服務器發送一個報文；第二次握手是服務器收到請求報文之后發送一個應答報文給客戶端；第三次握手是客戶端收到應答報文之后再發送一個報文給服務器，三次握手就算成功，
  • 為什么是三次握手？兩次握手不行嗎？
    • 要想建立一個TCP連接，需要共同確認客戶端服務端的發送、接收功能正常，
    • 第一次握手：客戶端向服務端發送請求，服務器收到，服務器得知：服務器接收正常、客戶端發送正常
    • 第二次握手：服務端發送應答給客戶端，客戶端收到，客戶端得知：客戶端發送接收正常、服務器發送接受正常
    • 第三次握手：客戶端發送請求給服務端，服務端收到，服務端得知：服務器發送接受正常，客戶端發送接收正常
    • 因此，至少三次握手雙方才能確認對方和己方的發送接收均正常，其中，第三次握手可以攜帶資料，前兩次不可以，
• 發送HTTP請求
  • 發送HTTP請求的程序就是構建HTTP請求報文
• 服務器處理請求并回傳回傳HTTP報文
  • 簡單來說就是后端傳來服務器請求的資料
• 瀏覽器決議渲染頁面
  • Webkit渲染頁面并顯示，構建DOM樹
• 連接結束
  • TCP連接釋放，四次揮手
  • 第一次揮手，客戶端發出連接釋放報文段，停止發送資料，主動關閉TCP連接，進入終止狀態1
  • 第二次揮手，服務端收到連接釋放報文段之后即刻向客戶端發送確認報文段，服務器進入關閉等待狀態，此時客戶端到服務器端的連接釋放，客戶端收到服務器發的確認之后進入終止狀態2
  • 第三次揮手，服務端發出連接釋放報文段，進入最后確認狀態，等待客戶端的確認，
  • 第四次揮手，客戶端收到連接釋放報文段，發出確認報文段，客戶端進入時間等待狀態，TCP未釋放，經過2倍最大生存時間MSL，客戶端關閉，

DNS尋址的遞回查詢和迭代查詢

DNS，Domain Name System，域名系統，就是根據域名（網址/URL）獲得對應IP地址，查找哪個服務器上存在對應的資源，

DNS查詢的步驟：（任何一個步驟中查到映射，直接回傳，否則進入下一個步驟）

• ①首先查找瀏覽器快取、本地hosts檔案中是否有域名映射，如果存在，則回傳IP地址映射，完成決議，
• ②查找本地DNS決議器快取是否有這個網址的映射
• ③查找本地DNS服務器：如果查詢的域名包含在本地配置區域資源，表示是由本地DNS服務器決議，具有權威性；如果查詢的域名不由本地DNS服務器區域決議，但是服務器快取有這個域名的映射，這個結果不具有權威性，但兩者都會回傳決議結果，
  • 這個程序好比于：我要查找員工屬于哪個部門，剛好找到他的所屬部門，直接得知結果，很權威；但是我要是找的部門不是他所屬部門，這個部門負責人告訴我他屬于哪個部門，我得知結果，不權威，
• ④如果本地DNS服務器失效，則使用遞回查詢或者迭代查詢來尋址：
  • 如果未采用轉發模式，使用迭代查詢，本地DNS服務器向13臺根域名服務器發起DNS請求，回傳一個負責該頂級域名的服務器IP，之后向權限域名系統發起請求，獲取到IP映射就回傳，整個查詢程序類比于DFS，有回退，
  • 如果采用轉發模式，則使用遞回查詢，本地DNS服務器會把請求轉發至上一級DNS服務器，直到查詢到IP映射回傳為止，整個查詢程序類比于BFS，沒有回退，
  • 

TCP保證安全傳輸

• 三次握手

  • 三次握手保證了連接的正常，可以得知雙方的發送和接收是正常的，

• 超時重傳

  • 發送一個資料包之后沒有收到ACK，等待一段時間，超時之后將會重新發送，這個等待的時間被稱為RTO，檢測丟失報文的方法其實就是預設定時器，當一個TCP Segment發送出去之后，啟動定時器，當定時器的時間走完，默認這個報文丟失，定時器的時間一開始是預設的（Linux為1s），當不斷嘗試超時重傳之后，會不斷疊加定時器的時間，
  • 當一個Segment發送之后，會存放在一個視窗中，等待相應的ACK確認，如果沒有收到ACK確認，那么將會一直存在視窗中，一個計時器未結束時，每個Segment在視窗中的位置不變，
  • 對于重傳時間是如何計算的問題，在RFC2988中也提供了一種至今Linux使用的方案，

• 快速重傳

  • 超時重傳中，只有當定時器結束了才會重新發送，這樣的設定在延遲要求高的環境中不符合需求，
  • 快速重傳機制，實作了另外的一種丟包評定標準，即如果接收端連續收到3次dup ACK，發送方就認為這個seq的包丟失了，立刻進行重傳，這樣的丟包評定標準下，只要接收方回復及時，就能快速開啟重傳，減少了時間消耗，
  • 在快速重傳中，會發生out-of-order的現象，但是在滑動視窗中會有嚴格的順序控制，如果收到亂序片段，那么將會需要重復發送ACK，假設發送報文段依次為1、2、3、4，現在接收方收到2、3、4，并沒有收到1，那么按照協議將需要重新發送1的ACK（但是現在沒有收到1就發不了1的ACK），而現在的2、3、4屬于亂序片段，所以可以判斷可以開始快速重傳，

• 擁塞控制

  • 某段時間內，對網路中的某一資源的請求超過了網路所能提供的可用部分，將會給網路帶來高負擔，導致網路性能下降，網路的吞吐量將會隨著負荷的增大而下降，這就是網路擁塞，發生了擁塞，那么就要避免，類比于“堵車”，同一時刻大量車輛通過單一車道，導致這條路擁塞，
  • TCP擁塞控制有四種實作演算法：慢開始（slow-start）、擁塞避免（congestion avoidance）、快重傳（fast retransmit）、快恢復（fast recovery）
  • 慢開始和擁塞避免：（兩者一般一起使用）

  

  • 慢開始和擁塞避免：這個程序中，發送方維護一個叫做擁塞視窗cwnd（congestion window）的狀態變數，擁塞視窗的大小取決于網路的擁塞程度，剛開始的時候，并不清楚網路的擁塞程度，所以最好的方法就是先試探一下，由小到大逐漸增大發送視窗，參考上圖就是發送方逐漸增大cwnd值，實際上，TCP使用位元組數作為視窗大小，每經過一個傳輸輪次，擁塞視窗就加倍，一個傳輸輪次經過的時間就是RTT，
  • 類比于限流路段，我不知道路況是否擁堵，我每次按照一定的規則開放車道，如果不堵車，我就一直增大開放的數量，最大限度地利用道路，但是這個程序中，我不可能一直按照加倍的規則開放下去，這樣遲早會一下子造成嚴重堵車，所以在實際操作中，我們還要維護一個滿開始門限ssthresh，防止一次開放過多的視窗造成擁塞，
  • 當cwnd < ssthresh，使用慢開始；當 cwnd > ssthresh，使用擁塞避免；當 cwnd = ssthresh，兩者皆可使用，擁塞避免改用每次探測之后視窗值加1的機制，避免了一次開放過多的擁塞視窗，每經過一個往返時間RTT就把發送方的擁塞視窗cwnd+1，
    
  • 快重傳和快恢復：快重傳可以快速知道個別報文段的丟失，按照下面的這種情況，快重傳機制下，接收方應該快速發送連續的三個ACK，發送方收到連續的三個ACK立即開始快重傳丟失的報文段，按照上圖的顯示，在收到三個重復的ACK之后，并不進行慢開始，而是調整慢開始門限值為 ssthresh = cwnd / 2 ，同時設定 cwnd 為1，進入慢開始階段，
  • 

• 滑動視窗

  • 滑動視窗實作的是流量控制，目的就是讓發送方發送資料不要過快，接收方要來得及接收，
  • 
  • 這個階段中，發送方發送視窗的值不應該超過接收方給出的接收視窗的值，TCP視窗單位是位元組，不是報文段，
  • 

• 檢驗和

  • 發送的資料包的二進制相加然后取反，目的是檢測資料在傳輸程序中的任何變化，如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段，利用CRC回圈冗余校驗，可以檢測或校驗資料傳輸或者保存后可能出現的錯誤，

UDP協議

• UDP（User Datagram Protocol）：用戶資料報協議，
• UDP是一種不可靠的、無連接的、盡最大努力交付的運輸層協議，它僅僅包含運輸層必備的功能：多路復用/多路分解，差錯檢測，
• 在UDP中，發送資料之后僅僅通過接收方是否回復資訊來判斷傳輸是否成功，并不會像TCP一樣收到來自接收方的反饋，所以這一點上并不可靠（UDP類比于微信聊天資訊你已讀不回復，但是我并不知道你看沒看到資訊；TCP類比于淘寶聊天資訊，我發出去了你收到并查看，我可以看到已讀來得知你看到訊息），為了解決這個問題，加入一個UDP延時，如果規定時間內收不到回復，就重新發送，DNS中就是用的UDP來發送域名查詢報文，
• UDP提供差錯檢驗，利用UDP檢驗和來實作，但是并不會進行錯誤修復，要么丟掉錯誤資訊，要么上報應用程式，
• UDP的特點：①反應迅速（無需連接）；②節省性能資源（無連接狀態）；③節省資料段空間（分組首部小），通常可以用來傳輸媒體檔案等安全性要求不高的資料，

GET和POST的區別

• GET產生一個TCP資料包；POST產生兩個TCP資料包，
• GET請求會被瀏覽器主動cache，而POST不會，除非手動設定
• GET請求只能進行URL編碼，而POST支持多種編碼方式
• GET請求引數會被完整保留在瀏覽器歷史記錄里，而POST中的引數不會被保留
• GET請求在URL中傳送的引數是有長度限制的，而POST沒有
• 對引數的資料型別，GET只接受ASCII字符，而POST沒有限制
• GET比POST更不安全，因為引數直接暴露在URL上，所以不能用來傳遞敏感資訊

Cookie和Session

• Cookie，曲奇，指的是瀏覽器發給服務器的一種檔案；Session，會話，
• Session是在服務端保存的一個資料結構，用來跟蹤用戶的狀態，這個資料可以保存在集群、資料庫、檔案中；Cookie是客戶端保存用戶資訊的一種機制，用來記錄用戶的一些資訊，也是實作Session的一種方式，HTTP協議是無狀態的協議，不能對之前的請求和回應狀態做出管理，所以為了保證無狀態又要進行管理，就提出了Cookie和Session的方案來解決這個問題，常用的場景比如用戶登錄，如果要進行安全性高的驗證登錄，HTTP本身并不知道用戶是否進行了登錄，所以為了避免每次跳轉頁面都要進行登錄，那么就得讓HTTP請求攜帶一個資訊，告訴服務器已經登錄（管理登錄狀態），
• Cookie從客戶端理解：Cookie就是附加在HTTP請求和應答中的一個附加資訊，服務器在向客戶端發送應答訊息的時候，會附帶一個Set-Cookie的首部欄位資訊，告訴客戶端瀏覽器保存Cookie，然后在客戶端下次發送請求時攜帶Cookie資訊，這樣就保證了服務器對于客戶端的狀態的管理，如果瀏覽器禁用了Cookie，那么會使用URL重寫來實作，在URL請求引數中添加一個類似于sid=xx的引數以達到相同效果，使用場景：標識用戶登錄狀態、保存用戶名和密碼等，
• 
• Session從服務端理解：Session可以理解為會話，實際中一臺服務器不可能只服務于一個用戶，那么服務端要得知各種操作歸屬于哪一用戶，為了達到這一目的，服務端會創建一個Session，標識用戶并且跟蹤用戶操作，服務端保存Session的方法一般有檔案、資料庫、記憶體，使用場景：用戶登錄之后加購操作等，

HTTP協議

• HTTP協議，Hyper Text Transfer Protocol，超文本傳輸協議，是一種應用層的協議，
• HTTP使用統一資源識別符號（Uniform Resource Identifiers，URI）來傳輸資料和建立連接，URL是一種特殊型別的URI，包含了用于查找某個資源的足夠的資訊URL，

參考檔案：HTTP協議簡單解釋_一個菜鳥的博客-CSDN博客_http協議
https://mp.weixin.qq.com/s/1Z8ieE_HKTzEBVQ54v0hqA

• HTTP的特點主要為：①簡單快速；②靈活；③無狀態（現在一般可以使用Cookie保持Session，實作了狀態追蹤）；④無連接（服務器一般對Keep-Alive功能提供支持，可以實作長連接）
• HTTP協議主要分為請求和應答程序，這兩個程序又分為：Http Request 和 Http Response
  
  • Http Request：Http請求一般分為請求行（標識請求的方法）、請求頭部（請求目的地、User-Agent等）、空行（分隔請求頭部和請求正文）、請求正文（請求的資料）
    
  • Http Response：Http應答一般分為狀態行（回應訊息的狀態碼存放處）、訊息報頭（客戶端要使用的附加資訊）、空行（分隔作用）、回應正文（對應請求應該發送的資料）
    
• HTTP協議中常用的請求報文方法主要為GET和POSt，但是還包含一些其他方法，
  

URI和URL

• URI，uniform resource identifier，統一資源識別符號，用來唯一的標識一個資源，
• URL，uniform resource locator，統一資源定位器，相當于一個具體的URI，不僅可以標志資源，還指示了如何定位這個資源，

HTTP各版本

• HTTP 0.9版本

  • HTTP協議的第一個版本，功能簡單，已棄用
  • 僅支持純文本資料的傳輸，雖然支持HTML，但是不支持圖片插入
  • 僅支持GET請求方式，且不支持請求頭
  • 無狀態，短連接，沒有對用戶狀態的管理；每次請求建立一個TCP連接，回應之后關閉TCP連接，

• HTTP 1.0版本

  • 支持POST、GET、HEAD三種方法
  • 支持長連接keep-alive（但默認還是使用短連接：瀏覽器每一次請求建立一次TCP連接，請求處理完畢之后斷開），
  • 服務器不跟蹤用戶的行為也不記錄用戶過往請求，

• HTTP 1.1版本

  • 新增PUT、DELETE、CONNECT、TRACE、OPTIONS方法，是現今使用最多的版本，
  • 支持長連接，在一次TCP連接中可以發送多個請求或回應，且默認使用長連接，
  • 支持寬帶優化、斷點續傳，請求的物件部分資料，可以不必發送整個物件；檔案上傳下載支持續傳，
  • 因為長連接產生的問題：隊頭阻塞，長連接中，發送請求和回應都是串行化的，前面的訊息會造成后面的訊息也阻塞，解決方法是創建多個TCP連接，這樣就可以基本保證了可用性，瀏覽器默認的最大TCP連接數是6個，

• HTTP 2.0版本

  • 二進制分幀，所有幀都是用二進制編碼，節省了空間
  • 多路復用：HTTP 2.0中所有的連接都是持久化的，相比1.1版本可以不用維護更多的TCP連接，在處理并發請求的時候，可以將多個資料流中互不依賴的幀可以亂序發送，同時還支持優先級，接收方接收之后可以根據幀頭部資訊將幀組合起來，（解決了1.1版本中的隊頭阻塞問題）
  • 頭部壓縮：1.1版本每次傳輸都需要傳輸一份首部，2.0讓雙方各自快取一份首部欄位表，達到更快傳輸的目標，

• HTTP 3.0版本

  • 基于UDP的QUIC多路復用：在一個QUIC中可以并發發送多個HTTP請求Stream，且如果各個Stream互不依賴，那么就不會造成使用TCP帶來的隊頭阻塞問題，這個問題源頭上是因為TCP連接，TCP連接的性質決定了重傳會影響隊后的資料發送，所以干脆選用UDP來解決這個方案，
  • 0RRT建鏈：RRT表示Round-Trip Time，3.0可以實作0RRT建鏈，一般來說HTTPS協議要建立完整鏈接包括TCP握手和TLS握手，總計需要至少2-3個RTT，普通的HTTP協議也需要至少1個RTT才可以完成握手，基于UDP的QUIC協議可以在第一次發送包的時候直接發送業務資料，但是由于首次連接需要發送公鑰資料，所以首次連接并不使用這一方法，

  

  參考檔案：圖解 | 為什么HTTP3.0要棄用TCP協議，而改用UDP協議？_濤哥聊Python-CSDN博客

HTTP斷點續傳

HTTP的斷點續傳，保證了在傳輸檔案的時候因意外中斷的傳輸能夠在恢復的時候繼續傳輸，主要原理是是HTTP1.1（RFC2616）中header定義的Range和contentRange欄位，記分別記錄了檔案的大小以及傳輸節點，

支持斷點續傳的思路是：客戶端（通常是瀏覽器）向服務器端上傳某個檔案，服務器端不斷記錄上傳的進度，如果一旦掉線或發生其它例外，客戶端可以向服務器查詢某個檔案已經上傳的狀態，從上次上傳的檔案位置接著上傳，

實作思路：①記錄當前檔案；②規定檔案的切片粒度；③記錄檔案的傳輸進度；④記錄傳輸中斷點；⑤中斷點續傳

• 記錄當前檔案：不能單依靠檔案名來進行設計，一般也不根據檔案內容來標識（太復雜），采用的方案是：檔案名+檔案修改時間+檔案大小+瀏覽器ID的組合值來進行Hash計算，這樣基本能滿足所有需求，
• 規定檔案切片粒度：HTML5中的File.slice(start,end)可以對檔案進行切片處理，
• 記錄檔案傳輸進度：通過HTML可以計算檔案上傳的進度，已傳輸的檔案可以不必再進行上傳，
• 記錄傳輸中斷點：一旦發生故障，這個切片內檔案未傳輸完，那么記錄該切片的位置，下次重傳的位置，
• 中斷點續傳：記錄重傳點，之后開始對檔案未上傳完的部分繼續上傳，

HTTPS保證安全

HTTP協議在使用的時候是進行一個明文傳輸的，這樣不可避免的會出現三大問題：

（1） 竊聽風險（eavesdropping）：第三方可以獲知通信內容，
（2） 篡改風險（tampering）：第三方可以修改通信內容，
（3） 冒充風險（pretending）：第三方可以冒充他人身份參與通信，

HTTPS即HTTP+SSL協議，SSL，Secure Sockets Layer，安全套接字協議，現在實際使用中SSL已經被TLS替代，TLS，Transport Layer Security，安全傳輸層協議，使用這兩個協議可以一定程度加強安全性，

• 證書加密：服務器在使用證書加密之前，需要向證書頒發機構CA申請證書，在HTTPS的連接程序中，服務器會把證書發送給客戶端，客戶端驗證證書是否過期、合法等，以此來判定服務器的身份，雖然證書很多，但是CA機構是有限的，一般的作業系統都會將CA寫到系統中，所以驗證合法性其實很簡單，
  • 驗證合法性的操作：①首先根據證書層級關系找到上級證書；②服務器證書中存在一個證書指紋，利用上級證書的公鑰解密證書指紋得到簽名sign1；③通過簽名演算法算得服務器證書的簽名sign2；④如果sign1==sign2則代表證書不是偽造的也沒被篡改，

HTTPS的連接分為七個步驟：

1. Client Hello
2. Server Hello
3. 服務器發送證書
4. 客戶端驗證證書
5. 客戶端生成亂數，通過證書中的公鑰進行非對稱加密，發送到服務器
6. 服務器使用私鑰解密，獲取到該亂數，將該亂數設定為密鑰，使用對稱加密加密需要發送的資料
7. 客戶端解密資料，SSL通信開始

HTTPS在加密的程序中使用的是非對稱加密，使用公鑰對要進行傳輸的資訊進行加密，再使用私鑰可以對加密過后的資訊進行解密（逆向也行），不同于對稱加密中加密解密使用的是相同的密鑰，非對稱加密即便公鑰泄露也無法用公鑰解密加密的資訊，

不使用對稱加密進行加密的原因：要對資訊進行加密，那么客戶端必須要接收到來自服務器的密鑰，密鑰的傳輸不加密等于沒加密，密鑰的傳輸加密也需要一個密鑰，這樣嵌套下去最終不是解決問題的辦法，

事實上，非對稱加密（公鑰加密演算法）通常用于首次連接的建立中，之后的資料加密考慮到速度問題一般使用到的是對稱加密，解決方案：使用公鑰加密演算法加密以后要使用的公鑰，之后使用公鑰進行加密傳輸的資料，

實際上即便采用公鑰加密的方式進行傳輸，還是可能會出現問題，在實際的網路使用中，BS雙方都需要發送資料，所以雙方各自都需要生成公鑰和密鑰，首次連接時需要交換各自的公鑰，然后雙方使用對方提供的公鑰加密傳輸資訊傳輸之后的資料，

考慮首次交換密鑰的安全性，一旦首次交換密鑰就發生中間人攻擊，同時又無法確定密鑰真偽性，就不能保證后續通訊安全了，

• 常用的對稱加密演算法：DES、AES、3DES、RC2、RC4
• 常用的非對稱加密演算法：RSA（最著名的公鑰加密演算法）、DSA、ECC
• 單向散列函式的加密演算法：MD5、SHA

RSA加密演算法

對于非對稱加密，難點在于找到一對公鑰私鑰，利用公鑰不可以推算出私鑰，或者使用私鑰不可以推算出公鑰，這就要求找到一種不可逆的演算法，加減乘除這樣的計算是可逆的，知道其中的兩個數（可以類比于加密資訊、公鑰或私鑰的一個）可以推算出另外一個數，不可逆的計算最典型的就是取模計算，例如 10 % 3 = 1，知道1和3兩個數字并不能知道目標數字就是10，所以是不可逆的，

要算出這個x的值，唯一方法就是遍歷，小的數字范圍是可行的，但是如果是這種：

這樣的情況下基本不可能通過遍歷的方法求結果，所以就稱模運算是單向函式，不可逆計算，

如果要加密的內容是m，加密使用的密鑰是e，加密之后的密文是c，要求出這個m只需要將c用解密的密鑰d進行冪運算，再對N取模即可，

再將上面的兩個公式合并，可以得到：

如何對e和d進行取值，需要用到歐拉定理：

歐拉函式：對于一個正整數n，小于n且和n互質的正整數（包括1）的個數，記作φ(n) ，

簡單來說，φ(n) 就是算**[1,n)**范圍的內的質因數個數，

將等式進行變換之后，可以得到下面的形式：

這個時候對比上面的加密解密程序，可以得到d和e的關系：

根據歐拉函式的性質，可以得到質數的歐拉函式結果等于本身-1，且兩個質數的乘積的歐拉函式的值等于各自的歐拉函式結果乘積，根據這兩個性質，一般計算歐拉函式的方法就是質因數分解（利用遞回計算），可以得到：

在這里e和n就作為加密的公鑰，d就作為解密的私鑰，例如：對字符a的加密解密程序

參考檔案：對稱加密與非對稱加密，以及RSA的原理_LeeLu的博客-CSDN博客_rsa對稱加密還是非對稱
參考資料：探秘公鑰加密演算法 RSA_嗶哩嗶哩_bilibili

對稱加密和非對稱加密

• 對稱加密，加密和解密使用的是同一把密鑰，常用的對稱加密演算法：DES，AES，3DES
• 非對稱加密，加密和解密使用的是不同的密鑰，一把作為公開分享給加密方的叫做公鑰，另一把不分享作為解密的私鑰，公鑰加密的密文只有私鑰能進行解密；私鑰加密的密文也只有公鑰能進行解密，常見的非對稱加密演算法：RSA，ECC
• 在效率上來說，對稱加密的效率顯然更高，但是非對稱加密的安全性更高，所以一般在實際的HTTPS加密程序中，首次連接使用的是公鑰加密演算法（非對稱加密）來傳輸資料加密所要使用的對稱加密的密鑰，之后傳輸中使用的都是對稱加密演算法，

HTTP常見狀態碼

ARP協議和RARP協議

• ARP協議，Address Resolution Protocol，地址決議協議，根據IP地址找到設備的物理地址，ARP協議歸屬于網路層，因為IP協議中使用了ARP協議，

• RARP協議，Reverse Address Resolution Protocol，反向地址轉換協議，根據MAC地址找到IP地址，現在一般使用DHCP協議，這個協議實作了RARP協議的功能，
• 每一臺主機都設有一個ARP高速快取（ARP cache），里面有本局域網上的各主機和路由器的IP地址到硬體地址的映射表，這些都是該主機目前知道的一些地址，
• ARP運行之時，使用協議在ARP映射表中查找目標IP的硬體地址，如果存在，則回傳目標IP的MAC地址；反之：①向當前局域網廣播目的IP發送ARP請求分組；②其他主機收到ARP請求分組；③目的主機收到ARP請求分組并回應；④請求主機將目的主機回應資訊寫入ARP映射表，