計算機網絡中一些比較重要的概念

分層

OSI模型有哪幾層?

  1. 應用層(數據):定義了應用進程間的通訊和交互的規則,經過應用進程間的交互來完成特定網絡應用。
  2. 表示層(數據):用於應用層數據的編碼和轉換功能,確保一個系統的應用層發送的數據能被另外一個系統的應用層識別。
  3. 會話層(數據):負責創建、管理和終止表示層實體之間的通訊會話。
  4. 傳輸層(段):創建端到端的連接,爲上層協議提供端到端的可靠和透明的數據傳輸服務,包括處理差錯控制和流量控制等問題,向上層屏蔽了下層數據通訊的細節。
  5. 網絡層(包):經過IP尋址來創建兩個節點之間的鏈接,爲源端的運輸層送來的分組,選擇合適的路由和交換節點,正確無誤地按照地址傳送給目的端的運輸層。
  6. 數據鏈路層(幀):將比特組合成字節,再將字節組合成幀,使用MAC地址訪問介質,並進行差錯檢測。
  7. 物理層(比特流):實現相鄰計算機節點之間比特流的透明傳送,儘量屏蔽掉具體傳輸介質和物理設備的差別。

每一層使用的是什麼設備?

  1. 網關:應用層、傳輸層
  2. 路由器:網絡層
  3. 交換機:數據鏈路層、網絡層
  4. 網橋:數據鏈路層
  5. 集線器:物理層
  6. 中繼器:物理層

網絡層

地址解析協議 ARP

網絡層實現主機之間的通訊,而鏈路層實現具體每段鏈路之間的通訊。所以在通訊過程當中,IP 數據報的源地址和目的地址始終不變,而 MAC 地址隨着鏈路的改變而改變。web

ARP 實現由 IP 地址獲得 MAC 地址。每一個主機都有一個 ARP 高速緩存,裏面有本局域網上的各主機和路由器的 IP 地址到 MAC 地址的映射表。算法

若是主機 A 知道主機 B 的 IP 地址,可是 ARP 高速緩存中沒有該 IP 地址到 MAC 地址的映射,此時主機 A 經過廣播的方式發送 ARP 請求分組,主機 B 收到該請求後會發送 ARP 響應分組給主機 A 告知其 MAC 地址,隨後主機 A 向其高速緩存中寫入主機 B 的 IP 地址到 MAC 地址的映射。瀏覽器

網際控制報文協議 ICMP

ICMP 是爲了更有效地轉發 IP 數據報和提升交付成功的機會。它封裝在 IP 數據報中,可是不屬於高層協議。緩存

ICMP 報文分爲差錯報告報文和詢問報文。服務器

image-20190803112942000

Ping

Ping 是 ICMP 的一個重要應用,主要用來測試兩臺主機之間的連通性。網絡

Ping 的原理是經過向目的主機發送 ICMP Echo 請求報文,目的主機收到以後會發送 Echo 回答報文。Ping 會根據時間和成功響應的次數估算出數據包往返時間以及丟包率。併發

Traceroute

Traceroute 是 ICMP 的另外一個應用,用來跟蹤一個分組從源點到終點的路徑。tcp

Traceroute 發送的 IP 數據報封裝的是沒法交付的 UDP 用戶數據報,並由目的主機發送終點不可達差錯報告報文。測試

  • 源主機向目的主機發送一連串的 IP 數據報。第一個數據報 P1 的生存時間 TTL 設置爲 1,當 P1 到達路徑上的第一個路由器 R1 時,R1 收下它並把 TTL 減 1,此時 TTL 等於 0,R1 就把 P1 丟棄,並向源主機發送一個 ICMP 時間超過差錯報告報文;
  • 源主機接着發送第二個數據報 P2,並把 TTL 設置爲 2。P2 先到達 R1,R1 收下後把 TTL 減 1 再轉發給 R2,R2 收下後也把 TTL 減 1,因爲此時 TTL 等於 0,R2 就丟棄 P2,並向源主機發送一個 ICMP 時間超過差錯報文。
  • 不斷執行這樣的步驟,直到最後一個數據報剛剛到達目的主機,主機不轉發數據報,也不把 TTL 值減 1。可是由於數據報封裝的是沒法交付的 UDP,所以目的主機要向源主機發送 ICMP 終點不可達差錯報告報文。
  • 以後源主機知道了到達目的主機所通過的路由器 IP 地址以及到達每一個路由器的往返時間。

