16位源埠號：TCP 發端 埠號（標示傳送方計算機上的應用程式收發埠）。

16位目的埠號：TCP 接收端埠號（標示接收方計算機上應用程式收發埠）

32位序號（sequence number）：將整個一次TCP 通訊（從三次握手到四次揮手）中傳輸的傳送方傳送的資料作為一次流動的位元組流，32位序號，它表示在傳送的這個報文段第一個位元組在整個位元組流中所處的位元組位置。在tcp中tcp用序號對每個位元組進行計數（這個值與傳送的幀數沒有關係，而是與傳送的資料位元組數有關係)。

32位確認序號：一次TCP通訊中，傳送該報文的傳送方，確認收到的另一方傳送過來的位元組序+1（即所期望收到的下一個序號）。

4位資料偏移

保留（6位）：6位值域，這些位必須是0。

URG： 緊急指標（ urgent pointer）有效。 
ACK： 確認序號有效。 
PSH： 接收方應該儘快將這個報文段交給應用層。 
RST： 重建連線。 
SYN： 同步序號用來發起一個連線。 
FIN： 發端完成傳送任務。

16位視窗大小：流量控制，用來表示想收到的每個TCP資料段的大小。

16位校驗和：檢驗和覆蓋了整個的 TCP報文段（TCP首部和TCP資料），收資訊機要與源機器數值 結果完全一樣，從而證明資料的有效性。檢驗和覆蓋了整個的TCP報文段。

16位緊急指標：指向後面是優先資料的位元組，在URG標誌設定了時才有效。如果URG標誌沒有被設定，緊急域作為填充。加快處理標示為緊急的資料段。

選項：長度不定，但長度必須為1個位元組。如果沒有選項就表示這個1位元組的域等於0。

資料：該TCP協議包負載的資料。

• wireshark 分析TCP 協議

• 傳送 3個字串

如上圖所示傳送“123”，這個字串。注意此時sequence number 為1， TCP segment data 為3 bytes。 則下一次傳送的報文起始位元組為【next sequence number：4】。

• 傳送長字串

 接著傳送1個大小為2523 位元組的長字串。

wireshark捕獲到的資料如下：

可以看出： 2523位元組長度的資料被分為了len=1452，和len=1071 這2個報文傳送。

觀察其中的第一個報文，可以發現Sequence number：4。

正好對應了第一次傳送3個位元組的短字串【next sequence number：4】。

因此可以得出結論： 多次send之間tcp連線通過位元組流序，保證了收發位元組順序的一致。

為什麼2523位元組長度的資料被分為2個數據包傳送1452,1072 2個報文傳送？

通過觀察整個通訊流程，發現在三次握手時，有mss協商：

。因此可以得出結論：

理論上tcp沒有規定1個tcp報文資料長度，但通過三次握手協商了各方最大發送的資料長度。因此超過這個長度的資料將被分包。

• UDP協議分析：

源埠和目的埠：（埠是用來指明資料的來源（應用程式）以及資料發往的目的地（同樣是應用程式））欄位包含了16位元的UDP協議埠號，它使得多個應用程式可以多路複用同一個傳輸層協議及UDP協議，僅通過埠號來區分不同的應用程式。

長度（length）：欄位記錄了該UDP資料包的總長度（以位元組為單位），包括8位元組的UDP頭和其後的資料部分。最小值是8（報文頭的長度），最大值為65535位元組。


UDP校驗和（Checksum）：的內容超出了UDP資料報文字身的範圍，實際上，它的值是通過計算UDP資料報及一個偽包頭而得到的。校驗和的計算方法與通用的一樣，都是累加求和。UDP資料報中實際的有效成分。偽首部並非TCP&UDP資料報中實際的有效成分。偽首部是一個虛擬的資料結構，其中的資訊是從資料報所在IP分組頭的分組頭中提取的，既不向下傳送也不向上遞交，而僅僅是為計算校驗和。這樣的校驗和，既校驗了TCP&UDP使用者資料的源埠號和目的埠號以及TCP&UDP使用者資料報的資料部分，又檢驗了IP資料報的源IP地址（資料來源裝置）和目的地址。偽報頭保證TCP&UDP資料單元到達正確的目的地址。

經過試驗，無論多大包，從udp協議這一層級來說，並沒有分為多個udp包。在試驗中： 當包的長度達到10153時，接收端根本無法接收到傳送的包（傳送發並不能得到是否接收成功的訊息）。

建議傳送的包長度不超過512 byte。