成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

為什么 TCP/IP 協議會拆分數據

網絡 網絡管理
TCP/IP這兩個協議不僅能夠保證數據會從源機器的源進程發送到目標機器的目標進程中,還能保證數據的不重不漏以及發送的順序。

TCP/IP 協議簇建立了互聯網通信協議的概念模型,該協議簇的兩個主要協議就是 TCP 和 IP 協議。這兩個協議不僅能夠保證數據會從源機器的源進程發送到目標機器的目標進程中,還能保證數據的不重不漏以及發送的順序。

圖 1 - TCP/IP 協議簇

當應用層協議使用 TCP/IP 協議傳輸數據時,TCP/IP 協議簇可能會將應用層發送的數據分成多個包依次發送,而數據的接收方收到的數據可能是分段的或者拼接的,所以它需要對接收的數據進行拆分或者重組。本文會分別從 IP 協議和 TCP 協議兩個角度出發分析為什么應用層寫入的數據包會被 TCP/IP 協議拆分發送:

  • IP 協議會分片傳輸過大的數據包(Packet)避免物理設備的限制;
  • TCP 協議會分段傳輸過大的數據段(Segment)保證傳輸的可靠性和順序;

最大傳輸單元

IP 協議是用于傳輸數據包的協議,作為網絡層協議,它能提供數據的路由和尋址功能,讓數據通過網絡到達目的地。不同設備之間傳輸數據前,需要先確定一個 IP 數據包的大小上限,即最大傳輸單元(Maximum transmission unit,即 MTU),MTU 是 IP 數據包能夠傳輸的數據上限。

MTU 的值不是越大越好,更大的 MTU 意味著更低的額外開銷,更小的 MTU 意味著更低的網絡延遲。每一個物理設備都有自己的 MTU,兩個主機之間的 MTU 依賴于底層的網絡能力,它由整個鏈路上 MTU 最小的物理設備決定[^3],如下圖所示,網絡路徑的 MTU 由 MTU 最小的紅色物理設備決定,即 1000:

圖 2 - 路徑最大傳輸單元發現

路徑最大傳輸單元發現(Path MTU Discovery,PMTUD)是用來確定兩個主機傳輸路徑 MTU 的機制,它的工作原理如下[^4]:

(1) 向目的主機發送 IP 頭中 DF 控制位為 1 的數據包,DF 是不分片(Don't Fragment,DF)的縮寫;

(2) 路徑上的網絡設備根據數據包的大小和自己的 MTU 做出不同的決定:

  • 如果數據包大于設備的 MTU,就會丟棄數據包并發回一個包含該設備 MTU 的 ICMP 消息;
  • 如果數據包小于設備的 MTU,就會繼續向目的主機傳遞數據包;

(3) 源主機收到 ICMP 消息后,會不斷使用新的 MTU 發送 IP 數據包,直到 IP 數據包達到目的主機;

ICMP 是互聯網控制消息協議(Internet Control Message Protocol,ICMP),它能在 IP 主機之間傳遞控制消息[^5]。

以太網對數據幀的限制一般都是 1500 字節[^6],在一般情況下,IP 主機的路徑 MTU 都是 1500,去掉 IP 首部的 20 字節,如果待傳輸的數據大于 1480 節,那么該 IP 協議就會將數據包分片傳輸。

IP 協議數據分片對傳輸層協議是透明的,假設我們使用 UDP 協議傳輸 2000 字節的數據,加上 UDP 8 字節的協議頭],IP 協議需要傳輸 2008 字節的數據。如下圖所示,當 IP 協議發現待傳輸的數據大于 1480 字節,就會將數據分成下面的兩個數據包:

圖 3 - 分片傳輸的 UDP 數據

  • 20 字節 IP 協議頭 + 8 字節 UDP 協議頭 + 1472 字節數據;
  • 20 字節 IP 協議頭 + 528 字節數據;

