IP UDP TCP協議格式 待完善

2021-09-27 06:24:43 字數 1977 閱讀 2192

udp協議和tcp協議同位於傳輸層,介於網路層(ip)和應用層之間:udp資料部分為應用層報文,而udp報文在ip中承載。如下圖:

在接收時當ip層根據協議欄位把udp報文向上傳送到udp模組後,udp模組再根據埠號將資料傳送到相應的程序中,以此實現程序到程序間的通訊。

注:上圖中分組1包含udp頭部,後續分組並不包含udp頭部

源埠號:埠號0-65535,1-1024保留埠號,為標準的服務埠

目的埠號:字面含義

udp長度:udp報文的位元組長度(udp首部和資料長度),最小為8,對應不包含資料

udp校驗和: 檢驗udp首部和資料部分的正確性

udp報文抓包

udp允許傳輸的最大長度理論上2^16 - udp head - iphead( 65507 位元組 = 65535 - 20 - 8)

但是實際上udp資料報的資料區最大長度為1472位元組。分析如下:

首先,我們知道,tcp/ip通常被認為是乙個四層協議系統,包括鏈路層,網路層,運輸層,應用層.

udp屬於運輸層,下面我們由下至上一步一步來看:

乙太網(ethernet)資料幀的長度必須在46-1500位元組之間,這是由乙太網的物理特性決定的。這個1500位元組被稱為鏈路層的mtu(最大傳輸單元)。

但這並不是指鏈路層的長度被限制在1500位元組,其實這這個mtu指的是鏈路層的資料區。 並不包括鏈路層的首部和尾部的18個位元組。 所以,事實上,這個1500位元組就是網路層ip資料報的長度限制。 因為ip資料報的首部為20位元組,所以ip資料報的資料區長度最大為1480位元組.

而這個1480位元組就是用來放tcp傳來的tcp報文段或udp傳來的udp資料報的。 又因為udp資料報的首部8位元組,所以udp資料報的資料區最大長度為1472位元組。這個1472位元組就是我們可以使用的位元組數。

超過1500位元組怎麼辦?

這也就是說ip資料報大於1500位元組,大於mtu.這個時候傳送方ip層就需要分片(fragmentation).

把資料報分成若干片,使每一片都小於mtu.而接收方ip層則需要進行資料報的重組.

這樣就會多做許多事情,而更嚴重的是,由於udp的特性,當某一片資料傳送中丟失時,接收方便

無法重組資料報.將導致丟棄整個udp資料報。

因此,在普通的區域網環境下,我建議將udp的資料控制在1472位元組以下為好.

進行internet程式設計時則不同,因為internet上的路由器可能會將mtu設為不同的值.

如果我們假定mtu為1500來傳送資料的,而途經的某個網路的mtu值小於1500位元組,那麼系統將會使用一系列的機

制來調整mtu值,使資料報能夠順利到達目的地,這樣就會做許多不必要的操作。鑑於internet上的標準mtu值為576位元組,

所以我建議在進行internet的udp程式設計時. 最好將udp的資料長度控制項在548位元組(576-8-20)以內.

二、tcp

tcp 包的大小就應該是 1500 - ip頭(20) - tcp頭(20) = 1460 (bytes)

我們在用socket程式設計時,udp協議要求包小於64k。tcp沒有限定,tcp包頭中就沒有「包長度」字段,而完全依靠ip層去處理分幀。這就是為什麼tcp常常被稱作一種「流協議」的原因,開發者在使用tcp服務的時候,不必去關心資料報的大小,只需講socket看作一條資料流的入口,往裡面放資料就是了,tcp協議本身會進行擁塞/流量控制。

diff命令 待完善

diff命令在最簡單的情況下,比較給定的兩個檔案的不同。如果使用 代替 檔案 引數,則要比較的內容將來自標準輸入。diff命令是以逐行的方式,比較文字檔案的異同處。如果該命令指定進行目錄的比較,則將會比較該目錄中具有相同檔名的檔案,而不會對其子目錄檔案進行任何比較操作。來自 diff命令在最簡單的情...

頁面效能 待完善

本文是學習慕課網上課程前端跳槽面試必備技巧的學習筆記,便於之後複習。本文說明頁面效能的方法 資源壓縮合併,減少http請求 非核心 非同步載入 非同步載入的方式 非同步載入的區別 利用瀏覽器快取 很關鍵的一步 快取的分類 快取的原理 使用cdn 預解析dns 標籤在很多瀏覽器中預設開啟預解析 如果是...

Windows HOOK總結 待完善

安裝鉤子 hhook winapi setwindowshookex 1,鉤子型別 in int idhook,2,函式位址,即掛鉤型別事件發生時,系統應該呼叫的函式 in hookproc lpfn,3,標識乙個dll,這個dll中包含第二個引數表示的函式 例項控制代碼 in hinstance ...