1.5 計算機網絡體系結構

本文轉載自查看原文 2021-10-11 21:30 165 計算機網絡

這是重點和難點，抽象概念比較多，學習的時候要多思考。

1.5.1 常見的計算機網絡體系結構

為了使不同體系結構的計算機網絡能夠互連，國際組織1977年成立專門機構研究該問題，不久他們就研究出一個使所有計算機在世界范圍內互連成網的框架，也就是著名的“開放系統互連參考模型”，簡稱OSI。

20世紀90年代初期，雖然標准已經注冊出來了，但是因特網已經搶先在全世界覆蓋了相當大的范圍，因特網從1983年開始使用TCP/IP協議族，並逐步演變成TCP/IP參考模型

在過去，制訂標准的人往往是專家學者。但現在，許多公司都紛紛擠進各種各樣的標准化組織，使得技術標准有着濃厚的商業氣息。

OSI標准失敗的原因可歸納為：

1）OSI的專家們缺乏實戰經驗，完成OSI標准時沒有商用驅動力

2）OSI本身體系結構復雜，實現難度大，效率低

3）OSI研發周期長，因而使得其他那些按照他標准生產的設備無法進入市場

4）OSI層次划分不合理，有些功能在多個體系重復出現

因為IP的意思是網際，所以TCP/IP的網絡層叫網際層。

我們自己的電腦帶有TCP/IP協議族，路由器也帶有TCP/IP協議族，只不過路由器只包含網絡接口層和網際層。

TCP/IP的網絡接口層並沒有強制規定要有什么內容，這樣做的目的是可以互連全世界各種不同的網絡接口。比如有線的以太網接口，無線局域網的WIFI接口。

因此，本質上TCP/IP協議只有上面的三層。

IP協議是TCP/IP中的網際層的核心協議。
TCP和UDP是TCP/IP體系結構運輸層的兩個重要的協議
應用層包含了大量的應用層協議，例如HTTP,SMTP,DNS,RTP等

IP協議可以將不同的網絡接口進行互連，並向其上的TCP協議和UDP協議提供網絡互連服務

而TCP協議在享受IP協議提供的網絡互聯服務的基礎上，可向應用層的相應協議提供可靠傳輸的服務。UDP協議在享受IP協議提供的網絡互聯服務的基礎上，可向應用層的相應協議提供不可靠傳輸的服務。

IP協議作為TCP/IP中的核心協議，一方面負責互連不同的網絡接口。另一方面為各種網絡應用提供服務

TCP/IP體系中有大量的協議，IP協議和TCP協議是其中兩個非常重要的協議，因此，用TCP/IP這兩個協議來表示整個協議大家族。在嵌入式開發領域，TCP/IP協議族常稱為TCP/IP協議棧。這是因為TCP/IP協議體系的分層結構，與數據結構中的棧，在圖形畫法上是類似的。

因為TCP/IP協議的網絡接口層是沒有實現的，OSI的又太多了，所以我們學習的時候，采用一種折中的思想。我們學習5層-原理體系結構。

1.5.2 分層的必要性

計算機網絡是個非常復雜的系統。早在最初的APPANET設計時就提出了分層的設計概念

分層可以將龐大復雜的問題，轉換成若干較小的局部問題，而這些較小的局部問題就比較易於研究和處理

下面我們按照簡單到復雜的順序，來看看實現計算機網絡要面臨哪些主要的問題，以及如何將這些問題划分到對應的層次，層層處理。

先來看最簡單的兩台：

注意：

傳輸媒體一般不認為是物理層的。
信號傳輸的時候並不是我們畫的這種方波01信號，這個只是方便大家學習。

實用的計算機網絡，一般都由多台主機構成。

假設我們已經解決了物理層的問題，也就是說主機間可以發送信號來傳輸比特0或1了。

我們來看看在這樣一個總線型的網絡上還需要解決什么問題。

A發送數據給C，但是表示數據的信號會通過總線傳播到總線的每一個主機。

那么問題就來了，主機C如何知道是發給自己的，自己要接受？而主機B.D.E又如何知道該數據並不是發送給自己的，自己應該拒絕呢？

這就很自然的引出了如何標識網絡中個主機的問題。也就是主機編址問題。大家可能聽說過網卡上的MAC地址，其實他就是主機在網絡中的地址。