數據的接收方在收到數據包時會對分片的數據進行重組,不過因為第二個數據包中不包含 UDP 協議的相關信息,一旦發生丟包,整個 UDP 數據報就無法重新拼裝。如果 UDP 數據報需要傳輸的數據過多,那么 IP 協議就會大量分片,增加了不穩定性。

如果 IP 協議沒有數據包大小的限制,那么上層可以以消息為單位傳輸數據,自然就不存在分片和組裝的需求,不過因為物理設備的 MTU 限制,想要保證數據傳輸的可靠性和穩定性還需要傳輸層的配合。

最大分段大小

TCP 協議是面向字節流的協議,應用層交給 TCP 協議的數據并不會以消息為單位向目的主機發送,應用層交給 TCP 協議發送的數據可能會被拆分到多個數據段中。

TCP 協議引入了最大分段大小(Maximum segment size,MSS)這一概念,它是 TCP 數據段能夠攜帶的數據上限[^8]。在正常情況下,TCP 連接的 MSS 是 MTU - 40 字節[^9],即 1460 字節;不過如果通信雙方沒有指定 MSS 的話,在默認情況下 MSS 的大小是 536 字節[^10]。

IP 協議的 MTU 是物理設備上的限制,它限制了路徑能夠發送數據包的上限,而 TCP 協議的 MSS 是操作系統內核層面的限制,通信雙方會在三次握手[^11]時確定這次連接的 MSS。一旦確定了 MSS,TCP 協議就會對應用層交給 TCP 協議發送的數據進行拆分,構成多個數據段。

需要注意的是,IP 協議和 TCP 協議雖然都會對數據進行拆分,但是 IP 協議以數據包(Package)為單位組織數據,而 TCP 協議以數據段(Segment)為單位組織數據。

如下圖所示,如果 TCP 連接的 MSS 是 1460 字節,應用層想要通過 TCP 協議傳輸 2000 字節的數據,那么 TCP 協議會根據 MSS 將 2000 字節的數據拆分到兩個數據段中:

圖 4 - 分段傳輸的 TCP 數據

  • 20 字節 IP 頭 + 20 字節 TCP 頭 + 1460 字節數據;
  • 20 字節 IP 頭 + 20 字節 TCP 頭 + 540 字節數據;

從應用層的角度來看,兩個數據段中 2000 字節的數據構成了發送方想要發送的消息,但是 TCP 協議是面向字節流的,向協議寫入的數據會以流的形式傳遞到對端。

TCP 協議為了保證可靠性,會通過 IP 協議的 MTU 計算出 MSS 并根據 MSS 分段避免 IP 協議對數據包進行分片。因為 IP 協議對數據包的分片對上層是透明的,如果協議不根據 MTU 做一些限制,那么 IP 協議的分片會導致部分數據包失去傳輸層協議頭,一旦數據包發生丟失就只能丟棄全部數據。

我們可以通過一個例子分析 MSS 存在的必要性。如下圖所示,假設 TCP 協議中不存在 MSS 的概念,因為每個數據段的大小沒有上限,當 TCP 協議交給 IP 層發送兩個 1600 字節(包括 IP 和 TCP 協議頭)的數據包時,由于物理設備的限制,IP 協議的路徑 MTU 為 1500 字節,所以 IP 協議會對數據包分片:

圖 4 - 分片傳輸的 TCP 數據

四個數據包中只有兩個會包含 TCP 協議頭,即控制位、序列號等信息,剩下的兩個數據包中不包含任何信息。因為網絡無法保證數據包的送達順序,所以當上述四個數據包亂序到達目的主機時,因為數據包中 TCP 協議頭的缺失,所以接收方沒有辦法對數據包進行重組,自然也就無法保證可靠性和順序了。

總結

