iOS 移動(dòng)開(kāi)發(fā)網(wǎng)絡(luò) Part1:我認(rèn)識(shí)的TCP/IP

1.OSI七層 TCP/IP五層

1.1 OSI七層參考模型

應(yīng)用層
表示層
會(huì)話(huà)層
傳輸層
網(wǎng)絡(luò)層
數(shù)據(jù)鏈路層
物理層

對(duì)于OSI七層參考模型,我想說(shuō)只有這七個(gè)詞條.任何與實(shí)際生產(chǎn)脫鉤的東西都需要硬性記憶.
而TCP/IP五層模型我不需要硬性記憶,就可以根據(jù)應(yīng)用邏輯復(fù)述出來(lái).

1.2 TCP/IP五層模型

TCP/IP五層模型

應(yīng)用層
傳輸層
網(wǎng)絡(luò)層
數(shù)據(jù)鏈路層
物理層

TCP/IP是一組通信協(xié)議的代名詞,是由一系列協(xié)議組成的協(xié)議簇.

TCP/IP.png

上圖是TCP/IP五層模型前四層對(duì)應(yīng)的協(xié)議.(圖片來(lái)源自網(wǎng)絡(luò),部分翻譯與本文有出入)

接下來(lái)我們就按順序來(lái)說(shuō)說(shuō)每一層.

2.應(yīng)用層

應(yīng)用層的協(xié)議有:HTTP,FTP,DNS等.他們都是有自己對(duì)應(yīng)端口的,
所謂端口就是:數(shù)據(jù)由網(wǎng)絡(luò)到達(dá)終端(手機(jī),PC),然后交給誰(shuí).QQ聊天的數(shù)據(jù)就交給QQ,網(wǎng)頁(yè)瀏覽的數(shù)據(jù)就交給瀏覽器.QQ,瀏覽器等進(jìn)程都是有對(duì)應(yīng)端口的.但端口分為不同類(lèi)型:

IANA:互聯(lián)網(wǎng)地址編碼分配機(jī)構(gòu)(Internet Assigned Numbers Authority)

熟知端口(著名端口):0-1023,由IANA指派和控制.(如:FTP:21,SSH:22,SMTP:25,DNS:53,HTTP:80,HTTPS:443等)
注冊(cè)端口:1024-49151,IANA不指派也不控制,但須注冊(cè).
動(dòng)態(tài)端口(短暫端口):49152-65535,IANA不指派也不控制,無(wú)須注冊(cè).通常被用來(lái)在主動(dòng)發(fā)起連接時(shí)隨機(jī)分配使用.

接下來(lái)我們會(huì)用HTTP,DNS來(lái)走完TCP/IP的五層結(jié)構(gòu).用這兩個(gè)因?yàn)?
1.HTTP對(duì)應(yīng)TCP,DNS對(duì)應(yīng)UDP,這樣可以囊括傳輸層的兩個(gè)重要協(xié)議.
2.HTTP與DNS在真實(shí)的應(yīng)用場(chǎng)景下有穿插.

2.1 HTTP

HTTP_GET@2x.png

如上圖所示就是我打開(kāi)簡(jiǎn)書(shū)首頁(yè)時(shí)用HTTP的GET方式發(fā)出的請(qǐng)求.(字段有些多,看上去復(fù)雜,其實(shí)我們做的只是輸入一個(gè)網(wǎng)址,其他參數(shù)瀏覽器自己會(huì)配置好的)
到HTTP的各個(gè)字段全都配置好后,其實(shí)HTTP的'發(fā)'工作也就已經(jīng)完成了,下面就該把數(shù)據(jù)交給傳輸層的TCP了.(數(shù)據(jù)傳入TCP前還有個(gè)小插曲,請(qǐng)看2.2 DNS)

2.2 DNS

我在打開(kāi)網(wǎng)頁(yè)的時(shí)候輸入的是http://www.reibang.com/,這是域名.但在真實(shí)的網(wǎng)絡(luò)環(huán)境下是不會(huì)用域名進(jìn)行通信的.通信時(shí)數(shù)字的效率永遠(yuǎn)是最快的,這也就是IP地址(就像生活中的郵編與門(mén)牌號(hào)).

四川成都溫江柳臺(tái)大道555號(hào)     郵編:611130

但完全讓我們這些凡夫俗子用輸入IP的方式來(lái)訪(fǎng)問(wèn)網(wǎng)頁(yè)也不現(xiàn)實(shí)!

www.baidu.com  119.75.217.109
www.163.com  114.80.143.193

DNS(Domain Name System)也就是一個(gè)折中.
DNS就是一個(gè)域名換IP的應(yīng)用協(xié)議.

這也就是上面說(shuō)的插曲.HTTP請(qǐng)求數(shù)據(jù)準(zhǔn)備完畢后,不是往www.reibang.com域名上發(fā),而是往www.reibang.com對(duì)應(yīng)的IP上發(fā).以下就是用DNS,以域名為參數(shù),請(qǐng)求對(duì)應(yīng)的IP地址.

DNS_query.png

而且這個(gè)DNS請(qǐng)求是直接向IP地址發(fā)的,我們?cè)诮K端(手機(jī),PC)上都會(huì)配置DNS服務(wù)器的IP地址,就是用在這的.當(dāng)然DNS的請(qǐng)求數(shù)據(jù)準(zhǔn)備好后,其實(shí)DNS'發(fā)'的工作也就已經(jīng)完畢了,數(shù)據(jù)會(huì)交給下層傳輸層的UDP.

以下就是DNS收到的回復(fù):


DNS_response.png

DNS緩存:當(dāng)然不可能每回用瀏覽器打開(kāi)www.reibang.com都要用DNS詢(xún)問(wèn)下DNS服務(wù)器簡(jiǎn)書(shū)的域名對(duì)應(yīng)的IP地址是什么.操作系統(tǒng)本身有DNS緩存,瀏覽器自己也有DNS緩存.有興趣請(qǐng)戳:主流操作系統(tǒng)、瀏覽器DNS緩存時(shí)間

3.傳輸層

前文說(shuō)到:
DNS將數(shù)據(jù)準(zhǔn)備好后交給UDP.
DNS收到回復(fù),獲取到域名對(duì)應(yīng)的IP地址,HTTP也會(huì)將準(zhǔn)備好數(shù)據(jù)交給TCP.

UDP與TCP同屬于傳輸層.他們的關(guān)系就好像郵政和順豐一樣.都是快遞公司,但由于工作屬性,模式,態(tài)度的不一樣,被不同的應(yīng)用層協(xié)議所用.

TCP---傳輸控制協(xié)議,提供的是面向連接,可靠的字節(jié)流服務(wù).當(dāng)客戶(hù)和服務(wù)器彼此交換數(shù)據(jù)前,必須先在雙方之間建立一個(gè)TCP連接,之后才能傳輸數(shù)據(jù).TCP提供數(shù)據(jù)包重發(fā),丟棄重復(fù)數(shù)據(jù),檢驗(yàn)數(shù)據(jù),流量控制,擁塞控制等功能,保證數(shù)據(jù)能從一端傳到另一端.