主機在發送數據時，應該給數據附加上目的地址。當其他主機收到后，看一下目的地址和自己的地址是否匹配，來決定是否接受數據。這就又引出了一個問題：目的主機如何從所表示的一連串比特流中區分出地址和數據？也就是需要解決分組的封裝格式的問題。

另外對於總線型的網絡，還會出現下面這種典型的問題：某個時刻總線是空閑的，也就是沒有主機使用總線來發送數據，一會，主機B和D同時向總線發送數據。這必然會造成信號碰撞。

因此，如何協調各主機爭用主線，也是必須要解決的問題。

需要說明的是，這種總線型的早以淘汰，現在使用的是以太網交換機將多台主機互連形成的交換式以太網。

那么以太網交換機又是如何實現的呢？

我們將這些問題全部划分到數據鏈路層。

到目前為止大家發現，只要解決了物理層和數據鏈路層各自所面臨的問題，我們就可以實現分組在一個網絡上實現傳輸了。但是我們每天都會使用的因特網是由非常多的網絡和路由器互連起來的，僅解決物理層和數據鏈路層的問題，還是不能正常工作。

我們來看這個例子：

這是一個由3個路由器，4個網絡組合起來的小型互聯網。我們可以把它看做因特網中很小的一部分，在之前的例子中，僅有一個網咯，我們不需要對網絡進行標識，而在本例中，有多個網絡。很顯然，我們面臨着如何標識各網絡以及網絡中各主機的問題？

換句話說，也就是網絡和主機共同編址的問題。相信同學們一定聽過IP地址，例如這是網絡N1中各設備的網絡地址

該類IP地址的前三個10進制數用來標識網絡，第四個10進制數用來標識主機。

在本例中，網絡N1的網絡號為192，168 ，1。該網絡上的筆記本，主機，路由器的IP地址的前三個數應該都是192,168,1。第四個十進制數分別為1，2，254。用來標識他們自己。

我們再來看一個問題，源主機和目的主機之間的路徑不只一條，分組可走不同的路勁到達目的主機。這樣就引出了路由器如何轉發分組的問題？以及如何進行路由選擇的問題？

我們將這些問題全部划分到網絡層

到目前為止，我們解決了物理層，數據鏈路層，網絡層各自的問題。則可以實現分組在網絡間傳輸的問題。但是對於計算機網絡應用而言這仍然不夠。

比如，假設這台主機中運行着兩個與網絡通信相關的應用進程，瀏覽器進程和qq進程

另外一台服務器運行着與網絡通信相關的服務器進程。

某個時刻，主機收到來自服務器的分組，那么這些分組應該交給瀏覽器進程處理呢？還是交給QQ進程處理呢？

這就引出了我們如何標識與網絡通信相關的應用進程問題？進而解決進程之間基於網絡的通信問題。

另外，如果某個分組在傳輸過程中出現了誤碼，或者由於路由器繁忙導致路由器丟失分組，換句話說：若出現傳輸錯誤，應該如何處理？

我們將這些問題全部划分到運輸層。

解決了上面的問題的話我們就可以實現進程之間基於網絡的通信。

在此基礎上，只需制定各種應用層協議，並按照協議標准編寫相應的應用程序。通過應用進程間的交互來完成特定的網絡應用。例如，支持萬維網應用的HTTP協議，支持電子郵件的SMTP協議，支持文件傳送的FTP協議等。我們將這些問題全部划分到應用層。

總結：

1.5.3 分層思想舉例

假設網絡拓撲如下，主機屬於網絡N1，服務器屬於網絡N2，N1和N2通過路由器互連。

我們使用主機中的瀏覽器來訪問web服務器，當輸入網址后，主機會向web服務器發送請求。web服務器收到請求后，會發回相應的響應

主機的瀏覽器收到相應后，將其解析為具體的網頁內容顯示出來。

主機和web服務器之間基於網絡的通信，實際上是主機中的瀏覽器應用進程與web服務器中的web服務器應用進程之間基於網絡的通信。

那么體系結構中的各層在體系結構中起到什么樣的作用呢？

應用層按照HTTP請求協議的規定，構建一個HTTP請求報文，內容如下

應用層將HTTP請求交付給運輸層處理，運輸層給HTTP報文添加一個TCP首部，使之成為TCP報文段。下圖為TCP報文段的首部格式，該首部的作用主要是為了區分應用進程，以及實現可靠傳輸。

