如圖所示：
tcp首部行開銷為20位元組而udp則為8位元組，所以udp分組首部開銷更小。
文件為：rfc 1071
從上圖的報文段結構我們知道每個首部欄位為16位元。現在假設源埠號、目的埠號和長度字段三個16位元字分別為：
源埠號：0110 0110 0110 0000——十進位制：26208
目的埠號：0101 0101 0101 0101——十進位制：21845
長度字段：1000 1111 0000 1100——十進位制：36620
1、現在第一步：計算傳送方udp報文段檢驗和
從圖可知檢驗和為：1011 0101 0011 1101——也是16位元字。
2、現在我們得到我們的udp報文段首部行了，那麼加上應用資料我們就得到了乙個udp報文段了
3、接受方進行差錯檢測
接受方得到了我們傳送過去的udp報文段，現在它將得到的報文段的首部行欄位（4個16位元字加在一起）求和——源埠號+目的埠號+長度+檢驗和，注意溢位的部分要進行回卷。（把所有16位的字相加，如果遇到進製，則將高於16位元組的進製部分的值加到最低位上）
從源發出的udp報文段我們知道該和應該等於：
也就是說如果這些位元的和中有乙個位是0，則說明該分組出現了差錯。
實際上，計算檢驗和checksum時除了udp報文段以外還包括ip首部的一些字段為什麼udp首先提供了檢驗和就像許多鏈路層協議（包括流行的乙太網協議）也提供了差錯檢測那樣。原因是不能保證源和目的之間所有的鏈路都提供了差錯檢測。只要有一條鏈路使用了沒有差錯檢測的協議，我們如果要保證端到端的資料傳輸服務提供差錯檢測，udp則需要在端到端的基礎上在運輸層提供差錯檢測。這是乙個在系統設計中被稱頌的端到端原則（end-end principle）
TCP報文段中的序號和確認號
前言 序號欄位和確認號字段是tcp報文段首部中兩個最重要的字段，這兩個欄位是tcp可靠傳輸服務的關鍵部分。tcp把資料看成乙個無結構的 有序的位元組流。序號是建立在傳送的字元流之上的，而不是建立在傳送的報文段的序列之上 序號 32bit 乙個報文段的序號是該報文段首位元組的位元組流編號，舉個栗子 假...
Linux 核心IP和UDP檢驗和計算
ip checksum a.接收報文 struct iphdr iph ip hdr skb if unlikely ip fast csum u8 iph,iph ihl goto checksum error b.傳送報文 ip send check iph udp checksum a.網絡卡...
核心udp報文擷取 修改和傳送
近來做乙個產品需要在閘道器上獲取特定udp埠 假設是1000埠 的報文，並將其 給其它裝置的1000埠。雖然此類文章網上已經有很多了，但我還是貼上來，這樣自己也做下記錄，大家也多乙份參考。下面只給出了 片段，自己慢慢除錯。我們假設網路拓撲如下所示 linux pc 1 server datasrv ...