接上篇：7.7 網絡（一）_龍赤子的博客-博客

創新互聯主營三水網站建設的網絡公司,主營網站建設方案,手機APP定制開發,三水h5小程序定制開發搭建,三水網站營銷推廣歡迎三水等地區企業咨詢

目錄

三 操作系統涉及的網絡內容

1 網絡棧

2 協議

3 應用

---

三 操作系統涉及的網絡內容 ? 1 網絡棧

這里我們重點討論操作系統里面的網絡。這部分在整個網絡架構中，屬于端的技術。對于端來講，要么是數據的生產者，要么是數據的消費者，所以主要任務就是數據的收發處理。其實這種收發也離不開分析處理，本質上，仍然是管道上的一截。如何來理解這一點呢？想想看，數據本身在線路上是不是不被處理？根據二進制的0和1調制而成的波形，是根據物理規律，在線路上以接近光的速度一路狂奔，原樣到達對端。因此，中間的路由器，也是屬于一個端點，雖然我們更常用節點來稱呼。只有端點，才能收發數據，處理數據，只不過，在這些所謂的“節點”端點上，更多的是處理如何轉發數據。這種差異，并不影響大家對網絡及其協議的理解?；谇懊娴木W絡拓撲圖，我們可以參考下圖來理解這一點：

上面這幅圖片來自下面這本經典的網絡教材，國內是有引進影印版的，現在據說到了第七版。對計算機網絡感興趣的讀者，可以買來看看。

過濾掉本節第一幅圖中的路由器等中間節點，只看紅色箭頭連接的兩個端點。我們可以用下圖來更清晰的展示這個過程：

這個圖的最底層部分，我們在前面的網絡傳輸部分，已經看到過了。物理層就是網卡硬件負責的事情了，而網絡接口層和物理層之間，就是驅動跟網卡的銜接之處。

其實，從上圖可以明顯的看出，整個傳輸系統有兩個管道，一個是最底層的物理管道，一個是在其之上，由對等節點構成的邏輯管道（右邊部分為了展示解封裝，去掉了各個層的頭部，特此說明）。一個物理管道加n個邏輯管道，構成了操作系統的網絡系統。而邏輯管道，又是大部分計算機網絡教材所重點講述的部分。

在物理管道之上，其實是有兩層關系的。一層是上面所述的，通過水平關系展示的邏輯管道；一層則是通過上下關系展示的封裝棧道。如果要用四個字來描述計算機的網絡，就可以用上下左右這四個字來概括了。計算機網絡所要解決的，也就是這兩個關系問題：上下問題和左右問題。上下問題解決數據如何建，左右問題解決數據如何傳。

關于數據如何建，也就是數據如何封裝的問題，前面已有論述到，主要是建立一套約定的規則，大家遵守規則，這樣接收方才能解封裝。這套規則，就叫協議。但是，協議不僅僅要封裝數據，就如在網絡傳輸部分所說的，通道存在丟失數據的可能性，因此，這里的協議，還需要處理數據的可靠傳輸問題，也就是數據如何傳的問題?？梢姡灰愣藚f議，就搞定了網絡。

但是，網絡要處理的問題很多很多，如果只用一兩個協議來囊括網絡的所有內容，那么協議就會顯得過于臃腫和復雜。所以，為了簡化問題的處理，進一步的，人們把這些問題分開處理，劃分成許多層，每層只關注問題的一個方面，處理一個抽象層面的內容。比如，如下圖所示，ISO將網絡劃分為七層。其中，應用層關注數據如何應對業務的問題；傳輸層關注數據可靠與否及如何處理丟失、重復、亂序等問題；而網絡層則只是關注數據如何路由的問題；最后，鏈路層關注與底層物理通道的銜接。這樣，應用層將數據交給傳輸層傳輸，傳輸層又將數據交給網絡層路由，網絡層又將數據交給鏈路層發送。這樣，一層銜接一層，最終完成數據傳輸任務。

分層是個好主意，但是分太多層，則問題處理又顯得過于啰嗦，容易出現邊界不清、職責不明確的問題，反而將問題復雜化。因此，計算機網絡中，實際常用的是上圖中間的四層結構。

層分好了，新的問題又來了。雖然通過分層，問題得到了簡化，但是網絡傳輸的需求是多種多樣的。為了完成某個層的任務，實際中發現，通過一兩個協議搞定一個層，也似乎是過于絕對了。尤其是對應用層，業務種類千變萬化，視頻的、音頻的、文字的，各有各的特點，因此，要高效利用網絡，還得繼續切割。這樣，每個層又可以劃分為多個協議， 每一個協議只處理一個相對獨立的問題，如此一來，就形成了一個協議棧簇，如下圖所示：

整個協議棧就像搭積木，一層一層，一塊一塊構建起來的，如下圖所示：

上面圖中所示的協議類型，只是作為例子說明問題。實際中協議的數量和種類遠遠不止這些。另外，棧也只是為了形象的說明協議簇的構成。又因為協議棧中，TCP和IP這兩個協議最為流行，也最為基礎，因此，這個協議棧就常常叫做TCP/IP協議棧。這就是我們常說的 TCP/IP協議棧叫法的來由。

