OSI七層模型 和 TCP/IP四層模型的對比

• OSI七層模型： 理論上的網(wǎng)絡(luò)通信模型 記憶： (物、鏈、網(wǎng)、輸、會、示、用)

• TCP/IP四層模型： 實際上的網(wǎng)絡(luò)通信標準

(1) 七層網(wǎng)絡(luò)體系結(jié)構(gòu)各層的主要功能：

應用層：

最上層的，也是我們能直接接觸到的就是應用層（Application Layer），我們電腦或手機使用的應用軟件都是在應用層實現(xiàn)。那么，當兩個不同設(shè)備的應用需要通信的時候，應用就把應用數(shù)據(jù)傳給下一層，也就是傳輸層。

所以，應用層只需要專注于為用戶提供應用功能，為應用程序提供交互服務。在互聯(lián)網(wǎng)中的應用層協(xié)議很多，比如 HTTP、FTP、Telnet、DNS、SMTP等。

應用層是不用去關(guān)心數(shù)據(jù)是如何傳輸?shù)?，就類似于，我們寄快遞的時候，只需要把包裹交給快遞員，由他負責運輸快遞，我們不需要關(guān)心快遞是如何被運輸?shù)摹?/p>

而且應用層是工作在操作系統(tǒng)中的用戶態(tài)，傳輸層及以下則工作在內(nèi)核態(tài)。

表示層：

主要負責數(shù)據(jù)格式的轉(zhuǎn)換，如加密解密、轉(zhuǎn)換翻譯、壓縮解壓縮等。

會話層：

負責在網(wǎng)絡(luò)中的兩節(jié)點之間建立、維持和終止通信，如服務器驗證用戶登錄便是由會話層 完成的。

運輸層：

應用層的數(shù)據(jù)包會傳給傳輸層，傳輸層（Transport Layer）是為應用層提供網(wǎng)絡(luò)支持的。

負責兩個進程的通信，即端到端通信。向主機進程提供通用的數(shù)據(jù)傳輸服務。該層主要有以下兩種傳輸協(xié)議協(xié)議：TCP\ UDP

• TCP 的全稱叫傳輸控制協(xié)議（Transmission Control Protocol），大部分應用使用的正是 TCP 傳輸層協(xié)議，比如 HTTP 應用層協(xié)議。TCP 相比 UDP 多了很多特性，比如流量控制、超時重傳、擁塞控制等，這些都是為了保證數(shù)據(jù)包能可靠地傳輸給對方。
• UDP 相對來說就很簡單，簡單到只負責發(fā)送數(shù)據(jù)包，不保證數(shù)據(jù)包是否能抵達對方，但它實時性相對更好，傳輸效率也高。當然，UDP 也可以實現(xiàn)可靠傳輸，把 TCP 的特性在應用層上實現(xiàn)就可以，不過要實現(xiàn)一個商用的可靠 UDP 傳輸協(xié)議，也不是一件簡單的事情。

應用需要傳輸?shù)臄?shù)據(jù)可能會非常大，如果直接傳輸就不好控制，因此當傳輸層的數(shù)據(jù)包大小超過 MSS（TCP 最大報文段長度） ，就要將數(shù)據(jù)包分塊，這樣即使中途有一個分塊丟失或損壞了，只需要重新發(fā)送這一個分塊，而不用重新發(fā)送整個數(shù)據(jù)包。在 TCP 協(xié)議中，我們把每個分塊稱為一個?TCP 段（TCP Segment）。

當設(shè)備作為接收方時，傳輸層則要負責把數(shù)據(jù)包傳給應用，但是一臺設(shè)備上可能會有很多應用在接收或者傳輸數(shù)據(jù)，因此需要用一個編號將應用區(qū)分開來，這個編號就是端口。

比如 80 端口通常是 Web 服務器用的，22 端口通常是遠程登錄服務器用的。而對于瀏覽器（客戶端）中的每個標簽欄都是一個獨立的進程，操作系統(tǒng)會為這些進程分配臨時的端口號。

由于傳輸層的報文中會攜帶端口號，因此接收方可以識別出該報文是發(fā)送給哪個應用。

網(wǎng)絡(luò)層：

傳輸層可能大家剛接觸的時候，會認為它負責將數(shù)據(jù)從一個設(shè)備傳輸?shù)搅硪粋€設(shè)備，事實上它并不負責。

實際場景中的網(wǎng)絡(luò)環(huán)節(jié)是錯綜復雜的，中間有各種各樣的線路和分叉路口，如果一個設(shè)備的數(shù)據(jù)要傳輸給另一個設(shè)備，就需要在各種各樣的路徑和節(jié)點進行選擇，而傳輸層的設(shè)計理念是簡單、高效、專注，如果傳輸層還負責這一塊功能就有點違背設(shè)計原則了。

