計算機網絡面試考點全面解析

傳輸層概述

• 做用：傳輸層爲它上面的應用層提供通訊服務。
• 在OSI七層參考模型中，傳輸層是面向通訊的最高層，也是用戶功能的最底層。
• 傳輸層兩大重要的功能：複用 和 分用。
  • 複用：在發送端，多個應用進程公用一個傳輸層；
  • 分用：在接收端，傳輸層會根據端口號將數據分派給不一樣的應用進程。
• 和網絡層的區別：
  • 網絡層爲不一樣主機提供通訊服務，而傳輸層爲不一樣主機的不一樣應用提供通訊服務。
  • 網絡層只對報文頭部進行差錯檢測，而傳輸層對整個報文進行差錯檢測。

UDP（用戶數據報協議）詳解

UDP的特色

1. UDP只在IP數據報服務的基礎上增長了少許的功能：複用與分用、對整個報文的差錯檢測。

2. UDP是無鏈接的 通訊前不須要創建鏈接，通訊結束也無需釋放鏈接。

3. UDP是不可靠的 它是盡力而爲交付，不能確保每個數據報都送達。

4. UDP是面向報文的 所謂『面向報文』就是指：UDP數據傳輸的單位是報文，且不會對數據做任何 拆分 和 拼接 操做。 在發送端，應用程序給傳輸層的UDP什麼樣的數據，UDP不會對數據進行切分，只增長一個UDP頭並交給網絡層。 在接收端，UDP收到網絡層的數據報後，去除IP數據報頭部後遍交給應用層，不會做任何拼接操做。

5. UDP沒有擁塞控制 UDP始終以恆定的速率發送數據，並不會根據網絡擁塞狀況對發送速率做調整。這種方式有利有弊。 弊端：網絡擁塞時有些報文可能會丟失，所以UDP不可靠。 優勢：有些使用場景容許報文丟失，如：直播、語音通話，但對實時性要求很高，此時UDP仍是頗有用武之地的。

6. UDP支持一對1、一對多、多對多、多對一通訊 而TCP只支持一對一通訊。

7. UDP首部開銷小，只有8字節。 而TCP頭部至少由20字節，相比於TCP要高效不少。

PS：問：UDP不可靠具體體如今哪些方面？ 數據報丟失？數據報順序？

UDP報文頭

• 源端口
• 目的端口
• 長度：整個數據報的長度
• 檢驗和：整個數據報的檢驗和。

TCP（傳輸控制協議）詳解

TCP特色

1. TCP是面向鏈接的 通訊前須要創建鏈接，通訊結束須要釋放鏈接。

2. TCP提供可靠交付服務 所謂『可靠』指的是：TCP發送的數據無重複、無丟失、無錯誤、與發送端順序一致。

3. TCP是面向字節流的 所謂『面向字節流』指的是：TCP以字節爲單位。雖然傳輸的過程當中數據被劃分紅一個個數據報，但這只是爲了方便傳輸，接收端最終接受到的數據將與發送端的數據如出一轍。

4. TCP提供全雙工通訊 所謂『全雙工通訊』指的是：TCP的兩端既能夠做爲發送端，也能夠做爲接收端。

5. 一條TCP鏈接的兩端只能有兩個端點 TCP只能提供點到點的通訊，而UDP能夠任意方式的通訊。

TCP鏈接 與 套接字

• 什麼是『TCP鏈接』？ TCP鏈接是一種抽象的概念，表示一條能夠通訊的鏈路。 每條TCP鏈接有且僅有兩個端點，表示通訊的雙方。且雙發在任意時刻均可以做爲發送者和接收者。

• 什麼是『套接字』？ 一條TCP鏈接的兩端就是兩個套接字。 套接字=IP地址:端口號。 所以，TCP鏈接=（套接字1，套接字2）=（IP1:端口號1，IP2:端口號2）

TCP頭部

TCP頭部長度有20字節的固定部分，選項部分長度不定，但最多40字節，所以TCP頭部在20-60字節之間。

