[[400080]]

一、計網(wǎng)分層結(jié)構(gòu)

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

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

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

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

這里我們可以不管底層的網(wǎng)線接口如何發(fā)送，把物理層抽離，在他之上創(chuàng)建一個新的層次，這就是數(shù)據(jù)鏈路層。

我們依然不滿足于局域網(wǎng)的規(guī)模，需要把所有的局域網(wǎng)聯(lián)系起來，這個時候就需要用到路由器來連接兩個局域網(wǎng)：

但是如果我們還是使用硬件地址來作為通信對象的唯一標(biāo)識，那么當(dāng)網(wǎng)絡(luò)規(guī)模越來越大，需要記住所有機(jī)器的硬件地址是不現(xiàn)實(shí)的;

同時，一個網(wǎng)絡(luò)對象可能會頻繁更換設(shè)備，這個時候硬件地址表維護(hù)起來更加復(fù)雜。這里使用了一個新的地址來標(biāo)記一個網(wǎng)絡(luò)對象：IP地址。

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

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

• 寫完信，我會在信上寫好我朋友A的地址，并放到北京市郵局(給信息附加目標(biāo)IP地址，并發(fā)送給路由器)
• 郵局會幫我把信運(yùn)輸?shù)缴虾Ｊ挟?dāng)?shù)剜]局(信息會經(jīng)過路由傳遞到目標(biāo)IP局域網(wǎng)的路由器)
• 上海市當(dāng)?shù)芈酚善鲿臀野研沤唤o朋友A(局域網(wǎng)內(nèi)通信)

因此，這里IP地址就是一個網(wǎng)絡(luò)接入地址(朋友A的住址)，我只需要知道目標(biāo)IP地址，路由器就可以把消息給我?guī)У健Ｔ诰钟蚓W(wǎng)中，就可以動態(tài)維護(hù)一個MAC地址與IP地址的映射關(guān)系，根據(jù)目的IP地址就可以尋找到機(jī)器的MAC地址進(jìn)行發(fā)送。

這樣我們不需管理底層如何去選擇機(jī)器，我們只需要知道IP地址，就可以和我們的目標(biāo)進(jìn)行通信。這一層就是網(wǎng)絡(luò)層。網(wǎng)絡(luò)層的核心作用就是提供主機(jī)之間的邏輯通信。

這樣，在網(wǎng)絡(luò)中的所有主機(jī)，在邏輯上都連接起來了，上層只需要提供目標(biāo)IP地址和數(shù)據(jù)，網(wǎng)絡(luò)層就可以把消息發(fā)送到對應(yīng)的主機(jī)。

一個主機(jī)有多個進(jìn)程，進(jìn)程之間進(jìn)行不同的網(wǎng)絡(luò)通信，如邊和朋友開黑邊和女朋友聊微信。我的手機(jī)同時和兩個不同機(jī)器進(jìn)行通信。

那么當(dāng)我的手機(jī)收到數(shù)據(jù)時，如何區(qū)分是微信的數(shù)據(jù)，還是王者的數(shù)據(jù)?那么就必須在網(wǎng)絡(luò)層之上再添加一層：運(yùn)輸層：

運(yùn)輸層通過socket(套接字)，將網(wǎng)絡(luò)信息進(jìn)行進(jìn)一步的拆分，不同的應(yīng)用進(jìn)程可以獨(dú)立進(jìn)行網(wǎng)絡(luò)請求，互不干擾。

這就是運(yùn)輸層的最本質(zhì)特點(diǎn)：提供進(jìn)程之間的邏輯通信。這里的進(jìn)程可以是主機(jī)之間，也可以是同個主機(jī)，所以在android中，socket通信也是進(jìn)程通信的一種方式。

現(xiàn)在不同的機(jī)器上的應(yīng)用進(jìn)程之間可以獨(dú)立通信了，那么我們就可以在計算機(jī)網(wǎng)絡(luò)上開發(fā)出形形式式的應(yīng)用：如web網(wǎng)頁的http，文件傳輸ftp等等。這一層稱為應(yīng)用層。

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