路由選擇協議

路由選擇協議都是自適應的,能隨着網絡通訊量和拓撲結構的變化而自適應地進行調整。編碼

互聯網能夠劃分爲許多較小的自治系統 AS,一個 AS 可使用一種和別的 AS 不一樣的路由選擇協議。

能夠把路由選擇協議劃分爲兩大類:

  • 自治系統內部的路由選擇:RIP 和 OSPF
  • 自治系統間的路由選擇:BGP

內部網關協議 RIP

RIP 是一種基於距離向量的路由選擇協議。距離是指跳數,直接相連的路由器跳數爲 1。跳數最多爲 15,超過 15 表示不可達。

RIP 按固定的時間間隔僅和相鄰路由器交換本身的路由表,通過若干次交換以後,全部路由器最終會知道到達本自治系統中任何一個網絡的最短距離和下一跳路由器地址。

RIP 協議實現簡單,開銷小。可是 RIP 能使用的最大距離爲 15,限制了網絡的規模。而且當網絡出現故障時,要通過比較長的時間才能將此消息傳送到全部路由器。

內部網關協議 OSPF

開放最短路徑優先 OSPF,是爲了克服 RIP 的缺點而開發出來的。

開放表示 OSPF 不受某一家廠商控制,而是公開發表的;最短路徑優先表示使用了 Dijkstra 提出的最短路徑算法 SPF。

OSPF 具備如下特色:

  • 向本自治系統中的全部路由器發送信息,這種方法是洪泛法。
  • 發送的信息就是與相鄰路由器的鏈路狀態,鏈路狀態包括與哪些路由器相連以及鏈路的度量,度量用費用、距離、時延、帶寬等來表示。
  • 只有當鏈路狀態發生變化時,路由器纔會發送信息。

全部路由器都具備全網的拓撲結構圖,而且是一致的。相比於 RIP,OSPF 的更新過程收斂的很快。

外部網關協議 BGP

AS 之間的路由選擇很困難,主要是因爲:

  • 互聯網規模很大;
  • 各個 AS 內部使用不一樣的路由選擇協議,沒法準肯定義路徑的度量;
  • AS 之間的路由選擇必須考慮有關的策略,好比有些 AS 不肯意讓其它 AS 通過。

BGP 只能尋找一條比較好的路由,而不是最佳路由。

每一個 AS 都必須配置 BGP 發言人,經過在兩個相鄰 BGP 發言人之間創建 TCP 鏈接來交換路由信息。

傳輸層

UDP 和 TCP 的特色

image-20190803120713093

  • UDP是無鏈接的,盡最大可能交付,沒有擁塞控制,面向報文(對於應用程序傳下來的報文不合並也不拆分,只是添加 UDP 首部),支持一對1、一對多、多對一和多對多的交互通訊。

    雖然 UDP 不提供可靠交付,但在某些狀況下 UDP 確是一種最有效的工做方式,好比: QQ 語音、 QQ 視頻 、直播等等

  • TCP是面向鏈接的,提供可靠交付,有流量控制,擁塞控制,提供全雙工通訊,面向字節流(把應用層傳下來的報文當作字節流,把字節流組織成大小不等的數據塊),每一條 TCP 鏈接只能是點對點的(一對一)。

    TCP的可靠體如今TCP在傳遞數據以前,會有三次握手來創建鏈接,並且在數據傳遞時,有確認、窗口、重傳、擁塞控制機制,在數據傳完後,還會斷開鏈接用來節約系統資源。這不只使協議數據單元的首部增大不少,還要佔用許多處理機資源。TCP 通常用於文件傳輸、發送和接收郵件、遠程登陸等場景。