UDP---用戶(hù)數(shù)據(jù)報(bào)協(xié)議,是一個(gè)簡(jiǎn)單的面向數(shù)據(jù)報(bào)的傳輸層協(xié)議.UDP不提供可靠性,它只是把應(yīng)用層提供的數(shù)據(jù)發(fā)送出去,但是并不能保證它們能到達(dá)目的地.由于UDP在傳輸數(shù)據(jù)報(bào)前不用在客戶(hù)和服務(wù)器之間建立一個(gè)連接,且沒(méi)有數(shù)據(jù)包重發(fā)等機(jī)制,故而傳輸速度很快.

TCP UDP
正式通信前先建立連接,結(jié)束后斷開(kāi)連接 無(wú)連接
流量控制 沒(méi)這回事
數(shù)據(jù)包重發(fā) 沒(méi)這回事
丟棄重復(fù)數(shù)據(jù) 沒(méi)這回事
擁塞控制 沒(méi)這回事

說(shuō)那么多,簡(jiǎn)單些的描述就是:
TCP是面向連接,可靠的數(shù)據(jù)傳輸協(xié)議
UDP是無(wú)連接,不可靠的數(shù)據(jù)傳輸協(xié)議

接下來(lái)我們也會(huì)由連接和可靠這兩塊來(lái)對(duì)TCP和UDP進(jìn)行對(duì)比分析.

3.1 TCP

在說(shuō)TCP的面向連接和可靠之前,我們先來(lái)看看TCP報(bào)文段的格式,因?yàn)闊o(wú)論是面向連接還是可靠都依賴(lài)于TCP報(bào)文段的格式.

3.1.1 TCP報(bào)文段的格式
TCP segment.png

很清楚的能看到TCP報(bào)文段大體分為兩部分:TCP首部,TCP數(shù)據(jù)部分.
HTTP的數(shù)據(jù)交給TCP就放在TCP數(shù)據(jù)部分.

TCP首部:

源端口和目的端口:上面已經(jīng)說(shuō)過(guò)了應(yīng)用層協(xié)議都有對(duì)應(yīng)的端口號(hào)(HTTP:80)

序號(hào)(seq):TCP連接中傳送的數(shù)據(jù)流中的每一個(gè)字節(jié)都編上一個(gè)序號(hào).序號(hào)字段的值則指的是本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào).

確認(rèn)號(hào)(ask):是期望收到對(duì)方的下一個(gè)報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào).

首部長(zhǎng)度:它指出TCP首部共有多少個(gè)4字節(jié),首部長(zhǎng)度可以在20~60字節(jié)之間.因此,這個(gè)字段值可以在5(5X4=20)至15(15X4=60)之間.

標(biāo)記位:URG,ACK,PSH,RST,SYN,FIN.標(biāo)記該TCP報(bào)文段的意圖(如:ASK==>確認(rèn)).

窗口:窗口用來(lái)控制對(duì)方發(fā)送的數(shù)據(jù)量,單位為字節(jié).TCP連接的一端根據(jù)設(shè)置的緩存空間大小確定自己的接收窗口大小,然后通知對(duì)方以確定對(duì)方的發(fā)送窗口的上限.

檢驗(yàn)和:檢驗(yàn)和檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分.在計(jì)算檢驗(yàn)和時(shí),要在TCP報(bào)文段的前面加上12字節(jié)的偽首部.

緊急指針:緊急指針指出在本報(bào)文段中的緊急數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào).

選項(xiàng):長(zhǎng)度可變.TCP只規(guī)定了一種選項(xiàng),即最大報(bào)文段長(zhǎng)度 MSS(Maximum Segment Size).MSS告訴對(duì)方TCP:"我的緩存所能接收的報(bào)文段的數(shù)據(jù)字段的最大長(zhǎng)度是MSS個(gè)字節(jié)."

填充:這是為了使整個(gè)首部長(zhǎng)度是4字節(jié)的整數(shù)倍
3.1.2 連接
  • 建立連接,三次握手
三次握手.png

以上就是三次握手的TCP報(bào)文段的交互,參數(shù)很多,現(xiàn)在只需要關(guān)注seq(序號(hào))和ack(確認(rèn)號(hào)),其他的可以先忽略不看.

three times handshake.png

ack(確認(rèn)號(hào))看的是圖上小寫(xiě)的ack.大寫(xiě)的ACK是起標(biāo)記作用的.

可以簡(jiǎn)單的理解為:

three times handshake

Client  [SYN=1,seq=x]==>  Server     (在嗎?我要給你發(fā)數(shù)據(jù)咯)
Client  <==[SYN=1,seq=y,ack=x+1]  Server    (在的,你發(fā)吧)
Client  [seq=x+1,ack=y+1]==>  Server     (好,馬上發(fā))

這樣的握手完成后就開(kāi)始正式的數(shù)據(jù)交互.

正式的數(shù)據(jù)交互流程后面會(huì)說(shuō),我們現(xiàn)在來(lái)看看數(shù)據(jù)交互完畢后的斷開(kāi)連接==>四次揮別.

  • 斷開(kāi)連接,四次揮別
four wave.png
在四次揮別前,因?yàn)橛袛?shù)據(jù)交互,所以seq的值會(huì)比較大
Client  ==>  Server  最大seq是u-1  

1.客戶(hù)端對(duì)服務(wù)器說(shuō),我傳給你的最后一個(gè)數(shù)據(jù)是u-1(seq=u),我發(fā)完了,現(xiàn)在想走了(FIN=1),你回個(gè)話(huà).
(FIN報(bào)文段即使不攜帶數(shù)據(jù),也要消耗一個(gè)序號(hào))

2.服務(wù)器對(duì)客戶(hù)端說(shuō),你傳給我的最后一個(gè)數(shù)據(jù)是u-1(ack=u+1,之前的報(bào)文段消耗了一個(gè)序號(hào)),我下一步要發(fā)送的數(shù)據(jù)是從v開(kāi)始的(seq=v).
你發(fā)送完了,可是我沒(méi)有發(fā)送完啊,等著讓我發(fā)完磅网！然后服務(wù)器就開(kāi)始把剩下的數(shù)據(jù)給客戶(hù)端.(如果服務(wù)器還有數(shù)據(jù)要給客戶(hù)端的話(huà))

3.服務(wù)器的剩余數(shù)據(jù)發(fā)送完之后,就對(duì)客戶(hù)端說(shuō),我發(fā)送給你的最后一個(gè)數(shù)據(jù)的序號(hào)是w-1(seq=w),
你傳給我的最后一個(gè)數(shù)據(jù)是u-1(ack=u+1),現(xiàn)在我的數(shù)據(jù)也發(fā)完了,我想走了(FIN=1).

4.客戶(hù)端對(duì)服務(wù)器說(shuō)我給你的最后一個(gè)數(shù)據(jù)是u-1(seq=u+1),我收到你的最后一個(gè)數(shù)據(jù)是w-1(ack=w+1,FIN報(bào)文要消耗掉一個(gè)序號(hào)),你可以走了.

還可以看出最后一次揮別發(fā)出后,客戶(hù)端還等待了2個(gè)MSL.
MSL (Maximum Segment Lifetime),報(bào)文最大生存時(shí)間,他是任何報(bào)文在網(wǎng)絡(luò)上存在的最長(zhǎng)時(shí)間,超過(guò)這個(gè)時(shí)間報(bào)文將被丟棄.

