艾銻知識 |為什么 TCP/IP 協(xié)議會拆分?jǐn)?shù)據(jù)
2020-02-19 15:48 作者:艾銻無限 瀏覽量:
疫情即將結(jié)束,如何提升企業(yè)工作效率
艾銻無限免費(fèi)為企業(yè)提供IT服務(wù)
這幾天如果大家關(guān)注疫情數(shù)據(jù)的變化,可以看到湖北以外30個(gè)省區(qū)市新增確診病例12連降,這意味著疫情很快就會結(jié)束,大家再也不用在家辦公了,到不是在家工作不好,但人類發(fā)明工作不
簡簡單單只是為了實(shí)現(xiàn)結(jié)果的達(dá)成,還有一個(gè)非常重要的因素就是人與人之間的聯(lián)結(jié),這是人類內(nèi)在價(jià)值的需要,透過工作與人接觸,共同感受彼此的能量流動,從而達(dá)到自我價(jià)值的實(shí)現(xiàn),這就像演員都渴望登上奧斯卡的舞臺,而實(shí)現(xiàn)自我角色的認(rèn)可。
在家辦公,必盡是家,松、散、無所謂的態(tài)度會隨時(shí)產(chǎn)生,我相信不是每個(gè)人都會這樣,但大部分人會如此,接下來即將回到公司,回到自己的工作崗位,難免會把在家的狀態(tài)帶入工作中,如果
每個(gè)人都這是這樣的狀態(tài),很快會讓企業(yè)限入新的窘境,那就是沒有狀態(tài),也不會有好的結(jié)果,狀態(tài)就是一切。團(tuán)隊(duì)的勢氣決定企業(yè)整體的戰(zhàn)斗力,那如何調(diào)整陸陸續(xù)續(xù)回來的團(tuán)隊(duì)成員呢?

艾銻無限對中小企業(yè)有三條建議:
第一,重新梳理整個(gè)企業(yè)的戰(zhàn)略,疫情的發(fā)生,是否給你企業(yè)帶來了變化?如果有那是什么?是否需要調(diào)整自己原有的戰(zhàn)略方向來應(yīng)對疫情發(fā)生后的影響?
第二,重新明確每個(gè)人的目標(biāo)和目的,目標(biāo)就是回來的人要干什么?干到什么程度?什么時(shí)間可以看到這個(gè)結(jié)果的發(fā)生?目的就是為什么要這個(gè)目標(biāo)?這個(gè)目標(biāo)與自己的意義是什么?與企業(yè)的意義是什么?達(dá)成了會怎么樣?達(dá)不成會怎么樣?一定要讓員工想清晰這些問題,只有想清晰了才會改變自己對待接下來工作的態(tài)度。
第三,企業(yè)高管與員工建立一對一對話機(jī)制,因疫情的影響,每個(gè)人心理或多或少都會產(chǎn)生一些內(nèi)在的變化,做為企業(yè)的高層管理人員,最好與企業(yè)內(nèi)部員工一對一的進(jìn)行溝通,去了解在這個(gè)過程中員工受到的影響和產(chǎn)生的變化,以便接下來擁有更好的狀態(tài)投入工作中。以上三點(diǎn)做為每一家企業(yè)的管理者都有必要重視起來,因?yàn)檫@關(guān)系著企業(yè)接下來的生、死、存、亡,當(dāng)然這只是我們一家之言,可根據(jù)自身的情況做出相應(yīng)的調(diào)整和改變。
那為什么我們會有這樣的思考,因?yàn)榘R無限是一家企業(yè)互聯(lián)網(wǎng)”云”解決方案服務(wù)平臺,企業(yè)在初創(chuàng)時(shí)經(jīng)歷了2003年的非典,后來又經(jīng)歷了2008年的經(jīng)濟(jì)危機(jī)以及2016年互聯(lián)網(wǎng)創(chuàng)業(yè)大潮,生生死死,幾經(jīng)沉浮,最終發(fā)現(xiàn)上述三點(diǎn)是生死線中最重要的,所以愿意分享給大家,期望這次疫情大家不僅能渡過難關(guān),更能看見大家在這個(gè)過程中強(qiáng)而有力的領(lǐng)導(dǎo)力,讓自己企業(yè)力挽狂瀾,在2020年有一個(gè)更好的未來。
在這次疫情后各個(gè)企業(yè)恢復(fù)的過程中,艾銻無限還能為大家做的就是免費(fèi)為中小企業(yè)提供相應(yīng)的IT服務(wù),以下是艾銻無限可以提供服務(wù)的內(nèi)容,如果大家有相應(yīng)的需求,可以打下面的電話與我們的企業(yè)相關(guān)人員聯(lián)系,我們一定會盡全力幫助大家渡過難關(guān)。

