引言
? ?就目前而言委粉，多數(shù)網(wǎng)絡(luò)編程的系列的文章都在圍繞著計(jì)算機(jī)網(wǎng)絡(luò)體系進(jìn)行闡述呜师，但其中太多理論概念，對(duì)于大部分開發(fā)者而言贾节，用途甚微汁汗。因此，在本系列中則會(huì)以實(shí)際開發(fā)者的工作為核心栗涂，從Java程序員的角度出發(fā)知牌，詳細(xì)解讀Java的網(wǎng)絡(luò)編程核心內(nèi)容。
一斤程、計(jì)算機(jī)網(wǎng)絡(luò)的“前世今生”與基礎(chǔ)概念
? ?先來看看維基百科對(duì)于 計(jì)算機(jī)網(wǎng)絡(luò) 這個(gè)名詞的解釋：
計(jì)算機(jī)網(wǎng)絡(luò)是指將位于不同地理位置角寸，但具有獨(dú)立功能的多臺(tái)設(shè)備，通過通信設(shè)備和線路連接起來忿墅，在網(wǎng)絡(luò)操作系統(tǒng)扁藕，網(wǎng)絡(luò)管理軟件、網(wǎng)絡(luò)通信協(xié)議的協(xié)調(diào)管理下疚脐，實(shí)現(xiàn)資源共享和信息傳遞的計(jì)算機(jī)系統(tǒng)亿柑。
簡(jiǎn)單來說，計(jì)算機(jī)網(wǎng)絡(luò)就是用于滿足不同機(jī)器之間通信棍弄、共享的一種系統(tǒng)望薄。
其實(shí)一開始計(jì)算機(jī)網(wǎng)絡(luò)是用于軍事化目的的，因美國(guó)軍方需要一種多節(jié)點(diǎn)的通信技術(shù)呼畸，確保在其一部分節(jié)點(diǎn)被摧毀后痕支，也能夠確保通信依舊正常，因此組建了一個(gè)部門ARPA并在1966年完成了ARPANET（阿帕網(wǎng)）項(xiàng)目蛮原，該項(xiàng)目也是最早的計(jì)算機(jī)網(wǎng)絡(luò)之一卧须。
? ?當(dāng)然，后續(xù)隨著科技不斷進(jìn)步儒陨，各種網(wǎng)絡(luò)相關(guān)的技術(shù)百家爭(zhēng)鳴花嘶，出現(xiàn)了各式各樣的網(wǎng)絡(luò)技術(shù)，但同時(shí)也帶來了很大的局限性框全，例如：不同的計(jì)算機(jī)網(wǎng)絡(luò)之間并不能相互通信察绷、不同操作系統(tǒng)之間無(wú)法通信、覆蓋范圍及其有限等津辩。因此拆撼，ARPA需要一種技術(shù)將不同的計(jì)算機(jī)局域網(wǎng)互聯(lián)，最終ARPA組織創(chuàng)建了一個(gè)新的項(xiàng)目被稱為internetwork因特網(wǎng)喘沿，也被稱為“互聯(lián)網(wǎng)”闸度。
? ?在internetwork項(xiàng)目的研發(fā)過程中，1974年蚜印，Robert E. Kahn以及Vinton G. Cerf兩位教授正式提出了新的傳輸協(xié)議：TCP/IP協(xié)議莺禁，用于滿足不同計(jì)算機(jī)網(wǎng)絡(luò)之間的互聯(lián)通信，ARPA到1982年接受TCP/IP選定為Internet主要的計(jì)算機(jī)通信系統(tǒng)窄赋，作為因特網(wǎng)通信的“基石”哟冬。
1.1楼熄、計(jì)算機(jī)網(wǎng)絡(luò)的組成
從組成上而言，計(jì)算機(jī)網(wǎng)絡(luò)主要由主機(jī)浩峡、協(xié)議可岂、傳輸介質(zhì)以及軟件四部分組成。
- 主機(jī)：可以是手機(jī)翰灾、電腦缕粹、服務(wù)器、電子手表等任意計(jì)算機(jī)硬件纸淮。
- 協(xié)議：各類定義歸法的網(wǎng)絡(luò)通信協(xié)議平斩，如
TCP/IP、IPX/SPX咽块、AppleTalk等绘面。 - 傳輸介質(zhì)：傳輸數(shù)據(jù)的通道，可以是實(shí)體銅線糜芳、電纜飒货、光纖，也可以是無(wú)形的電磁波空間介質(zhì)峭竣。
- 軟件：涵蓋所有聯(lián)網(wǎng)的應(yīng)用塘辅，如QQ、微信皆撩、支付寶扣墩、淘寶、京東等各類軟件扛吞。
1.2呻惕、計(jì)算機(jī)網(wǎng)絡(luò)的功能組成
計(jì)算機(jī)網(wǎng)絡(luò)體系主要提供的兩個(gè)核心功能就在于：
- 資源共享：資源子網(wǎng)實(shí)現(xiàn)。
- 數(shù)據(jù)通信：通信子網(wǎng)實(shí)現(xiàn)滥比。
資源子網(wǎng)以及通信子網(wǎng)也對(duì)應(yīng)著OSI中的上三層和下三層亚脆。
? ?不過如果學(xué)習(xí)過計(jì)算機(jī)網(wǎng)絡(luò)課程的小伙伴應(yīng)該都知道，其實(shí)計(jì)算機(jī)網(wǎng)絡(luò)是一個(gè)復(fù)雜而龐大的系統(tǒng)盲泛，由軟件濒持、驅(qū)動(dòng)硼婿、硬件不见、線路等多部門共同組成，但對(duì)于這些理論性內(nèi)容不再闡述泊愧，有興趣的可以自行了解村视。
1.3官套、網(wǎng)絡(luò)分層與OSI七層模型的由來
? ?計(jì)算機(jī)網(wǎng)絡(luò)是個(gè)非常復(fù)雜的系統(tǒng)，由于最初各個(gè)計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)不同，導(dǎo)致雙方網(wǎng)絡(luò)之間無(wú)法互通奶赔，因此惋嚎，20世紀(jì)90年代，ISO國(guó)際標(biāo)準(zhǔn)化推出了OSI模型打算制定計(jì)算機(jī)網(wǎng)絡(luò)體系標(biāo)準(zhǔn)纺阔。
簡(jiǎn)單來說就類似于國(guó)內(nèi)的普通話瘸彤，因?yàn)椴煌》莸姆窖圆煌奕唬瑢?dǎo)致不同地方的人交流起來并不方便笛钝，因此定義了“普通話”這一標(biāo)準(zhǔn)，所有人都遵循該標(biāo)準(zhǔn)進(jìn)行交流溝通愕宋。
? ?但由ISO組織制定的OSI網(wǎng)絡(luò)七層模型結(jié)構(gòu)并沒有得到廣泛應(yīng)用玻靡，實(shí)際中應(yīng)用最廣泛的是TCP/IP體系結(jié)構(gòu)。換句話說中贝，OSI七層模型只是理論上官方制定的國(guó)際標(biāo)準(zhǔn)囤捻，而TCP/IP體系結(jié)構(gòu)才是事實(shí)上的國(guó)際標(biāo)準(zhǔn)。
PS：國(guó)際標(biāo)準(zhǔn)化組織提出的
OSI模型未得到廣泛應(yīng)用的原因：
①制定時(shí)太過理想化邻寿，未考慮實(shí)際的應(yīng)用場(chǎng)景蝎土。
②拆分過于精細(xì)化，實(shí)現(xiàn)起來過于復(fù)雜绣否，運(yùn)行效率并不高誊涯。
③OSI體系的制定周期過長(zhǎng)，導(dǎo)致按其標(biāo)準(zhǔn)生產(chǎn)的設(shè)備無(wú)法及時(shí)投入市場(chǎng)搶占份額蒜撮。
④OSI體系因?yàn)榉謱舆^多暴构，設(shè)計(jì)也不合理，有些相同的功能在多個(gè)層次重復(fù)出現(xiàn)段磨。
? ?但因?yàn)?code>TCP/IP體系中的最后一層沒有制定規(guī)范的標(biāo)準(zhǔn)取逾，所以對(duì)于學(xué)習(xí)計(jì)算機(jī)網(wǎng)絡(luò)完善體系時(shí)會(huì)缺失一部分，所以又提出了一種折中方案苹支，也就是綜合OSI以及TCP/IP兩個(gè)體系的優(yōu)缺點(diǎn)砾隅，提出了一種五層結(jié)構(gòu)的原理體系，因此在接觸計(jì)算機(jī)網(wǎng)絡(luò)體系時(shí)债蜜，通常都會(huì)存在三種分層結(jié)構(gòu)：
- 法定標(biāo)準(zhǔn)體系：
OSI七層結(jié)構(gòu)晴埂。 - 實(shí)際應(yīng)用體系：
TCP/IP四層結(jié)構(gòu)。 - 原理教學(xué)體系：五層結(jié)構(gòu)策幼。
二邑时、OSI七層網(wǎng)絡(luò)模型與TCP/IP協(xié)議簇
? ?計(jì)算機(jī)網(wǎng)絡(luò)體系采用的是分層結(jié)構(gòu)，每個(gè)層次之間互不干擾特姐，上層不需要關(guān)心下層的具體實(shí)現(xiàn)晶丘，下層只需要為上層提供服務(wù)即可。
在
ISO組織定義的國(guó)際標(biāo)準(zhǔn)OSI模型中，是七層網(wǎng)絡(luò)模型浅浮。
在實(shí)際應(yīng)用最廣泛的TCP/IP模型中沫浆，是四層網(wǎng)絡(luò)模型。
當(dāng)然滚秩，在計(jì)算機(jī)網(wǎng)絡(luò)教學(xué)中专执，也提出了五層網(wǎng)絡(luò)模型。
但無(wú)論多少層網(wǎng)絡(luò)模型郁油，其實(shí)本質(zhì)上都是在敘述相同的內(nèi)容本股，只不過拆分的精細(xì)度不同而已，三種網(wǎng)絡(luò)模型對(duì)應(yīng)如下：
2.1桐腌、OSI七層網(wǎng)絡(luò)模型
OSI七層網(wǎng)絡(luò)模型中拄显，每層的功能如下：
- 應(yīng)用層：人與計(jì)算機(jī)網(wǎng)絡(luò)交互的窗口。
- 表示層：負(fù)責(zé)數(shù)據(jù)格式的封裝案站，如加密躬审、壓縮、編解碼等蟆盐。
- 會(huì)話層：建立承边、終止、管理不同端間的會(huì)話連接石挂。
- 傳輸層：提供端到端（兩臺(tái)機(jī)器）之間的傳輸機(jī)制博助，以及提供流量控制、出錯(cuò)效驗(yàn)誊稚。
- 網(wǎng)絡(luò)層：邏輯尋址翔始，IP地址，在下兩層的基礎(chǔ)上向資源子網(wǎng)提供服務(wù)里伯。
- 數(shù)據(jù)鏈路層：負(fù)責(zé)建立和管理節(jié)點(diǎn)間的鏈路城瞎，將數(shù)據(jù)封裝成幀，進(jìn)行可靠傳輸疾瓮。
- 物理層：在介質(zhì)媒體上傳輸比特流脖镀。
在TCP/IP體系中，將原本OSI體系中的應(yīng)用層狼电、表示層蜒灰、會(huì)話層合并為了應(yīng)用層，將數(shù)據(jù)鏈路層和物理層合并為了數(shù)據(jù)鏈路層肩碟，因此TCP/IP體系中只存在四層結(jié)構(gòu)强窖。
注意點(diǎn)：在最初因?yàn)榧夹g(shù)問題，因此數(shù)據(jù)傳輸必須建立在物理實(shí)體介質(zhì)的基礎(chǔ)之上削祈，但如今無(wú)線電的電磁波技術(shù)也可以做到利用空氣作為介質(zhì)翅溺，從而達(dá)到傳輸數(shù)據(jù)的目的脑漫。
在OSI分層體系中，上三層：應(yīng)用層咙崎、表示層优幸、會(huì)話層組成資源子網(wǎng)，下三層：網(wǎng)絡(luò)層褪猛、數(shù)據(jù)鏈路層网杆、物理層組成通信子網(wǎng)。
2.1.1伊滋、OSI模型的通信的封裝與解析過程
? ?在網(wǎng)絡(luò)通信中碳却，通信雙方都必須是對(duì)等的，并且雙方都遵守相同協(xié)議的新啼，這樣才可通信追城。好比舉個(gè)例子：
竹子想發(fā)微信信息給熊貓，喊熊貓出來玩燥撞，但雙方之間的通信基礎(chǔ)必須對(duì)等，也就是說迷帜，熊貓的手機(jī)上也必須要安裝了微信物舒，否則竹子無(wú)法通過微信與熊貓出來玩。
但如果竹子說的是漢語(yǔ)戏锹，熊貓只能懂漢語(yǔ)冠胯，雙方并未遵守相同的“協(xié)議”，那兩者之間自然也無(wú)法進(jìn)行通信锦针。因此荠察，通信的另一要素則是：通信雙方都必須遵守相同的協(xié)議。
而在計(jì)算機(jī)網(wǎng)絡(luò)中奈搜，當(dāng)兩臺(tái)機(jī)器進(jìn)行通信時(shí)悉盆，其過程主要包含數(shù)據(jù)的封裝與解封：
? ?如上圖，左側(cè)是發(fā)送端馋吗，右側(cè)是接收端焕盟，當(dāng)發(fā)送端的應(yīng)用嘗試傳輸一條數(shù)據(jù)時(shí)，數(shù)據(jù)會(huì)根據(jù)網(wǎng)絡(luò)分層結(jié)構(gòu)宏粤，從上至下依次封裝脚翘，每層都對(duì)數(shù)據(jù)做一定的處理，最后在物理層轉(zhuǎn)換為比特流（二進(jìn)制數(shù)據(jù)）绍哎，然后傳輸至接收端来农。
? ?因?yàn)殡p方之間遵守的都是相同的協(xié)議體系（網(wǎng)絡(luò)模型），因此接收端會(huì)首先接收到比特流數(shù)據(jù)崇堰，然后從下至上依次解封數(shù)據(jù)沃于，最終在應(yīng)用層還原數(shù)據(jù)，從而達(dá)到通信的目的。
2.2揽涮、TCP/IP協(xié)議簇
? ?TCP/IP應(yīng)該是計(jì)算機(jī)網(wǎng)絡(luò)中聽的次數(shù)最多的詞匯抠藕，但它并非單純的指TCP和IP兩個(gè)協(xié)議，而是一組協(xié)議的代名詞蒋困，指由許許多多的網(wǎng)絡(luò)協(xié)議一同組成的“協(xié)議簇”盾似，TCP/IP協(xié)議簇主要組成如下：
上面列出了一些
TCP/IP協(xié)議簇中常用的一些協(xié)議，但整個(gè)協(xié)議簇是由大大小小上百個(gè)協(xié)議一同組成的（對(duì)于TCP/IP協(xié)議簇中的一些常用協(xié)議可參考：百度百科）雪标。? ?在計(jì)算機(jī)網(wǎng)絡(luò)體系中零院，每層都會(huì)存在多個(gè)協(xié)議，但一個(gè)協(xié)議只會(huì)隸屬于一層村刨。同時(shí)告抄，協(xié)議也可以由軟件、硬件兩個(gè)維度來實(shí)現(xiàn)嵌牺。
除開最常見的TCP/IP協(xié)議簇外打洼，還有一些其他的協(xié)議組，如
IPX/SPX逆粹、NetBEUI募疮、AppleTalk等協(xié)議組。
2.2.1僻弹、通信協(xié)議的基本概念
? ?前面的敘述中阿浓，更偏向于“空中樓閣”般的理論概念，比較生澀難懂蹋绽，接下來我們以實(shí)際的TCP/IP協(xié)議出發(fā)芭毙，再對(duì)計(jì)算機(jī)網(wǎng)絡(luò)更進(jìn)一步闡述。
? ?TCP/IP通信協(xié)議是最完整卸耘、使用最廣泛的網(wǎng)絡(luò)協(xié)議體系退敦，它的魅力在于可使不同硬件結(jié)構(gòu)，不同操作系統(tǒng)的計(jì)算機(jī)相互通信鹊奖，通信協(xié)議中定義多方之間發(fā)送/接收的報(bào)文格式苛聘、順序以及規(guī)則，其中語(yǔ)法定義了傳輸?shù)膱?bào)文格式忠聚，語(yǔ)義定義了報(bào)文傳輸規(guī)則设哗，時(shí)序定義了報(bào)文傳輸順序，計(jì)算機(jī)通信的本質(zhì)就在于信息報(bào)文的相互交換两蟀。
2.2.2网梢、協(xié)議數(shù)據(jù)單元(PDU)
? ?計(jì)算機(jī)網(wǎng)絡(luò)體系中，不同節(jié)點(diǎn)通信時(shí)交換的信息報(bào)文被稱為協(xié)議數(shù)據(jù)單元（PDU）赂毯，PDU主要由協(xié)議頭信息+數(shù)據(jù)（SDU）組成战虏，數(shù)據(jù)是指發(fā)送端需要傳輸給接收端的信息拣宰，而協(xié)議頭信息中，則包含了完成傳輸所需的控制信息烦感，如地址巡社、長(zhǎng)度、序號(hào)手趣、分段標(biāo)識(shí)晌该、差錯(cuò)控制信息等。
? ?基于TCP/IP體系而言绿渣，PDU在不同層存在不同的稱呼朝群，如下圖：
2.3、計(jì)算機(jī)網(wǎng)絡(luò)體系中各層綜述
? ?就目前而言中符，前面的闡述中已經(jīng)將計(jì)算機(jī)網(wǎng)絡(luò)中最常見的OSI姜胖、TCP/IP體系簡(jiǎn)單介紹明白了，但對(duì)于這些體系中淀散，不同層的具體作用卻并沒有進(jìn)行探討右莱。因此，接下來我們從自己設(shè)計(jì)一個(gè)計(jì)算機(jī)網(wǎng)絡(luò)體系的角度出發(fā)吧凉，分別來探討網(wǎng)絡(luò)分層的必要性與每個(gè)分層的具體含義隧出。
2.3.1、物理層
先來看最簡(jiǎn)單的通信模型：
如上圖阀捅，兩臺(tái)電腦之間通物理媒體連接，互相傳遞信息针余，從而達(dá)到通信的目的饲鄙。
在這種最簡(jiǎn)單的直連通信模型中，想要實(shí)現(xiàn)雙方之間的通信圆雁，那應(yīng)該考慮如下幾個(gè)問題：
- ①連接兩臺(tái)電腦之間的傳輸媒體可以采用哪些介質(zhì)類型忍级。
- ②連接兩臺(tái)電腦時(shí)，兩臺(tái)電腦應(yīng)該存在怎樣的物理接口伪朽。
- ③傳輸數(shù)據(jù)時(shí)轴咱，使用何種信號(hào)表達(dá)比特流中的
0和1。 - ④雙方之間通信時(shí)烈涮，不同的傳輸介質(zhì)朴肺，數(shù)據(jù)傳輸?shù)乃俣葮?biāo)準(zhǔn)又該是多少。
對(duì)于如上問題坚洽，我們可以將其全部歸納到“物理層”來解決戈稿，在該層中定義標(biāo)準(zhǔn)規(guī)范。
簡(jiǎn)單來說讶舰，物理層主要任務(wù)是負(fù)責(zé)在介質(zhì)上正確的傳送比特流鞍盗，并規(guī)定物理接口的各種特性和物理設(shè)備的標(biāo)準(zhǔn)需了，如網(wǎng)線的接口類型、光纖的接口類型般甲、各種傳輸介質(zhì)的傳輸速率等肋乍。
2.3.2、數(shù)據(jù)鏈路層
但一般現(xiàn)在不會(huì)存在直連型網(wǎng)絡(luò)敷存，常用的計(jì)算機(jī)網(wǎng)絡(luò)都是由多臺(tái)機(jī)器共同組成的墓造，如下：
在這種總線連接的通信模型中，當(dāng)一臺(tái)主機(jī)历帚，比如
A向D發(fā)送數(shù)據(jù)時(shí)滔岳，數(shù)據(jù)會(huì)通過總線傳輸至總線上的所有主機(jī)，此時(shí)D如何知道該條數(shù)據(jù)是發(fā)給自己的呢挽牢？其他主機(jī)又如何區(qū)分?jǐn)?shù)據(jù)不是發(fā)給自己的呢谱煤？因此，對(duì)于這種多臺(tái)機(jī)器組成的網(wǎng)絡(luò)模型而言禽拔，我們也需要解決一系列問題刘离，如：
- ①編址問題：如何區(qū)分總線上的各主機(jī)（如
MAC地址），在發(fā)送數(shù)據(jù)時(shí)睹栖，帶上目標(biāo)主機(jī)的地址硫惕，其他主機(jī)根據(jù)數(shù)據(jù)中的目標(biāo)地址確認(rèn)是否是發(fā)給自己的。 - ②當(dāng)其他主機(jī)收到傳遞的數(shù)據(jù)后野来，如何從比特流中正確區(qū)分出數(shù)據(jù)和目的地址恼除。
- ③當(dāng)同時(shí)多臺(tái)主機(jī)共用主線時(shí)，如何協(xié)調(diào)各主機(jī)競(jìng)爭(zhēng)總線曼氛，避免數(shù)據(jù)發(fā)生碰撞豁辉。
對(duì)于上述中的這些問題，可以全部劃歸到鏈路層處理舀患。
因此可以得出徽级，數(shù)據(jù)鏈路層主要任務(wù)是實(shí)現(xiàn)數(shù)據(jù)在不可靠的物理線路上的可靠傳遞，負(fù)責(zé)提供物理地址尋址聊浅、數(shù)據(jù)的成幀餐抢、流量控制、差錯(cuò)控制等功能低匙，確保數(shù)據(jù)的可靠傳輸旷痕。
PS：對(duì)于這種總線型網(wǎng)絡(luò)早已淘汰，目前常用的則是以太網(wǎng)的交換式通信模型：
交換式通信模型
2.3.3努咐、網(wǎng)絡(luò)層
到目前為止苦蒿，解決了物理層及鏈路層中的問題后，就可以實(shí)現(xiàn)數(shù)據(jù)在一個(gè)局域網(wǎng)絡(luò)中的傳輸了渗稍。但實(shí)際每天都接觸的因特網(wǎng)是由無(wú)數(shù)個(gè)小網(wǎng)絡(luò)和路由器互連組成的佩迟，如下：
因此只解決前面所敘述的問題還是無(wú)法在龐大的計(jì)算機(jī)網(wǎng)絡(luò)中實(shí)現(xiàn)通信团滥，畢竟之前因?yàn)橹挥幸粋€(gè)網(wǎng)絡(luò)，所以不需要對(duì)網(wǎng)絡(luò)進(jìn)行標(biāo)識(shí)报强。但在這種廣域網(wǎng)模型中灸姊，會(huì)存在大大小小無(wú)數(shù)個(gè)局域網(wǎng)，所以想要從一臺(tái)主機(jī)將數(shù)據(jù)傳輸給另一臺(tái)主機(jī)時(shí)秉溉，此時(shí)又該如何精準(zhǔn)定位到某個(gè)網(wǎng)絡(luò)中的具體主機(jī)呢力惯？因此又產(chǎn)生了一系列的問題需要加以解決：
- ①如何標(biāo)識(shí)各個(gè)網(wǎng)絡(luò)及網(wǎng)絡(luò)中的主機(jī)（網(wǎng)絡(luò)和主機(jī)共同編址問題，如IP地址）召嘶。
- ②一臺(tái)主機(jī)向另一臺(tái)主機(jī)發(fā)送數(shù)據(jù)時(shí)父晶，在廣域網(wǎng)中往往存在多條鏈路可走，此時(shí)如何選擇最合適的路由弄跌。
而對(duì)于這些問題我們都可以劃歸到網(wǎng)絡(luò)層處理甲喝。
所以，網(wǎng)絡(luò)層主要負(fù)責(zé)將網(wǎng)絡(luò)地址翻譯成對(duì)應(yīng)的物理地址铛只，并通過路由選擇算法為數(shù)據(jù)的傳輸選擇最適當(dāng)?shù)穆窂?/strong>埠胖。
路由選擇：路由主要包括路由表和路由算法兩個(gè)方面，網(wǎng)絡(luò)層會(huì)根據(jù)速度淳玩、距離(步跳數(shù))直撤、價(jià)格及網(wǎng)絡(luò)擁塞程度等因素，在路由表的多條通信路徑中找一條最佳路徑蜕着。
2.3.4谋竖、傳輸層
至此，如果解決了物理層承匣、鏈路層及網(wǎng)絡(luò)層的問題圈盔，數(shù)據(jù)就可以做到在不同的網(wǎng)絡(luò)中進(jìn)行通信。但這對(duì)于普通用戶而言仍然不夠悄雅，因?yàn)橐慌_(tái)主機(jī)上會(huì)安裝多個(gè)應(yīng)用程序，好比：
主機(jī)A上安裝了QQ铁蹈、微信宽闲、谷歌瀏覽器，當(dāng)另一臺(tái)主機(jī)向主機(jī)A發(fā)送數(shù)據(jù)時(shí)握牧，那這些數(shù)據(jù)到底應(yīng)該交給主機(jī)上的哪個(gè)進(jìn)程處理呢容诬？
因此還需要解決：
- ①如何解決進(jìn)程之間基于網(wǎng)絡(luò)的通信問題，如何標(biāo)識(shí)網(wǎng)絡(luò)通信相關(guān)的進(jìn)程沿腰。
- ②如果數(shù)據(jù)在傳輸過程中出現(xiàn)丟包览徒、誤碼等傳輸錯(cuò)誤，又該如何處理颂龙。
這些問題可以被劃歸到傳輸層加以解決习蓬。
? ?基于OSI模型而言纽什，上三層資源子網(wǎng)主要負(fù)責(zé)用戶數(shù)據(jù)處理帚称，下三層通信子網(wǎng)主要負(fù)責(zé)數(shù)據(jù)通信则涯，而傳輸層位于OSI模型中的第四層拔稳，是資源子網(wǎng)與通信子網(wǎng)之間的橋梁究履，因此酷宵，無(wú)論是在OSI亦或TCP/IP體系中膛腐，傳輸層都是至關(guān)重要的一層铡俐。
傳輸層的主要功能是：提供端到端之間的傳輸機(jī)制以及提供差錯(cuò)效驗(yàn)和流量控制结蟋，保證報(bào)文的正確傳輸或听。 在TCP/IP體系中探孝，主要提供了兩種傳輸服務(wù)：
- “面向連接”的
TCP可靠傳輸協(xié)議。 - “面向無(wú)連接”的
UDP不可靠傳輸協(xié)議誉裆。
2.3.5顿颅、應(yīng)用層
? ?應(yīng)用層無(wú)論是在OSI亦或TCP/IP模型中，都是位于最高層找御，它是用戶元镀、各種應(yīng)用程序和網(wǎng)絡(luò)之間的接口，其功能是直接向用戶提供服務(wù)霎桅，并完成用戶在網(wǎng)絡(luò)中的各種操作栖疑，應(yīng)用層為用戶提供的服務(wù)范圍涵蓋：文件目錄服務(wù)、文件傳輸服務(wù)滔驶、遠(yuǎn)程登錄服務(wù)遇革、電子郵箱服務(wù)、打印服務(wù)揭糕、網(wǎng)絡(luò)管理服務(wù)萝快、安全服務(wù)、域名管理服務(wù)等著角，這些服務(wù)由應(yīng)用層中各種協(xié)議及應(yīng)用程序提供揪漩。
TCP/IP體系中將資源子網(wǎng)都合并為了應(yīng)用層，但在OSI模型中吏口，資源子網(wǎng)是分為應(yīng)用層奄容、表示層、會(huì)話層三個(gè)層次的产徊，也就是拆分粒度更精細(xì)化昂勒，服務(wù)也更為精細(xì)化。
2.3.5.1舟铜、OSI-表示層
? ?主要負(fù)責(zé)應(yīng)用層的用戶數(shù)據(jù)處理戈盈，例如數(shù)據(jù)編/解碼、數(shù)據(jù)的加密解密谆刨、數(shù)據(jù)壓縮塘娶、數(shù)據(jù)格式處理等归斤，其作用如其名，主要處理用戶信息的表示問題血柳。
2.3.5.2官册、OSI-會(huì)話層
? ?會(huì)話層位于OSI模型的第五層，是用戶應(yīng)用程序和網(wǎng)絡(luò)之間的接點(diǎn)难捌，主要負(fù)責(zé)網(wǎng)絡(luò)中的兩節(jié)點(diǎn)間建立膝宁、管理和終止通信。會(huì)話層的功能涵蓋：建立通信鏈接根吁、保持會(huì)話過程员淫、維持通信鏈接的暢通、同步節(jié)點(diǎn)間的對(duì)話信息击敌、決定通信是否終止以及通信中斷時(shí)決定從何處重新發(fā)送介返。
簡(jiǎn)單而言，應(yīng)用層主要是為用戶與網(wǎng)絡(luò)之間沃斤，提供各類可“接觸”的窗口圣蝎。
2.3.6、TCP/IP體系中數(shù)據(jù)的通信過程
與之前的OSI模型的通信過程相同衡瓶，TCP/IP體系中徘公，一端想往另一端傳輸數(shù)據(jù)時(shí)，數(shù)據(jù)也會(huì)經(jīng)歷封裝與解封的過程哮针，數(shù)據(jù)經(jīng)過每一層時(shí)都會(huì)加入當(dāng)前層的協(xié)議信息关面，從而形成本層的PDU，繼而向下傳遞十厢，直到最終被轉(zhuǎn)換為比特流數(shù)據(jù)等太，通過傳輸介質(zhì)轉(zhuǎn)換為信號(hào)傳輸?shù)搅硪欢耍硪欢私邮盏街髣t會(huì)依次解封數(shù)據(jù)蛮放，過程如下：
同比生活缩抡，也就是類似收發(fā)快遞的過程：
- 發(fā)件：[發(fā)件人]→[貨物]→[驛站]→[快遞公司站點(diǎn)]
- 傳輸介質(zhì)：[運(yùn)輸路線]→[中轉(zhuǎn)站]
- 收件：[快遞公司站點(diǎn)]→[驛站]→[貨物]→[收件人]
2.3.7、計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)總結(jié)
? ?到目前為止包颁，計(jì)算機(jī)網(wǎng)絡(luò)中一些比較重要的基礎(chǔ)概念已介紹完畢缝其，前面的論述中，從計(jì)算機(jī)網(wǎng)絡(luò)的誕生徘六，到法定的OSI標(biāo)準(zhǔn)體系以及TCP/IP體系進(jìn)行了簡(jiǎn)單分析，對(duì)于開發(fā)者而言榴都，這些基礎(chǔ)知識(shí)了解即可待锈，想要深入學(xué)習(xí)的小伙伴可觀看《湖科大的計(jì)算機(jī)網(wǎng)絡(luò)視頻教學(xué)》，講的比較透徹切通俗易懂嘴高。
三竿音、IP網(wǎng)絡(luò)協(xié)議與TCP和屎、UDP網(wǎng)絡(luò)傳輸層協(xié)議
? ?前面更多的在敘述計(jì)算機(jī)網(wǎng)絡(luò)的整體的結(jié)構(gòu)，接下來則準(zhǔn)備對(duì)計(jì)算機(jī)網(wǎng)絡(luò)中幾個(gè)常見的網(wǎng)絡(luò)協(xié)議進(jìn)行闡述春瞬，如IP柴信、TCP、UDP等協(xié)議（HTTP宽气、HTTPS放在下章講解）随常。
3.1、IP協(xié)議
? ?當(dāng)應(yīng)用層的數(shù)據(jù)被封裝后萄涯，想要將數(shù)據(jù)在網(wǎng)絡(luò)上傳輸绪氛，數(shù)據(jù)究竟要被發(fā)往何處，又該如何精準(zhǔn)的在網(wǎng)絡(luò)上定位目標(biāo)機(jī)器涝影，此時(shí)起到關(guān)鍵作用的就是“IP協(xié)議”枣察。
? ?IP協(xié)議的作用在于把各種數(shù)據(jù)包準(zhǔn)確無(wú)誤的傳遞給目標(biāo)方，其中兩個(gè)重要的條件是IP地址和MAC地址燃逻。其中IP地址就是所有主機(jī)在網(wǎng)絡(luò)通信中的唯一標(biāo)識(shí)序目，但由于IP地址是稀有資源，不可能每個(gè)主機(jī)都擁有一個(gè)IP地址伯襟，因此路由器里面會(huì)記錄我們主機(jī)的MAC地址猿涨，通常的IP地址是路由器根據(jù)MAC地址生成的，而MAC地址是全球唯一的逗旁。
舉例：IP地址就如同是物流線路上的驛站地址嘿辟，而MAC地址就是具體貨架上貨物的位置。
之前的IP地址采用的IPv4格式片效，目前大部分主機(jī)都已向IPv6過渡红伦。
3.1.1、IP地址的組成與分類
? ?IP地址一般由網(wǎng)絡(luò)標(biāo)識(shí)(NetID)和主機(jī)標(biāo)識(shí)(HostID) 兩部分組成淀衣，其中網(wǎng)絡(luò)標(biāo)識(shí)對(duì)應(yīng)著網(wǎng)絡(luò)地址昙读，表示其局域網(wǎng)屬于互聯(lián)網(wǎng)中的哪一個(gè)網(wǎng)絡(luò)；主機(jī)標(biāo)識(shí)對(duì)應(yīng)著一臺(tái)機(jī)器的主機(jī)地址膨桥，表示機(jī)器屬于該局域網(wǎng)絡(luò)中的哪一臺(tái)主機(jī)蛮浑。
? ?通常情況下，一個(gè)IP存在四組數(shù)字只嚣，每組數(shù)字對(duì)應(yīng)著八位二進(jìn)制數(shù)字（一個(gè)IP地址共計(jì)32Bit）沮稚，每組之間分別用.隔開，其中不同類型的IP地址册舞，表示網(wǎng)絡(luò)標(biāo)識(shí)和主機(jī)標(biāo)識(shí)的數(shù)字段也不同蕴掏，目前的IP地址主要可分為A、B、C盛杰、D、E五大類定拟，如下：
A類IP
A類地址由8位網(wǎng)絡(luò)標(biāo)識(shí)+24位主機(jī)標(biāo)識(shí)組成青自，也就是之前的四組數(shù)字中雷滚，第一組表示網(wǎng)絡(luò)地址，而后三組代表主機(jī)地址。網(wǎng)絡(luò)地址的最高位，即首位必須為0，其中0和127都為保留位，因此A類IP的網(wǎng)絡(luò)地址范圍為1~126(1.0.0.0~126.0.0.0)，也就代表著可用的A類網(wǎng)絡(luò)有126個(gè)，每個(gè)網(wǎng)絡(luò)中最大可容納一千多萬(wàn)臺(tái)主機(jī)（224-2）孽文。
PS：為什么
A類網(wǎng)絡(luò)的地址范圍是1~126呢郁副？
因?yàn)?code>A類IP中用8bit表示網(wǎng)絡(luò)標(biāo)識(shí)既荚，首位需要保留為0晴叨，因此剩下的7bit能夠表示的最大數(shù)字為127件蚕，末位127也需保留，因此A類網(wǎng)絡(luò)地址的取值范圍為1~126。
示意圖如下：
例如32.44.128.5這個(gè)地址皆怕，其中第一段代表網(wǎng)絡(luò)地址虱黄，剩余三段表示網(wǎng)絡(luò)中的主機(jī)地址。
B類IP
B類地址由16位網(wǎng)絡(luò)標(biāo)識(shí)+16位主機(jī)標(biāo)識(shí)組成泳叠，因此IP中第一段和第二段都為網(wǎng)絡(luò)標(biāo)識(shí)作瞄，其中前兩位為保留位1宗挥、0属韧，因此B類IP的網(wǎng)絡(luò)地址取值范圍為128~191(128.0.0.0~191.255.0.0)，總計(jì)可用的B類網(wǎng)絡(luò)數(shù)量為16382個(gè)退渗，每個(gè)網(wǎng)絡(luò)中可容納6萬(wàn)多臺(tái)主機(jī)（216-2）移稳。B類IP組成示意圖如下：
例如
128.123.11.32這個(gè)地址，其中前兩段為網(wǎng)絡(luò)地址翻翩，后兩段表示網(wǎng)絡(luò)中的主機(jī)地址都许。
C類IP
C類地址由24位網(wǎng)絡(luò)標(biāo)識(shí)+8位主機(jī)標(biāo)識(shí)組成稻薇，也就是說，整個(gè)IP地址中胶征，前三段都為網(wǎng)絡(luò)地址塞椎，最后一段為主機(jī)地址。C類地址中睛低，前三位都為保留位忱屑，即C類網(wǎng)絡(luò)的最高位必須為1、1暇昂、0，因此C類網(wǎng)絡(luò)地址的取值范圍為192-223(192.0.0.0~223.255.255.0)伴嗡，粗略計(jì)算下來急波，C類網(wǎng)絡(luò)的數(shù)量可達(dá)209萬(wàn)左右，每個(gè)網(wǎng)絡(luò)中允許存在254臺(tái)主機(jī)（28-2）瘪校，組成示意如下：
如
192.0.0.121這個(gè)IP澄暮，前三段為網(wǎng)絡(luò)地址，最后一段則為網(wǎng)絡(luò)中的主機(jī)地址阱扬。
D類IP
D類和后續(xù)的E類屬于特殊的IP地址泣懊，D類地址被稱為廣播或組播地址，其最高位必須是1麻惶、1馍刮、1、0窃蹋，因此取值范圍為224~239(224.0.0.0~239.255.255.255)卡啰，如下：
E類IP
E類地址則屬于保留的地址，為以后接入更多的網(wǎng)絡(luò)預(yù)留的IP警没，其最高位必須為1匈辱、1、1杀迹、1亡脸，即E類IP第一段的取值范圍為240~255(240.0.0.255~239.255.255.254)：
但255.255.255.255這個(gè)全1的IP屬于特殊含義的地址，表示當(dāng)前子網(wǎng)的廣播地址树酪，如同全0的IP：0.0.0.0代表本機(jī)地址一樣浅碾，帶有特殊的含義。
IP分類小結(jié)
? ?因不同類型的網(wǎng)絡(luò)IP規(guī)模不同嗅回，所以它們也分別應(yīng)用于不同的場(chǎng)景及穗，如：
- ①
A類IP適用于大型網(wǎng)絡(luò)，由于單個(gè)網(wǎng)絡(luò)中可容納的主機(jī)數(shù)非常巨大绵载，因此常被保留給政府機(jī)構(gòu)使用埂陆。 - ②
B類IP適用于中型網(wǎng)絡(luò)苛白，一般會(huì)被分配給公益組織、中大型企業(yè)等焚虱。 - ③
C類IP適用于小型網(wǎng)絡(luò)购裙，這種IP適用于所有需要網(wǎng)絡(luò)的個(gè)體和小集體，如網(wǎng)吧鹃栽、家庭躏率、個(gè)人電腦等。 - ④
D類IP用于組播民鼓。 - ⑤
E類IP用于保留和實(shí)驗(yàn)薇芝。
3.1.2、子網(wǎng)掩碼
? ?子網(wǎng)掩碼又被稱為網(wǎng)絡(luò)掩碼丰嘉、地址掩碼夯到、子網(wǎng)絡(luò)遮罩，它的作用主要有兩個(gè)：
- 一饮亏、區(qū)分
IP中網(wǎng)絡(luò)地址和主機(jī)地址耍贾。 - 二、劃分子網(wǎng)路幸，擴(kuò)大網(wǎng)段內(nèi)的可用
IP數(shù)目荐开。
但默認(rèn)的子網(wǎng)掩碼值也并非都相同，不同的網(wǎng)絡(luò)類型存在不同的默認(rèn)掩碼简肴，如：
-
A類網(wǎng)絡(luò)的默認(rèn)子網(wǎng)掩碼：255.0.0.0 -
B類網(wǎng)絡(luò)的默認(rèn)子網(wǎng)掩碼：255.255.0.0 -
C類網(wǎng)絡(luò)的默認(rèn)子網(wǎng)掩碼：255.255.255.0
一個(gè)子網(wǎng)掩碼決定著一個(gè)子網(wǎng)（獨(dú)立的單個(gè)網(wǎng)絡(luò)）內(nèi)可容納的主機(jī)數(shù)量晃听，計(jì)算公式為：可容納的主機(jī)數(shù)量=(2的n次方)-2。這個(gè)n可以理解為二進(jìn)制掩碼中0的數(shù)量着帽，例如：
- A類默認(rèn)掩碼：
255.0.0.0轉(zhuǎn)換為二進(jìn)制為：11111111.00000000.00000000.00000000杂伟，后面有24個(gè)0，因此可容納的主機(jī)數(shù)量為(2的24次方)-2仍翰，即16777214臺(tái)主機(jī)赫粥。 - C類默認(rèn)掩碼：
255.255.255.0轉(zhuǎn)換為二進(jìn)制為：11111111.11111111.11111111.00000000，后面存在8個(gè)0予借，因此C類網(wǎng)可容納主機(jī)數(shù)量為(2的8次方)-2越平，即254臺(tái)主機(jī)。
修改子網(wǎng)掩碼為局域網(wǎng)擴(kuò)容
? ?在中型企業(yè)中灵迫，經(jīng)常會(huì)碰到一個(gè)問題秦叛，公司使用C類網(wǎng)，因此子網(wǎng)內(nèi)可容納的主機(jī)（電腦）數(shù)量為254臺(tái)瀑粥，但實(shí)際公司的電腦可能超出這個(gè)數(shù)量挣跋，如存在440臺(tái)電腦，那此時(shí)如何更改路由器的設(shè)置可以讓440臺(tái)電腦同時(shí)上網(wǎng)呢狞换？
- 方案一：增加路由器的數(shù)量避咆，更改多個(gè)路由器配置舟肉。
- 方案二：通過改變子網(wǎng)掩碼的方式為局域網(wǎng)擴(kuò)容。
查库，對(duì)于第一種方案需要增加經(jīng)濟(jì)成本路媚，因此可以暫不考慮。來看看第二種方案樊销，此時(shí)將子網(wǎng)掩碼修改到多少合適呢整慎？計(jì)算過程如下：
- ①：主機(jī)數(shù)量/子網(wǎng)可容納主機(jī)的最大數(shù)，再向上取整围苫，即：
-
440/254≈1.73裤园，向上取整結(jié)果=2，也就是容納440臺(tái)電腦需要2個(gè)網(wǎng)段剂府。
-
- ②子網(wǎng)掩碼決定著子網(wǎng)內(nèi)可容納的主機(jī)總量比然，那么設(shè)：
2的N次方≈主機(jī)數(shù)量，求N：-
2的N次方=440周循，可算出N>8，即N=9最合適万俗，因此掩碼低位應(yīng)當(dāng)存在9個(gè)0湾笛； - 即：
11111111.11111111.11111110.00000000，轉(zhuǎn)換為十進(jìn)制：255.255.254.0闰歪； - 因此最終計(jì)算出子網(wǎng)掩碼為
255.255.254.0最合適嚎研。
-
此時(shí)假設(shè)路由器的LAN口配置是197.118.0.1，那根據(jù)第一步計(jì)算出的網(wǎng)段數(shù)量库倘，分配兩個(gè)子網(wǎng)段临扮，197.118.0.1~197.118.1.254即可滿足需求，采用這種更改子網(wǎng)掩碼的方式教翩，就在不增加路由器的情況下杆勇，也能達(dá)成了為局域網(wǎng)增加可用IP數(shù)的需求。
最終可用
IP范圍為：197.118.0.1/23饱亿，可用IP地址共計(jì)510個(gè)蚜退。
嗯？xxx/23是什么東東彪笼？其實(shí)這個(gè)值是子網(wǎng)掩碼的簡(jiǎn)寫方式钻注，之前算出來的子網(wǎng)掩碼為255.255.254.0，轉(zhuǎn)換為二進(jìn)制配猫，一共存在23個(gè)1幅恋，因此可以簡(jiǎn)寫為xxx/23。
如何判斷兩個(gè)IP處于同一個(gè)網(wǎng)段
兩個(gè)IP處于同一網(wǎng)段的前提是：兩個(gè)IP的網(wǎng)絡(luò)標(biāo)識(shí)必須一致泵肄，那如何計(jì)算網(wǎng)絡(luò)地址呢捆交？
網(wǎng)絡(luò)地址 =
IP地址 “位與” 子網(wǎng)掩碼淑翼。
如C類網(wǎng)197.118.0.198、197.118.1.114兩個(gè)IP零渐，子網(wǎng)掩碼為255.255.254.0窒舟，如何計(jì)算網(wǎng)絡(luò)地址？首先需要將掩碼與IP全部都轉(zhuǎn)換為二進(jìn)制诵盼，如下：
-
197.118.0.198：11000101.01110110.00000000.11000110 -
197.118.1.114：11000101.01110110.00000001.01110010 -
255.255.254.0：11111111.11111111.11111110.00000000
首先將197.118.0.198網(wǎng)絡(luò)部分（前三段）的二進(jìn)制值同掩碼進(jìn)行位與運(yùn)算惠豺，最終可以計(jì)算出：
11000101.01110110.00000000，轉(zhuǎn)換為十進(jìn)制為197.118.0风宁。
緊接著再197.118.1.114網(wǎng)絡(luò)部分的二進(jìn)制值同子網(wǎng)掩碼進(jìn)行位與運(yùn)算洁墙，計(jì)算結(jié)果：
11000101.01110110.00000000，轉(zhuǎn)換為十進(jìn)制為197.118.0戒财。
最終可得到結(jié)果：197.118.0.198热监、197.118.1.114的網(wǎng)絡(luò)地址都為197.118.0，代表著這兩個(gè)IP處于同一個(gè)網(wǎng)段饮寞。
子網(wǎng)掩碼小結(jié)
子網(wǎng)掩碼這塊的內(nèi)容孝扛，如果你不是專門做網(wǎng)絡(luò)相關(guān)的工程師，哪適當(dāng)了解即可幽崩，如不理解其內(nèi)容也無(wú)關(guān)緊要苦始，作為軟件開發(fā)者并不需要太過深入研究。
3.1.3慌申、IP協(xié)議核心流程
? ?經(jīng)過上述內(nèi)容學(xué)習(xí)后陌选，我們已經(jīng)對(duì)IP協(xié)議中的IP組成、分類蹄溉、計(jì)算等知識(shí)已經(jīng)建立起了基礎(chǔ)咨油，接下來在重點(diǎn)看看IP協(xié)議的核心流程。IP協(xié)議核心主要包含IP尋址和路由控制柒爵。
? ?前面曾提及：網(wǎng)絡(luò)上任何一臺(tái)主機(jī)都會(huì)存在自己的IP地址役电，那么當(dāng)應(yīng)用層數(shù)據(jù)被封裝后，能夠精準(zhǔn)定位到目標(biāo)主機(jī)的關(guān)鍵原因就在于IP棉胀，可以通過IP地址在網(wǎng)絡(luò)中進(jìn)行尋址宴霸，從而讓數(shù)據(jù)到達(dá)目的主機(jī)。
但在實(shí)際的網(wǎng)絡(luò)通信過程中膏蚓，可能有時(shí)數(shù)據(jù)發(fā)送的鏈路非常遙遠(yuǎn)瓢谢，如你從中國(guó)向日本網(wǎng)友發(fā)送一條數(shù)據(jù)，那么由于一些網(wǎng)絡(luò)抖動(dòng)驮瞧、物理介質(zhì)損壞都會(huì)導(dǎo)致數(shù)據(jù)丟失氓扛。但此時(shí)又該如何確保數(shù)據(jù)“安穩(wěn)”到達(dá)目的地呢？
為了防止數(shù)據(jù)由于介質(zhì)損壞或網(wǎng)絡(luò)抖動(dòng)等原因丟失，因此會(huì)在數(shù)據(jù)的傳輸鏈路中加入一些“中轉(zhuǎn)站”采郎，也就是所謂的“路由器”千所，一方面可以備份數(shù)據(jù)窿锉，查看數(shù)據(jù)是否丟失抖部，如果丟失會(huì)重新發(fā)送，另一方面也可以控制數(shù)據(jù)的轉(zhuǎn)發(fā)循衰。當(dāng)然整份，這個(gè)控制數(shù)據(jù)轉(zhuǎn)發(fā)的過程也被稱為“路由控制”待错。
正因?yàn)槁酚煽刂频拇嬖冢约词咕W(wǎng)絡(luò)復(fù)雜多變烈评，也能夠通過路由器的控制將數(shù)據(jù)“安穩(wěn)”送達(dá)至目的主機(jī)火俄。
但因數(shù)據(jù)傳輸過程中，數(shù)據(jù)從發(fā)送方到接收方之間存在的鏈路是不可預(yù)估的讲冠，因此數(shù)據(jù)傳輸?shù)逆溌飞峡赡軙?huì)分布很多路由器瓜客。本質(zhì)上數(shù)據(jù)在鏈路中傳輸，就是一個(gè)個(gè)路由器相互之間交換數(shù)據(jù)報(bào)的過程竿开，當(dāng)然谱仪，這個(gè)過程也被稱為“跳”。
跳：數(shù)據(jù)包經(jīng)過一臺(tái)路由器就是一跳否彩。
好比一個(gè)網(wǎng)絡(luò)中存在四個(gè)路由器：A芽卿、B、C胳搞、D，如果局域網(wǎng)A中的主機(jī)要給局域網(wǎng)D中的主機(jī)發(fā)送數(shù)據(jù)称杨，從理論上來說就會(huì)經(jīng)過B肌毅、C、D三臺(tái)路由器姑原，也就是會(huì)經(jīng)過三跳悬而。
哪當(dāng)數(shù)據(jù)到達(dá)某個(gè)路由器后，它如何知道“下一跳”該去往何處呢锭汛？此時(shí)中轉(zhuǎn)的路由器就會(huì)解析收到的數(shù)據(jù)報(bào)笨奠，然后從中解析出IP數(shù)據(jù)報(bào)，然后查詢自身的路由表唤殴，從而選擇“下一跳”該走的路線般婆，最終不斷重復(fù)該過程直至數(shù)據(jù)到達(dá)目標(biāo)主機(jī)。這種多次轉(zhuǎn)發(fā)數(shù)據(jù)的過程也被稱為“多跳路由”朵逝。
3.1.4蔚袍、IPv4與IPv6
? ?目前的網(wǎng)絡(luò)幾乎大部分還是基于IPv4版本，但同時(shí)大部分應(yīng)用程序也開始支持IPv6，IPv6是“Internet Protocol Version 6（互聯(lián)網(wǎng)協(xié)議第6版）”的縮寫啤咽，是用于替代IPv4的下一代IP協(xié)議晋辆，也就是下一代互聯(lián)網(wǎng)的協(xié)議。
? ?IPv6相較于IPv4而言宇整，主要不同點(diǎn)在于：
- ①地址空間不同瓶佳，
IPv4地址采用32位長(zhǎng)度，IPv6的地址則采用128位長(zhǎng)度鳞青。 - ②
IPv6的路由表會(huì)比IPv4更小霸饲、更精細(xì)。 -
IPv6的組播支持以及對(duì)流的支持要強(qiáng)于IPv4盼玄。 -
IPv6的安全性更高贴彼，使用IPv6的用戶可對(duì)網(wǎng)絡(luò)層數(shù)據(jù)進(jìn)行加密。 - 協(xié)議擴(kuò)充不同埃儿，
IPv6允許協(xié)議進(jìn)行擴(kuò)充器仗，而IPv4不允許。
前述的IP協(xié)議分析都是基于IPv4版本而言的童番，因?yàn)槟壳爸髁鞯木W(wǎng)絡(luò)版本還是IPv4精钮，但如今也逐步向IPv6過渡。
3.2剃斧、“面向連接”的TCP可靠傳輸協(xié)議
? ?TCP(Transmission Control Protocol)傳輸控制協(xié)議是面向連接的可靠傳輸協(xié)議轨香，是位于傳輸層的核心協(xié)議之一，在不可靠的互聯(lián)網(wǎng)絡(luò)上幼东，IP協(xié)議只提供了簡(jiǎn)單不可靠的包交換臂容，但網(wǎng)絡(luò)中不同主機(jī)之間經(jīng)常需要一種可靠的、類似于管道一樣的連接根蟹、流機(jī)制脓杉，去穩(wěn)定傳輸一些數(shù)據(jù)，如視頻简逮、音頻球散、圖片等大文件數(shù)據(jù)。
? ?因此TCP應(yīng)運(yùn)而生散庶，TCP協(xié)議是為了在不可靠的互聯(lián)網(wǎng)絡(luò)上提供可靠的端到端之間蕉堰，字節(jié)流傳輸而專門設(shè)計(jì)的一個(gè)傳輸協(xié)議，TCP中采用字節(jié)流傳輸數(shù)據(jù)悲龟。
3.2.1屋讶、TCP協(xié)議簡(jiǎn)介
先來看看TCP的報(bào)文頭結(jié)構(gòu)：
TCP報(bào)文頭結(jié)構(gòu)中的各字段釋義如下：
- ①源端口/目的端口：指數(shù)據(jù)發(fā)送方的應(yīng)用進(jìn)程端口號(hào)及接收方的進(jìn)程端口號(hào)。
- ②序號(hào)：
TCP為了保證數(shù)據(jù)的可靠傳輸须教，會(huì)對(duì)分段數(shù)據(jù)標(biāo)注序號(hào)丑婿，勇于組裝和確認(rèn)數(shù)據(jù)的正確性。 - ③確認(rèn)序號(hào)：當(dāng)接收方收到接收到本次數(shù)據(jù)時(shí)，下次需要發(fā)送的數(shù)據(jù)段序號(hào)羹奉。
- ④首部：表示
TCP報(bào)文頭的長(zhǎng)度秒旋，因?yàn)?code>TCP頭長(zhǎng)度可變性，因此需要在頭信息中聲明每個(gè)頭的長(zhǎng)度诀拭。 - ⑤保留位：預(yù)留一些空間給未來拓展時(shí)使用迁筛。
- ⑥
URG：表示本次發(fā)送的報(bào)文數(shù)據(jù)中是否緊急數(shù)據(jù)。 - ⑦
ACK：確認(rèn)信號(hào)耕挨，當(dāng)報(bào)文中ACK=1的時(shí)候表示正確或同意细卧。 - ⑧
PSH：表示接收方應(yīng)該盡快將這個(gè)報(bào)文交給應(yīng)用層，為后續(xù)數(shù)據(jù)騰出空間筒占，不要停留在緩沖區(qū)贪庙。 - ⑨
RST：如果收到RST=1的報(bào)文，說明與主機(jī)的連接出現(xiàn)嚴(yán)重錯(cuò)誤（如主機(jī)崩潰）翰苫，必須釋放連接止邮，然后重新建立連接。 - ⑩
SYN：建立一個(gè)新連接奏窑，SYN=1表示這是一個(gè)請(qǐng)求建立連接的報(bào)文段导披。 - ?
FIN：斷開一個(gè)連接，FIN=1表示通知告知對(duì)方本段要關(guān)閉連接了埃唯。 - ?窗口大辛秘啊：表示現(xiàn)在允許發(fā)送的數(shù)據(jù)量，當(dāng)?shù)竭_(dá)此值墨叛，需要
ACK確認(rèn)后才能繼續(xù)發(fā)送數(shù)據(jù)止毕。 - ?效驗(yàn)和： 通過
CRC算法提供額外的可靠性，用于效驗(yàn)數(shù)據(jù)正確性漠趁。 - ?緊急指針：標(biāo)記緊急數(shù)據(jù)在數(shù)據(jù)字節(jié)流中的位置扁凛。
- ?選項(xiàng)：這塊屬于動(dòng)態(tài)的可選擇參數(shù)。主要選項(xiàng)如下：
- 最大報(bào)文段長(zhǎng)度棚潦、窗口擴(kuò)大、時(shí)間戳膝昆。
- 數(shù)據(jù)：報(bào)文段傳輸?shù)臄?shù)據(jù)內(nèi)容（不屬于
TCP報(bào)文頭的范疇內(nèi)）丸边。
? ?當(dāng)應(yīng)用層向傳輸層傳遞數(shù)據(jù)時(shí)，TCP會(huì)首先對(duì)數(shù)據(jù)流進(jìn)行分段荚孵，將大的數(shù)據(jù)拆分成一個(gè)個(gè)的數(shù)據(jù)報(bào)文段妹窖，然后會(huì)將封裝好的數(shù)據(jù)包傳遞給網(wǎng)絡(luò)層的IP層。同時(shí)收叶，為了防止數(shù)據(jù)在網(wǎng)絡(luò)傳輸中丟包骄呼，TCP也會(huì)對(duì)每個(gè)數(shù)據(jù)包分配一個(gè)序號(hào)，當(dāng)接收方成功收到發(fā)送的數(shù)據(jù)后，會(huì)返回一個(gè)ACK確認(rèn)蜓萄，如果發(fā)送方在規(guī)定的合理時(shí)間（RTT）內(nèi)未收到接收方的ACK隅茎，那么對(duì)應(yīng)的數(shù)據(jù)包會(huì)被認(rèn)定為已丟失，發(fā)送方會(huì)將該段數(shù)據(jù)重新傳輸嫉沽。
當(dāng)數(shù)據(jù)接收完成后辟犀，
TCP會(huì)用校驗(yàn)和函數(shù)來檢驗(yàn)數(shù)據(jù)是否正確，在發(fā)送方和接收方都需要計(jì)算該值绸硕，發(fā)送方計(jì)算后會(huì)將該值放在TCP頭中攜帶發(fā)送堂竟，接收方接收到數(shù)據(jù)后，也會(huì)再次計(jì)算該值玻佩，再與報(bào)文頭中的值進(jìn)行比對(duì)出嘹，確認(rèn)數(shù)據(jù)的正確性。
3.2.2咬崔、連接管理機(jī)制 - 三次握手與四次揮手
? ?由于TCP是基于管道連接式通信的協(xié)議税稼，因此在數(shù)據(jù)傳遞之前，必須要先建立連接刁赦，當(dāng)數(shù)據(jù)傳輸完畢后娶聘，也必須要關(guān)閉連接。因此甚脉，這就引出了面試過程中人盡皆知的問題：“為什么TCP是三次握手丸升，四次揮手！”
想要了解清楚這個(gè)問題的答案牺氨，那么得先了解
TCP建立與關(guān)閉連接的過程狡耻。
TCP的三次握手
? ?所謂的TCP三次握手，其實(shí)是指TCP建立連接的過程猴凹，因?yàn)?code>TCP屬于可靠性的傳輸協(xié)議夷狰，因此在發(fā)送數(shù)據(jù)前必須要先確保發(fā)送/接收數(shù)據(jù)的雙方狀態(tài)正常，因此需要經(jīng)過“三次握手”的過程郊霎，具體如下：
- ①客戶端向服務(wù)端發(fā)送建立連接的數(shù)據(jù)包
SYN=1,seq=x沼头，然后進(jìn)入syn-send等待確認(rèn)連接狀態(tài)。-
SYN=1：代表請(qǐng)求建立連接书劝。 -
seq=x：當(dāng)前數(shù)據(jù)包的序號(hào)进倍。
-
- ②服務(wù)端接收到請(qǐng)求建立連接的數(shù)據(jù)包后，允許建立連接的情況下购对，會(huì)返回響應(yīng)報(bào)文
SYN=1,ACK=1,seq=y,ack=x+1給客戶端猾昆。-
SYN=1：TCP是雙全工協(xié)議，因此服務(wù)端也需向客戶端發(fā)送SYN=1信號(hào)骡苞。 -
ACK=1：確認(rèn)客戶端建立連接的請(qǐng)求垂蜗。 -
seq=y：表示當(dāng)前服務(wù)端返回給客戶端的序號(hào)楷扬。 -
ack=x+1：確認(rèn)客戶端序號(hào)x之前的請(qǐng)求都已收到。
-
- ③因?yàn)槭请p全工協(xié)議贴见，連接是雙向的烘苹，因此客戶端也需確認(rèn)一下服務(wù)端的連接請(qǐng)求，收到服務(wù)端的
SYN=1后蝇刀，也需返回ACK=1,seq=x+1,ack=y+1的數(shù)據(jù)包螟加。-
ACK=1：表示確認(rèn)服務(wù)端的連接建立請(qǐng)求。 -
seq=x+1：當(dāng)前數(shù)據(jù)包的請(qǐng)求序號(hào)吞琐。 -
ack=y+1：確認(rèn)服務(wù)端序號(hào)y之前的數(shù)據(jù)都已成功接收捆探。
-
經(jīng)過如上三個(gè)步驟，客戶端和服務(wù)端雙方之間確認(rèn)請(qǐng)求后站粟，連接會(huì)成功建立黍图，緊接著雙方都會(huì)處于estab-lishen狀態(tài)，數(shù)據(jù)可以正常傳輸奴烙。
當(dāng)然助被，這個(gè)過程略微有些難理解，換個(gè)日常生活的例子來快速理解一遍切诀！
- ①特種兵-竹子：我是竹子揩环，熊貓收到請(qǐng)回答！收到請(qǐng)回答幅虑！
- ②指揮部-熊貓：熊貓收到丰滑，我是熊貓，竹子能收到嗎倒庵？收到請(qǐng)回答褒墨！
- ③特種兵-竹子：竹子收到！竹子收到擎宝！
- 通話開始.........
TCP的四次揮手
當(dāng)“三次握手”完成后郁妈，客戶端和服務(wù)端之間會(huì)成功建立連接，從此開啟雙方端到端之間的數(shù)據(jù)傳輸绍申，當(dāng)一方數(shù)據(jù)傳輸完成后噩咪，會(huì)嘗試中斷連接，因此又會(huì)經(jīng)歷“四次揮手”的過程极阅，如下：
- ①客戶端完成數(shù)據(jù)傳輸后胃碾，會(huì)發(fā)出
FIN=1,seq=u關(guān)閉連接的報(bào)文，然后等待服務(wù)端響應(yīng)涂屁。-
FIN=1：代表請(qǐng)求關(guān)閉連接书在。 -
seq=u：請(qǐng)求序號(hào)灰伟。
-
- ②服務(wù)端收到客戶端的“關(guān)閉”請(qǐng)求后拆又，會(huì)給客戶端返回確認(rèn)關(guān)閉的報(bào)文：
ACK=1,seq=v,ack=u+1儒旬。-
ACK=1：確認(rèn)客戶端“關(guān)閉連接”的請(qǐng)求。 -
seq=v：請(qǐng)求序號(hào)帖族。 -
ack=u+1：確認(rèn)客戶端序號(hào)u及其以前的數(shù)據(jù)都已成功接收栈源。 - 客戶端傳輸完成數(shù)據(jù)后，會(huì)告訴服務(wù)端自己要關(guān)閉連接了竖般；
- 但服務(wù)端可能數(shù)據(jù)還未傳輸完成甚垦，因此會(huì)繼續(xù)傳輸自己的數(shù)據(jù)，直至自身的數(shù)據(jù)也傳輸完成后涣雕，也會(huì)告訴客戶端：自己也要關(guān)閉連接了艰亮。
-
- ③服務(wù)端傳輸完成自己的數(shù)據(jù)后，向客戶端發(fā)送關(guān)閉連接的報(bào)文：
FIN=1,ACK=1,seq=w,ack=u+1挣郭。-
FIN=1：表示自己也要“關(guān)閉連接”了迄埃。 -
ACK=1：確認(rèn)收到了之前的數(shù)據(jù)。 -
seq=w：請(qǐng)求序號(hào)兑障。 -
ack=u+1：確認(rèn)客戶端序號(hào)u之前的數(shù)據(jù)都已成功接收侄非。
-
- ④客戶端接收到服務(wù)端“關(guān)閉連接”的請(qǐng)求后，給服務(wù)端響應(yīng)確認(rèn)報(bào)文：
ACK=1,seq=u+1,ack=w+1流译。-
ACK=1：確認(rèn)服務(wù)端“關(guān)閉連接”的請(qǐng)求逞怨。 -
seq=u+1：請(qǐng)求序號(hào)。 -
ack=w+1：確認(rèn)服務(wù)端序號(hào)w之前的數(shù)據(jù)都已成功接收福澡。
-
前面提及過叠赦，因?yàn)?code>TCP是雙全工的協(xié)議，因此雙方都可以主動(dòng)釋放連接竞漾，在TCP中眯搭，當(dāng)一方數(shù)據(jù)傳輸完成后，就會(huì)主動(dòng)關(guān)閉連接业岁，也就會(huì)經(jīng)歷“揮手”的過程鳞仙，同樣我們也可以舉個(gè)通俗一些的例子來認(rèn)識(shí)這個(gè)過程：
- ①特種兵-竹子：竹子匯報(bào)完畢，請(qǐng)指示笔时！
- ②指揮部-熊貓：指揮部收到棍好！
..&*/?..!^...繼續(xù)說完自己要交代的任務(wù)。 - ③指揮部-熊貓：這里是熊貓允耿，任務(wù)已指示完畢借笙！
- ④特種兵-竹子：竹子收到！
- 中斷通話.........
三次握手是指TCP建立連接需要發(fā)送三個(gè)數(shù)據(jù)包较锡，主要目的是在于：為了確認(rèn)雙方的接收能力和發(fā)送能力是否正常业稼、指定自己的初始化序列號(hào)為后面的可靠性傳送做準(zhǔn)備。
四次揮手是指TCP關(guān)閉連接時(shí)需要發(fā)送四個(gè)數(shù)據(jù)包蚂蕴，主要目的在于：當(dāng)客戶端發(fā)送完數(shù)據(jù)后低散，給服務(wù)端發(fā)送“我要關(guān)閉連接了”的請(qǐng)求俯邓，然后服務(wù)端告知客戶端收到了“關(guān)閉請(qǐng)求”，但此時(shí)服務(wù)端會(huì)繼續(xù)向客戶端傳輸未發(fā)送的數(shù)據(jù)熔号，客戶端也照舊可以接收服務(wù)端的數(shù)據(jù)稽鞭，直到服務(wù)端的數(shù)據(jù)傳輸完成后，服務(wù)端也會(huì)發(fā)出“關(guān)閉連接”的請(qǐng)求引镊，客戶端同意后朦蕴，最終才會(huì)斷開連接，從而保證數(shù)據(jù)正车芡罚可靠的交互吩抓。
本質(zhì)上“三次握手與四次揮手”就是在指
TCP建立與關(guān)閉連接的過程，搞明白建立和關(guān)閉連接的過程后再來看看最開始的問題：“為什么TCP是三次握手赴恨，四次揮手琴拧！”
為什么TCP是三次握手，四次揮手
? ?因?yàn)榻⑦B接“握手”時(shí)嘱支，當(dāng)服務(wù)端接收到“客戶端想與服務(wù)端建立連接”的請(qǐng)求后蚓胸，可以立馬返回“同意+與客戶端建立連接”報(bào)文，客戶端也確認(rèn)建立連接后除师，就可以稱為“握手完成”沛膳。
? ?但關(guān)閉連接時(shí)的“揮手”，因?yàn)橐环綌?shù)據(jù)傳輸完成后就會(huì)提出關(guān)閉連接汛聚，不過另外一方可能還依舊存在數(shù)據(jù)未發(fā)送完成锹安，因此服務(wù)端就不能在“確認(rèn)關(guān)閉”連接的時(shí)候，也同時(shí)發(fā)出“關(guān)閉連接”的請(qǐng)求倚舀，因?yàn)樽约旱臄?shù)據(jù)還沒發(fā)送完成呢叹哭，所以會(huì)等到自身的數(shù)據(jù)全部傳輸后，再主動(dòng)向客戶端發(fā)起一次“關(guān)閉連接”的請(qǐng)求痕貌，等待客戶端“確認(rèn)關(guān)閉”后风罩，從而完成整個(gè)“揮手”動(dòng)作。
3.2.3舵稠、TCP中的沾包問題
? ?要理解“TCP沾包”問題之前超升，首先要理解TCP傳輸數(shù)據(jù)的方式。TCP在傳輸數(shù)據(jù)時(shí)哺徊，會(huì)給每個(gè)分割后的報(bào)文段分配一個(gè)序號(hào)室琢，接收方在收到數(shù)據(jù)后，會(huì)按照序號(hào)排好落追，然后將其放置在TCP緩沖區(qū)中盈滴。同時(shí)TCP為了提升傳輸速度，若連續(xù)幾次發(fā)送的數(shù)據(jù)都很少轿钠，TCP會(huì)根據(jù)優(yōu)化算法把多個(gè)數(shù)據(jù)合并成一個(gè)包發(fā)出巢钓。
沾包問題：多個(gè)數(shù)據(jù)包在一塊兒宽菜，無(wú)法確定每個(gè)數(shù)據(jù)包之間的分割邊界，因此從應(yīng)用層的角度看來竿报，就好像多個(gè)數(shù)據(jù)包“沾”在了一起。
? ?對(duì)于TCP傳輸層而言继谚，發(fā)送方和接收方都有可能造成數(shù)據(jù)沾包問題烈菌。
? ?發(fā)送發(fā)導(dǎo)致的數(shù)據(jù)沾包問題：TCP為了優(yōu)化傳輸速度，往往會(huì)等收集到足夠多的數(shù)據(jù)后才發(fā)送一包數(shù)據(jù)花履，因此發(fā)送發(fā)傳輸?shù)臄?shù)據(jù)就出現(xiàn)了沾包問題芽世。
? ?還有一種情況則是：當(dāng)需要發(fā)送的數(shù)據(jù)大于MSS規(guī)定，那么TCP就會(huì)對(duì)數(shù)據(jù)包進(jìn)行拆包诡壁，一個(gè)數(shù)據(jù)包會(huì)被分開傳輸济瓢，最終導(dǎo)致數(shù)據(jù)出現(xiàn)沾包問題。
? ?接收方導(dǎo)致的數(shù)據(jù)沾包問題：TCP中妹卿，如果數(shù)據(jù)被接收后旺矾，應(yīng)用程序沒有及時(shí)讀取緩沖區(qū)中的數(shù)據(jù)報(bào)文，就會(huì)導(dǎo)致緩沖區(qū)中堆積大量的報(bào)文數(shù)據(jù)夺克。這種情況下箕宙，站在TCP層的角度而言，看到的是一個(gè)個(gè)的數(shù)據(jù)報(bào)文依次排列著铺纽，但對(duì)于應(yīng)用層的程序來說柬帕，看到的就是一串連續(xù)的字節(jié)流數(shù)據(jù)，應(yīng)用程序無(wú)法知道每個(gè)數(shù)據(jù)包之間的分割邊界狡门，站在應(yīng)用層的角度來看陷寝，所有的數(shù)據(jù)包就好像都“沾”在一起了一樣，應(yīng)用程序根據(jù)預(yù)先設(shè)定好的大小從緩沖區(qū)中接收數(shù)據(jù)其馏，最終會(huì)一次性讀取到多包數(shù)據(jù)凤跑。
沾包問題解決方案
- ①當(dāng)使用
TCP短連接時(shí)，不必考慮沾包問題叛复。 - ②當(dāng)發(fā)送無(wú)結(jié)構(gòu)數(shù)據(jù)饶火，如文件傳輸時(shí)，也不需要考慮沾包問題致扯，因?yàn)檫@類數(shù)據(jù)只管發(fā)送和接收保存即可肤寝。
- ③如果使用長(zhǎng)連接，那么則需要考慮沾包問題：
- 如果發(fā)送的報(bào)文都是相同的結(jié)構(gòu)抖僵，那么可以在首部中添加數(shù)據(jù)長(zhǎng)度鲤看，接收方根據(jù)首部中記錄的數(shù)據(jù)大小讀取數(shù)據(jù)。
- 將每個(gè)數(shù)據(jù)包封裝成固定長(zhǎng)度耍群，不夠的用
0補(bǔ)齊义桂，接收方每次按照固定大小讀取數(shù)據(jù)即可找筝。 - 在數(shù)據(jù)之間設(shè)置邊界，比如添加特殊符號(hào)慷吊，這樣接收方收到數(shù)據(jù)時(shí)袖裕，根據(jù)特殊符號(hào)分割數(shù)據(jù)即可。
3.2.4溉瓶、TCP協(xié)議中的其他核心概念
? ?因?yàn)?code>TCP既要保證可靠性急鳄，同時(shí)又要盡可能提高傳輸性能，所以整個(gè)TCP設(shè)計(jì)的尤為復(fù)雜堰酿，牽扯出的概念也很多疾宏，比如為了保證數(shù)據(jù)的可靠傳輸，TCP中提供的機(jī)制：
- 效驗(yàn)和：數(shù)據(jù)接收完成后進(jìn)行效驗(yàn)触创。
- 序列號(hào)：數(shù)據(jù)按順序傳輸和接收坎藐。
- 確認(rèn)應(yīng)答：收到數(shù)據(jù)之后返回
ACK應(yīng)答。 - 超時(shí)重試：超出規(guī)定時(shí)間后哼绑，發(fā)送方未收到
ACK應(yīng)答岩馍，則會(huì)重新再次發(fā)送數(shù)據(jù)。 - 連接管理：建立和管理連接時(shí)抖韩，都會(huì)經(jīng)歷三次握手兼雄、四次揮手確保數(shù)據(jù)可靠傳遞。
- 流量控制：
TCP根據(jù)接收端的處理能力, 來決定發(fā)送端的發(fā)送速度帽蝶，避免丟包赦肋。 - 擁塞機(jī)制：
TCP采用慢啟動(dòng)機(jī)制，由于網(wǎng)絡(luò)擁塞情況不確定励稳，剛建立連接時(shí)會(huì)先發(fā)送少量數(shù)據(jù)的包佃乘，“摸清楚”網(wǎng)絡(luò)擁塞程度后，再優(yōu)化成合適的數(shù)據(jù)包大小傳輸驹尼。
在確保了數(shù)據(jù)可靠傳輸?shù)耐瑫r(shí)趣避，TCP也提供了一堆機(jī)制盡可能提高數(shù)據(jù)傳輸性能：
- 滑動(dòng)窗口：因?yàn)榻邮找粭l數(shù)據(jù)，返回一個(gè)
ACK這種應(yīng)答機(jī)制大大影響了傳輸效率新翎，因此TCP中引入了一個(gè)新概念：窗口程帕，窗口大小是指無(wú)需等待ACK就可繼續(xù)發(fā)送數(shù)據(jù)的最大值，當(dāng)收到第一個(gè)ACK確認(rèn)應(yīng)答后地啰，窗口向后移動(dòng)愁拭，發(fā)送后續(xù)的數(shù)據(jù)枪汪，因?yàn)檫@個(gè)窗口不斷向后滑動(dòng)东帅，所以叫做滑動(dòng)窗口。 - 快速重傳：結(jié)合上述的滑動(dòng)窗口機(jī)制音榜，當(dāng)某個(gè)數(shù)據(jù)出現(xiàn)丟包時(shí)，接收方會(huì)持續(xù)向發(fā)送方傳輸相同的
ACK應(yīng)答序號(hào)惜论，當(dāng)發(fā)送方連續(xù)三次接收到相同的應(yīng)答序號(hào)時(shí)许赃，就會(huì)對(duì)該序號(hào)的數(shù)據(jù)報(bào)進(jìn)行重發(fā)。 - 延遲應(yīng)答：接收方應(yīng)答速度越快馆类，那么窗口會(huì)越小混聊，而延遲應(yīng)答就是指：接收端稍等一會(huì)兒后再發(fā)送應(yīng)答信號(hào)，應(yīng)答速度越慢乾巧，窗口越大句喜，網(wǎng)絡(luò)吞吐量就越大，傳輸效率就越高（但受到數(shù)量和時(shí)間的限制）卧抗。
- 捎帶應(yīng)答：在一般數(shù)據(jù)的傳輸過程中，大多數(shù)情況下都是一發(fā)一收的過程鳖粟，因此
ACK應(yīng)答可以“搭數(shù)據(jù)的順風(fēng)車”社裆，和接收方回應(yīng)的數(shù)據(jù)報(bào)文一起返回，如三次握手中的第二次握手向图，采用的就是捎帶應(yīng)答機(jī)制泳秀，ACK應(yīng)答信號(hào)和建立連接的數(shù)據(jù)報(bào)一起發(fā)送給了客戶端。
同時(shí)榄攀，TCP協(xié)議中嗜傅，每建立一條連接都會(huì)維持九個(gè)定時(shí)器，可以適當(dāng)了解：
- 超時(shí)重傳定時(shí)器：超出規(guī)定時(shí)間范圍后檩赢，未收到應(yīng)答信息吕嘀，對(duì)數(shù)據(jù)進(jìn)行重發(fā)。
- 闭曷鳎活定時(shí)器：如果已建立的連接超出規(guī)定時(shí)間后還沒有數(shù)據(jù)交互偶房，則保活定時(shí)器超時(shí)军浆，向?qū)Χ税l(fā)送弊匮螅活探測(cè)包，根據(jù)客戶端的反饋決定是否繼續(xù)維持連接乒融，如客戶端正常則重置定時(shí)器時(shí)間掰盘，如客戶端異常則關(guān)閉
TCP連接。 - 持續(xù)定時(shí)器：也被稱為零窗口探測(cè)定時(shí)器赞季，當(dāng)接收方緩沖區(qū)數(shù)據(jù)滿了之后愧捕，會(huì)在應(yīng)答報(bào)文中通知發(fā)送方將窗口置
0，阻止發(fā)送方繼續(xù)發(fā)送數(shù)據(jù)申钩。當(dāng)緩沖區(qū)數(shù)據(jù)被讀取后晃财，會(huì)再向發(fā)送方發(fā)出一個(gè)ACK，通知發(fā)送方可以繼續(xù)傳輸數(shù)據(jù)，但為了防止該ACK丟失導(dǎo)致死鎖現(xiàn)象出現(xiàn)断盛，發(fā)送方也會(huì)啟動(dòng)零窗口探測(cè)定時(shí)器罗洗，每隔一段時(shí)間，發(fā)送方會(huì)主動(dòng)發(fā)送探測(cè)包钢猛，迫使接收端響應(yīng)伙菜，從而得知其接收窗口有無(wú)打開。 -
ACK延遲定時(shí)器：延時(shí)應(yīng)答的定時(shí)器命迈，和超市重傳定時(shí)器功能類似贩绕。 -
SYNACK定時(shí)器：新建連接時(shí)等待ACK應(yīng)答的定時(shí)器，超出時(shí)間后會(huì)關(guān)閉連接壶愤。 -
FIN_WAIT2定時(shí)器：關(guān)閉連接時(shí)等待ACK的定時(shí)器淑倾，超時(shí)后會(huì)取消“關(guān)閉連接”。 -
ER延遲定時(shí)器征椒、PTO定時(shí)器娇哆、TIME_WAIT定時(shí)器：這三玩意兒沒研究過。
3.3勃救、“面向無(wú)連接”的UDP不可靠傳輸協(xié)議
? ?UDP(User Datagram Protocol)協(xié)議是傳輸層的一個(gè)不可靠傳輸協(xié)議碍讨，它為應(yīng)用程序提供了一種無(wú)需建立連接就可以發(fā)送封裝的IP數(shù)據(jù)包的方法。在傳輸層中蒙秒，與TCP協(xié)議互補(bǔ)勃黍，UDP除了給應(yīng)用層提供了發(fā)送數(shù)據(jù)包的功能外，幾乎沒有做任何其他事情晕讲。而面向連接的TCP恰恰相反覆获，幾乎做了所有的事情。
? ?剛剛提到過瓢省，UDP僅為應(yīng)用層提供了發(fā)送數(shù)據(jù)報(bào)的功能锻梳，主要就是指UDP對(duì)IP協(xié)議的擴(kuò)充：
- ①建立在
IP協(xié)議的基礎(chǔ)上，擴(kuò)展出端口號(hào)净捅，可使數(shù)據(jù)分發(fā)到具體的應(yīng)用程序疑枯。 - ②建立在
IP協(xié)議的基礎(chǔ)上，擴(kuò)展出數(shù)據(jù)傳輸過程中的數(shù)據(jù)差錯(cuò)效驗(yàn)機(jī)制蛔六。
接下來先看看UDP的報(bào)文頭結(jié)構(gòu)荆永。
3.3.1、UDP的報(bào)文頭
對(duì)比
TCP復(fù)雜的報(bào)文頭結(jié)構(gòu)国章，UDP的頭部就顯得比較簡(jiǎn)單了具钥，整個(gè)頭共8字節(jié)：
- ①源端口/目的端口：指數(shù)據(jù)發(fā)送方的應(yīng)用進(jìn)程端口號(hào)及接收方的進(jìn)程端口號(hào)。
- ②報(bào)文長(zhǎng)度：
Header+Data的總長(zhǎng)度液兽，因?yàn)?code>UDP頭為8字節(jié)骂删，所以該值最小為8掌动。 - 效驗(yàn)和：檢測(cè)UDP數(shù)據(jù)報(bào)在傳輸中是否有錯(cuò)，有則丟棄（
UDP檢驗(yàn)和并非必須的）宁玫，就算效驗(yàn)時(shí)檢測(cè)出錯(cuò)誤粗恢，也僅只是丟棄數(shù)據(jù)包，不會(huì)對(duì)數(shù)據(jù)進(jìn)行糾正欧瘪，也就是不會(huì)重發(fā)數(shù)據(jù)報(bào)眷射。
3.3.2、UDP核心流程
? ?UDP是一個(gè)無(wú)連接的協(xié)議佛掖，因此采用UDP傳輸協(xié)議的程序妖碉，在傳遞數(shù)據(jù)時(shí)，不會(huì)存在建立/釋放連接的過程芥被。當(dāng)數(shù)據(jù)需要傳輸時(shí)欧宜，會(huì)對(duì)于應(yīng)用層的數(shù)據(jù)簡(jiǎn)單的封裝，也就是加上自己的UDP頭后拴魄，直接會(huì)將數(shù)據(jù)丟給IP層冗茸，然后交由鏈路傳輸。
正因?yàn)槿缟咸匦愿Γ虼?code>UDP的傳輸速度僅受到數(shù)據(jù)生成的速度蚀狰、計(jì)算機(jī)算力和傳輸帶寬的限制愉昆。
? ?在接收端职员，UDP會(huì)把每個(gè)消息段放在隊(duì)列/緩沖區(qū)中，程序每次從隊(duì)列中讀一個(gè)消息段跛溉。當(dāng)然焊切，接收端收到數(shù)據(jù)后，也會(huì)對(duì)數(shù)據(jù)做效驗(yàn)芳室，但效驗(yàn)完成后专肪，如若數(shù)據(jù)存在差錯(cuò)，那UDP只會(huì)單純的丟棄該數(shù)據(jù)包堪侯，不會(huì)要求發(fā)送端重發(fā)數(shù)據(jù)嚎尤。
因?yàn)橛捎?code>UDP高效的傳輸性能，因此常備應(yīng)用在廣播通知伍宦、音頻通話芽死、視頻傳輸?shù)榷嗝襟w數(shù)據(jù)流業(yè)務(wù)，而且這類業(yè)務(wù)中次洼，如果有一個(gè)數(shù)據(jù)包丟失关贵，在很短的時(shí)間內(nèi)就會(huì)有另一個(gè)新的數(shù)據(jù)就會(huì)替換它，因此就算數(shù)據(jù)傳輸不可靠也無(wú)關(guān)緊要卖毁。
3.3.3揖曾、UDP中的丟包問題
? ?由于UDP的不可靠傳輸，因此數(shù)據(jù)出現(xiàn)丟包是很常見的事情，一般UDP中造成數(shù)據(jù)丟包的原因主要如下：
- ①接收端處理數(shù)據(jù)時(shí)間過長(zhǎng)炭剪，導(dǎo)致不同包之間的數(shù)據(jù)處理間隔時(shí)間過長(zhǎng)练链，造成丟包。
- ②
UDP單個(gè)數(shù)據(jù)包過大念祭，導(dǎo)致緩沖區(qū)快速被填滿兑宇，接收端程序來不及處理造成丟包。 - ③發(fā)送端數(shù)據(jù)發(fā)送頻率過快粱坤，接收端處理速度跟不上隶糕，從而導(dǎo)致數(shù)據(jù)丟包。
- ④發(fā)/收雙方之間存在網(wǎng)絡(luò)不穩(wěn)定站玄，導(dǎo)致數(shù)據(jù)無(wú)法正常分發(fā)枚驻，從而導(dǎo)致丟包。
- 一般來說株旷，丟包的原因很簡(jiǎn)單再登，要么是網(wǎng)絡(luò)問題，要么就是接收方處理速度跟不上導(dǎo)致的晾剖。
丟包問題解決方案
- ①如果是數(shù)據(jù)包過大造成丟包锉矢，那么則可以切割數(shù)據(jù)后分批次發(fā)送。
- ②如果是發(fā)送頻率過高導(dǎo)致丟包齿尽，可以適當(dāng)控制頻率/減小流量沽损，或調(diào)大緩沖區(qū)。
- ③如是緩沖區(qū)最大了循头，還是由于處理不過來導(dǎo)致數(shù)據(jù)丟包绵估，那么可以在程序內(nèi)再實(shí)現(xiàn)一個(gè)緩存區(qū)，先讀取數(shù)據(jù)到程序中緩存卡骂，從而提升接收端的吞吐量国裳。
- ④如果程序中對(duì)于丟包容忍率很低，那么可以自己實(shí)現(xiàn)重發(fā)機(jī)制全跨，或直接切換
TCP實(shí)現(xiàn)缝左。
四、騰訊QQ通信原理剖析
? ?騰訊QQ浓若、微信兩應(yīng)用是國(guó)內(nèi)社交通信軟件中當(dāng)之無(wú)愧的“霸主”渺杉，其中的QQ是一個(gè)基于TCP/UDP兩個(gè)協(xié)議相結(jié)合的通訊軟件。其中聊天首先采用UDP打洞方式七嫌，其次考慮TCP通信少办，當(dāng)然，對(duì)于文件傳輸诵原、表情包發(fā)送英妓、QQ空間等是采用TCP傳輸挽放。
4.1、登錄原理
? ?曾經(jīng)的老版QQ是可以自己選擇登錄方式的蔓纠，也就是用戶自己可以選TCP或UDP方式登錄辑畦，如下：
但目前的新版QQ中，都是采用基于
TCP協(xié)議的HTTP方式登錄腿倚，即與我們本身做的登錄原理大致相同纯出，先通過調(diào)用后端接口獲取令牌信息，然后認(rèn)證.....敷燎，最后登錄完成后暂筝，QQ會(huì)保持一條TCP連接來維持在線狀態(tài)。
4.2硬贯、通信原理
? ?QQ的主要通信方式是基于UDP打洞技術(shù)焕襟，通過服務(wù)器中轉(zhuǎn)方式實(shí)現(xiàn)的信息傳輸，這聽起來是不是很不可思議饭豹？QQ作為“頂級(jí)”的聊天軟件鸵赖，怎么可以采用這樣的不可靠方式來傳輸消息呢？
這里面牽扯到很多原因拄衰，有歷史原因它褪，也綜合考慮了服務(wù)器負(fù)載、網(wǎng)絡(luò)復(fù)雜度翘悉、服務(wù)器數(shù)量/網(wǎng)絡(luò)帶寬成本問題茫打、實(shí)現(xiàn)難度等多方面因素導(dǎo)致的。
? ?由于UDP傳輸不可靠镐确，因此騰訊采用了上層協(xié)議來保證可靠傳輸：如果客戶端使用UDP協(xié)議發(fā)出消息后包吝，服務(wù)器收到該包饼煞，需要使用UDP協(xié)議發(fā)回一個(gè)應(yīng)答包源葫，通過這種方式來保證消息無(wú)遺漏的傳輸。
不過有時(shí)候之所以會(huì)看到“消息發(fā)送失敗的紅色感嘆號(hào)”砖瞧，但對(duì)方又收到了這個(gè)消息的情況息堂，就是因?yàn)榭蛻舳税l(fā)出的消息，服務(wù)器已經(jīng)收到并轉(zhuǎn)發(fā)成功块促，但客戶端由于網(wǎng)絡(luò)原因沒有收到服務(wù)器的應(yīng)答包引起的荣堰。
也包括網(wǎng)絡(luò)比較差的情況下，UDP無(wú)序?qū)е碌摹?/p>
4.3、文件傳輸原理
? ?當(dāng)A想要向B傳輸一個(gè)文件時(shí)斋扰，A首先會(huì)向服務(wù)器發(fā)出一個(gè)文件傳輸?shù)恼?qǐng)求渡八，服務(wù)器接收到該請(qǐng)求后啃洋，會(huì)將其轉(zhuǎn)發(fā)給B，同時(shí)會(huì)將A的臨時(shí)IP發(fā)送給B屎鳍，如果A宏娄、B兩個(gè)客戶端在同一內(nèi)網(wǎng)，那么B會(huì)直接嘗試連接A逮壁，從而達(dá)到文件傳輸?shù)哪康摹?br>
? ?但如若A孵坚、B并不在同一個(gè)局域網(wǎng)，那么A的文件傳輸操作就會(huì)由服務(wù)器進(jìn)行文件中轉(zhuǎn)窥淆，因?yàn)榉?wù)器具備公網(wǎng)IP卖宠，因此A、B兩個(gè)客戶端都可以連接到服務(wù)器忧饭，于是A逗堵、B最終就通過這種中轉(zhuǎn)的方式順利達(dá)成文件傳輸?shù)哪康摹?/p>
4.4、音/視頻通話原理
? ?前面提到過眷昆，QQ的文字聊天幾乎都是通過服務(wù)器中轉(zhuǎn)的方式工作的蜒秤，因?yàn)檫@種形式一方面可以保證“記錄同步到云端”，另一方面也方便“刑事偵查”亚斋。
? ?但音/視頻通話作媚，數(shù)據(jù)傳輸全經(jīng)過服務(wù)器中轉(zhuǎn)，對(duì)于服務(wù)器是一個(gè)沉重的負(fù)擔(dān)帅刊，所以QQ的音/視頻通話本質(zhì)上是通過NAT穿透+P2P對(duì)等通信實(shí)現(xiàn)的纸泡，當(dāng)然，在P2P直接通信失敗時(shí)赖瞒，會(huì)退而求次女揭，服務(wù)器介入處理，通過中轉(zhuǎn)模式實(shí)現(xiàn)傳輸栏饮。
大概過程如下：
-
A打算與B進(jìn)行視頻通話吧兔，那會(huì)在“啟動(dòng)時(shí)”向服務(wù)器發(fā)送一個(gè)“通話請(qǐng)求”。 - 服務(wù)器接收到請(qǐng)求后袍嬉，會(huì)先獲取通話雙方的
IP/Prot境蔼，然后將其相互交換。 - 服務(wù)器協(xié)助穿透
NAT伺通，A箍土、B雙方根據(jù)服務(wù)器分發(fā)的地址建立連接。 -
A罐监、B雙方連接對(duì)端地址吴藻，然后相互傳遞數(shù)據(jù)，從而達(dá)到通話數(shù)據(jù)傳輸?shù)哪康摹?/li>
? ?從如上過程中可以得出：QQ客戶端之間“通話”弓柱，如果可以直接P2P通信沟堡，則服務(wù)器把他們各自的公網(wǎng)IP疮鲫、端口號(hào)分發(fā)給彼此，這樣他們的流量數(shù)據(jù)可以P2P傳輸弦叶，服務(wù)器在其中只分發(fā)QQ客戶端IP俊犯、端口號(hào)信息，不會(huì)負(fù)擔(dān)太大伤哺。但如果P2P通信失敗燕侠，服務(wù)器會(huì)介入，采用服務(wù)器中轉(zhuǎn)方式完成立莉。
如果
NAT無(wú)法穿透绢彤，那則無(wú)法進(jìn)行P2P通信，無(wú)法穿透的原因也可能由于地理位置蜓耻、網(wǎng)絡(luò)類型限制等多方面因素導(dǎo)致茫舶。
P2P通信翻譯過來也就是端到端通信，在P2P模型中刹淌，服務(wù)器只作為客戶端地址的中轉(zhuǎn)站存在饶氏，不需要承擔(dān)高昂的流量成本。
4.5有勾、騰訊QQ原理分析小結(jié)
? ?在上述過程中疹启，我們只能大概分析QQ通信其中的原理，并不能保證這是騰訊內(nèi)部具體的實(shí)現(xiàn)方案蔼卡，因?yàn)榧?xì)致的具體過程只有騰訊自己明白喊崖。也包括其具體實(shí)現(xiàn)定然復(fù)雜千百萬(wàn)倍，并非三言兩語(yǔ)之間就可闡述清楚雇逞，因此對(duì)于QQ通信原理的分析部分荤懂，大概理解其原理即可。
五塘砸、計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)與網(wǎng)絡(luò)傳輸協(xié)議總結(jié)
? ?在本章中节仿，對(duì)于計(jì)算機(jī)網(wǎng)絡(luò)的基礎(chǔ)內(nèi)容進(jìn)行了全面闡述，從最初的計(jì)算機(jī)網(wǎng)絡(luò)起源開始谣蠢，到常見的網(wǎng)絡(luò)體系粟耻、網(wǎng)絡(luò)分層結(jié)構(gòu)查近、IP網(wǎng)絡(luò)協(xié)議眉踱、TCP可靠傳輸協(xié)議、UDP不可靠傳輸協(xié)議以及騰訊QQ軟件原理分析等多塊內(nèi)容進(jìn)行了分析霜威，本章旨在先為后續(xù)篇章打下網(wǎng)絡(luò)編程的基礎(chǔ)谈喳，方便后續(xù)撰寫其他內(nèi)容時(shí)做好準(zhǔn)備。