四次揮別因?yàn)榘l(fā)生在正式傳遞數(shù)據(jù)后,不像三次握手從空白開(kāi)始,所以序號(hào)和確認(rèn)號(hào)會(huì)比較復(fù)雜.

3.1.3 可靠
A.數(shù)據(jù)分段
  • 緩存
TCP Cache.png

在三次握手之后,TCP通信雙方都為連接開(kāi)辟了緩存.這里提到緩存是數(shù)據(jù)分段,流量控制,暫存亂序數(shù)據(jù)的基石.

  • 序號(hào)

為什么需要序號(hào)?因?yàn)閿?shù)據(jù)傳輸?shù)倪^(guò)程中不是'1來(lái)1回'那么簡(jiǎn)單!

在三次握手和四次揮別中,雙方對(duì)發(fā)報(bào)文段,報(bào)文段是'1來(lái)1回'非常有序的.但在數(shù)據(jù)傳輸?shù)倪^(guò)程中,并不是'1來(lái)1回'的停等作業(yè)方式,而是多發(fā)多確認(rèn)的流水線(xiàn)作業(yè)方式.例如:

例1.先看看簡(jiǎn)單的大段數(shù)據(jù)的發(fā)送與確認(rèn)

>> seq:991241 ack:1105 len>610 //發(fā)出[序號(hào)為991241,長(zhǎng)度為610]的包
Ack<<seq:1105 ack:991851 //(注意:991851=991241+610)確認(rèn)收到[序號(hào)為991241,長(zhǎng)度為610]的包

例2.再看看多個(gè)數(shù)據(jù)包一個(gè)確認(rèn)包

延遲確認(rèn):
收到對(duì)方發(fā)來(lái)的包,
同時(shí)也有數(shù)據(jù)要發(fā)給對(duì)方,就立刻發(fā)出確認(rèn)包(確認(rèn)包內(nèi)也包含自己本身就要發(fā)的數(shù)據(jù));
沒(méi)有數(shù)據(jù)要發(fā)給對(duì)方,就等一段時(shí)間(Windows默認(rèn)是200ms)再發(fā)出確認(rèn)包,在這段時(shí)間內(nèi)如果又恰好有數(shù)據(jù)要發(fā)給對(duì)方則立刻發(fā)出確認(rèn)包.

>> seq:991241 ack:1105 len>610 //發(fā)出[序號(hào)為991241,長(zhǎng)度為610]的包
>> seq:991851 ack:1105 len>610 //發(fā)出[序號(hào)為991851,長(zhǎng)度為610]的包
Ack<<seq:1105 ack:991461 //(注意:991461=991241+610+610)確認(rèn)收到[序號(hào)為991241,長(zhǎng)度為610]的包 + 確認(rèn)收到[序號(hào)為991851,長(zhǎng)度為610]的包

例3.再看看更復(fù)雜的雙方數(shù)據(jù)包交錯(cuò)的情況

通常都是發(fā)送方多個(gè)包發(fā)給接收方,接收方才有一個(gè)確認(rèn)包回復(fù),而且還會(huì)出現(xiàn)交錯(cuò)的情況.如下:

>> seq:991241 ack:1105 len>610 //send packet1
>> seq:991851 ack:1105 len>610 //send packet2
>> seq:992461 ack:1105 len>1448 //send packet3
>> seq:993909 ack:1105 len>818 //send packet4
Ack<<seq:1105 ack:991461 //receive packet[1+2]
......

簡(jiǎn)化版:
Sender send packet1==> Receiver
Sender send packet2==> Receiver
Sender send packet3==> Receiver
Sender send packet4==> Receiver
Sender <==receive packet[1+2] Receiver
......

多個(gè)包發(fā)出,一個(gè)包確認(rèn),前面已經(jīng)說(shuō)過(guò)了;
交錯(cuò)是指如上情況:發(fā)出4個(gè)包后收到的確認(rèn)包只確認(rèn)[1+2],而不是[1+2+3+4].

以上3個(gè)例子很好的說(shuō)明了數(shù)據(jù)傳輸過(guò)程中發(fā)出與確認(rèn)次序的錯(cuò)綜復(fù)雜.這就要求得有序號(hào)來(lái)區(qū)分眾多的報(bào)文段.

附加內(nèi)容 相對(duì)序號(hào)與絕對(duì)序號(hào):
我們用Wireshark默認(rèn)看到的序號(hào)是相對(duì)序號(hào),絕對(duì)序號(hào)通過(guò)設(shè)置也能看到.默認(rèn)顯示相對(duì)序號(hào)的原因是相對(duì)序號(hào)比較小,比較容易跟蹤.至于絕對(duì)序號(hào)有多大,請(qǐng)看下面的圖片,自行感受.

相對(duì)序號(hào).png
絕對(duì)序號(hào).png

那么報(bào)文段的序號(hào)是如何生成的呢?

請(qǐng)看前面的圖片TCP Cache.png.當(dāng)數(shù)據(jù)在發(fā)送方的緩存中時(shí),每個(gè)字節(jié)的數(shù)據(jù)會(huì)被分配字節(jié)號(hào).

字節(jié)號(hào)

以字節(jié)為單位
字節(jié)號(hào)的定義范圍:0~(2^32-1)
編號(hào)機(jī)制:隨機(jī)
-----------
舉例:
隨機(jī)生成1057
共6000個(gè)字節(jié)
字節(jié)號(hào)區(qū)間==>1057~7056

6000個(gè)字節(jié),按每段1000個(gè)字節(jié)分為6段,每段的序號(hào)就是這段中第一個(gè)字節(jié)數(shù)據(jù)的字節(jié)號(hào).

[1057~7056]的字節(jié)分為6個(gè)報(bào)文段:
報(bào)文段1==>1000個(gè)字節(jié)==>字節(jié)區(qū)間:[1057~2056]==>序號(hào)1057
報(bào)文段2==>1000個(gè)字節(jié)==>字節(jié)區(qū)間:[2057~3056]==>序號(hào)2057
報(bào)文段3==>1000個(gè)字節(jié)==>字節(jié)區(qū)間:[3057~4056]==>序號(hào)3057
報(bào)文段4==>1000個(gè)字節(jié)==>字節(jié)區(qū)間:[4057~5056]==>序號(hào)4057
報(bào)文段6==>1000個(gè)字節(jié)==>字節(jié)區(qū)間:[5057~6056]==>序號(hào)5057
報(bào)文段6==>1000個(gè)字節(jié)==>字節(jié)區(qū)間:[6057~7056]==>序號(hào)6057
  • 分段

前面提到:6000個(gè)字節(jié),按每段1000個(gè)字節(jié)分為6段.這只是舉個(gè)例子,那么在真實(shí)的數(shù)據(jù)交互中是按什么標(biāo)準(zhǔn)來(lái)分段的呢?

這里就需要通覽傳輸層,網(wǎng)絡(luò)層,網(wǎng)絡(luò)接口層的數(shù)據(jù)結(jié)構(gòu).

傳輸層(TCP)==>TCP報(bào)文段
網(wǎng)絡(luò)層==>IP數(shù)據(jù)報(bào)
網(wǎng)絡(luò)接口層==>以太幀
data_like.png
以太幀:RFC802.3標(biāo)準(zhǔn)規(guī)定,一個(gè)以太幀最少64字節(jié),最大1518字節(jié),那么去掉6字目標(biāo)MAC地址、6字節(jié)源MAC地址土匀、2字節(jié)類(lèi)型柬帕、4字節(jié)CRC,
對(duì)應(yīng)區(qū)間即為46~1500字節(jié),如果不足46字節(jié)可以填充.

