IP段格式

IP數(shù)據(jù)報的首部長度和數(shù)據(jù)長度都是可變長的，但總是4字節(jié)的整數(shù)倍。

對于IPv4，4位版本字段是4。4位首部長度的數(shù)值是以4字節(jié)為單位的，最小值為5，也就是說首部長度最小是4x5=20字節(jié)，也就是不帶任何選項的IP首部，4位能表示的最大值是15，也就是說首部長度最大是60字節(jié)。

8位TOS字段有3個位用來指定IP數(shù)據(jù)報的優(yōu)先級（目前已經(jīng)廢棄不用），還有4個位表示可選的服務(wù)類型（最小延遲、最大?吐量、最大可靠性、最小成本），還有一個位總是0。總長度是整個數(shù)據(jù)報（包括IP首部和IP層payload）的字節(jié)數(shù)。每傳一個IP數(shù)據(jù)報，16位的標(biāo)識加1，可用于分片和重新組裝數(shù)據(jù)報。

3位標(biāo)志和13位片偏移用于分片。TTL（Time to live)是這樣用的：源主機為數(shù)據(jù)包設(shè)定一個生存時間，比如64，每過一個路由器就把該值減1，如果減到0就表示路由已經(jīng)太長了仍然找不到目的主機的網(wǎng)絡(luò)，就丟棄該包，因此這個生存時間的單位不是秒，而是跳（hop）。協(xié)議字段指示上層協(xié)議是TCP、UDP、ICMP還是IGMP。然后是校驗和，只校驗IP首部，數(shù)據(jù)的校驗由更高層協(xié)議負責(zé)。IPv4的IP地址長度為32位。

想一想，前面講了以太網(wǎng)幀中的最小數(shù)據(jù)長度為46字節(jié)，不足46字節(jié)的要用填充字節(jié)補上，那么如何界定這46字節(jié)里前多少個字節(jié)是IP、ARP或RARP數(shù)據(jù)報而后面是填充字節(jié)？

UDP數(shù)據(jù)報格式

UDP數(shù)據(jù)段

下面分析一幀基于UDP的TFTP協(xié)議幀。
以太網(wǎng)首部
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協(xié)議
0020: 00 01 ‘c’’:’’’‘q’
0030: ‘w’‘e’‘r’‘q’’.’‘q’‘w’'e’00 ‘n’‘e’‘t’‘a(chǎn)’‘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以太網(wǎng)首部：源MAC地址是00:05:5d:61:58:a8，目的MAC地址是00:05:5d:67:d0:b1，上層協(xié)議類型0x0800表示IP。

IP首部：每一個字節(jié)0x45包含4位版本號和4位首部長度，版本號為4，即IPv4，首部長度為5，說明IP首部不帶有選項字段。服務(wù)類型為0，沒有使用服務(wù)。16位總長度字段（包括IP首部和IP層payload的長度）為0x0053，即83字節(jié)，加上以太網(wǎng)首部14字節(jié)可知整個幀長度是97字節(jié)。IP報標(biāo)識是0x9325，標(biāo)志字段和片偏移字段設(shè)置為0x0000，就是DF=0允許分片，MF=0此數(shù)據(jù)報沒有更多分片，沒有分片偏移。TTL是0x80，也就是128。上層協(xié)議0x11表示UDP協(xié)議。IP首部校驗和為0x25ec，源主機IP是c0 a8 00 37（192.168.0.55），目的主機IP是c0 a8 00 01（192.168.0.1）。

UDP首部：源端口號0x05d4（1492）是客戶端的端口號，目的端口號0x0045（69）是TFTP服務(wù)的well-known端口號。UDP報長度為0x003f，即63字節(jié)，包括UDP首部和UDP層pay-load的長度。UDP首部和UDP層payload的校驗和為0xac40。
TFTP是基于文本的協(xié)議，各字段之間用字節(jié)0分隔，開頭的00 01表示請求讀取一個文件，接下來的各字段是：
c:\qwerq.qwe
netascii
blksize 512
timeout 10
tsize 0