2 協議

通過前面的內容，我們了解到，網絡棧主要由協議構成，這里我們來看看協議是做什么用的，有哪些共性的東西。

協議在計算機網絡中的重要性不言而喻。但是，協議到底是指什么呢？從名稱上，我們可以直觀的感受到，協議應該是一套行為準則及其約束規則。一件事情，做什么、怎么做、有哪些約束（時間、“地點”等），這些就是協議要解決的問題。

沒有接觸過具體協議的讀者，根據上面所述的內容，可能還是會有太抽象、太縹緲，無法觸摸的感覺。即使是開始學習計算機網絡的讀者，大部分對協議的理解也是有限?？赡苡X得自己懂了，但是，真正要用起來，還是會無處下手。記得筆者當年學習計算機網絡時，有一個作業是實現一個郵件收發的客戶端。老師只給了協議要求，沒有提其他約束，也就是語言不限，平臺不限，選自己熟悉的來。界面也不限，只看最后功能結果。那時，雖然在課堂上，協議二字已經聽到過無數次了，但是當真正要編碼實現時，不知該如何入手。最關鍵的是，不知道該如何使用給的郵件“協議”。這就是對協議的理解過于抽象的緣故，說白了，就是沒有實際具體的感受一下，協議是什么，怎么用。

摒棄傳統教科書的概念，我們先用一種較為通俗的說法來解釋協議二字。我認為，協議是數據封裝加邏輯處理。就是說，數據該怎么封裝，有哪些字段，協議需要說明，這是基礎。然后，基于封裝所用到的數據字段，來定義一套運行流程。當然，也可以反過來，先定義一套運行流程，比如有限狀態機。然后再根據流程的運行需要，定義所需的字段。一般來講，協議中所定義的流程，在邏輯上需要是完備的。但是大部分并不能通過數學語言來嚴格的證明，就如計算機里的很多算法一樣，正確性難以通過數學模型來證明。因此，協議可能存在漏洞。

對協議的完整理解，實際上是需要通過語法、語義、語用三個層面來把握的。

首先，語法層面。語法層面主要涵蓋了協議的字段構成。這跟我們平常交流的語言是類似的?！拔页燥垺笔且粋€合規的主謂賓結構，大家都按此來。如果有人說“我飯吃”，聽者大概是可以理解的，但是在計算機世界里，嚴格的數學要求，是不允許出現這種病句的。這類“病句”在接收端是無法正確解析的。所以，要想互聯互通，就要遵守協議的格式要求。

其次，語義層面。語義層面主要是展示一條協議要表達的具體含義。協議中應該包含哪些字段，這就是語義要求的。我們日常溝通中，一句話可能長，也可能短，這是由溝通要傳達的信息所決定的，協議也類似。以常見的網絡媒體流播放協議RTSP為例，就包括了流描述、建立、播放、暫停、終止等多條具體協議。每一條的字段都是為完成這條協議的任務而設定的。

最后，語用層面。語用層面主要是整體的反映協議的功能作用，涵蓋了協議的邏輯流程。就像我們的文章是由很多句子構成的，協議要干成一件事，很多時候，也是通過多條具體的協議組合來完成的。還是以前面的RTSP為例，在語用層面，體現的就是播放媒體這件事的過程。要做這件事，需要先發現支持哪些媒體格式，然后建立媒體會話，之后播放。播放過程中可能出現暫停、恢復反復交替的過程。最后，終止會話，釋放資源。這個嚴密設計的流程，體現的就是語用層面的內容。

通過上面的內容，我們再來理解協議的概念，可能就更清晰具體一些了?；氐角懊驵]件作業的例子，當時無處下手，就是因為沒有一個具體的東西可以輔助來理解協議的概念。后來，我發現，通過抓包學習網絡，尤其是協議，倒是一個好方法。讀者如果感興趣，可以試試。如果筆者當時知道這個方法，那么，完成那個郵件客戶端的作業，也就不會那么痛苦了。這里，以RTSP協議為例，一個抓包的結果如下：

雖然可以通過上面三個層面來理解協議，但是，有些協議實現的并不那么簡明，相反，因為要處理的問題本身就比較復雜，所以協議的設計和實現也相對復雜許多。TCP就是這樣一個典型例子。除此，協議畢竟是要計算機處理的，雖然作用類似我們溝通交流的語言，但是，要照顧到機器的需求，因此很多信息是隱含在字段中的，這就是為啥協議要通過學習才能理解的原因。舉個例子，拿TCP的超時重傳來講，協議中可能只包含確認序號，而不會直接提供是否超時，是否需要重傳的信息，因此，協議的實現者要通過確認序號字段和上下文，自己判斷是否超時了，是否需要重傳。

在前面提到，網絡可能存在的丟包，讓可靠傳輸的設計陡然變復雜了許多。這種復雜性，主要在于處理很多細節的問題。就本質而言，TCP實現可靠傳輸無外乎兩大法寶，一個是確認，一個是重傳。首先，通過確認，判斷數據是否可靠到達了對端。如果沒有，那么就通過重傳，將數據再傳輸一次，然后再次確認，直到數據到達目的端。