歷經(jīng)10幾年,艾銻無限服務(wù)了5000多家中小企業(yè)并保障了幾十萬臺設(shè)備的正常運(yùn)轉(zhuǎn),積累了豐富的企業(yè)IT緊急問題和特殊故障的解決方案,我們?yōu)槟钠髽I(yè)提供的IT服務(wù)分為三大版塊:
第一版塊是保障性IT外包服務(wù):如電腦設(shè)備運(yùn)維,辦公設(shè)備運(yùn)維,網(wǎng)絡(luò)設(shè)備運(yùn)維,服務(wù)器運(yùn)維等綜合性企業(yè)IT設(shè)備運(yùn)維服務(wù)。
第二版塊是功能性互聯(lián)網(wǎng)外包服務(wù):如網(wǎng)站開發(fā)外包,小程序開發(fā)外包,APP開發(fā)外包,電商平臺開發(fā)外包,業(yè)務(wù)系統(tǒng)的開發(fā)外包和后期的運(yùn)維外包服務(wù)。
第三版塊是增值性云服務(wù)外包:如企業(yè)郵箱上云,企業(yè)網(wǎng)站上云,企業(yè)存儲上云,企業(yè)APP小程序上云,企業(yè)業(yè)務(wù)系統(tǒng)上云,阿里云產(chǎn)品等后續(xù)的云運(yùn)維外包服務(wù)。

更多服務(wù)也可以登錄艾銻無限的官網(wǎng):
www.bjitwx.com 查看詳細(xì)說明。
每家企業(yè)都有著不同的人,每個(gè)人都有著不一樣的思考,所以企業(yè)不需要統(tǒng)一所有人的思維,企業(yè)只需要統(tǒng)一所有人的心,因?yàn)橹灰脑谝黄鹆耍芰烤蜁弦?,能量合一企業(yè)將無所不能。
相信這次疫情帶給中國企業(yè)的不僅僅是災(zāi)難,更有可能的是歷練,這些年中國的經(jīng)濟(jì)發(fā)展非常快速,大部分中小企業(yè)的成長都是隨著國家政策及整個(gè)社會的大勢起來的,沒有經(jīng)過挑戰(zhàn)和困難,所以存活周期也會很短,從2016年大眾創(chuàng)業(yè),萬眾創(chuàng)新倡導(dǎo)下成立了上千萬家企業(yè),但真正存活下來的就只有幾十萬家,這樣即不能給國家?guī)砀玫姆€(wěn)定持續(xù)的發(fā)展,也不能為社會創(chuàng)造更大的價(jià)值,反而讓更多的人投機(jī)取巧,心浮氣躁,沉不下來真正把一件事做好,做到極致。
所以這次疫情也會讓這些企業(yè)重新思考,問問自己,為什么要創(chuàng)造這家企業(yè),想為這個(gè)國家和社會帶來的是什么?這家企業(yè)真正創(chuàng)造的是什么?如何做才能讓社會變得更好?等等.....
所以企業(yè)真正去思考,用心去創(chuàng)造價(jià)值的時(shí)候,也就是人們幸福快樂的時(shí)候,因?yàn)樵僖膊挥脫?dān)心假貨、次貨、買到不好的產(chǎn)品,所以疫情即是一場災(zāi)難,又是成就我們中國的一次機(jī)會,讓我們?nèi)袊擞X醒。生命只有一次,做就做到最好。