MTU:Maxitum Transmission Unit 最大傳輸單元1500字節(jié).(太幀最大字節(jié)數(shù)1518-6-6-2-4) ==>對(duì)應(yīng)IP數(shù)據(jù)報(bào)的大小

MSS:Maxitum Segment Size 最大分段大小1460字節(jié)(MTU減去IP數(shù)據(jù)報(bào)的頭20字節(jié)和TCP報(bào)文段的頭20字節(jié)) ==>對(duì)應(yīng)TCP報(bào)文段去除20字節(jié)首部的大小
MTU and MSS.png

MTU的最大值是由下向上決定的.在啟用巨幀(Jumbo Frame)的網(wǎng)絡(luò)中MTU會(huì)很大(可以到9000字節(jié)),相應(yīng)的MSS也會(huì)很大.但本文以以太幀的規(guī)格來(lái)講述所有流程,特殊情況會(huì)額外說(shuō)明.

通過(guò)的什么描述是不是就可以確認(rèn):一般以太網(wǎng)下的MSS就是1460字節(jié).可以這么說(shuō),但真正的MSS是要通信雙方'協(xié)商'產(chǎn)生的.

還記得TCP報(bào)文段格式中的選項(xiàng)字段定義了MSS嗎?

TCP通信雙方在三次握手的時(shí)候就已經(jīng)交換過(guò)彼此的MSS了.通信雙方會(huì)以雙方提供的MSS值的最小值作為本次通信的MSS值.

TCP發(fā)送數(shù)據(jù)時(shí),將大于MSS的數(shù)據(jù)分成多段(MSS一般為1460字節(jié)).

那么TCP報(bào)文段的數(shù)據(jù)部分是不是一定可以達(dá)到MSS(1460字節(jié))?
不一定.因?yàn)門(mén)CP首部除了20字節(jié)的固定部分,還可以有多達(dá)40字節(jié)的可選信息.可選信息多一些,數(shù)據(jù)部分就要少一些,反正TCP報(bào)文段整體不能超過(guò)MSS+20個(gè)字節(jié).

B.流量控制

還記得TCP報(bào)文段格式中的窗口字段嗎?

見(jiàn)圖TCP Cache.png,TCP的接收方是有接收緩存的.

這個(gè)窗口字段就是告訴發(fā)送方現(xiàn)在的接收方的接收緩存最大的容量.

WSV:Window size value 接收方的接收窗口
接收方的接收窗口決定了發(fā)送方'一口氣'最多能發(fā)送多少字節(jié).發(fā)送方收到WSV后,再與自己發(fā)送出去卻并未被確認(rèn)的數(shù)據(jù)進(jìn)行比對(duì),來(lái)確認(rèn)自己接下來(lái)發(fā)送數(shù)據(jù)量的大小.

C.擁塞控制

發(fā)送方的發(fā)送窗口是受接收方的接收窗口和網(wǎng)絡(luò)影響的,其中限制得更嚴(yán)的因素起決定作用.接收窗口的影響方式非常簡(jiǎn)單,只要在包里用Win=n告知發(fā)送方就可以了.而網(wǎng)絡(luò)的影響方式非常復(fù)雜. ------《Wireshark網(wǎng)絡(luò)分析就這么簡(jiǎn)單》林沛滿(mǎn)

上面的這段話(huà)很好的表達(dá)了流量控制與擁塞控制的關(guān)系.
流量控制==>顧及的是接收方的感受;
擁塞控制==>顧及的是網(wǎng)絡(luò)大環(huán)境的感受;

  • 在途字節(jié)數(shù)

由于確認(rèn)的延遲以及交錯(cuò)就會(huì)出現(xiàn)一些數(shù)據(jù)在途中.

在途字節(jié)數(shù) = 發(fā)出的字節(jié)數(shù) - 確認(rèn)收到的字節(jié)數(shù)

  • 擁塞點(diǎn)

擁塞點(diǎn):能導(dǎo)致網(wǎng)絡(luò)擁塞的數(shù)據(jù)量;(發(fā)生擁塞時(shí)刻的在途字節(jié)數(shù))

網(wǎng)絡(luò)的影響方式之所以復(fù)雜是因?yàn)?

1.變化==>網(wǎng)絡(luò)帶寬是共享的,有時(shí)很擠,有時(shí)很空
2.未知==>由于是一個(gè)動(dòng)態(tài)的值,網(wǎng)絡(luò)上所有設(shè)備都不知道自己的擁塞點(diǎn)
3.沒(méi)法通知==>接收窗口可以在包內(nèi)用字段通知對(duì)方的,而自己的擁塞點(diǎn)是沒(méi)法通知發(fā)送方的
4.瓶頸因素多==>線(xiàn)路上所有的路由器和交互機(jī)都可能是瓶頸

面對(duì)這么復(fù)雜的情況,沒(méi)有完美的解決方案.
發(fā)送方只能維護(hù)一個(gè)虛擬的擁塞窗口,利用算法盡可能逼近擁塞點(diǎn).

1.慢啟動(dòng)

開(kāi)始發(fā)送的時(shí)候,RFC建議以2至4個(gè)MSS開(kāi)始,具體個(gè)數(shù)視MSS的大小而定.
收到N個(gè)MSS的確認(rèn)后,再加n個(gè)MSS.(如:2,4,8,16......)

當(dāng)慢啟動(dòng)到達(dá)慢啟動(dòng)門(mén)限(ssthresh),慢啟動(dòng)就得轉(zhuǎn)入擁塞避免.具體的慢啟動(dòng)門(mén)限可以定為以前發(fā)生過(guò)擁塞時(shí)擁塞點(diǎn)的一半.

2.擁塞避免

RFC建議一個(gè)往復(fù)時(shí)間加一個(gè)MSS(如:16,17,18......)

以上的擁塞控制都還是在非常理想的狀況下,我們并未評(píng)論出現(xiàn)丟包的情況.接下來(lái)將會(huì)討論丟包,出現(xiàn)丟包后除了數(shù)據(jù)包重發(fā),擁塞控制也要做出相應(yīng)的反應(yīng).

根據(jù)采取不同的判斷條件來(lái)判定丟包,數(shù)據(jù)包重發(fā)可以分為超時(shí)重傳和快速重傳.快速重傳又因?yàn)橐粋€(gè)優(yōu)化參數(shù)衍生出快速重傳加強(qiáng)版.我們先介紹快速重傳,因?yàn)樗鼊偤煤?code>擁塞控制的第三個(gè)狀態(tài)——快速恢復(fù)有關(guān);

3.快速恢復(fù)

  • 快速重傳

超時(shí)重傳的缺點(diǎn)很明顯,我們有段時(shí)間不作為.

正常 發(fā)送與確認(rèn)的流程是

接收方在收到packet1后,ack packet2的序號(hào),表示已經(jīng)收到了packet1,期待收到packet1后的包.
接收方在收到packet2后,ack packet3的序號(hào).表示已經(jīng)收到了packet2,期待收到packet2后的包.
......