TCP 三次握手

image-20190803113848257

假設 A 爲客戶端,B 爲服務器端。

  • 首先 B 處於 LISTEN(監聽)狀態,等待客戶的鏈接請求。
  • A 向 B 發送鏈接請求報文,SYN=1,ACK=0,選擇一個初始的序號 x。
  • B 收到鏈接請求報文,若是贊成創建鏈接,則向 A 發送鏈接確認報文,SYN=1,ACK=1,確認號爲 x+1,同時也選擇一個初始的序號 y。
  • A 收到 B 的鏈接確認報文後,還要向 B 發出確認,確認號爲 y+1,序號爲 x+1。
  • B 收到 A 的確認後,鏈接創建。

三次握手的緣由

  • 第三次握手是爲了防止失效的鏈接請求到達服務器,讓服務器錯誤打開鏈接。
  • 客戶端發送的鏈接請求若是在網絡中滯留,那麼就會隔很長一段時間才能收到服務器端發回的鏈接確認。客戶端等待一個超時重傳時間以後,就會從新請求鏈接。可是這個滯留的鏈接請求最後仍是會到達服務器,若是不進行三次握手,那麼服務器就會打開兩個鏈接。若是有第三次握手,客戶端會忽略服務器以後發送的對滯留鏈接請求的鏈接確認,不進行第三次握手,所以就不會再次打開鏈接。

TCP 的四次揮手

image-20190803113934388

如下描述不討論序號和確認號,由於序號和確認號的規則比較簡單。而且不討論 ACK,由於 ACK 在鏈接創建以後都爲 1。

  • A 發送鏈接釋放報文,FIN=1。
  • B 收到以後發出確認,此時 TCP 屬於半關閉狀態,B 能向 A 發送數據可是 A 不能向 B 發送數據。
  • 當 B 再也不須要鏈接時,發送鏈接釋放報文,FIN=1。
  • A 收到後發出確認,進入 TIME-WAIT 狀態,等待 2 MSL(最大報文存活時間)後釋放鏈接。
  • B 收到 A 的確認後釋放鏈接。

四次揮手的緣由

客戶端發送了 FIN 鏈接釋放報文以後,服務器收到了這個報文,就進入了 CLOSE-WAIT 狀態。這個狀態是爲了讓服務器端發送還未傳送完畢的數據,傳送完畢以後,服務器會發送 FIN 鏈接釋放報文。

TIME_WAIT

客戶端接收到服務器端的 FIN 報文後進入此狀態,此時並非直接進入 CLOSED 狀態,還須要等待一個時間計時器設置的時間 2MSL。這麼作有兩個理由:

  • 確保最後一個確認報文可以到達。若是 B 沒收到 A 發送來的確認報文,那麼就會從新發送鏈接釋放請求報文,A 等待一段時間就是爲了處理這種狀況的發生。
  • 等待一段時間是爲了讓本鏈接持續時間內所產生的全部報文都從網絡中消失,使得下一個新的鏈接不會出現舊的鏈接請求報文。

