您好,登錄后才能下訂單哦!
TCP/IP協議中用戶數據的傳遞過程及協議頭部信息是怎樣的,相信很多沒有經驗的人對此束手無策,為此本文總結了問題出現的原因和解決方法,通過這篇文章希望你能解決這個問題。
由底層到上層,分別是:l鏈路層,網絡層,運輸層和應用層。
這里以FTP協議為例來看下客戶端和服務器端,在協議層面是如何交互的。
在局域網內,鏈路層基本上是相同的,以太網為例,如下圖所示,對應的協議棧需要采用對應的協議來交互數據。
在不同的局域網,鏈路層往往不同,假設一個是以太網,一個是令牌環網,那么在IP層對應的路由協議上面需要同時支持這兩種網絡,在路由器的支持下,兩種網絡可以相互適配,以便達到相互通訊的地步。
在IP層往上,就已經屏蔽了這部分差別,所以在運輸層和應用層,與局域網內部通訊是一致的。
在研究數據的封裝和分用之前,讓我們先看下對應的層次都有哪些網絡協議,如下圖所示:
數據要從一端發往另外一端,涉及到的第一個問題,便是如何將數據打包,這種打包的標準時需要事先商量好的,策略是每一層都添加一個對應的協議層頭部,往下傳遞。
應用層在發送數據的時候,首先需要將對應的用戶數據,在應用層打包,這樣就會在應用層協議層面,加個對應的應用層首部,構成“應用層首部+用戶數據”的一整個數據 = 應用數據。
應用層數據往下傳遞到TCP層,TCP會將這些數據再加一個報文頭部,變成“TCP首部+應用層數據” = TCP數據,并傳遞給IP層。
IP層接到數據之后,會添加個IP首部,變成“IP首部+TCP數據” = IP數據,并傳遞給鏈路層。
假設鏈路層是以太網,于是鏈路層數據便成為“”以太網首部+IP數據+以太網尾部”=以太網數據。
對于接收端來說,與發送端正好是相反的,對應的協議層次,會把該層的數據頭部剝掉,并按照規范解析出數據,傳遞給上一層,一直到對應的應用程序為止。
例如:IP層,會根據IP頭部的數據位,來知道運輸層是UDP還是TCP,并決定將IP數據是傳給UDP還是TCP協議來繼續處理。
IP頭部,有20位字節組成,其中IP數據的長度是U16,最大值是65535,U16的首部校驗和,U8的生存時間,U8的協議(這個用來記錄 運輸層是何種協議,UDP還是TCP)。U32的源端IP地址和U32的目的端IP地址。
IPv6的數據頭部如下所述, 其中源地址和目的地址,都是16個字節的大小。
圖片來自網絡,侵權告知,會及時刪除
UDP頭部+UDP數據,共同構成了UDP數據,被封裝在IP 數據之中,作為IP的數據內容,其中UDP的頭部只有8個字節的大小。
UDP頭部內容詳細如下所示:U16的源端口和目的端口,該字段的用意是用來區分同一臺機器上面的使用相同IP地址的,不同的應用程序。
U16的UDP數據長度,其實IP的數據長度是U16,所以UDP這一層的數據長度應該是:IP的數據長度-8字節的UDP頭部長度。
U16的UDP檢驗和,這個UDP是可選的。
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協議中用戶數據的傳遞過程及協議頭部信息是怎樣的的方法了嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。