TCP/IP協議中用戶數據的傳遞過程及協議頭部信息是怎樣的

TCP/IP協議中用戶數據的傳遞過程及協議頭部信息是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

1.網絡協議的分層

由底層到上層，分別是：l鏈路層，網絡層，運輸層和應用層。

這里以FTP協議為例來看下客戶端和服務器端，在協議層面是如何交互的。

在局域網內，鏈路層基本上是相同的，以太網為例，如下圖所示，對應的協議棧需要采用對應的協議來交互數據。

在不同的局域網，鏈路層往往不同，假設一個是以太網，一個是令牌環網，那么在IP層對應的路由協議上面需要同時支持這兩種網絡，在路由器的支持下，兩種網絡可以相互適配，以便達到相互通訊的地步。

在IP層往上，就已經屏蔽了這部分差別，所以在運輸層和應用層，與局域網內部通訊是一致的。

2.網絡協議的封裝和分用

在研究數據的封裝和分用之前，讓我們先看下對應的層次都有哪些網絡協議，如下圖所示：

數據要從一端發往另外一端，涉及到的第一個問題，便是如何將數據打包，這種打包的標準時需要事先商量好的，策略是每一層都添加一個對應的協議層頭部，往下傳遞。

應用層在發送數據的時候，首先需要將對應的用戶數據，在應用層打包，這樣就會在應用層協議層面，加個對應的應用層首部，構成“應用層首部+用戶數據”的一整個數據 = 應用數據。

應用層數據往下傳遞到TCP層，TCP會將這些數據再加一個報文頭部，變成“TCP首部+應用層數據” = TCP數據，并傳遞給IP層。

IP層接到數據之后，會添加個IP首部，變成“IP首部+TCP數據” = IP數據，并傳遞給鏈路層。

假設鏈路層是以太網，于是鏈路層數據便成為“”以太網首部+IP數據+以太網尾部”=以太網數據。

對于接收端來說，與發送端正好是相反的，對應的協議層次，會把該層的數據頭部剝掉，并按照規范解析出數據，傳遞給上一層，一直到對應的應用程序為止。

例如：IP層，會根據IP頭部的數據位，來知道運輸層是UDP還是TCP，并決定將IP數據是傳給UDP還是TCP協議來繼續處理。

3.IP層的頭部數據

IP頭部，有20位字節組成，其中IP數據的長度是U16,最大值是65535，U16的首部校驗和，U8的生存時間，U8的協議（這個用來記錄 運輸層是何種協議，UDP還是TCP）。U32的源端IP地址和U32的目的端IP地址。

IPv6的數據頭部如下所述， 其中源地址和目的地址，都是16個字節的大小。

圖片來自網絡，侵權告知，會及時刪除

4.UDP頭部

UDP頭部+UDP數據，共同構成了UDP數據，被封裝在IP 數據之中，作為IP的數據內容，其中UDP的頭部只有8個字節的大小。

UDP頭部內容詳細如下所示：U16的源端口和目的端口，該字段的用意是用來區分同一臺機器上面的使用相同IP地址的，不同的應用程序。

U16的UDP數據長度，其實IP的數據長度是U16，所以UDP這一層的數據長度應該是：IP的數據長度-8字節的UDP頭部長度。

U16的UDP檢驗和，這個UDP是可選的。

5.TCP頭部

TCP數據由：TCP首部+TCP數據 共同構成，TCP數據。會被封裝到IP數據中，其中TCP首部由20個字節構成，如下圖所示：

圖片發自簡書App

TCP的首部，詳細內容如下所示：

U16的源端口和目的端口，用于區分相同IP地址下面的不同應用程序。U32的序列號和確認序號，用來實現TCP的可靠性傳輸，是TCP可靠性傳輸重要的一個環節，通過REQ+ACK的方式來完成。關于該序號，是根據時間的關系隨機生成的一個序號，遞增的產生方式。

標識位SYN和ACK，用于三次握手。FIN用于四次揮手。RST表示復位連接。PSH表示需要盡可能快的將數據送往接收進程。

U16的窗口大小，用于控制TCP的流量傳輸速率。U16的校驗和，這個是必須要存在的，保證TCP的可靠性的一部分。

看完上述內容，你們掌握TCP/IP協議中用戶數據的傳遞過程及協議頭部信息是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！