基礎面試題 — 計算機網絡

有感而發

做爲計算機相關專業的必修課之一，計算機網絡在編程中的地位從未被超越。整個社會都在高度依賴網絡所提供的各類服務，咱們一邊享受網絡所提供的便利，一邊也在經過網絡成爲被販賣的對象，網絡安全的重要性，日益凸顯。此外，若是太依賴於網絡，每天生活在網絡中，在必定程度上也會削弱咱們在實際生活中的各項技能，所以，審時度勢，合理利用網絡，方能讓咱們活得更出彩。若是咱們告別各類電子設備，迴歸到煤油燈的生活，想一想天天都有大把的時間，能夠作……也能夠作……（反正不會熬夜）。

計算機網絡體系結構

計算機網絡的體系結構也就是咱們熟知的七層網絡模型或五層網絡模型，接下來從下往上大體介紹下各個層級及其做用：

• 物理層：其任務是規範物理傳輸媒介相關接口的特性（可理解爲把光電信號轉換成0或1比特數據，根據0或1比特數據轉換成對應的光電信號）；
• 數據鏈路層：在相鄰節點之間透明傳送被封裝成幀的IP數據報（封裝成幀，透明傳輸）；
• 網絡層（IP層）：經過選擇合適的路由，爲網絡系統中的主機提供通訊服務（路由選擇，地址解析等）；
• 傳輸層：經過傳輸層的協議，爲不一樣主機間的應用進程提供通訊服務（經過端口區分進程）；
• 會話層：負責處理不一樣主機進程間會話的創建、控制和關閉（會話管理，數據流同步）；
• 表示層：負責根據數據格式、編碼、壓縮和解壓縮、加密和解密，轉換計算機和網絡通訊間的數據格式；
• 應用層：爲用戶應用程序提供通訊服務，保證通訊雙方的可用性和數據的完整性；

一些關鍵詞

• ping：ICMP網際控制報文協議，通常使用ICMP協議的回送請求和回送應答測試兩個主機之間的連通性；
• MTU：Maximum Transfer Unit最大傳送單元，即IP數據報，鏈路層所容許的最大傳輸單元；
• MSS：Maximum Segment Size最大報文段長度，即傳送到IP層不須要分片的長度；

差錯檢驗

• 傳輸層：對數據段和頭部總體校驗（IP頭部長度：TCP20字節，UDP8字節）；
• 網絡層：只校驗首部（IP層首部20字節）；
• 鏈路層：比特差錯校驗（校驗0和1）；

TCP和UDP的區別？

協議	面向鏈接？	可靠交付？	點對點？	擁塞避免？	流量控制？	面向字節or報文？
UDP	無鏈接	盡最大努力但不保證可靠	一對1、多對多、多對1、多對多	不支持	不支持	面向報文
TCP	面向鏈接	保證可靠	只支持一對一	支持	支持	面向字節流（會對字節進行編號）

TCP 爲什麼要三次握手和四次揮手？

TCP是面向鏈接的，因此在數據傳輸以前要先創建鏈接，3次握手是爲了創建鏈接，數據傳輸完畢後必需要釋放鏈接，4次揮手就是爲了釋放鏈接。

• 三次握手（簡化版）
  1. 服務端建立傳輸控制塊TCB，準備接收客戶端的鏈接請求並進入LISTEN（收聽）狀態，客戶端建立TCB後向服務端發送鏈接請求報文；
  2. 服務端收到後隨即發出確認報文（此時還沒創建鏈接）；
  3. 客戶端收到服務器端的確認後再發出一次確認報文，服務端收到後創建鏈接，握手結束。

PS：客戶端最後發送的那次確認主要是爲了防止已失效的鏈接請求報文忽然又傳送到服務端，於是產生錯誤和致使服務端資源浪費。

