[[400080]]

一、計網分層結構

考慮最簡單的情況：兩臺主機之間的通信。這個時候只需要一條網線把兩者連起來，規定好彼此的硬件接口，如都用USB、電壓10v、頻率2.4GHz等，這一層就是物理層，這些規定就是物理層協議。

我們當然不滿足于只有兩臺電腦連接，因此我們可以使用交換機把多個電腦連接起來，如下圖：

這樣連接起來的網絡，稱為局域網，也可以稱為以太網(以太網是局域網的一種)。在這個網絡中，我們需要標識每個機器，這樣才可以指定要和哪個機器通信。這個標識就是硬件地址MAC。

硬件地址隨機器的生產就被確定，永久性唯一。在局域網中，我們需要和另外的機器通信時，只需要知道他的硬件地址，交換機就會把我們的消息發送到對應的機器。

這里我們可以不管底層的網線接口如何發送，把物理層抽離，在他之上創建一個新的層次，這就是數據鏈路層。

我們依然不滿足于局域網的規模，需要把所有的局域網聯系起來，這個時候就需要用到路由器來連接兩個局域網：

但是如果我們還是使用硬件地址來作為通信對象的唯一標識，那么當網絡規模越來越大，需要記住所有機器的硬件地址是不現實的;

同時，一個網絡對象可能會頻繁更換設備，這個時候硬件地址表維護起來更加復雜。這里使用了一個新的地址來標記一個網絡對象：IP地址。

通過一個簡單的寄信例子來理解IP地址。

我住在北京市，我朋友A住在上海市，我要給朋友A寫信：

• 寫完信，我會在信上寫好我朋友A的地址，并放到北京市郵局(給信息附加目標IP地址，并發送給路由器)
• 郵局會幫我把信運輸到上海市當地郵局(信息會經過路由傳遞到目標IP局域網的路由器)
• 上海市當地路由器會幫我把信交給朋友A(局域網內通信)

因此，這里IP地址就是一個網絡接入地址(朋友A的住址)，我只需要知道目標IP地址，路由器就可以把消息給我帶到。在局域網中，就可以動態維護一個MAC地址與IP地址的映射關系，根據目的IP地址就可以尋找到機器的MAC地址進行發送。

這樣我們不需管理底層如何去選擇機器，我們只需要知道IP地址，就可以和我們的目標進行通信。這一層就是網絡層。網絡層的核心作用就是提供主機之間的邏輯通信。

這樣，在網絡中的所有主機，在邏輯上都連接起來了，上層只需要提供目標IP地址和數據，網絡層就可以把消息發送到對應的主機。

一個主機有多個進程，進程之間進行不同的網絡通信，如邊和朋友開黑邊和女朋友聊微信。我的手機同時和兩個不同機器進行通信。

那么當我的手機收到數據時，如何區分是微信的數據，還是王者的數據?那么就必須在網絡層之上再添加一層：運輸層：

運輸層通過socket(套接字)，將網絡信息進行進一步的拆分，不同的應用進程可以獨立進行網絡請求，互不干擾。

這就是運輸層的最本質特點：提供進程之間的邏輯通信。這里的進程可以是主機之間，也可以是同個主機，所以在android中，socket通信也是進程通信的一種方式。

現在不同的機器上的應用進程之間可以獨立通信了，那么我們就可以在計算機網絡上開發出形形式式的應用：如web網頁的http，文件傳輸ftp等等。這一層稱為應用層。

應用層還可以進一步拆分出表示層、會話層，但他們的本質特點都沒有改變：完成具體的業務需求 。和下面的四層相比，他們并不是必須的，可以歸屬到應用層中。

最后對計網分層進行小結：

• 最底層物理層，負責兩個機器之間通過硬件的直接通信;
• 數據鏈路層使用硬件地址在局域網中進行尋址，實現局域網通信;
• 網絡層通過抽象IP地址實現主機之間的邏輯通信;
• 運輸層在網絡層的基礎上，對數據進行拆分，實現應用進程的獨立網絡通信;
• 應用層在運輸層的基礎上，根據具體的需求開發形形式式的功能。

這里需要注意的是，分層并不是在物理上的分層，而是邏輯上的分層。通過對底層邏輯的封裝，使得上層的開發可以直接依賴底層的功能而無需理會具體的實現，簡便了開發。

這種分層的思路，也就是責任鏈設計模式，通過層層封裝，把不同的職責獨立起來，更加方便開發、維護等等。

二、TCP面向字節流特性

TCP并不是把應用層傳輸過來的數據直接加上首部然后發送給目標，而是把數據看成一個字節 流，給他們標上序號之后分部分發送。這就是TCP的面向字節流特性：

• TCP會以流的形式從應用層讀取數據并存放在自己的發送緩存區中，同時為這些字節標上序號
• TCP會從發送方緩沖區選擇適量的字節組成TCP報文，通過網絡層發送給目標
• 目標會讀取字節并存放在自己的接收方緩沖區中，并在合適的時候交付給應用層

面向字節流的好處是無需一次存儲過大的數據占用太多內存，壞處是無法知道這些字節代表的意義，例如應用層發送一個音頻文件和一個文本文件，對于TCP來說就是一串字節流，沒有意義可言，這會導致粘包以及拆包問題，后面講。