TCP 協議如何保證可靠傳輸

  1. 應用數據被分割成 TCP 認爲最適合發送的數據塊。
  2. TCP 給發送的每個包進行編號,接收方對數據包進行排序,把有序數據傳送給應用層。
  3. 校驗和: TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和,目的是檢測數據在傳輸過程當中的任何變化。若是收到段的檢驗和有差錯,TCP 將丟棄這個報文段和不確認收到此報文段。
  4. TCP 的接收端會丟棄重複的數據。
  5. 流量控制: TCP 鏈接的每一方都有固定大小的緩衝空間,TCP的接收端只容許發送端發送接收端緩衝區能接納的數據。當接收方來不及處理髮送方的數據,能提示發送方下降發送的速率,防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 (TCP 利用滑動窗口實現流量控制)
  6. 擁塞控制: 當網絡擁塞時,減小數據的發送。
  7. ARQ協議: 也是爲了實現可靠傳輸的,它的基本原理就是每發完一個分組就中止發送,等待對方確認。在收到確認後再發下一個分組。
  8. 超時重傳: 當 TCP 發出一個段後,它啓動一個定時器,等待目的端確認收到這個報文段。若是不能及時收到一個確認,將重發這個報文段。

ARQ協議

自動重傳請求(Automatic Repeat-reQuest,ARQ)是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。它經過使用確認和超時這兩個機制,在不可靠服務的基礎上實現可靠的信息傳輸。若是發送方在發送後一段時間以內沒有收到確認幀,它一般會從新發送。ARQ包括中止等待ARQ協議和連續ARQ協議。

中止等待ARQ協議

  • 中止等待協議是爲了實現可靠傳輸的,它的基本原理就是每發完一個分組就中止發送,等待對方確認(回覆ACK)。若是過了一段時間(超時時間後),仍是沒有收到 ACK 確認,說明沒有發送成功,須要從新發送,直到收到確認後再發下一個分組;
  • 在中止等待協議中,若接收方收到重複分組,就丟棄該分組,但同時還要發送確認;

優勢: 簡單

缺點: 信道利用率低,等待時間長

無差錯狀況:

發送方發送分組,接收方在規定時間內收到,而且回覆確認.發送方再次發送。

出現差錯狀況(超時重傳):

中止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認,就重傳前面發送過的分組(認爲剛纔發送過的分組丟失了)。所以每發送完一個分組須要設置一個超時計時器,其重傳時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱爲 自動重傳請求 ARQ 。另外在中止等待協議中若收到重複分組,就丟棄該分組,但同時還要發送確認。連續 ARQ 協議 可提升信道利用率。發送維持一個發送窗口,凡位於發送窗口內的分組可連續發送出去,而不須要等待對方確認。接收方通常採用累積確認,對按序到達的最後一個分組發送確認,代表到這個分組位置的全部分組都已經正確收到了。

確認丟失和確認遲到

  • 確認丟失 :確認消息在傳輸過程丟失。當A發送M1消息,B收到後,B向A發送了一個M1確認消息,但卻在傳輸過程當中丟失。而A並不知道,在超時計時事後,A重傳M1消息,B再次收到該消息後採起如下兩點措施:1. 丟棄這個重複的M1消息,不向上層交付。 2. 向A發送確認消息。(不會認爲已經發送過了,就再也不發送。A能重傳,就證實B的確認消息丟失)。
  • 確認遲到 :確認消息在傳輸過程當中遲到。A發送M1消息,B收到併發送確認。在超時時間內沒有收到確認消息,A重傳M1消息,B仍然收到並繼續發送確認消息(B收到了2份M1)。此時A收到了B第二次發送的確認消息。接着發送其餘數據。過了一會,A收到了B第一次發送的對M1的確認消息(A也收到了2份確認消息)。處理以下:1. A收到重複的確認後,直接丟棄。2. B收到重複的M1後,也直接丟棄重複的M1。

連續ARQ協議

連續 ARQ 協議可提升信道利用率。發送方維持一個發送窗口,凡位於發送窗口內的分組能夠連續發送出去,而不須要等待對方確認。接收方通常採用累計確認,對按序到達的最後一個分組發送確認,代表到這個分組爲止的全部分組都已經正確收到了。

優勢: 信道利用率高,容易實現,即便確認丟失,也沒必要重傳。