了解了協議是什么后，我們再來看看協議的實現。

協議畢竟不是語言，能夠變化無窮。相反，機器能夠處理的情況都是有限的，這是圖靈機理論上的要求。因此，實際中，無論協議多么的復雜，其運作流程，都可以通過一個有限狀態機來描述。如果一個不夠，那就來多個。這不是開玩笑，而是有實際例子的。筆者之前搞過PPP協議的實現，當時，那是我遇到的最復雜的協議處理。我將其稱為多層螺旋結構，如下圖所示：

在這種多層螺旋結構中，每一層都是一個狀態機。下層狀態機成功后，就躍遷到上層狀態機。直到最高層的狀態機，負責最終的數據傳輸。當當前層的狀態機出現錯誤后，就回落到下一層的狀態機，繼續協商處理。PPP就是這樣的一種協議。代碼中，針對每一個狀態機，定義了處理接口，也定義了狀態機之間的遷移關系。簡單表示，如下圖所示：

一般而言，協議的規范文檔中，都會對事件的處理和狀態遷移做出說明，開發者實現時，只需要按照規范文檔做就可以了，不需要自己設計狀態機。這種對協議的使用，相對而言是比較簡單的，真正復雜的是協議設計。針對一個問題，如何設計一套邏輯完備的協議作為解決方案，這才是真正考驗開發者的。因為這個過程中，需要通過整體把握，考慮很多因素，作出很多取舍決策，才能完成目標。標準制定者，就是在干這項工作，其工作輸出結果就是我們學習的各種協議。

提這一點，是因為國內的教學，都是傾向于輸出標準答案，而忽略了研究思考的過程。這種灌輸式的方式，其實是很影響創新的。不過，我前面建議大家去看的那本計算機網絡教材，有一個很大的不同，就是采用啟發的方式，引導讀者不斷思考如何設計一個可靠傳輸協議。通過這樣一步一步的迭代，完成對TCP協議的講解，因此，很值得讀者細細品味。

3 應用

通過上面的介紹，相信大家對協議有了基本的認識。協議設計大家可能會遇到，但對大部分讀者而言，使用操作系統的網絡棧開發網絡應用，可能才是常態。那么，如何使用協議棧來開發網絡應用呢？下面，我們就對這部分內容進行一些介紹。

首先，我們常見的或者用到的網絡應用，大部分都是基于套接字程序來實現的。操作系統網絡棧展現出來的接口有兩個層面，一個是垂直方向的套接字接口，用于實現數據的收發；一個是水平方向的配置接口，用于管理網絡。如下圖所示：

套接字位于傳輸層之上，也就是說，通過套接字，可以實現應用層的協議。當然，這也不絕對，操作系統一般也提供RAW類型的套接字，方面應用實現傳輸層的協議。關于套接字接口的使用，有一套標準流程，大家可以在網絡上搜索相關的例子來學習。應用軟件開發者構造好自己的數據后，就可以交給套接字接口，由套接字接口協助將其發送給對端。接收端通過套接字接口拿到的就是發送端原樣的數據。至于數據該如何解釋，這就是應用層協議負責的事情了。我們可以這樣來理解，收發端的套接字接口共同組成了一個虛擬的傳輸通道。

套接字接口的相關內容本身并不復雜。但是，網絡編程卻并不簡單。這其中的難點在于性能優化上。如何實現高性能的并發處理，是網絡編程進階的關鍵所在。在這一點上，不僅僅是應用設計者，相關SDK設計者，甚至操作系統設計者都在持續的優化。感興趣的讀者，可以去了解異步IO相關的一些內容，這里就不再展開了。

關于套接字編程，這里最后再補充一點。我們用的手機、電腦等產品，其上跑的網絡應用豐富多彩，而且很多是同時在用的，所以，通過套接字接口構建的虛擬通道，在一臺設備上，可以存在多個，且每個彼此是獨立的，可以認為相互不影響（排除對內存、帶寬等資源的占用影響）。不僅僅是設備級別，即使在一個應用中，這種虛擬通道也可能存在很多個。虛擬通道的關鍵構建元素是網絡五元組，即{源地址、源端口、協議、目的地址、目的端口}，所以，設備節點間的虛擬通道是N:N的映射關系。早年筆者接觸過BT協議下載軟件，對此還是深有感觸的。下面這幅圖，是當時理解多個下載上傳通道時畫的。

好了，關于網絡的介紹就到這里，希望本文對大家理解計算機網絡有所幫助。

你是否還在尋找穩定的海外服務器提供商？創新互聯www.cdcxhl.cn海外機房具備T級流量清洗系統配攻擊溯源，準確流量調度確保服務器高可用性，企業級服務器適合批量采購，新人活動首月15元起，快前往官網查看詳情吧

標題名稱：7.7網絡（二）-創新互聯
地址分享：http://www.js-pz168.com/article4/cohioe.html

成都網站建設公司_創新互聯，為您提供網站排名、網站導航、電子商務、全網營銷推廣、網站設計、關鍵詞優化

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