最后對計網(wǎng)分層進(jìn)行小結(jié)：

• 最底層物理層，負(fù)責(zé)兩個機(jī)器之間通過硬件的直接通信;
• 數(shù)據(jù)鏈路層使用硬件地址在局域網(wǎng)中進(jìn)行尋址，實(shí)現(xiàn)局域網(wǎng)通信;
• 網(wǎng)絡(luò)層通過抽象IP地址實(shí)現(xiàn)主機(jī)之間的邏輯通信;
• 運(yùn)輸層在網(wǎng)絡(luò)層的基礎(chǔ)上，對數(shù)據(jù)進(jìn)行拆分，實(shí)現(xiàn)應(yīng)用進(jìn)程的獨(dú)立網(wǎng)絡(luò)通信;
• 應(yīng)用層在運(yùn)輸層的基礎(chǔ)上，根據(jù)具體的需求開發(fā)形形式式的功能。

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

這種分層的思路，也就是責(zé)任鏈設(shè)計模式，通過層層封裝，把不同的職責(zé)獨(dú)立起來，更加方便開發(fā)、維護(hù)等等。

二、TCP面向字節(jié)流特性

TCP并不是把應(yīng)用層傳輸過來的數(shù)據(jù)直接加上首部然后發(fā)送給目標(biāo)，而是把數(shù)據(jù)看成一個字節(jié) 流，給他們標(biāo)上序號之后分部分發(fā)送。這就是TCP的面向字節(jié)流特性：

• TCP會以流的形式從應(yīng)用層讀取數(shù)據(jù)并存放在自己的發(fā)送緩存區(qū)中，同時為這些字節(jié)標(biāo)上序號
• TCP會從發(fā)送方緩沖區(qū)選擇適量的字節(jié)組成TCP報文，通過網(wǎng)絡(luò)層發(fā)送給目標(biāo)
• 目標(biāo)會讀取字節(jié)并存放在自己的接收方緩沖區(qū)中，并在合適的時候交付給應(yīng)用層

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

三、可靠傳輸原理

前面講到，TCP是可靠傳輸協(xié)議，也就是，一個數(shù)據(jù)交給他，他肯定可以完整無誤地發(fā)送到目標(biāo)地址，除非網(wǎng)絡(luò)炸了。他實(shí)現(xiàn)的網(wǎng)絡(luò)模型如下：

對于應(yīng)用層來說，他就是一個可靠傳輸?shù)牡讓又С址?wù);而運(yùn)輸層底層采用了網(wǎng)絡(luò)層的不可靠傳輸。雖然在網(wǎng)絡(luò)層甚至數(shù)據(jù)鏈路層就可以使用協(xié)議來保證數(shù)據(jù)傳輸?shù)目煽啃裕@樣網(wǎng)絡(luò)的設(shè)計會更加復(fù)雜、效率會隨之降低。把數(shù)據(jù)傳輸?shù)目煽啃员ＷC放在運(yùn)輸層，會更加合適。

可靠傳輸原理的重點(diǎn)總結(jié)一下有：滑動窗口、超時重傳、累積確認(rèn)、選擇確認(rèn)、連續(xù)ARQ。

停止等待協(xié)議

要實(shí)現(xiàn)可靠傳輸，最簡便的方法就是：我發(fā)送一個數(shù)據(jù)包給你，然后你跟我回復(fù)收到，我繼續(xù)發(fā)送下一個數(shù)據(jù)包。傳輸模型如下：

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

然后再來考慮另一種情況：丟包。網(wǎng)絡(luò)環(huán)境不可靠，導(dǎo)致每一次發(fā)送的數(shù)據(jù)包可能會丟失，如果機(jī)器A發(fā)送了數(shù)據(jù)包丟失了，那么機(jī)器B永遠(yuǎn)接收不到數(shù)據(jù)，機(jī)器A永遠(yuǎn)在等待。