而快速重傳做了一點(diǎn)小改動(dòng):

快速重傳 發(fā)送與確認(rèn)的流程是

接收方在收到packet1后,ack packet2的序號(hào),表示已經(jīng)收到了packet1,期待收到packet1后的包.
接收方在收到packet3后,ack packet2的序號(hào).表示收到了packet2后的某個(gè)包,還是期待收到packet2.(Dup Ack)
接收方在收到packet4后,ack packet2的序號(hào).表示收到了packet2后的某個(gè)包,還是期待收到packet2.(Dup Ack)
接收方在收到packet5后,ack packet2的序號(hào).表示收到了packet2后的某個(gè)包,還是期待收到packet2.(Dup Ack)
.......

當(dāng)接受方收到的包比自己期望的序號(hào)大的時(shí)候,發(fā)出的確認(rèn)為重復(fù)確認(rèn)(Dup Ack).
當(dāng)發(fā)送方收到的三個(gè)Dup Ack,就認(rèn)定被重復(fù)確認(rèn)序號(hào)所代表的包需要重傳,這也就是傳說(shuō)中的快速重傳.

>> seq:991241 ack:1105 len>610 //packet1
>> seq:991851 ack:1105 len>610 //packet2
>> seq:992461 ack:1105 len>1448 //packet3
>> seq:993909 ack:1105 len>818 //packet4
>> seq:994727 ack:1105 len>1448 //packet5
>> seq:996175 ack:1105 len>818 //packet6

Ack<<seq:1105 ack:991851 //packet1 receive,I look forward packet after packet1
Dup Ack<<seq:1105 ack:991851 //Dup Ack==> receive packet after packet2,I look forward packet after packet1
Dup Ack<<seq:1105 ack:991851 //Dup Ack==> receive packet after packet2,I look forward packet after packet1
Dup Ack<<seq:1105 ack:991851 //Dup Ack==> receive packet after packet2,I look forward packet after packet1

發(fā)生快速重傳的同時(shí),發(fā)送窗口調(diào)整為發(fā)生擁塞時(shí)擁塞點(diǎn)/2+3,繼續(xù)走擁塞避免的流程,這個(gè)流程稱(chēng)為快速恢復(fù).

附加內(nèi)容:快速重傳加強(qiáng)版

快速重傳雖然比超時(shí)重傳對(duì)性能有所提高,但如果細(xì)想其實(shí)是有bug的.
當(dāng)packet2出現(xiàn)丟包和packet2+packet3都出現(xiàn)丟包,Dup Ack的序號(hào)是一樣的.這也就意味著發(fā)送方其實(shí)不知道具體丟了哪個(gè)包.在這種情況下,只能先重發(fā)packet2,在確認(rèn)packet2收到后才知道packet3也需要重發(fā).

理想的方案是接收方的包內(nèi)有一個(gè)區(qū)間值,表示已經(jīng)收到數(shù)據(jù)的區(qū)間.這也就是我們要說(shuō)的SACK.

比如再出現(xiàn)packet2+packet3都丟失
Dup Ack<<seq:1105 ack:991851 SACK:993909-994726 //收到4號(hào)包,還是期待收到packet1后的包
Dup Ack<<seq:1105 ack:991851 SACK:993909-996174 //收到4+5號(hào)包,還是期待收到packet1后的包
Dup Ack<<seq:1105 ack:991851 SACK:993909-996993 //收到4+5+6號(hào)包,還是期待收到packet1后的包

這樣發(fā)送方也就知道缺失的區(qū)間(即:缺哪些包);

前面已經(jīng)借由快速恢復(fù)講述了快速重傳,現(xiàn)在我們?cè)僬f(shuō)說(shuō)超時(shí)重傳.

  • 超時(shí)重傳

發(fā)出多個(gè)數(shù)據(jù)包都設(shè)置了定時(shí)器,當(dāng)某個(gè)數(shù)據(jù)包在RTO(Retransmission Timeout)內(nèi)沒(méi)有得到確認(rèn),就判定這個(gè)包出現(xiàn)丟包,重傳這個(gè)包.

Sender send packet1==> Receiver
Sender send packet2==> Receiver
Sender send packet3==> Receiver
Sender send packet4==> Receiver
Sender <==ack packet1 Receiver
Sender <==ack packet3 Receiver
Sender <==ack packet4 Receiver
.
.
.
packet2 timeout
Retransfer packet2

發(fā)生超時(shí)重傳的同時(shí),發(fā)送窗口調(diào)整為1,慢啟動(dòng)門(mén)限調(diào)整為發(fā)生擁塞時(shí)擁塞點(diǎn)的一半(注意不是發(fā)生擁塞時(shí)發(fā)送窗口的一半),從頭走一遍慢啟動(dòng)+擁塞避免的流程.

總體來(lái)說(shuō),慢啟動(dòng)+擁塞避免+快速恢復(fù),三者的關(guān)系可以概括為下圖:

FSM description of TCP congestion control.png

TCP的內(nèi)容很多,本文無(wú)法言盡,筆者也在不斷學(xué)習(xí)中.

3.2 UDP

UDP_data_like.png

相對(duì)TCP,UDP的數(shù)據(jù)格式和兩方交互流程都非常簡(jiǎn)單.
可以簡(jiǎn)單的總結(jié)為數(shù)據(jù)交給UDP,UDP就發(fā).

3.3 算筆帳

我們來(lái)算筆帳:
TCP==>三次握手,四次揮別,假如中間數(shù)據(jù)非常簡(jiǎn)單只有一個(gè)發(fā)送,一個(gè)確認(rèn)收到.也就是說(shuō)TCP一次完整的通信至少要用掉9個(gè)TCP報(bào)文段,但9個(gè)TCP報(bào)文段中的的確確是我們需要的只有兩個(gè).所以TCP==>安全+慢.
UDP==>假如中間數(shù)據(jù)非常簡(jiǎn)單只有一個(gè)發(fā)送,一個(gè)回復(fù).也就是說(shuō)UDP一次完整的通信用掉2個(gè)UDP數(shù)據(jù)報(bào),一點(diǎn)也不浪費(fèi).所以UDP ==>不安全+快.

另外由上面TCP擁塞控制的分析可以看出,TCP在覺(jué)知到網(wǎng)絡(luò)出現(xiàn)擁塞的時(shí)候,會(huì)限制自己的發(fā)送數(shù)據(jù)量,而UDP是沒(méi)有這回事的.那么一旦網(wǎng)絡(luò)出現(xiàn)擁塞,網(wǎng)絡(luò)帶寬的分配對(duì)TCP其實(shí)是不公平的.

而各個(gè)應(yīng)用層的協(xié)議則會(huì)根據(jù)自己的需要選擇TCP或者UDP:

TCP:
FTP
Telnet
HTTP
SMTP

UDP:
DNS
TFTP
SNMP

Although we covered reliable data transfer in this chapter, we should keep in mind that reliable data transfer can be provided by link-, network-, transport-, or application-layer protocols. Any of the upper four layers of the protocol stack can implement acknowledgments, timers, retransmissions, and sequence numbers and provide reliable data transfer to the layer above.------from Computer Networking: A Top-Down Approach, 6/e