一般的網(wǎng)絡(luò)通信都是像TFTP協(xié)議這樣，通信的雙方分別是客戶端和服務(wù)器，客戶端主動發(fā)起請求（上面的例子就是客戶端發(fā)起的請求幀），而服務(wù)器被動地等待、接收和應(yīng)答請求。客戶端的IP地址和端口號唯一標(biāo)識了該主機上的TFTP客戶端進程，服務(wù)器的IP地址和端口號唯一標(biāo)識了該主機上的TFTP服務(wù)進程，由于客戶端是主動發(fā)起請求的一方，它必須知道服務(wù)器的IP地址和TFTP服務(wù)進程的端口號，所以，一些常見的網(wǎng)絡(luò)協(xié)議有默認的服務(wù)器端口，

例如HTTP服務(wù)默認TCP協(xié)議的80端口，FTP服務(wù)默認TCP協(xié)議的21端口，TFTP服務(wù)默認UDP協(xié)議的69端口（如上例所示）。

在使用客戶端程序時，必須指定服務(wù)器的主機名或IP地址，如果不明確指定端口號則采用默認端口，請讀者查閱ftp、tftp等程序的man page了解如何指定端口號。

/etc/services中列出了所有well-known的服務(wù)端口和對應(yīng)的傳輸層協(xié)議，

這是由IANA（Internet Assigned Numbers Authority）規(guī)定的，**其中有些服務(wù)既可以用TCP也可以用UDP，為了清晰，IANA規(guī)定這樣的服務(wù)采用相同的TCP或UDP默認端口號，**而另外一些TCP和UDP的相同端口號卻對應(yīng)不同的服務(wù)。

很多服務(wù)有well-known的端口號，然而客戶端程序的端口號卻不必是well-known的，往往是每次運行客戶端程序時由系統(tǒng)自動分配一個空閑的端口號，用完就釋放掉，稱為ephemeral的端口號，想想這是為什么？

前面提過，UDP協(xié)議不面向連接，也不保證傳輸?shù)目煽啃?/strong>，例如：
發(fā)送端的UDP協(xié)議層只管把應(yīng)用層傳來的數(shù)據(jù)封裝成段交給IP協(xié)議層就算完成任務(wù)了，如果因為網(wǎng)絡(luò)故障該段無法發(fā)到對方，UDP協(xié)議層也不會給應(yīng)用層返回任何錯誤信息。

接收端的UDP協(xié)議層只管把收到的數(shù)據(jù)根據(jù)端口號交給相應(yīng)的應(yīng)用程序就算完成任務(wù)了，如果發(fā)送端發(fā)來多個數(shù)據(jù)包并且在網(wǎng)絡(luò)上經(jīng)過不同的路由，到達接收端時順序已經(jīng)錯亂了，UDP協(xié)議層也不保證按發(fā)送時的順序交給應(yīng)用層。

通常接收端的UDP協(xié)議層將收到的數(shù)據(jù)放在一個固定大小的緩沖區(qū)中等待應(yīng)用程序來提取和處理，如果應(yīng)用程序提取和處理的速度很慢，而發(fā)送端發(fā)送的速度很快，就會丟失數(shù)據(jù)包，UDP協(xié)議層并不報告這種錯誤。

因此，使用UDP協(xié)議的應(yīng)用程序必須考慮到這些可能的問題并實現(xiàn)適當(dāng)?shù)慕鉀Q方案，例如等待應(yīng)答、超時重發(fā)、為數(shù)據(jù)包編號、流量控制等。一般使用UDP協(xié)議的應(yīng)用程序?qū)崿F(xiàn)都比較簡單，只是發(fā)送一些對可靠性要求不高的消息，而不發(fā)送大量的數(shù)據(jù)。例如，基于UDP的TFTP協(xié)議一般只用于傳送小文件（所以才叫trivial的ftp），而基于TCP的FTP協(xié)議適用于 各種文件的傳輸。TCP協(xié)議又是如何用面向連接的服務(wù)來代替應(yīng)用程序解決傳輸?shù)目煽啃詥栴}呢。

TCP數(shù)據(jù)報格式

與UDP協(xié)議一樣也有源端口號和目的端口號，通訊的雙方由IP地址和端口號標(biāo)識。32位序號、32位確認序號、窗口大小稍后詳細解釋。4位首部長度和IP協(xié)議頭類似，表示TCP協(xié)議頭的長度，以4字節(jié)為單位，因此TCP協(xié)議頭最長可以是4x15=60字節(jié)，如果沒有選項字段，TCP協(xié)議頭最短20字節(jié)。URG、ACK、PSH、RST、SYN、FIN是六個控制位，

總結(jié)

以上是生活随笔為你收集整理的网络基础3（IP段格式，UDP数据报格式，TCP数据报格式）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。