缺點: 不能向發送方反映出接收方已經正確收到的全部分組的信息。 好比:發送方發送了 5條 消息,中間第三條丟失(3號),這時接收方只能對前兩個發送確認。發送方沒法知道後三個分組的下落,而只好把後三個所有重傳一次。這也叫 Go-Back-N(回退 N),表示須要退回來重傳已經發送過的 N 個消息。

滑動窗口和流量控制

TCP 利用滑動窗口實現流量控制。流量控制是爲了控制發送方發送速率,保證接收方來得及接收。 窗口是緩存的一部分,用來暫時存放字節流。發送方和接收方各有一個窗口,接收方經過 TCP 報文段中的窗口字段告訴發送方本身的窗口大小,發送方根據這個值和其它信息設置本身的窗口大小。

發送窗口內的字節都容許被髮送,接收窗口內的字節都容許被接收。若是發送窗口左部的字節已經發送而且收到了確認,那麼就將發送窗口向右滑動必定距離,直到左部第一個字節不是已發送而且已確認的狀態;接收窗口的滑動相似,接收窗口左部字節已經發送確認並交付主機,就向右滑動接收窗口。接收窗口只會對窗口內最後一個按序到達的字節進行確認,發送方獲得一個字節的確認以後,就知道這個字節以前的全部字節都已經被接收。

擁塞控制

若是網絡出現擁塞,分組將會丟失,此時發送方會繼續重傳,從而致使網絡擁塞程度更高。所以當出現擁塞時,應當控制發送方的速率。這一點和流量控制很像,可是出發點不一樣。流量控制是爲了讓接收方能來得及接收,而擁塞控制是爲了下降整個網絡的擁塞程度。

image-20190803114210615

TCP 主要經過四個算法來進行擁塞控制:慢開始、擁塞避免、快重傳、快恢復。

發送方須要維護一個叫作擁塞窗口(cwnd)的狀態變量,注意擁塞窗口與發送方窗口的區別:擁塞窗口只是一個狀態變量,實際決定發送方能發送多少數據的是發送方窗口。

爲了便於討論,作以下假設:

  • 接收方有足夠大的接收緩存,所以不會發生流量控制;
  • 雖然 TCP 的窗口基於字節,可是這裏設窗口的大小單位爲報文段。

image-20190803114222157

慢開始與擁塞避免

發送的最初執行慢開始,令 cwnd = 1,發送方只能發送 1 個報文段;當收到確認後,將 cwnd 加倍,所以以後發送方可以發送的報文段數量爲:二、四、8 ...

注意到慢開始每一個輪次都將 cwnd 加倍,這樣會讓 cwnd 增加速度很是快,從而使得發送方發送的速度增加速度過快,網絡擁塞的可能性也就更高。設置一個慢開始門限 ssthresh,當 cwnd >= ssthresh 時,進入擁塞避免,每一個輪次只將 cwnd 加 1。

若是出現了超時,則令 ssthresh = cwnd / 2,而後從新執行慢開始。

快重傳與快恢復

在接收方,要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2,此時收到 M4,應當發送對 M2 的確認。

在發送方,若是收到三個重複確認,那麼能夠知道下一個報文段丟失,此時執行快重傳,當即重傳下一個報文段。例如收到三個 M2,則 M3 丟失,當即重傳 M3。

在這種狀況下,只是丟失個別報文段,而不是網絡擁塞。所以執行快恢復,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此時直接進入擁塞避免。

慢開始和快恢復的快慢指的是 cwnd 的設定值,而不是 cwnd 的增加速率。慢開始 cwnd 設定爲 1,而快恢復 cwnd 設定爲 ssthresh。

image-20190803114234109

應用層

Web 頁面請求過程

整體來講分爲如下幾個過程:

  1. DNS解析
  2. TCP鏈接
  3. 發送HTTP請求
  4. 服務器處理請求並返回HTTP報文
  5. 瀏覽器解析渲染頁面
  6. 鏈接結束

image-20190803135321710

相關文章
相關標籤/搜索