五層模型的前四層都可以實(shí)現(xiàn)可靠數(shù)據(jù)傳輸.UDP也可以用得很安全,我開(kāi)個(gè)腦洞:那就是開(kāi)發(fā)者在應(yīng)用層實(shí)現(xiàn)可靠數(shù)據(jù)傳輸.

4.網(wǎng)絡(luò)層

TCP與UDP的數(shù)據(jù)殊途同歸,最終都會(huì)被封裝成IP數(shù)據(jù)報(bào).

4.1 IP數(shù)據(jù)報(bào)格式

IP數(shù)據(jù)報(bào)格式.png
版本:比如IPv4、IPv6

首部長(zhǎng)度:指的是首部占'4個(gè)字節(jié)'的數(shù)目,包括任何選項(xiàng).由于首部長(zhǎng)度只占4位,因此首部最長(zhǎng)為60個(gè)字節(jié)

服務(wù)類(lèi)型:包括 3位的優(yōu)先權(quán)子字段 4位的TOS子字段 1位未用位但必須置0的子字段.

總長(zhǎng)度:一共16位,理論最大長(zhǎng)度為65535字節(jié),但是受硬件限制,和其它方面的考慮,大部分路由器或主機(jī)支持8192字節(jié).

標(biāo)志:標(biāo)識(shí)是否IP分片.第一位無(wú)用;  第二位0:允許分片,1:不允許;  第三位0:最后一片,1:后面還有分片. //[no use],[Don't Fragment],[More Fragment]

片偏移:此分片在原始數(shù)據(jù)的偏移,用于分片重組,因?yàn)?3位,所以支持的最大字節(jié)為8192.

生存時(shí)間TTL:規(guī)定網(wǎng)絡(luò)數(shù)據(jù)包在網(wǎng)際層傳輸時(shí),代表最多可以經(jīng)過(guò)路由器的個(gè)數(shù),每經(jīng)過(guò)一個(gè)路由值就會(huì)減1.
各種操作系統(tǒng)的默認(rèn)值都不一樣,xp是128,win7、unix和linux是64,也有255的.
當(dāng)它為0時(shí),數(shù)據(jù)會(huì)被丟棄,并回傳一個(gè)ICMP包來(lái)通知發(fā)送者.

協(xié)議:協(xié)議字段指出此數(shù)據(jù)報(bào)攜帶的數(shù)據(jù)是使用何種協(xié)議,以便使目的主機(jī)的IP層知道應(yīng)將數(shù)據(jù)部分上交給哪個(gè)處理過(guò)程.(如:TCP:6,UDP:17,ICMP:1)

首部檢驗(yàn)和:這個(gè)字段只檢驗(yàn)數(shù)據(jù)報(bào)的首部,但不包括數(shù)據(jù)部分.這是因?yàn)閿?shù)據(jù)報(bào)每經(jīng)過(guò)一個(gè)路由器,路由器都要重新計(jì)算一下首部檢驗(yàn)和.

源IP地址:發(fā)送方的IP地址

目的IP地址:接收方的IP地址

數(shù)據(jù):加入的TCP報(bào)文段或者UDP數(shù)據(jù)報(bào)

IP數(shù)據(jù)報(bào)格式中說(shuō)到了幾個(gè)陌生的概念:TOS,IP分片,ICMP.下面會(huì)挨個(gè)講解

  • TOS

TOS一共8位,包括:

3位的優(yōu)先權(quán)子字段
4位的TOS子字段
1位未用位但必須置0的子字段

3位的優(yōu)先權(quán)子字段

111--Network Control(網(wǎng)絡(luò)控制);
110--Internetwork Control(網(wǎng)間控制);
101--Critic(關(guān)鍵);
100--Flash Override(疾速);
011--Flash(閃速);
010--Immediate(快速);
001--Priority(優(yōu)先);
000--Routine(普通).

4位的TOS子字段

0000--normal service;(一般服務(wù))
1000--minimize delay;(最小時(shí)延)
0100--maximize throughput;(最大吞吐量)
0010--maximize reliability;(最高可靠)
0001--minimize monetary cost.(最小費(fèi)用)
  • IP分片

前面已經(jīng)提過(guò):
以太幀:RFC802.3標(biāo)準(zhǔn)規(guī)定,一個(gè)以太幀最大1518字節(jié),那么去掉6字節(jié)目標(biāo)MAC地址隔节、6字節(jié)源MAC地址、2字節(jié)類(lèi)型寂呛、4字節(jié)CRC,得到IP數(shù)據(jù)報(bào)對(duì)應(yīng)的MTU(Maxitum Transmission Unit 最大傳輸單元1500字節(jié)).
但是一個(gè)IP數(shù)據(jù)報(bào)則可能會(huì)有8192字節(jié),超過(guò)以太幀對(duì)IP數(shù)據(jù)報(bào)的最大限制(MTU),那么這時(shí)就需要IP分片,分批進(jìn)行傳輸.

Note:不要亂,先前說(shuō)TCP數(shù)據(jù)按MSS分段,這里又說(shuō)IP分片.到底這么回事啊?
TCP協(xié)議為可靠的傳輸協(xié)議,TCP層對(duì)數(shù)據(jù)進(jìn)行分段,避免了IP分片的發(fā)生,IP分片多用在UDP協(xié)議.

IP數(shù)據(jù)報(bào)對(duì)應(yīng)的MTU是1500字節(jié),這也意味著:
TCP報(bào)文段最大1460字節(jié);(1500-20-20,IP首部20字節(jié),TCP固定首部20字節(jié))
UDP數(shù)據(jù)報(bào)最大1472字節(jié);(1500-20-8,,IP首部20字節(jié),UDP首部20字節(jié))

TCP自行分段,不參與分片就不多說(shuō)了.
UDP的數(shù)據(jù)會(huì)一股腦的給到IP層,UDP的數(shù)據(jù)大于1472字節(jié)就會(huì)被分片.分片后再傳輸給接收方.

多個(gè)分片到達(dá)接收方后,又是如何重組成源數(shù)據(jù)的呢?
接收方收到標(biāo)志位第三位為0的分片,代表這是最后一個(gè)分片,接收方開(kāi)始根據(jù)片偏移來(lái)將多個(gè)分片重組成源數(shù)據(jù).

  • ICMP

ICMP(Internet Control Message Protocol)互聯(lián)網(wǎng)控制報(bào)文協(xié)議.IP層在傳輸數(shù)據(jù)時(shí)出現(xiàn)的報(bào)錯(cuò)都會(huì)用這個(gè)協(xié)議來(lái)通知發(fā)送方.我們平時(shí)用的ping命令也是用的這個(gè)協(xié)議.

ICMP,TCP,UDP的數(shù)據(jù)都是由IP層封裝好,然后在網(wǎng)絡(luò)中傳輸?shù)?但I(xiàn)CMP并不與應(yīng)用層有關(guān)聯(lián),所以不和TCP,UDP歸為一層.

說(shuō)完網(wǎng)絡(luò)層IP數(shù)據(jù)報(bào)的格式,就該說(shuō)IP地址是如何分配的,才能讓數(shù)據(jù)能準(zhǔn)確無(wú)誤的到達(dá)設(shè)置了目的IP的終端設(shè)備.

4.2 IP地址的分配

以下討論的都是IPv4,IPv6筆者也沒(méi)有完全了解.

192.168.199.112