數據拆分的根本原因說到底還是物理設備的限制,不過每一層協議都受限于下一層協議做出的決定,并依賴下層協議重新決定設計和實現的方法。雖然 TCP/IP 協議在傳輸數據時都需要對數據進行拆分,但是它們做出拆分數據的設計基于不同的上下文,也有著不同的目的,我們在這里總結一下兩個網絡協議做出類似決定的原因:

  • IP 協議拆分數據是因為物理設備的限制,一次能夠傳輸的數據由路徑上 MTU 最小的設備決定,一旦 IP 協議傳輸的數據包超過 MTU 的限制就會發生丟包,所以我們需要通過路徑 MTU 發現獲取傳輸路徑上的 MTU 限制;
  • TCP 協議拆分數據是為了保證傳輸的可靠性和順序,作為可靠的傳輸協議,為了保證數據的傳輸順序,它需要為每一個數據段增加包含序列號的 TCP 協議頭,如果數據段大小超過了 IP 協議的 MTU 限制,接收方就無法按順序對數據包進行重組,TCP 協議也就無法提供可靠性和順序的保證;

通過本文的分析,相信各位讀者不僅了解了為什么 TCP/IP 協議會拆分數據,也了解了為什么 UDP 協議的數據報不應該超過 MTU - 28 字節,一旦超過該限制,IP 協議的分片機制會增加 UDP 數據報無法重組的可能性]。到最后,我們還是來看一些比較開放的相關問題,有興趣的讀者可以仔細思考一下下面的問題:

  • IP 協議的分片機制都會導致哪些問題?
  • TCP 連接雙方是如何確定連接的 MSS?這個值是動態的么?

 

責任編輯:趙寧寧 來源: 真沒什么邏輯
相關推薦

2021-08-31 09:35:01

TCPIP漏洞

2019-09-30 09:41:04

五層協議OSITCP

2019-09-30 09:28:26

LinuxTCPIP

2020-03-10 08:27:24

TCP粘包網絡協議

2014-11-21 09:16:23

TCPIP

2010-09-08 15:11:36

TCP IP協議棧

2010-06-08 13:32:19

TCP IP協議基礎

2010-06-08 14:23:47

TCP IP協議概念

2020-12-03 08:37:38

TCPIPARP協議

2014-10-15 09:14:24

IP

2010-06-12 15:54:09

TCP IP協議

2010-06-18 14:37:20

TCP IP協議

2017-08-16 11:00:38

TCPIP協議

2019-09-18 20:07:06

AndroidTCP協議

2010-06-08 15:10:08

2010-06-09 16:28:50

TCP IP傳輸協議

2010-09-17 16:38:41

TCP IP協議

2010-06-13 14:49:40

TCP IP協議優化

2019-08-21 05:48:06

TCPIP協議棧

2010-06-08 13:50:40

TCP IP協議族
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 风间由美一区二区三区在线观看 | 久久综合九色综合欧美狠狠 | 国产一级视频在线观看 | 国产精品日韩欧美 | 久久99国产精品 | 国产免费看 | 国产精品久久久久久久久久免费看 | 精品视频一区二区三区 | 国产精品成人av | 亚洲欧美日韩精品久久亚洲区 | 久久小视频 | 一区二区三区久久久 | 激情五月婷婷综合 | 日本超碰 | 高清亚洲| 亚洲国产成人精品久久 | 欧美精品在欧美一区二区少妇 | 日本三级做a全过程在线观看 | 亚洲欧洲中文 | 黄色欧美 | 欧美久久久久久久久中文字幕 | 国产视频一区二区 | 欧美 日韩 国产 成人 在线 | 久久亚洲国产精品 | 在线中文字幕日韩 | 成人国产精品久久 | 日韩中出 | 久久精品成人一区 | www.国产精品 | 天天综合干 | 国产情品| 国产精品久久在线 | 免费观看色 | 嫩草91在线 | 久久精品国产v日韩v亚洲 | 一区二区免费在线观看 | 成人福利在线视频 | 亚洲精品一区二 | 一级片在线视频 | 看片91| 成人久久18免费网站 |