你對世界微笑,世界絕不會對你哭,希望大家都能樂觀起來,讓自己、自己的家人、自己的企業(yè)、還有自己的國家都快樂起來,把焦點(diǎn)放在我們想要什么上,而不是不要的事情上,我相信,就在不久的將來,我們一定會看到一個(gè)富強(qiáng)、文明、健康的中國以及中國人。
萬物同體,能量合一,最后無論你是中小企業(yè),還是大型國有企業(yè),只要你選擇艾銻無限,我們就一定全力以赴幫助大家渡過難關(guān),服務(wù)有限,信息無限,透過全體艾銻人的努力,為您收集最有效的IT技術(shù)信息,讓您企業(yè)更快速解決遇到的IT問題:
艾銻知識 |為什么 TCP/IP 協(xié)議會拆分?jǐn)?shù)據(jù)
TCP/IP 協(xié)議簇建立了互聯(lián)網(wǎng)通信協(xié)議的概念模型,該協(xié)議簇的兩個(gè)主要協(xié)議就是 TCP 和 IP 協(xié)議。這兩個(gè)協(xié)議不僅能夠保證數(shù)據(jù)會從源機(jī)器的源進(jìn)程發(fā)送到目標(biāo)機(jī)器的目標(biāo)進(jìn)程中,還能保證數(shù)據(jù)的不重不漏以及發(fā)送的順序。
圖 1 - TCP/IP 協(xié)議簇
當(dāng)應(yīng)用層協(xié)議使用 TCP/IP 協(xié)議傳輸數(shù)據(jù)時(shí),TCP/IP 協(xié)議簇可能會將應(yīng)用層發(fā)送的數(shù)據(jù)分成多個(gè)包依次發(fā)送,而數(shù)據(jù)的接收方收到的數(shù)據(jù)可能是分段的或者拼接的,所以它需要對接收的數(shù)據(jù)進(jìn)行拆分或者重組。本文會分別從 IP 協(xié)議和 TCP 協(xié)議兩個(gè)角度出發(fā)分析為什么應(yīng)用層寫入的數(shù)據(jù)包會被 TCP/IP 協(xié)議拆分發(fā)送:
-
IP 協(xié)議會分片傳輸過大的數(shù)據(jù)包(Packet)避免物理設(shè)備的限制;
-
TCP 協(xié)議會分段傳輸過大的數(shù)據(jù)段(Segment)保證傳輸?shù)目煽啃院晚樞?
最大傳輸單元
IP 協(xié)議是用于傳輸數(shù)據(jù)包的協(xié)議,作為網(wǎng)絡(luò)層協(xié)議,它能提供數(shù)據(jù)的路由和尋址功能,讓數(shù)據(jù)通過網(wǎng)絡(luò)到達(dá)目的地。不同設(shè)備之間傳輸數(shù)據(jù)前,需要先確定一個(gè) IP 數(shù)據(jù)包的大小上限,即最大傳輸單元(Maximum transmission unit,即 MTU),MTU 是 IP 數(shù)據(jù)包能夠傳輸?shù)臄?shù)據(jù)上限。
MTU 的值不是越大越好,更大的 MTU 意味著更低的額外開銷,更小的 MTU 意味著更低的網(wǎng)絡(luò)延遲。每一個(gè)物理設(shè)備都有自己的 MTU,兩個(gè)主機(jī)之間的 MTU 依賴于底層的網(wǎng)絡(luò)能力,它由整個(gè)鏈路上 MTU 最小的物理設(shè)備決定[^3],如下圖所示,網(wǎng)絡(luò)路徑的 MTU 由 MTU 最小的紅色物理設(shè)備決定,即 1000:
圖 2 - 路徑最大傳輸單元發(fā)現(xiàn)
路徑最大傳輸單元發(fā)現(xiàn)(Path MTU Discovery,PMTUD)是用來確定兩個(gè)主機(jī)傳輸路徑 MTU 的機(jī)制,它的工作原理如下[^4]:
(1) 向目的主機(jī)發(fā)送 IP 頭中 DF 控制位為 1 的數(shù)據(jù)包,DF 是不分片(Don't Fragment,DF)的縮寫;
(2) 路徑上的網(wǎng)絡(luò)設(shè)備根據(jù)數(shù)據(jù)包的大小和自己的 MTU 做出不同的決定:
-
如果數(shù)據(jù)包大于設(shè)備的 MTU,就會丟棄數(shù)據(jù)包并發(fā)回一個(gè)包含該設(shè)備 MTU 的 ICMP 消息;
-
如果數(shù)據(jù)包小于設(shè)備的 MTU,就會繼續(xù)向目的主機(jī)傳遞數(shù)據(jù)包;
(3) 源主機(jī)收到 ICMP 消息后,會不斷使用新的 MTU 發(fā)送 IP 數(shù)據(jù)包,直到 IP 數(shù)據(jù)包達(dá)到目的主機(jī);
ICMP 是互聯(lián)網(wǎng)控制消息協(xié)議(Internet Control Message Protocol,ICMP),它能在 IP 主機(jī)之間傳遞控制消息。
以太網(wǎng)對數(shù)據(jù)幀的限制一般都是 1500 字節(jié)[^6],在一般情況下,IP 主機(jī)的路徑 MTU 都是 1500,去掉 IP 首部的 20 字節(jié),如果待傳輸?shù)臄?shù)據(jù)大于 1480 節(jié),那么該 IP 協(xié)議就會將數(shù)據(jù)包分片傳輸。
IP 協(xié)議數(shù)據(jù)分片對傳輸層協(xié)議是透明的,假設(shè)我們使用 UDP 協(xié)議傳輸 2000 字節(jié)的數(shù)據(jù),加上 UDP 8 字節(jié)的協(xié)議頭],IP 協(xié)議需要傳輸 2008 字節(jié)的數(shù)據(jù)。如下圖所示,當(dāng) IP 協(xié)議發(fā)現(xiàn)待傳輸?shù)臄?shù)據(jù)大于 1480 字節(jié),就會將數(shù)據(jù)分成下面的兩個(gè)數(shù)據(jù)包:
圖 3 - 分片傳輸?shù)?UDP 數(shù)據(jù)
-
20 字節(jié) IP 協(xié)議頭 + 8 字節(jié) UDP 協(xié)議頭 + 1472 字節(jié)數(shù)據(jù);
-
20 字節(jié) IP 協(xié)議頭 + 528 字節(jié)數(shù)據(jù);
數(shù)據(jù)的接收方在收到數(shù)據(jù)包時(shí)會對分片的數(shù)據(jù)進(jìn)行重組,不過因?yàn)榈诙€(gè)數(shù)據(jù)包中不包含 UDP 協(xié)議的相關(guān)信息,一旦發(fā)生丟包,整個(gè) UDP 數(shù)據(jù)報(bào)就無法重新拼裝。如果 UDP 數(shù)據(jù)報(bào)需要傳輸?shù)臄?shù)據(jù)過多,那么 IP 協(xié)議就會大量分片,增加了不穩(wěn)定性。
如果 IP 協(xié)議沒有數(shù)據(jù)包大小的限制,那么上層可以以消息為單位傳輸數(shù)據(jù),自然就不存在分片和組裝的需求,不過因?yàn)槲锢碓O(shè)備的 MTU 限制,想要保證數(shù)據(jù)傳輸?shù)目煽啃院头€(wěn)定性還需要傳輸層的配合。
最大分段大小
TCP 協(xié)議是面向字節(jié)流的協(xié)議,應(yīng)用層交給 TCP 協(xié)議的數(shù)據(jù)并不會以消息為單位向目的主機(jī)發(fā)送,應(yīng)用層交給 TCP 協(xié)議發(fā)送的數(shù)據(jù)可能會被拆分到多個(gè)數(shù)據(jù)段中。
TCP 協(xié)議引入了最大分段大小(Maximum segment size,MSS)這一概念,它是 TCP 數(shù)據(jù)段能夠攜帶的數(shù)據(jù)上限[^8]。在正常情況下,TCP 連接的 MSS 是 MTU - 40 字節(jié)[^9],即 1460 字節(jié);不過如果通信雙方?jīng)]有指定 MSS 的話,在默認(rèn)情況下 MSS 的大小是 536 字節(jié)[^10]。
IP 協(xié)議的 MTU 是物理設(shè)備上的限制,它限制了路徑能夠發(fā)送數(shù)據(jù)包的上限,而 TCP 協(xié)議的 MSS 是操作系統(tǒng)內(nèi)核層面的限制,通信雙方會在三次握手[^11]時(shí)確定這次連接的 MSS。一旦確定了 MSS,TCP 協(xié)議就會對應(yīng)用層交給 TCP 協(xié)議發(fā)送的數(shù)據(jù)進(jìn)行拆分,構(gòu)成多個(gè)數(shù)據(jù)段。
需要注意的是,IP 協(xié)議和 TCP 協(xié)議雖然都會對數(shù)據(jù)進(jìn)行拆分,但是 IP 協(xié)議以數(shù)據(jù)包(Package)為單位組織數(shù)據(jù),而 TCP 協(xié)議以數(shù)據(jù)段(Segment)為單位組織數(shù)據(jù)。
如下圖所示,如果 TCP 連接的 MSS 是 1460 字節(jié),應(yīng)用層想要通過 TCP 協(xié)議傳輸 2000 字節(jié)的數(shù)據(jù),那么 TCP 協(xié)議會根據(jù) MSS 將 2000 字節(jié)的數(shù)據(jù)拆分到兩個(gè)數(shù)據(jù)段中:
圖 4 - 分段傳輸?shù)?TCP 數(shù)據(jù)
-
20 字節(jié) IP 頭 + 20 字節(jié) TCP 頭 + 1460 字節(jié)數(shù)據(jù);
-
20 字節(jié) IP 頭 + 20 字節(jié) TCP 頭 + 540 字節(jié)數(shù)據(jù);
從應(yīng)用層的角度來看,兩個(gè)數(shù)據(jù)段中 2000 字節(jié)的數(shù)據(jù)構(gòu)成了發(fā)送方想要發(fā)送的消息,但是 TCP 協(xié)議是面向字節(jié)流的,向協(xié)議寫入的數(shù)據(jù)會以流的形式傳遞到對端。
TCP 協(xié)議為了保證可靠性,會通過 IP 協(xié)議的 MTU 計(jì)算出 MSS 并根據(jù) MSS 分段避免 IP 協(xié)議對數(shù)據(jù)包進(jìn)行分片。因?yàn)?IP 協(xié)議對數(shù)據(jù)包的分片對上層是透明的,如果協(xié)議不根據(jù) MTU 做一些限制,那么 IP 協(xié)議的分片會導(dǎo)致部分?jǐn)?shù)據(jù)包失去傳輸層協(xié)議頭,一旦數(shù)據(jù)包發(fā)生丟失就只能丟棄全部數(shù)據(jù)。
我們可以通過一個(gè)例子分析 MSS 存在的必要性。如下圖所示,假設(shè) TCP 協(xié)議中不存在 MSS 的概念,因?yàn)槊總€(gè)數(shù)據(jù)段的大小沒有上限,當(dāng) TCP 協(xié)議交給 IP 層發(fā)送兩個(gè) 1600 字節(jié)(包括 IP 和 TCP 協(xié)議頭)的數(shù)據(jù)包時(shí),由于物理設(shè)備的限制,IP 協(xié)議的路徑 MTU 為 1500 字節(jié),所以 IP 協(xié)議會對數(shù)據(jù)包分片:
圖 4 - 分片傳輸?shù)?TCP 數(shù)據(jù)
四個(gè)數(shù)據(jù)包中只有兩個(gè)會包含 TCP 協(xié)議頭,即控制位、序列號等信息,剩下的兩個(gè)數(shù)據(jù)包中不包含任何信息。因?yàn)榫W(wǎng)絡(luò)無法保證數(shù)據(jù)包的送達(dá)順序,所以當(dāng)上述四個(gè)數(shù)據(jù)包亂序到達(dá)目的主機(jī)時(shí),因?yàn)閿?shù)據(jù)包中 TCP 協(xié)議頭的缺失,所以接收方?jīng)]有辦法對數(shù)據(jù)包進(jìn)行重組,自然也就無法保證可靠性和順序了。
總結(jié)
數(shù)據(jù)拆分的根本原因說到底還是物理設(shè)備的限制,不過每一層協(xié)議都受限于下一層協(xié)議做出的決定,并依賴下層協(xié)議重新決定設(shè)計(jì)和實(shí)現(xiàn)的方法。雖然 TCP/IP 協(xié)議在傳輸數(shù)據(jù)時(shí)都需要對數(shù)據(jù)進(jìn)行拆分,但是它們做出拆分?jǐn)?shù)據(jù)的設(shè)計(jì)基于不同的上下文,也有著不同的目的,我們在這里總結(jié)一下兩個(gè)網(wǎng)絡(luò)協(xié)議做出類似決定的原因:
-
IP 協(xié)議拆分?jǐn)?shù)據(jù)是因?yàn)槲锢碓O(shè)備的限制,一次能夠傳輸?shù)臄?shù)據(jù)由路徑上 MTU 最小的設(shè)備決定,一旦 IP 協(xié)議傳輸?shù)臄?shù)據(jù)包超過 MTU 的限制就會發(fā)生丟包,所以我們需要通過路徑 MTU 發(fā)現(xiàn)獲取傳輸路徑上的 MTU 限制;
-
TCP 協(xié)議拆分?jǐn)?shù)據(jù)是為了保證傳輸?shù)目煽啃院晚樞?,作為可靠的傳輸協(xié)議,為了保證數(shù)據(jù)的傳輸順序,它需要為每一個(gè)數(shù)據(jù)段增加包含序列號的 TCP 協(xié)議頭,如果數(shù)據(jù)段大小超過了 IP 協(xié)議的 MTU 限制,接收方就無法按順序?qū)?shù)據(jù)包進(jìn)行重組,TCP 協(xié)議也就無法提供可靠性和順序的保證;
通過本文的分析,相信各位讀者不僅了解了為什么 TCP/IP 協(xié)議會拆分?jǐn)?shù)據(jù),也了解了為什么 UDP 協(xié)議的數(shù)據(jù)報(bào)不應(yīng)該超過 MTU - 28 字節(jié),一旦超過該限制,IP 協(xié)議的分片機(jī)制會增加 UDP 數(shù)據(jù)報(bào)無法重組的可能性]。