1. 源端口 和 目的端口 傳輸層和網絡層一大重要區別就是傳輸層指定了數據報發往的應用進程，所以須要端口號標識。

2. 序號 當前TCP數據報數據部分的第一個字節的序號。 咱們知道，TCP是面向字節的，它會對發送的每個字節進行編號，並且不一樣數據報之間是連續編號的。 因爲本字段4字節，能夠給[0,2^32-1]個字節進行編號（大約4G），並且序號循環使用，當發送完2^32-1個字節後，序號又從0開始。 通常來講，當2^32-1個字節被髮送的時候，前面的字節早就發送成功了，所以序號能夠循環使用。

3. 確認號 表示當前主機做爲接收端時，指望接收的下一個字節的編號是多少。 也表示，當前主機已經正確接收的最後一個字節序號+1。

4. 數據偏移（報文長度） 它代表了數據報頭部的長度。

5. 保留字段

6. 標識符 TCP有7種標識符，用於表示TCP報文的性質。它們只能爲0或1。

• URG=1 當URG字段被置1，表示本數據報的數據部分包含緊急信息，此時緊急指針有效。 緊急數據必定位於當前數據包數據部分的最前面，緊急指針標明瞭緊急數據的尾部。 如control+c：這個命令要求操做系統當即中止當前進程。此時，這條命令就會存放在數據包數據部分的開頭，並由緊急指針標識命令的位置，並URG字段被置1。

• ACK=1 ACK被置1後確認號字段纔有效。 此外，TCP規定，在鏈接創建後傳送的全部報文段都必須把ACK置1。

• PSH=1 當接收方收到PSH=1的報文後，會當即將數據交付給應用程序，而不會等到緩衝區滿後再提交。 一些交互式應用須要這樣的功能，下降命令的響應時間。

• RST=1 當該值爲1時，表示當前TCP鏈接出現嚴重問題，必需要釋放重連。

• SYN=1 SYN在創建鏈接時使用。 當SYN=1，ACK=0時，表示當前報文段是一個鏈接請求報文。 當SYN=1，ACK=1時，表示當前報文段是一個贊成創建鏈接的應答報文。

• FIN=1 FIN=1表示此報文段是一個釋放鏈接的請求報文。

7. 接收窗口大小 該字段用於實現TCP的流量控制。 它表示當前接收方的接收窗口的剩餘容量，發送方收到該值後會將發送窗口調整成該值的大小。發送窗口的大小又決定了發送速率，因此接收方經過設置該值就能夠控制發送放的發送速率。 發送方每收到一個數據報都要調整當前的發送窗口。

8. 檢驗和 用於接收端檢驗整個數據包在傳輸過程當中是否出錯。

9. 緊急指針 用於標識緊急數據的尾部。

10. 選項字段 上述字段都是每一個TCP頭部必需要有的，而選項字段是可選的，且長度可變，最長40字節。 最經常使用的選項字段爲MMS：最大報文長度。

TCP三次握手

PS：TCP協議中，主動發起請求的一端稱爲『客戶端』，被動鏈接的一端稱爲『服務端』。無論是客戶端仍是服務端，TCP鏈接創建完後都能發送和接收數據。

起初，服務器和客戶端都爲CLOSED狀態。在通訊開始前，雙方都得建立各自的傳輸控制塊（TCB）。 服務器建立完TCB後遍進入LISTEN狀態，此時準備接收客戶端發來的鏈接請求。

第一次握手 客戶端向服務端發送鏈接請求報文段。該報文段的頭部中SYN=1，ACK=0，seq=x。請求發送後，客戶端便進入SYN-SENT狀態。

• PS1：SYN=1，ACK=0表示該報文段爲鏈接請求報文。
• PS2：x爲本次TCP通訊的字節流的初始序號。 TCP規定：SYN=1的報文段不能有數據部分，但要消耗掉一個序號。

