linux網路編程之TCP/IP基礎（五）：分析一幀基於UDP的TFTP協議幀

是UDP的段格式：

相比TCP段格式，UDP要簡單得多，也沒啥好說的，需要注意的是UDP資料長度指payload加上首部的長度。

下面分析一幀基於UDP的TFTP協議幀：

乙太網路首部

0000: 00 05 5d 67 d0 b1 00 05 5d 61 58 a8 08 00 

IP首部

0000: 45 00

0010: 00 53 93 25 00 00 80 11 25 ec c0 a8 00 37 c0 a8

0020: 00 01

UDP首部

0020： 05 d4 00 45 00 3f ac 40

TFTP協議

0020: 00 01 'c' ':' '\' 'q'

0030: 'w' 'e' 'r' 'q' '.' 'q' 'w' 'e' 00 'n' 'e' 't' 'a' 's' 'c' 'i'

0040: 'i' 00 'b' 'l' 'k' 's' 'i' 'z' 'e' 00 '5' '1' '2' 00 't' 'i'

0050: 'm' 'e' 'o' 'u' 't' 00 '1' '0' 00 't' 's' 'i' 'z' 'e' 00 '0'

0060: 00

乙太網路首部：源MAC地址是00:05:5d:61:58:a8，目的MAC地址是00:05:5d:67:d0:b1，上層協議類型0x0800表示IP。

IP首部：每一個位元組0x45包含4位版本號碼和4位首部長度，版本號碼為4，即IPv4，首部長度為5，說明IP首部不帶有選項欄位。服務類型為0，沒有使用服務。16位總長度欄位（包括IP首部和IP層payload的長度）為0x0053，即83位元組，加上乙太網路首部14+4位元組可知整個幀長度是101位元組。IP報標識是0x9325，標誌欄位和片位移欄位設定為0x0000，就是DF=0允許分區，MF=0此資料報沒有更多分區，沒有分區位移。TTL是0x80，也就是128。上層協議0x11表示UDP協議。IP首部校正和為0x25ec，源主機IP是c0
a8 00 37（192.168.0.55），目的主機IP是c0 a8 0001（192.168.0.1）。

UDP首部：源連接埠號碼0x05d4（1492）是用戶端的連接埠號碼，目的連接埠號碼0x0045（69）是TFTP服務的well-known連接埠號碼。UDP報長度為0x003f，即63位元組，包括UDP首部和UDP層payload的長度。UDP首部和UDP層payload的校正和為0xac40。

TFTP是基於文本的協議，各欄位之間用位元組0分隔，開頭的00 01表示請求讀取一個檔案，接下來的各欄位是：
c:\qwerq.qwe

netascii

blksize 512

timeout 10

tsize 0

就我個人而言，學習tcp/ip時最容易迷糊的就是那些資料大小，頭部大小什麼的，現在來總結一下，也許大家會清晰一點：

耐心地數一下，可知道tftp的純資料供55位元組（udp payload），加上udp頭部8位元組，就是63位元組，也就是前面說的UDP 頭部欄位記錄的UDP資料長度，再加上ip頭部20位元組，也就是83位元組，即前面說的ip頭部記錄的ip包大小，即udp payload + udp頭部 可以當作ip 層的payload，ip層payload
+ ip頭部 = 83位元組，加上乙太網路頭部14位元組，尾部校正4位元組，總共101位元組，即完整的一幀資料幀。

一般的網路通訊都是像TFTP協議這樣，通訊的雙方分別是用戶端和伺服器，用戶端主動發起請求（上面的例子就是用戶端發起的請求幀），而伺服器被動地等待、接收和應答請求。用戶端的IP地址和連接埠號碼唯一標識了該主機上的TFTP用戶端進程，伺服器的IP地址和連接埠號碼唯一標識了該主機上的TFTP服務進程，由於用戶端是主動發起請求的一方，它必須知道伺服器的IP地址和TFTP服務進程的連接埠號碼，所以，一些常見的網路通訊協定有預設的伺服器連接埠，例如HTTP服務預設TCP協議的80連接埠，FTP服務預設TCP協議的21連接埠，TFTP服務預設UDP協議的69連接埠（如上例所示）。在使用用戶端程式時，必須指定伺服器的主機名稱或IP地址，如果不明確指定連接埠號碼則採用預設連接埠，可以查閱ftp、tftp等程式的man
page瞭解如何指定連接埠號碼。/etc/services中列出了所有well-known的服務連接埠和對應的傳輸層協議，這是由IANA（Internet Assigned Numbers Authority）規定的，其中有些服務既可以用TCP也可以用UDP，為了清晰，IANA規定這樣的服務採用相同的TCP或UDP預設連接埠號碼，而另外一些TCP和UDP的相同連接埠號碼卻對應不同的服務。

很多服務有well-known的連接埠號碼，然而用戶端程式的連接埠號碼卻不必是well-known的，往往是每次運行用戶端程式時由系統自動分配一個閒置連接埠號碼，用完就釋放掉，稱為ephemeral的連接埠號碼。

UDP協議不連線導向，也不保證傳輸的可靠性，例如：

1、發送端的UDP協議層只管把應用程式層傳來的資料封裝成段交給IP協議層就算完成任務了，如果因為網路故障該段無法發到對方，UDP協議層也不會給應用程式層返回任何錯誤資訊。

2、接收端的UDP協議層只管把收到的資料根據連接埠號碼交給相應的應用程式就算完成任務了，如果發送端發來多個資料包並且在網路上經過不同的路由，到達接收端時順序已經錯亂了，UDP協議層也不保證按發送時的順序交給應用程式層。

3、通常接收端的UDP協議層將收到的資料放在一個固定大小的緩衝區中等待應用程式來提取和處理，如果應用程式提取和處理的速度很慢，而發送端發送的速度很快，就會遺失資料包，UDP協議層並不報告這種錯誤。

因此，使用UDP協議的應用程式必須考慮到這些可能的問題並實現適當的解決方案，例如等待應答、逾時重發、為資料包編號、流量控制等。一般使用UDP協議的應用程式實現都比較簡單，只是發送一些對可靠性要求不高的訊息，而不發送大量的資料。例如，基於UDP的TFTP協議一般只用於傳送小檔案（所以才叫trivial的ftp），而基於TCP的FTP協議適用於各種檔案的傳輸。

參考：

《Linux C 編程一站式學習》

《TCP/IP詳解 卷一》