三、可靠傳輸原理

前面講到，TCP是可靠傳輸協議，也就是，一個數據交給他，他肯定可以完整無誤地發送到目標地址，除非網絡炸了。他實現的網絡模型如下：

對于應用層來說，他就是一個可靠傳輸的底層支持服務;而運輸層底層采用了網絡層的不可靠傳輸。雖然在網絡層甚至數據鏈路層就可以使用協議來保證數據傳輸的可靠性，但這樣網絡的設計會更加復雜、效率會隨之降低。把數據傳輸的可靠性保證放在運輸層，會更加合適。

可靠傳輸原理的重點總結一下有：滑動窗口、超時重傳、累積確認、選擇確認、連續ARQ。

停止等待協議

要實現可靠傳輸，最簡便的方法就是：我發送一個數據包給你，然后你跟我回復收到，我繼續發送下一個數據包。傳輸模型如下：

這種“一來一去”的方法來保證傳輸可靠就是停止等待協議(stop-and-wait)。不知道還記不記得前面TCP首部有一個ack字段，當他設置為1的時候，表示這個報文是一個確認收到報文。

然后再來考慮另一種情況：丟包。網絡環境不可靠，導致每一次發送的數據包可能會丟失，如果機器A發送了數據包丟失了，那么機器B永遠接收不到數據，機器A永遠在等待。

解決這個問題的方法是：超時重傳。當機器A發出一個數據包時便開始計時，時間到還沒收到確認回復，就可以認為是發生了丟包，便再次發送，也就是重傳。

但重傳會導致另一種問題：如果原先的數據包并沒有丟失，只是在網絡中待的時間比較久，這個時候機器B會受到兩個數據包，那么機器B是如何辨別這兩個數據包是屬于同一份數據還是不同的數據?

這就需要前面講過的方法：給數據字節進行編號。這樣接收方就可以根據數據的字節編號，得出這些數據是接下來的數據，還是重傳的數據。

在TCP首部有兩個字段：序號和確認號，他們表示發送方數據第一個字節的編號，和接收方期待的下一份數據的第一個字節的編號。

連續ARQ協議

停止等待協議已經可以滿足可靠傳輸了，但有一個致命缺點：效率太低。發送方發送一個數據包之后便進入等待，這個期間并沒有干任何事，浪費了資源。解決的方法是：連續發送數據包。模型如下：

和停止等待最大的不同就是，他會源源不斷地發送，接收方源源不斷收到數據之后，逐一進行確認回復。這樣便極大地提高了效率。但同樣，帶來了一些額外的問題:

發送是否可以無限發送直到把緩沖區所有數據發送完?不可以。因為需要考慮接收方緩沖區以及讀取數據的能力。如果發送太快導致接收方無法接受，那么只是會頻繁進行重傳，浪費了網絡資源。所以發送方發送數據的范圍，需要考慮到接收方緩沖區的情況。這就是TCP的流量控制。

解決方法是：滑動窗口。基本模型如下：

• 發送方需要根據接收方的緩沖區大小，設置自己的可發送窗口大小，處于窗口內的數據表示可發送，之外的數據不可發送。
• 當窗口內的數據接收到確認回復時，整個窗口會往前移動，直到發送完成所有的數據

在TCP的首部有一個窗口大小字段，他表示接收方的剩余緩沖區大小，讓發送方可以調整自己的發送窗口大小。通過滑動窗口，就可以實現TCP的流量控制，不至于發送太快，導致太多的數據丟失。

連續ARQ帶來的第二個問題是：網絡中充斥著和發送數據包一樣數據量的確認回復報文，因為每一個發送數據包，必須得有一個確認回復。提高網絡效率的方法是：累積確認。

接收方不需要逐個進行回復，而是累積到一定量的數據包之后，告訴發送方，在此數據包之前的數據全都收到。例如，收到 1234，接收方只需要告訴發送方我收到4了，那么發送方就知道1234都收到了。

第三個問題是：如何處理丟包情況。在停止等待協議中很簡單，直接一個超時重傳就解決了。但，連續ARQ中不太一樣。

例如：接收方收到了 123 567，六個字節，編號為4的字節丟失了。按照累積確認的思路，只能發送3的確認回復，567都必須丟掉，因為發送方會進行重傳。這就是GBN(go-back-n) 思路。

但是我們會發現，只需要重傳4即可，這樣不是很浪費資源，所以就有了：選擇確認SACK 。在TCP報文的選項字段，可以設置已經收到的報文段，每一個報文段需要兩個邊界來進行確定。這樣發送方，就可以根據這個選項字段只重傳丟失的數據了。

可靠傳輸小結

到這里關于TCP的可靠傳輸原理就已經介紹得差不多。最后進行一個小結：

• 通過連續ARQ協議與發送-確認回復模式來保證每一個數據包都到達接收方
• 通過給字節編號的方法，來標記每一個數據是屬于重傳還是新的數據
• 通過超時重傳的方式，來解決數據包在網絡中丟失的問題
• 通過滑動窗口來實現流量控制
• 通過累積確認+選擇確認的方法來提高確認回復與重傳的效率
• 當然，這只是可靠傳輸的冰山一角，感興趣可以再深入去研究。