也就是說，我們不希望傳輸層協(xié)議處理太多的事情，只需要服務好應用即可，讓其作為應用間數(shù)據(jù)傳輸?shù)拿浇椋瑤椭鷮崿F(xiàn)應用到應用的通信，而實際的傳輸功能就交給下一層，也就是網(wǎng)絡(luò)層（Internet Layer）。

選擇合適的路由和交換結(jié)點，確保數(shù)據(jù)及時傳送。主要包括IP協(xié)議：

網(wǎng)絡(luò)層最常使用的是 IP 協(xié)議（Internet Protocol），IP 協(xié)議會將傳輸層的報文作為數(shù)據(jù)部分，再加上 IP 包頭組裝成 IP 報文，如果 IP 報文大小超過 MTU（以太網(wǎng)中一般為 1500 字節(jié)）就會再次進行分片，得到一個即將發(fā)送到網(wǎng)絡(luò)的 IP 報文。

網(wǎng)絡(luò)層負責將數(shù)據(jù)從一個設(shè)備傳輸?shù)搅硪粋€設(shè)備，世界上那么多設(shè)備，又該如何找到對方呢？因此，網(wǎng)絡(luò)層需要有區(qū)分設(shè)備的編號。

我們一般用 IP 地址給設(shè)備進行編號，對于 IPv4 協(xié)議， IP 地址共 32 位，分成了四段（比如，192.168.100.1），每段是 8 位。只有一個單純的 IP 地址雖然做到了區(qū)分設(shè)備，但是尋址起來就特別麻煩，全世界那么多臺設(shè)備，難道一個一個去匹配？這顯然不科學。

因此，需要將 IP 地址分成兩種意義：

• 一個是網(wǎng)絡(luò)號，負責標識該 IP 地址是屬于哪個「子網(wǎng)」的；
• 一個是主機號，負責標識同一「子網(wǎng)」下的不同主機；

怎么分的呢？這需要配合子網(wǎng)掩碼才能算出 IP 地址 的網(wǎng)絡(luò)號和主機號。

舉個例子，比如 10.100.122.0/24，后面的/24表示就是?255.255.255.0?子網(wǎng)掩碼，255.255.255.0 二進制是「11111111-11111111-11111111-00000000」，大家數(shù)數(shù)一共多少個1？不用數(shù)了，是 24 個1，為了簡化子網(wǎng)掩碼的表示，用/24代替255.255.255.0。知道了子網(wǎng)掩碼，該怎么計算出網(wǎng)絡(luò)地址和主機地址呢？

• 將 10.100.122.2 和 255.255.255.0 進行按位與運算，就可以得到網(wǎng)絡(luò)號，
• 將 255.255.255.0 取反后與IP地址進行進行按位與運算，就可以得到主機號。

大家可以去搜索下子網(wǎng)掩碼計算器，自己改變下「掩碼位」的數(shù)值，就能體會到子網(wǎng)掩碼的作用了。

那么在尋址的過程中，先匹配到相同的網(wǎng)絡(luò)號（表示要找到同一個子網(wǎng)），才會去找對應的主機。

除了尋址能力， IP 協(xié)議還有另一個重要的能力就是路由。實際場景中，兩臺設(shè)備并不是用一條網(wǎng)線連接起來的，而是通過很多網(wǎng)關(guān)、路由器、交換機等眾多網(wǎng)絡(luò)設(shè)備連接起來的，那么就會形成很多條網(wǎng)絡(luò)的路徑，因此當數(shù)據(jù)包到達一個網(wǎng)絡(luò)節(jié)點，就需要通過路由算法決定下一步走哪條路徑。

路由器尋址工作中，就是要找到目標地址的子網(wǎng)，找到后進而把數(shù)據(jù)包轉(zhuǎn)發(fā)給對應的網(wǎng)絡(luò)內(nèi)。

所以，IP 協(xié)議的尋址作用是告訴我們?nèi)ネ乱粋€目的地該朝哪個方向走，路由則是根據(jù)「下一個目的地」選擇路徑。尋址更像在導航，路由更像在操作方向盤。

數(shù)據(jù)鏈路層：

數(shù)據(jù)鏈路層通常簡稱為鏈路層。將網(wǎng)絡(luò)層傳下來的IP數(shù)據(jù)包組裝成幀，并再相鄰節(jié)點 的鏈路上傳送幀。

物理層 ：

實現(xiàn)相鄰節(jié)點間比特流的透明傳輸，盡可能屏蔽傳輸介質(zhì)和通信手段的差異。

(2)TCP/IP四層模型

?

?網(wǎng)絡(luò)接口層的傳輸單位是幀（frame），IP 層的傳輸單位是包（packet），TCP 層的傳輸單位是段（segment），HTTP 的傳輸單位則是消息或報文（message）。但這些名詞并沒有什么本質(zhì)的區(qū)分，可以統(tǒng)稱為數(shù)據(jù)包。文章來源地址http://www.zghlxwxcb.cn/news/detail-606859.html

到了這里，關(guān)于計算機網(wǎng)絡(luò)基礎(chǔ)-OSI七層模型 和 TCP/IP四層模型的對比的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！