上面是我電腦的IP地址.
IP地址共32位,常以4個(gè)十進(jìn)制數(shù)來(lái)書(shū)寫(xiě).

11111111.11111111.11111111.11111111
255.255.255.255

那么所有的IP地址就是0.0.0.0到255.255.255.255一共4294967296個(gè),42億多個(gè).目前世界人口已達(dá)75億,個(gè)人電腦怎诫、手機(jī)、大公司的服務(wù)器,42億多個(gè)IP地址早就不夠用了,所以才會(huì)有IPv6的誕生.

我們接下來(lái)會(huì)說(shuō)在IPv4夠用的時(shí)候,IP地址是如何分配的.

4.2.1 分類(lèi)網(wǎng)絡(luò)
分類(lèi)網(wǎng)絡(luò).png

IPv4夠用的時(shí)候,IP地址被分為以上的五類(lèi),提供給用戶(hù)的只有A,B,C類(lèi).三類(lèi)地址塊因?yàn)槟艹休d的主機(jī)數(shù)不一樣,為不同大小的機(jī)構(gòu)所用.

  • A類(lèi)

net-id范圍:0~127

第0個(gè)地址塊覆蓋范圍:0.0.0.0~0.255.255.255(保留,用作特殊用途)
第1個(gè)地址塊覆蓋范圍:1.0.0.0~1.255.255.255
第2個(gè)地址塊覆蓋范圍:2.0.0.0~2.255.255.255
.
.
.
第10個(gè)地址塊覆蓋范圍:10.0.0.0~10.255.255.255(專(zhuān)用私有地址)
最后一個(gè)地址塊覆蓋范圍:127.0.0.0~127.255.255.255(保留,用作特殊用途)

結(jié)論:A類(lèi)地址一共有128個(gè)地址塊,其中三個(gè)地址塊有特殊用途,因此可以在互聯(lián)網(wǎng)使用的地址塊有125個(gè).每個(gè)地址塊可以擁有2^24個(gè)主機(jī).
  • B類(lèi)

net-id范圍:128~191

第0個(gè)地址塊覆蓋范圍:128.0.0.0~128.0.255.255
第1個(gè)地址塊覆蓋范圍:128.1.0.0~128.1.255.255
第2個(gè)地址塊覆蓋范圍:128.2.0.0~128.2.255.255
.
.
.
最后一個(gè)地址塊覆蓋范圍:191.255.0.0~191.255.255.255
特殊保留地址塊:172.16.0.0~172.31.255.255(專(zhuān)用私有地址用途)

結(jié)論:B類(lèi)地址一共有16384個(gè)地址塊,其中16個(gè)地址塊有特殊用途,因此可以在互聯(lián)網(wǎng)使用的地址塊有16368個(gè).每個(gè)地址塊可以擁有2^16個(gè)主機(jī).
  • C類(lèi)

net-id范圍:192~223

第0個(gè)地址塊覆蓋范圍:192.0.0.0~192.0.0.255
第1個(gè)地址塊覆蓋范圍:192.0.1.0~192.0.1.255
.
.
.
最后一個(gè)地址塊覆蓋范圍:223.255.255.0~223.255.255.255
特殊保留地址塊:192.168.0.0~192.168.0.255(專(zhuān)用私有地址)

結(jié)論:C類(lèi)地址一共有2097152個(gè)地址塊,其中256個(gè)地址塊有特殊用途,因此可以在互聯(lián)網(wǎng)使用的地址塊有2097152-256=2096896個(gè).每個(gè)地址塊可以擁有2^8個(gè)主機(jī).
  • D類(lèi)

net-id范圍:224~239

用來(lái)進(jìn)行多播使用
  • E類(lèi)

net-id范圍:240~255

保留未用
  • 特殊IP
net-id為127的地址:127.0.0.3 用于環(huán)回測(cè)試(從理論上來(lái)說(shuō)只要是127打頭的都是環(huán)回地址.但2個(gè)地址除外:127.0.0.0是網(wǎng)絡(luò)地址,127.255.255.255是廣播地址)
host-id位全為0:意指"網(wǎng)絡(luò)地址"
host-id位全為1:意指網(wǎng)絡(luò)的"所有結(jié)點(diǎn)" (如:128.2.255.255指向128.2網(wǎng)絡(luò)的"所有結(jié)點(diǎn)")用于廣播
全為0的網(wǎng)絡(luò)地址:被保留用來(lái)指向默認(rèn)路由
4.2.2 無(wú)分類(lèi)網(wǎng)絡(luò)

分類(lèi)網(wǎng)絡(luò):A類(lèi)net-id位數(shù)為8,B類(lèi)net-id位數(shù)為16,C類(lèi)net-id位數(shù)為24.
分類(lèi)網(wǎng)絡(luò)是無(wú)分類(lèi)網(wǎng)絡(luò)的一個(gè)特例,無(wú)分類(lèi)網(wǎng)絡(luò)就是net-id位數(shù)非常靈活.
無(wú)分類(lèi)網(wǎng)絡(luò)書(shū)寫(xiě)方式是140.120.84.24/20,/后跟的是IP地址的net-id位數(shù).

4.2.3 分配子網(wǎng)

無(wú)論是分類(lèi)網(wǎng)絡(luò)還是無(wú)分類(lèi)網(wǎng)絡(luò),包含主機(jī)數(shù)很大的地址塊不可能在一家機(jī)構(gòu)中完全鋪開(kāi)了使用,機(jī)構(gòu)中有許多部門(mén),所以就需要為這些不同的部門(mén)分配不同的子網(wǎng).
分類(lèi)網(wǎng)絡(luò)與無(wú)分類(lèi)網(wǎng)絡(luò)分配子網(wǎng)的原理是一樣的,以下拿分類(lèi)網(wǎng)絡(luò)的網(wǎng)絡(luò)塊舉例:

C類(lèi)地址塊192.168.10.0,分成6個(gè)子網(wǎng).

掩碼很簡(jiǎn)單,就是與地址相與得到網(wǎng)絡(luò)地址.
子網(wǎng)掩碼就是向主機(jī)位借位,然后改變子網(wǎng)部分的數(shù)值,生成子網(wǎng).
分成6個(gè)子網(wǎng),向主機(jī)位借3位生成子網(wǎng)掩碼:11111111.11111111.11111111.11100000

分配子網(wǎng)_1.png
分配子網(wǎng)_2.png

子網(wǎng)位全為0,是"網(wǎng)絡(luò)地址",不能用
子網(wǎng)位全為1,是廣播地址,不能用

4.2.4 NAT

前面已經(jīng)提到目前世界人口已達(dá)75億,個(gè)人電腦贷痪、手機(jī)幻妓、大公司的服務(wù)器,42億多個(gè)IP地址早就不夠用了.而NAT(Network Address Translation,網(wǎng)絡(luò)地址轉(zhuǎn)換)就解決了IP地址不夠用的問(wèn)題.

在公司電腦的IP:192.168.199.112
在家IP:192.168.199.112
其實(shí)兩者根本就沒(méi)關(guān)系!

就好像

上海的人民廣場(chǎng)
不是
長(zhǎng)春的人民廣場(chǎng)