第二次握手 服務端收到鏈接請求報文段後，若是贊成鏈接，則會發送一個應答：SYN=1，ACK=1，seq=y，ack=x+1。 該應答發送完成後便進入SYN-RCVD狀態。

• PS1：SYN=1，ACK=1表示該報文段爲鏈接贊成的應答報文。
• PS2：seq=y表示服務端做爲發送者時，發送字節流的初始序號。
• PS3：ack=x+1表示服務端但願下一個數據報發送序號從x+1開始的字節。

第三次握手 當客戶端收到鏈接贊成的應答後，還要向服務端發送一個確認報文段，表示：服務端發來的鏈接贊成應答已經成功收到。 該報文段的頭部爲：ACK=1，seq=x+1，ack=y+1。 客戶端發完這個報文段後便進入ESTABLISHED狀態，服務端收到這個應答後也進入ESTABLISHED狀態，此時鏈接的創建完成！

爲何鏈接創建須要三次握手，而不是兩次握手？ 防止失效的鏈接請求報文段被服務端接收，從而產生錯誤。

PS：失效的鏈接請求：若客戶端向服務端發送的鏈接請求丟失，客戶端等待應答超時後就會再次發送鏈接請求，此時，上一個鏈接請求就是『失效的』。

若創建鏈接只需兩次握手，客戶端並無太大的變化，仍然須要得到服務端的應答後才進入ESTABLISHED狀態，而服務端在收到鏈接請求後就進入ESTABLISHED狀態。此時若是網絡擁塞，客戶端發送的鏈接請求遲遲到不了服務端，客戶端便超時重發請求，若是服務端正確接收並確認應答，雙方便開始通訊，通訊結束後釋放鏈接。此時，若是那個失效的鏈接請求抵達了服務端，因爲只有兩次握手，服務端收到請求就會進入ESTABLISHED狀態，等待發送數據或主動發送數據。但此時的客戶端早已進入CLOSED狀態，服務端將會一直等待下去，這樣浪費服務端鏈接資源。

TCP四次揮手

TCP鏈接的釋放一共須要四步，所以稱爲『四次揮手』。 咱們知道，TCP鏈接是雙向的，所以在四次揮手中，前兩次揮手用於斷開一個方向的鏈接，後兩次揮手用於斷開另外一方向的鏈接。

第一次揮手 若A認爲數據發送完成，則它須要向B發送鏈接釋放請求。該請求只有報文頭，頭中攜帶的主要參數爲： FIN=1，seq=u。此時，A將進入FIN-WAIT-1狀態。

• PS1：FIN=1表示該報文段是一個鏈接釋放請求。
• PS2：seq=u，u-1是A向B發送的最後一個字節的序號。

第二次揮手 B收到鏈接釋放請求後，會通知相應的應用程序，告訴它A向B這個方向的鏈接已經釋放。此時B進入CLOSE-WAIT狀態，並向A發送鏈接釋放的應答，其報文頭包含： ACK=1，seq=v，ack=u+1。

• PS1：ACK=1：除TCP鏈接請求報文段之外，TCP通訊過程當中全部數據報的ACK都爲1，表示應答。
• PS2：seq=v，v-1是B向A發送的最後一個字節的序號。
• PS3：ack=u+1表示但願收到從第u+1個字節開始的報文段，而且已經成功接收了前u個字節。

A收到該應答，進入FIN-WAIT-2狀態，等待B發送鏈接釋放請求。

第二次揮手完成後，A到B方向的鏈接已經釋放，B不會再接收數據，A也不會再發送數據。但B到A方向的鏈接仍然存在，B能夠繼續向A發送數據。

第三次揮手 當B向A發完全部數據後，向A發送鏈接釋放請求，請求頭：FIN=1，ACK=1，seq=w，ack=u+1。B便進入LAST-ACK狀態。

第四次揮手 A收到釋放請求後，向B發送確認應答，此時A進入TIME-WAIT狀態。該狀態會持續2MSL時間，若該時間段內沒有B的重發請求的話，就進入CLOSED狀態，撤銷TCB。當B收到確認應答後，也便進入CLOSED狀態，撤銷TCB。