運輸層將TCP報文段交付給網絡層處理，網絡層給TCP報文段添加一個IP首部，使之成為IP數據報，IP數據報的首部格式如下，該首部的作用是使IP數據報可以在互聯網上傳輸。也就是被路由器轉發。

網絡層將IP數據報交付給數據鏈路層處理，數據鏈路層給IP數據報添加一個首部和一個尾部使之成為幀

假設網絡N1是以太網，下面為以太網幀首部的格式。

該首部的作用主要是為了能夠讓幀能夠在一段鏈路上，或一個網絡上傳輸，能夠被相應的目的主機接收。

下面為以太網幀尾部的格式

其作用是為了讓目的主機檢查，所接收到的幀是否有誤碼。

數據鏈路層將幀交付給物理層，物理層將幀看做是比特流。

由於網絡N1是以太網，因此物理層還會給比特流前面添加前導碼。

前導碼的內容如下

其作用是讓目的主機做好接收幀的准備

物理層將添加有前導碼的比特流，變換成相應的信號發送到傳輸媒體，

我們來看路由器的處理過程。路由器的物理層將信號變換為比特流，

然后去掉前導碼后，將其交付給數據鏈路層

這實際上交付的是幀，數據鏈路層將幀的首部和尾部去掉后，將其交付給網絡層。這實際上交付的是IP數據報。

網絡層解析IP數據報的首部，從中提取出目的網絡地址，然后查找自身的路由表，確定轉發端口，以便進行轉發。

網絡層將IP數據報交付給數據鏈路層，數據鏈路層給IP數據報添加一個首部和一個尾部使之稱為幀

數據鏈路層將幀交付給物理層，物理層將幀看做是比特流，由於網絡N2是以太網，因此物理層還會給該比特流前面添加前導碼，

物理層將添加有前導碼的比特流，變換成相應的信號發送到傳輸媒體。

信號通過傳輸媒體到達web服務器。我們來看web服務器的處理過程。

物理層將信號變換為比特流，去掉前導碼，交給數據鏈路層。這實際上交付的是幀

數據鏈路層將幀的首部和尾部去掉后，將其交付給網絡層，這實際上交付的是IP數據報

網絡層將IP數據報去掉IP首部之后，將其交付給運輸層，這實際上交付的是TCP報文段

運輸層將TCP報文段的首部去掉之后，將其交付給應用層，這實際上交付的是HTTP請求報文。應用層對HTTP請求報文進行解析，然后給主機發回HTTP響應報文，與之前的過程類似，HTTP響應報文需要在web服務器層層封裝，然后通過物理層變換成相應的信號，再通過傳輸媒體傳輸到路由器。路由器轉發該響應報文給主機，主機通過物理層將收到的信號轉換為比特流，之后通過逐層解封，最終取出HTTP響應報文

1.5.4 專用術語

1.5.4.1實體：

任何可發送或接收信息的硬件和軟件進程，下圖中的字母

對等實體：通信雙方相同層次中的實體

1.5.4.2協議：

控制兩個對等實體進行邏輯通信的規則的集合，這種通信並不存在，只是我們假設出來的。目的在於我們可以專注研究一層而不用考慮其他層。

例如當我們在研究運輸層時我們可以看成運輸層的對等實體在進行邏輯通信，而不用考慮其他層。

計算機網絡協議有三個要素：

語法：定義所交換信息的格式語法就是定義這些小格子的長度和先后順序。換句話說：語法定義了所交換信息由哪些字段以及何種順序構成。格式不需要記住，能看懂就行。
語義：定義收發雙方要完成的操作。主機要訪問服務器，會構建一個HTTP的GET請求報文，然后將其發送給web服務器。web服務器收到該報文並進行解析。知道這是一個HTTP的GET請求報文。於是就在自身內部查找所請求的內容。並將找到的內容封裝到一個HTTP響應報文中發回該主機。主機收到HTTP響應報文之后對其進行解析，取出所請求的內容並由瀏覽器解析顯示。這個例子就可以體現出通信雙方收到分組后完成怎樣的操作。這是HTTP協議的語義所規定的。
同步：定義通信雙方的時序關系。比如TCP三次握手過程可以看出兩個主機之間的時序和狀態轉換。

只有雙方建立連接之后才可以進行數據傳輸。這個例子充分體現了同步。