互聯(lián)網(wǎng)分成公網(wǎng),內(nèi)網(wǎng)兩個(gè)層級(jí).
我們以HTTP請(qǐng)求為例:借助于NAT,內(nèi)網(wǎng)IP地址(我們電腦上看到的IP)所在的"內(nèi)部網(wǎng)絡(luò)"通過(guò)路由器發(fā)送數(shù)據(jù)包時(shí),將內(nèi)網(wǎng)IP地址轉(zhuǎn)換成合法公網(wǎng)IP地址(那42億多個(gè)IP地址中的一個(gè)),同時(shí)端口號(hào)也會(huì)被換掉.如圖:

NAT.png

然后在向公網(wǎng)上的服務(wù)器發(fā)出請(qǐng)求.服務(wù)器響應(yīng)后,數(shù)據(jù)回到路由器,NAT由剛剛所用公網(wǎng)IP地址+端口號(hào)映射得到內(nèi)網(wǎng)IP地址+端口號(hào),將數(shù)據(jù)進(jìn)一步傳給目的主機(jī).

這樣一個(gè)"內(nèi)部網(wǎng)絡(luò)"只需使用少量公網(wǎng)IP地址即可實(shí)現(xiàn)"內(nèi)部網(wǎng)絡(luò)"內(nèi)所有計(jì)算機(jī)與互聯(lián)網(wǎng)的通信需求.

5.數(shù)據(jù)鏈路層

學(xué)習(xí)ing.

6.物理層

學(xué)習(xí)ing.

文章參考:
《Wireshark網(wǎng)絡(luò)分析的藝術(shù)》 林沛滿(mǎn)
《Wireshark網(wǎng)絡(luò)分析就這么簡(jiǎn)單》 林沛滿(mǎn)
哈工大 計(jì)算機(jī)網(wǎng)絡(luò) 課程
Computer Networking: A Top-Down Approach, 6/e

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市劫拢，隨后出現(xiàn)的幾起案子肉津，更是在濱河造成了極大的恐慌胖缤，老刑警劉巖，帶你破解...
    沈念sama閱讀 218,755評(píng)論 6贊 507
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件阀圾，死亡現(xiàn)場(chǎng)離奇詭異哪廓，居然都是意外死亡，警方通過(guò)查閱死者的電腦和手機(jī)初烘，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,305評(píng)論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門(mén)涡真，熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)，“玉大人肾筐，你說(shuō)我怎么就攤上這事哆料。” “怎么了吗铐？”我有些...
    開(kāi)封第一講書(shū)人閱讀 165,138評(píng)論 0贊 355
  • 道士緝兇錄：失蹤的賣(mài)姜人
    文/不壞的土叔 我叫張陵东亦，是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我唬渗，道長(zhǎng)典阵，這世上最難降的妖魔是什么？ 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 58,791評(píng)論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任镊逝，我火速辦了婚禮壮啊，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘撑蒜。我一直安慰自己歹啼，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 67,794評(píng)論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來(lái)的
    文/花漫 我一把揭開(kāi)白布座菠。 她就那樣靜靜地躺著狸眼，像睡著了一般。 火紅的嫁衣襯著肌膚如雪浴滴。 梳的紋絲不亂的頭發(fā)上拓萌，一...
    開(kāi)封第一講書(shū)人閱讀 51,631評(píng)論 1贊 305
  • 城市分裂傳說(shuō)
    那天，我揣著相機(jī)與錄音巡莹，去河邊找鬼司志。 笑死，一個(gè)胖子當(dāng)著我的面吹牛降宅，可吹牛的內(nèi)容都是我干的骂远。 我是一名探鬼主播，決...
    沈念sama閱讀 40,362評(píng)論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開(kāi)眼腰根，長(zhǎng)吁一口氣：“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼激才！你這毒婦竟也來(lái)了？” 一聲冷哼從身側(cè)響起，我...
    開(kāi)封第一講書(shū)人閱讀 39,264評(píng)論 0贊 276
  • 萬(wàn)榮殺人案實(shí)錄
    序言：老撾萬(wàn)榮一對(duì)情侶失蹤瘸恼，失蹤者是張志新（化名）和其女友劉穎劣挫，沒(méi)想到半個(gè)月后，有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體东帅，經(jīng)...
    沈念sama閱讀 45,724評(píng)論 1贊 315
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡压固，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,900評(píng)論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了靠闭。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片帐我。...
    茶點(diǎn)故事閱讀 40,040評(píng)論 1贊 350
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡，死狀恐怖愧膀，靈堂內(nèi)的尸體忽然破棺而出拦键，到底是詐尸還是另有隱情，我是刑警寧澤檩淋，帶...
    沈念sama閱讀 35,742評(píng)論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布芬为，位于F島的核電站，受9級(jí)特大地震影響蟀悦，放射性物質(zhì)發(fā)生泄漏媚朦。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,364評(píng)論 3贊 330
  • 男人毒藥：我在死后第九天來(lái)索命
    文/蒙蒙 一熬芜、第九天 我趴在偏房一處隱蔽的房頂上張望莲镣。 院中可真熱鬧，春花似錦涎拉、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 31,944評(píng)論 0贊 22
  • 一樁弒父案鼓拧，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至越妈，卻和暖如春季俩，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背梅掠。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 33,060評(píng)論 1贊 270
  • 情欲美人皮
    我被黑心中介騙來(lái)泰國(guó)打工酌住， 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人阎抒。 一個(gè)月前我還...
    沈念sama閱讀 48,247評(píng)論 3贊 371
  • 代替公主和親
    正文 我出身青樓酪我，卻偏偏與公主長(zhǎng)得像，于是被迫代替她去往敵國(guó)和親且叁。 傳聞我的和親對(duì)象是個(gè)殘疾皇子都哭，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,979評(píng)論 2贊 355

推薦閱讀更多精彩內(nèi)容

  • 1.這篇文章不是本人原創(chuàng)的，只是個(gè)人為了對(duì)這部分知識(shí)做一個(gè)整理和系統(tǒng)的輸出而編輯成的，在此鄭重地向本文所引用文章的...
    SOMCENT閱讀 13,068評(píng)論 6贊 174
  • 個(gè)人認(rèn)為欺矫，Goodboy1881先生的TCP /IP 協(xié)議詳解學(xué)習(xí)博客系列博客是一部非常精彩的學(xué)習(xí)筆記纱新，這雖然只是...
    貳零壹柒_fc10閱讀 5,054評(píng)論 0贊 8
  • 同樣的，本文篇幅也比較長(zhǎng)穆趴，先來(lái)一張思維導(dǎo)圖脸爱，帶大家過(guò)一遍。 一未妹、 計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)分層 二阅羹、 TCP/IP 基礎(chǔ)...
    滌生_Woo閱讀 65,048評(píng)論 38贊 1,038
  • 協(xié)議基礎(chǔ) 協(xié)議就是計(jì)算機(jī)之間通過(guò)網(wǎng)絡(luò)實(shí)現(xiàn)通信時(shí)實(shí)現(xiàn)所達(dá)成的一種“約定”，這種約定使得那些由不同廠商的設(shè)備教寂，不同的C...
    d9fc24a0c9a9閱讀 2,363評(píng)論 0贊 6
  • 簡(jiǎn)介 用簡(jiǎn)單的話(huà)來(lái)定義tcpdump捏鱼，就是：dump the traffic on a network，根據(jù)使用者...
    保川閱讀 5,956評(píng)論 1贊 13