爲何A要先進入TIME-WAIT狀態，等待2MSL時間後才進入CLOSED狀態？ 爲了保證B能收到A的確認應答。 若A發完確認應答後直接進入CLOSED狀態，那麼若是該應答丟失，B等待超時後就會從新發送鏈接釋放請求，但此時A已經關閉了，不會做出任何響應，所以B永遠沒法正常關閉。

TCP可靠傳輸的實現

TCP的可靠性表如今：它嚮應用層提供的數據是 無差錯的、有序的、無丟失的，簡單的說就是：TCP最終遞交給應用層的數據和發送者發送的數據是如出一轍的。 TCP採用了流量控制、擁塞控制、連續ARQ等技術來保證它的可靠性。

PS：網絡層傳輸的數據單元爲『數據報』，傳輸層的數據單元爲『報文段』，但爲了方便起見，能夠統稱爲『分組』。

中止等待協議（ARQ協議）

TCP保證其可靠性採用的是更爲複雜的滑動窗口協議，但中止等待協議是它的簡化版，爲了方便理解，這裏先介紹中止等待協議。

AQR協議

ARQ(Automatic Repeat reQuest)自動重傳請求。 顧名思義，當請求失敗時它會自動重傳，直到請求被正確接收爲止。這種機制保證了每一個分組都能被正確接收。中止等待協議是一種ARQ協議。

中止等待協議的原理

• 無差錯的狀況 A向B每發送一個分組，都要中止發送，等待B的確認應答；A只有收到了B的確認應答後才能發送下一個分組。

• 分組丟失和出現差錯的狀況 發送者擁有超時計時器。每發送一個分組便會啓動超時計時器，等待B的應答。若超時仍未收到應答，則A會重發剛纔的分組。 分組出現差錯：若B收到分組，但經過檢查和字段發現分組在運輸途中出現差錯，它會直接丟棄該分組，而且不會有任何其餘動做。A超時後便會從新發送該分組，直到B正確接收爲止。 分組丟失：若分組在途中丟失，B並無收到分組，所以也不會有任何響應。當A超時後也會重傳分組，直到正確接收該分組的應答爲止。 綜上所述：當分組丟失 或 出現差錯 的狀況下，A都會超時重傳分組。

• 應答丟失 和 應答遲到 的狀況 TCP會給每一個字節都打上序號，用於判斷該分組是否已經接收。 應答丟失：若B正確收到分組，並已經返回應答，但應答在返回途中丟失了。此時A也收不到應答，從而超時重傳。緊接着B又收到了該分組。接收者根據序號來判斷當前收到的分組是否已經接收，若已接收則直接丟棄，並補上一個確認應答。 應答遲到：若因爲網絡擁塞，A遲遲收不到B發送的應答，所以會超時重傳。B收到該分組後，發現已經接收，便丟棄該分組，並向A補上確認應答。A收到應答後便繼續發送下一個分組。但通過了很長時間後，那個失效的應答最終抵達了A，此時A可根據序號判斷該分組已經接收，此時只需簡單丟棄便可。

中止等待協議的注意點

• 每發送完一個分組，該分組必須被保留，直到收到確認應答爲止。
• 必須給每一個分組進行編號。以便按序接收，並判斷該分組是否已被接收。
• 必須設置超時計時器。每發送一個分組就要啓動計時器，超時就要重發分組。
• 計時器的超時時間要大於應答的平均返回時間，不然會出現不少沒必要要的重傳，下降傳輸效率。但超時時間也不能太長。

滑動窗口協議（連續ARQ協議）

連續ARQ協議 在ARQ協議發送者每次只能發送一個分組，在應答到來前必須等待。而連續ARQ協議的發送者擁有一個發送窗口，發送者能夠在沒有獲得應答的狀況下連續發送窗口中的分組。這樣下降了等待時間，提升了傳輸效率。