• 四次揮手（簡化版）
  1. 客戶端應用進程先向其TCP發出鏈接釋放報文並中止數據的發送，進入終止等待狀態
  2. 服務端收到後隨即發出去確認並進入關閉等待狀態，客戶端收到確認後進入終止等待狀態2，若服務端仍有數據須要發送給客戶端，客戶端仍然須要接收。
  3. 服務端確認沒有須要向客戶端發送的數據後，服務端應用進程通知TCP釋放鏈接，並進入最後確認狀態，等待客戶端的確認
  4. 客戶端收到服務端的鏈接釋放的報文後，向服務端發出確認，服務端收到確認後關閉鏈接，客戶端在等待最長報文壽命結束後也關閉鏈接(若服務端超時沒有收到確認，則須要重發釋放鏈接的請求，此時客戶端會繼續發出確認並從新開啓一個等待計時器；防止已失效的鏈接請求報文出如今本鏈接中）

TCP 如何保證可靠的？

TCP協議主要是經過確認和重傳機制來保證可靠交付，TCP會對報文數據進行編號，每一個報文段都有起始編號和尾部編號，一個報文段能夠理解爲一個發送窗口的大小，也就是發送方來在未收到對方確認的狀況下能夠連續發送的報文大小。

1. 對於發送方來講發送報文段數據時，同時開啓超時計時器，在未收到確認以前都會暫時保留一份副本，發送方通過一段時間後（由超時計時器控制）就重傳這部分數據（多是發送方發送的報文超時，也多是接收方發送的確認超時），並從新設置超時計時器，直到收到確認爲止。
2. 發送方接收到確認（已收到的報文號段和期待下次接收的報文號段）後，移除保留的對應的報文段副本（從發送緩存中移除），並移動發送窗口，發送新的數據。
3. 接收方把接收到的報文段放到接收緩存中，包括按序到達的、但還沒有被接收應用程序讀取的數據和未按序到達的數據。接收方等到字節流中所缺乏的字節收到後，再按序交付給上層的應用進程。
4. 接收方若是收到的分組被檢測出有差錯或重複的數據就會丟棄，接收方可能會有缺失的報文段，對於接收方來講沒有收到就不會發送確認，此時發送方會重傳未被確認的報文段。

TCP 流量控制

流量控制就是讓發送發的發送速率不要太快，要讓接收方來得及接收。假設A向B發送數據，在鏈接創建時，B告訴A個人接收窗口rwnd="400"（rwnd表示receiver window，字節單位），假設一個報文段長度是100字節，A發送了序號1-100的報文段，還能發送300字節，A發送序號101-200報文段，還能發送200字節，此時B發送了序號1-100報文段和rwnd=300字節的確認報文，此時A可發送的大小就是300字節，若是A已發送了400字節，就不容許A再發送數據了，容許A超時重發舊的數據，但不容許A發送新數據，總的來講就是接收方控制發送方發送數據的速率，以便接收方來得及接收。

TCP 擁塞控制

TCP主要經過慢開始和擁塞避免進行擁塞控制。在不清楚網絡負荷的狀況下，若把大量數據發送到網絡，那麼就可能引發網絡擁塞，因此會先探測一下，即從小到大逐漸增大擁塞窗口（等同於發送窗口），當網絡出現擁塞再把擁塞窗口減少一些，以減小注入到網絡中的分組數。

1. TCP初始化時會把擁塞窗口設置爲一個MSS大小，並初始化慢開始門限（調節發送窗口大小）的值，在每收到一個對新的報文段的確認後，把擁塞窗口增長至多一個MSS的數值（1變2，2變4，4變8），用這樣的方法逐步增大發送方的擁塞窗口cwnd，使報文注入到網絡的速率更加合理。
2. 隨着傳輸輪次的增長，擁塞窗口的大小曾指數級增加，當擁塞窗口的大小等於慢開始門限的值時，此時會從慢開始切換到擁塞避免，能夠理解爲把擁塞窗口以前的指數級增加改成線性緩慢增加（通過一個往返時間擁塞窗口僅增長一個MSS大小）。
3. 隨着擁塞窗口的逐漸增大，當檢測到報文超時（在超時計時器內沒有收到確認），就把慢開始門限的值更新爲出現擁塞時擁塞窗口大小的一半，同時把擁塞窗口的大小從新置爲一個MSS，並開始執行慢開始算法，如此往復。

HTTP的組成部分

HTTP由三部分組成：開始行、Header和Body體；

• 開始行：用於區分是請求行仍是響應行
  • 請求行：Method URL HTTP/Version，如：GET /Joelixy/IVAlgorithms HTTP/1.1；
  • 狀態行：HTTP/Version StatusCode StatusMsg，如：HTTP/1.1 404 Not Found；
• Header

  • Request Header（通常有如圖所示字段，也可自定義）

    

  • Response Header（具體請參考下圖）

    

• Body
  • 通常的POST請求只有相關參數，上傳文件的POST請求會包含被編碼的文件數據。

上傳文件的HTTP請求

• —$boundary：能夠認爲是Body的邊界
• Content-Disposition：用於指定呈現方式，如：from-data：name="txt"
• Content-Type：
  • application/x-www-form-urlencoded：用來提交文本，不能上傳文件，用$_POST[]接收
  • multipart/form-data：用來提交表單數據，用$_FILES接收
• Content-Transfer-encoding：默認的編碼行不通時可指定編碼方式
• 數據：被上傳的編碼後的數據

GET和POST的區別

1. GET從服務端獲取數據，POST向服務端傳送數據
2. GET參數添加到表單的ACTION屬性所指的URL中；POST中將字段及其內容放置在HTML HEADER內一塊兒傳送到ACTION屬性所指的URL地址，用戶看不到這個過程。
3. 服務端用Request.QueryString獲取變量的值，用Request.Form獲取表單中的數據
4. GET傳送數據量較小，2KB之內，POST不受限，主要取決於服務端的限制
5. 安全性不同，GET請求直接暴露給用戶了，且還可能被服務器記錄，有泄漏風險；POST的全部操做對用戶都是不可見的

網絡安全

密碼體制

主要有兩種，一種是對稱祕鑰密碼體制，另外一種是公鑰密碼體制。

• 對稱密鑰密碼體制：即加密與解密都是相同的密碼體制，加解密速度快，可是若不對密鑰分發的過程加以保護，密鑰泄漏的風險仍是很高。
• 公鑰密碼體制：使用不一樣的加密密鑰和解密密鑰，即公鑰和私鑰，公鑰是公開的，私鑰是保密的，公鑰加密的數據只有私鑰能解密，私鑰加密的數據只有公鑰能解密。

密鑰分配

因爲密碼算法是公開的，因此網絡的安全性就徹底基於密鑰的安全之上，所以密鑰的管理和分發就顯得無比重要了。目前通用的作法是：

• 用公鑰分發：經過公鑰對臨時會話產生的對稱密鑰進行加密，而後進行分發，私鑰解密後，雙方就按照約定的加密方式進行加解密，對稱密鑰對數據加解密，公私鑰用於對報文鑑別。
• 雙向驗證：通訊的雙方都有本身的公鑰和私鑰對，通訊時經過證書的解析獲得對方的公鑰，而後雙發都有了本身的私鑰和對方的公鑰，這樣就能夠互相解密對方的加密數據，只是這種方式效率過低，不適合頻繁的網絡請求場景。

數字簽名

籤合同的時候，咱們都須要進行簽名，就是爲了保證其真實性，經過驗證簽名來代表這份合同的真實性。數字簽名就是爲了保證這個數據是某個發送者發送的，由於只有它才能夠有這樣的簽名，因此數字簽名必須保證三點功能：「報文鑑別、報文的完整性和不能否認」。

1. 報文鑑別：接收者可以覈實發送者對報文的簽名，也就是說，接收者能夠鑑別該報文的確是發送者發送的，其餘人沒法僞造對報文的簽名。
2. 報文的完整性：接收者確信所收到的數據和發送者發送的徹底同樣，沒有被篡改過，這就叫報文的完整性。
3. 不能否認：發送者過後不能抵賴對報文的簽名。

HTTPS如何對報文鑑別來保證數據的完整性？

1. 以客戶端和服務端爲例，服務端在發送報文時，會經過報文摘要算法對報文進行計算獲得報文摘要，而後服務端用本身的私鑰對報文摘要進行簽名，最後把簽名後的報文摘要追加到報文後一塊兒發送給客戶端。
2. 客戶端在收到服務端的報文後，把簽過名的報文摘要和報文進行分離後，會作兩件事，（1）客戶端用服務端的公鑰對簽過名的報文摘要解密獲得報文摘要，（2）對接收的報文進行報文摘要計算，也會獲得一個報文摘要。客戶端對比兩個報文摘要，若相等則說明收到的報文就是服務端發送的，相等也說明數據沒有被篡改過，不然說明數據被篡改或不是服務端發送的。
3. 同理，客戶端發送報文時也同樣，用本身的公鑰對報文摘要簽名，而後追加到報文後發送給服務端，服務端用私鑰解密，並作一樣的事情，來對報文進行鑑別。

HTTPS的握手流程

• 客戶端：向服務端發送clientHello以及支持的SSL版本號和加密套件、隨機字符串（後面協商對稱祕鑰的時候須要）
• 服務端：向客戶端發送ServerHello以及支持的SSL版本號和選擇的加密套件、隨機字符串和服務器的證書（被CA機構的私鑰簽名過的證書，有RSA公鑰、域名、版本、簽名使用的加密算法等，若須要雙向驗證，則須要客戶端也提供相應的證書，此處只考慮單向驗證）
• 客戶端：支持HTTPS的通常都有個可信的CA表（內置客戶端或系統中），表中有CA的公鑰（CA認證中心的公鑰都是公開的）。客戶端收到服務端的證書時就檢查此證書的發行者是否在本身的可信CA表中。若不在則沒法創建加密鏈接，若在就使用CA表中相應的公鑰對證書校驗並解密獲得服務端的公鑰。而後用公鑰加密客戶端產生的隨機字符串併發送給服務端，服務端收到後用私鑰解密獲得隨機字符串，此時雙方都有三個字符串，會用約定的加密方式加密隨機字符串生成對稱密鑰。
• 客戶端：向服務器發送一個報文，說明之後客戶端將使用此會話對稱密鑰進行加解密。而後客戶端再向服務器發送一個單獨的加密報文，代表客戶端的握手過程已完成。
• 服務端：也向客戶端發送一個報文，說明之後服務端將使用此會話密鑰進行加解密，而後服務端再向客戶端發送一個單獨的加密報文，代表服務端的握手過程已完成。
• 此時SSL握手已經完成，下面就能夠開始SSL的會話；

淘寶頁面發送HTTP請求的過程

• DNS解析（查找過程：本地域名Server(DNS高速緩存)->根域名Server->COM頂級域名Server
  • 先查找瀏覽器的DNS緩存->系統的DNS緩存->DNS服務器(先查找本身的DNS緩存->根域名Server->COM頂級域名->域名註冊商
  • 如：www.google.com域名，真實的域名是www.google.com.多一個點，瀏覽器向DNS請求時會自動添加該點，表示根域名服務器。
  • DNS緩存：瀏覽器緩存-系統緩存-路由器緩存-IPS服務器緩存-跟域名Server-頂級域名Server-主域名Server
• TCP創建鏈接
  • 拿到域名IP地址後，客戶端以一個隨機端口向服務器的Web程序80端口發起鏈接請求，鏈接請求通過下面4層網絡模型層層封裝到達服務端，進入到服務端的內核的TCP/IP協議棧，識別鏈接請求層層解開數據報，找到80端口到達Web程序，
• 發送HTTP請求（三部分）
  • GET：要求服務器將URL定位的資源放在響應報文的數據部分發送給客戶端，URL和參數經過「？」分割
  • POST：將數據封裝在HTTP請求數據中(HTML HEAD)
• 服務器處理HTTP請求並返回HTTP報文
  • 處理後就把數據返回給客戶端HTML數據
• 客戶端解析數據並渲染頁面
  • 客戶端解析HTML拿到數據，而後開始渲染頁面
• 斷開TCP鏈接
  • 服務端在一段時間後若沒有收到客戶端的請求，鏈接就會關閉；

總結

網絡是那麼的重要，幾乎每一個項目都避不開它，並且還可能會出現不少奇奇怪怪的網絡問題，因此有關網絡的相關基礎理論是編寫和調試網絡模塊的必備知識，最好經過調試來了解請求是如何創建和相互通訊的。

---

PS：以上描述的相關知識點，由我的總結並進行了簡化，不免會有不足和錯誤的地方，歡迎你們指正！