解決這個問題的方法是：超時重傳。當(dāng)機(jī)器A發(fā)出一個數(shù)據(jù)包時便開始計時，時間到還沒收到確認(rèn)回復(fù)，就可以認(rèn)為是發(fā)生了丟包，便再次發(fā)送，也就是重傳。

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

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

在TCP首部有兩個字段：序號和確認(rèn)號，他們表示發(fā)送方數(shù)據(jù)第一個字節(jié)的編號，和接收方期待的下一份數(shù)據(jù)的第一個字節(jié)的編號。

連續(xù)ARQ協(xié)議

停止等待協(xié)議已經(jīng)可以滿足可靠傳輸了，但有一個致命缺點(diǎn)：效率太低。發(fā)送方發(fā)送一個數(shù)據(jù)包之后便進(jìn)入等待，這個期間并沒有干任何事，浪費(fèi)了資源。解決的方法是：連續(xù)發(fā)送數(shù)據(jù)包。模型如下：

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

發(fā)送是否可以無限發(fā)送直到把緩沖區(qū)所有數(shù)據(jù)發(fā)送完?不可以。因?yàn)樾枰紤]接收方緩沖區(qū)以及讀取數(shù)據(jù)的能力。如果發(fā)送太快導(dǎo)致接收方無法接受，那么只是會頻繁進(jìn)行重傳，浪費(fèi)了網(wǎng)絡(luò)資源。所以發(fā)送方發(fā)送數(shù)據(jù)的范圍，需要考慮到接收方緩沖區(qū)的情況。這就是TCP的流量控制。

解決方法是：滑動窗口?；灸Ｐ腿缦拢?/p>

• 發(fā)送方需要根據(jù)接收方的緩沖區(qū)大小，設(shè)置自己的可發(fā)送窗口大小，處于窗口內(nèi)的數(shù)據(jù)表示可發(fā)送，之外的數(shù)據(jù)不可發(fā)送。
• 當(dāng)窗口內(nèi)的數(shù)據(jù)接收到確認(rèn)回復(fù)時，整個窗口會往前移動，直到發(fā)送完成所有的數(shù)據(jù)

在TCP的首部有一個窗口大小字段，他表示接收方的剩余緩沖區(qū)大小，讓發(fā)送方可以調(diào)整自己的發(fā)送窗口大小。通過滑動窗口，就可以實(shí)現(xiàn)TCP的流量控制，不至于發(fā)送太快，導(dǎo)致太多的數(shù)據(jù)丟失。

連續(xù)ARQ帶來的第二個問題是：網(wǎng)絡(luò)中充斥著和發(fā)送數(shù)據(jù)包一樣數(shù)據(jù)量的確認(rèn)回復(fù)報文，因?yàn)槊恳粋€發(fā)送數(shù)據(jù)包，必須得有一個確認(rèn)回復(fù)。提高網(wǎng)絡(luò)效率的方法是：累積確認(rèn)。

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

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

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

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

可靠傳輸小結(jié)

到這里關(guān)于TCP的可靠傳輸原理就已經(jīng)介紹得差不多。最后進(jìn)行一個小結(jié)：

• 通過連續(xù)ARQ協(xié)議與發(fā)送-確認(rèn)回復(fù)模式來保證每一個數(shù)據(jù)包都到達(dá)接收方
• 通過給字節(jié)編號的方法，來標(biāo)記每一個數(shù)據(jù)是屬于重傳還是新的數(shù)據(jù)
• 通過超時重傳的方式，來解決數(shù)據(jù)包在網(wǎng)絡(luò)中丟失的問題
• 通過滑動窗口來實(shí)現(xiàn)流量控制
• 通過累積確認(rèn)+選擇確認(rèn)的方法來提高確認(rèn)回復(fù)與重傳的效率
• 當(dāng)然，這只是可靠傳輸?shù)谋揭唤牵信d趣可以再深入去研究。