累計確認 在連續ARQ協議中，接收者也有個接收窗口，接收者並不須要每收到一個分組就返回一個應答，能夠連續收到分組以後統一返回一個應答。這樣能節省流量。 TCP頭部的ack字段就是用來累計確認，它表示已經確認的字節序號+1，也表示指望發送者發送的下一個分組的起始字節號。

發送窗口

發送窗口的大小由接收窗口的剩餘大小決定。接收者會把當前接收窗口的剩餘大小寫入應答TCP報文段的頭部，發送者收到應答後根據該值和當前網絡擁塞狀況設置發送窗口的大小。發送窗口的大小是不斷變化的。 發送窗口由三個指針構成：

• p1 p1指向發送窗口的後沿，它後面的字節表示已經發送且已收到應答。
• p2 p2指向還沒有發送的第一個字節。 p1-p2間的字節表示已經發送，但還沒收到確認應答。這部分的字節仍需保留，由於可能還要超時重發。 p2-p3間的字節表示能夠發送，但尚未發送的字節。
• p3 p3指向發送窗口的前沿，它前面的字節還沒有發送，且不容許發送。

發送者每收到一個應答，後沿就能夠向前移動指定的字節。此時若窗口大小仍然沒變，前沿也能夠向前移動指定字節。 當p2和前沿重合時，發送者必須等待確認應答。

接收窗口

接收者收到的字節會存入接收窗口，接收者會對已經正確接收的有序字節進行累計確認，發送完確認應答後，接收窗口就能夠向前移動指定字節。 若是某些字節並未按序收到，接收者只會確認最後一個有序的字節，從而亂序的字節就會被從新發送。

連續ARQ的注意點

1. 同一時刻發送窗口的大小並不必定和接收窗口同樣大。 雖然發送窗口的大小是根據接收窗口的大小來設定的，但應答在網絡中傳輸是有時間的，有可能t1時間接收窗口大小爲m，但當確認應答抵達發送者時，接收窗口的大小已經發生了變化。 此外發送窗口的大小還隨網絡擁塞狀況影響。當網絡出現擁塞時，發送窗口將被調小。

2. TCP標準並未規定未按序到達的字節的處理方式。但TCP通常都會緩存這些字節，等缺乏的字節到達後再交給應用層處理。這比直接丟棄亂序的字節要節約帶寬。

3. TCP標準規定接收方必需要有累計確認功能。接收方能夠對多個TCP報文段同時確認，但不能拖太長時間，通常是0.5S之內。 此外，TCP容許接收者在有數據要發送的時候捎帶上確認應答。但這種狀況通常較少，由於通常不多有兩個方向都要發送數據的狀況。

流量控制

什麼是流量控制？ 若是發送者發送過快，接收者來不及接收，那麼就會有分組丟失。爲了不分組丟失，控制發送者的發送速度，使得接收者來得及接收，這就是流量控制。

流量控制的目的？ 流量控制根本目的是防止分組丟失，它是構成TCP可靠性的一方面。

如何實現流量控制？ 由滑動窗口協議（連續ARQ協議）實現。 滑動窗口協議既保證了分組無差錯、有序接收，也實現了流量控制。

流量控制引起的死鎖 當發送者收到了一個窗口爲0的應答，發送者便中止發送，等待接收者的下一個應答。可是若是這個窗口不爲0的應答在傳輸過程丟失，發送者一直等待下去，而接收者覺得發送者已經收到該應答，等待接收新數據，這樣雙方就相互等待，從而產生死鎖。

持續計時器 爲了不流量控制引起的死鎖，TCP使用了持續計時器。每當發送者收到一個零窗口的應答後就啓動該計時器。時間一到便主動發送報文詢問接收者的窗口大小。若接收者仍然返回零窗口，則重置該計時器繼續等待；若窗口不爲0，則表示應答報文丟失了，此時重置發送窗口後開始發送，這樣就避免了死鎖的產生。

擁塞控制

擁塞控制 和 流量控制 的區別？

1. 擁塞控制：擁塞控制是做用於網絡的，它是防止過多的數據注入到網絡中，避免出現網絡負載過大的狀況；
2. 流量控制：流量控制是做用於接收者的，它是控制發送者的發送速度從而使接收者來得及接收。 PS：擁塞控制是針對於網絡而言的，它是防止往網絡中寫入太多分組，從而致使網絡擁塞的狀況；而流量控制是針對接收者的，它是經過控制發送者的發送速度保證接收者可以來得及接收。

擁塞控制的目的？

1. 緩解網絡壓力
2. 保證分組按時到達

慢開始算法 和 擁塞避免算法

• 發送方維護一個發送窗口，發送窗口的大小取決於網絡的擁塞狀況和接收窗口的大小，發送窗口是動態變化的。
• 發送方還維護一個慢開始門限
  1. 發送窗口 < 慢開始門限：使用慢開始算法
  2. 發送窗口 > 慢開始門限：使用擁塞避免算法
  3. 發送窗口 = 慢開始門限：使用慢開始算法或擁塞避免算法
• 算法的具體過程：
  1. 通訊開始時，發送方的發送窗口設爲1，併發送第一個分組M1；
  2. 接收方收到M1後，返回確認應答，此時發送方發送窗口擴大兩倍，併發送M二、M3；（即，發送方每次收到確認應答後，都將發送窗口設爲當前值的兩倍）
  3. 若發送窗口>慢開始門限，則使用擁塞避免算法，每次收到確認應答後都將發送窗口+1；
  4. 若發送方出現了超時重傳，則代表網絡出現擁塞，此時： a）慢開始門限設爲當前發送窗口的一半； b）發送窗口設爲1； c）啓用擁塞避免算法； PS：發送超時重傳時，發送窗口有可能已經超過了慢開始門限，也有可能還沒超過；此時無論何種狀況，都一概啓用擁塞避免算法，並執行上述三步操做！
• 慢開始算法的做用：慢開始算法將發送窗口從小擴大，並且按指數級擴大，從而避免一開始就往網絡中注入過多的分組從而致使擁塞；它將窗口慢慢擴大的過程其實也在探測網絡擁塞狀況的過程，當發現出現擁塞時，及時下降發送速度，從而減緩網絡擁塞。
• 擁塞避免算法的做用：擁塞避免算法使發送窗口以線性方式增加，而非指數級增加，從而使網絡更加不容易發生擁塞。
• AIMD算法（加法增大乘法減少算法） 慢開始算法 和 擁塞避免算法 還有個名稱叫作『加法增大乘法減少算法』。
  • 加法增長：指的是擁塞避免算法，使得發送窗口以線性的方式增加；
  • 乘法減少：指的是無論當前正使用慢開始算法仍是擁塞避免算法，只要發生擁塞時，慢開始門限將會變成當前窗口的一半。

快重傳算法 和 快恢復算法

• 上述慢開始算法和擁塞避免算法能保證網絡出現擁塞時進行相應的處理，而快重傳和快恢復是一種擁塞預防的方式，此時網絡可能還沒有出現擁塞，但已經有擁塞的徵兆，所以得做出一些預防措施。
• 快重傳原理：由於TCP具備累計確認的能力，所以接收者收到一個分組的時候不會當即發出應答，可能須要等待收到多個分組以後再同一發出累計確認。但快重傳算法就要求，接收者若是接收到一個亂序的分組的話，就必須當即發出前一個正確分組的確認應答，這樣能讓發送者儘早地知道有一個分組可能丟失。
• 快恢復原理：當發送者收到同一個分組的三個確認應答後，就基本能夠判斷這個分組已經丟失了；這時候無需等待超時，直接執行『乘法減少加法增大』：
  1. 將慢開始門限減半；
  2. 將發送窗口減半（不設爲1）；
  3. 使用擁塞避免算法；