IP頭、TCP頭、UDP頭詳解以及定義__網路相關

來源:互聯網
上載者:User

一、MAC幀頭定義

/*資料幀定義,頭14個位元組,尾4個位元組*/
typedef struct _MAC_FRAME_HEADER
{
 char m_cDstMacAddress[6];    //目的mac地址
 char m_cSrcMacAddress[6];    //源mac地址
 short m_cType;            //上一層協議類型,如0x0800代表上一層是IP協議,0x0806為arp
}__attribute__((packed))MAC_FRAME_HEADER,*PMAC_FRAME_HEADER;

 

typedef struct _MAC_FRAME_TAIL
{
 unsigned int m_sCheckSum;    //資料幀尾校正和
}__attribute__((packed))MAC_FRAME_TAIL, *PMAC_FRAME_TAIL;

 

二、IP頭結構的定義


 

/*IP頭定義,共20個位元組*/
typedef struct _IP_HEADER 
{
 char m_cVersionAndHeaderLen;       //版本資訊(前4位),頭長度(後4位)
 char m_cTypeOfService;            // 服務類型8位
 short m_sTotalLenOfPacket;        //資料包長度
 short m_sPacketID;              //資料包標識
 short m_sSliceinfo;               //分區使用
 char m_cTTL;                  //存活時間
 char m_cTypeOfProtocol;          //協議類型
 short m_sCheckSum;             //校正和
 unsigned int m_uiSourIp;          //源ip
 unsigned int m_uiDestIp;          //目的ip
} __attribute__((packed))IP_HEADER, *PIP_HEADER ;

三、tcp頭結構定義


 

/*TCP頭定義,共20個位元組*/
typedef struct _TCP_HEADER 
{
 short m_sSourPort;              // 源連接埠號碼16bit
 short m_sDestPort;              // 目的連接埠號碼16bit
 unsigned int m_uiSequNum;         // 序號32bit
 unsigned int m_uiAcknowledgeNum;  // 確認號32bit
 short m_sHeaderLenAndFlag;        // 前4位:TCP頭長度;中6位:保留;後6位:標誌位
 short m_sWindowSize;            // 視窗大小16bit
 short m_sCheckSum;              // 檢驗和16bit
 short m_surgentPointer;           // 緊急資料位移量16bit
}__attribute__((packed))TCP_HEADER, *PTCP_HEADER;


/*TCP頭中的選項定義

kind(8bit)+Length(8bit,整個選項的長度,包含前兩部分)+內容(如果有的話)

KIND = 1表示 無操作NOP,無後面的部分

  2表示 maximum segment   後面的LENGTH就是maximum segment選項的長度(以byte為單位,1+1+內容部分長度)

  3表示 windows scale     後面的LENGTH就是 windows scale選項的長度(以byte為單位,1+1+內容部分長度)

  4表示 SACK permitted    LENGTH為2,沒有內容部分

  5表示這是一個SACK包     LENGTH為2,沒有內容部分

  8表示時間戳記,LENGTH為10,含8個位元組的時間戳記
*/

typedef struct _TCP_OPTIONS
{
 char m_ckind;
 char m_cLength;
 char m_cContext[32];
}__attribute__((packed))TCP_OPTIONS, *PTCP_OPTIONS;

 

四、UDP頭結構的定義


 

/*UDP頭定義,共8個位元組*/

typedef struct _UDP_HEADER 
{
 unsigned short m_usSourPort;       // 源連接埠號碼16bit
 unsigned short m_usDestPort;       // 目的連接埠號碼16bit
 unsigned short m_usLength;        // 資料包長度16bit
 unsigned short m_usCheckSum;      // 校正和16bit
}__attribute__((packed))UDP_HEADER, *PUDP_HEADER;

====

http://www.cnblogs.com/li-hao/archive/2011/12/07/2279912.html

-------------------------------------------------------------------------------------------------------------------------------------  tcp、ip、udp頭部格式  

2.2 TCP/IP報文格式

  

  1、IP報文格式

  

  IP協議是TCP/IP協議族中最為核心的協議。它提供不可靠、不需連線的服務,也即依賴其他層的協議進行差錯控制。在區域網路環境,IP協議往往被封裝在乙太網路幀(見本章1.3節)中傳送。而所有的TCP、UDP、ICMP、IGMP資料都被封裝在IP資料報中傳送。如圖2-3所示:

    

   圖2-3  TCP/IP報文封裝

  

  圖2-4是IP頭部(前序)格式:(RFC 791)。

    

   圖2-4  IP頭部格式

  

  其中:

  

  ●版本(Version)欄位:佔4位元。用來表明IP協議實現的版本號碼,當前一般為IPv4,即0100。

  

  ●前序長度(Internet Header Length,IHL)欄位:佔4位元。是頭部佔32位元的數字,包括可選項。普通IP資料報(沒有任何選項),該欄位的值是5,即160位元=20位元組。此欄位最大值為60位元組。

  

  ●服務類型(Type of Service ,TOS)欄位:佔8位元。其中前3位元為優先權子欄位(Precedence,現已被忽略)。第8位元保留未用。第4至第7位元分別代表延遲、輸送量、可靠性和花費。當它們取值為1時分別代表要求最小時延、最大輸送量、最高可靠性和最小費用。這4位元的服務類型中只能置其中1位元為1。可以全為0,若全為0則表示一般服務。服務類型欄位聲明了資料報被網路系統傳輸時可以被怎樣處理。例如:TELNET協議可能要求有最小的延遲,FTP協議(資料)可能要求有最大輸送量,SNMP協議可能要求有最高可靠性,NNTP(Network News Transfer Protocol,網路新聞傳輸通訊協定)可能要求最小費用,而ICMP協議可能無特殊要求(4位元全為0)。實際上,大部分主機會忽略這個欄位,但一些動態路由協議如OSPF(Open Shortest Path First Protocol)、IS-IS(Intermediate System to Intermediate System Protocol)可以根據這些欄位的值進行路由決策。

  

  ●總長度欄位:佔16位元。指明整個資料報的長度(以位元組為單位)。最大長度為65535位元組。

  

  ●標誌欄位:佔16位元。用來唯一地標識主機發送的每一份資料報。通常每發一份報文,它的值會加1。

  

  ●標誌位欄位:佔3位元。標誌一份資料報是否要求分段。

  

  ●段位移欄位:佔13位元。如果一份資料報要求分段的話,此欄位指明該段位移距未經處理資料報開始的位置。

  

  ●生存期(TTL:Time to Live)欄位:佔8位元。用來設定資料報最多可以經過的路由器數。由發送資料的源主機設定,通常為32、64、128等。每經過一個路由器,其值減1,直到0時該資料報被丟棄。

  

  ●協議欄位:佔8位元。指明IP層所封裝的上層協議類型,如ICMP(1)、IGMP(2) 、TCP(6)、UDP(17)等。

  

  ●頭部校正和欄位:佔16位元。內容是根據IP頭部計算得到的校正和碼。計算方法是:對頭部中每個16位元進行二進位反碼求和。(和ICMP、IGMP、TCP、UDP不同,IP不對頭部後的資料進行校正)。

  

  ●源IP地址、目標IP地址欄位:各佔32位元。用來標明發送IP資料報文的源主機地址和接收IP報文的目標主機地址。

  

  可選項欄位:佔32位元。用來定義一些任選項:如記錄路徑、時間戳記等。這些選項很少被使用,同時並不是所有主機和路由器都支援這些選項。可選項欄位的長度必須是32位元的整數倍,如果不足,必須填充0以達到此長度要求。

  

  2、TCP資料區段格式

  

  TCP是一種可靠的、連線導向的位元組流服務。源主機在傳送資料前需要先和目標主機建立串連。然後,在此串連上,被編號的資料區段按序收發。同時,要求對每個資料區段進行確認,保證了可靠性。如果在指定的時間內沒有收到目標主機對所發資料區段的確認,源主機將再次發送該資料區段。

  

  如圖2-5所示,是TCP頭部結構(RFC 793、1323)。

    

   圖2-5  TCP頭部結構

  

  ●源、目標連接埠號碼欄位:佔16位元。TCP協議通過使用"連接埠"來標識源端和目標端的應用進程。連接埠號碼可以使用0到65535之間的任何數字。在收到服務要求時,作業系統動態地為用戶端的應用程式分配連接埠號碼。在伺服器端,每種服務在"眾所周知的連接埠"(Well-Know Port)為使用者提供服務。

  

  ●順序號欄位:佔32位元。用來標識從TCP源端向TCP目標端發送的資料位元組流,它表示在這個報文段中的第一個資料位元組。

  

  ●確認號欄位:佔32位元。只有ACK標誌為1時,確認號欄位才有效。它包含目標端所期望收到源端的下一個資料位元組。

  

  ●頭部長度欄位:佔4位元。給出頭部佔32位元的數目。沒有任何選項欄位的TCP頭部長度為20位元組;最多可以有60位元組的TCP頭部。

  

  ●標誌位欄位(U、A、P、R、S、F):佔6位元。各位元的含義如下:

  

  ◆URG:緊急指標(urgent pointer)有效。

  

  ◆ACK:確認序號有效。

  

  ◆PSH:接收方應該儘快將這個報文段交給應用程式層。

  

  ◆RST:重建串連。

  

  ◆SYN:發起一個串連。

  

  ◆FIN:釋放一個串連。

  

  ●視窗大小欄位:佔16位元。此欄位用來進行流量控制。單位為位元組數,這個值是本機期望一次接收的位元組數。

  

  ●TCP校正和欄位:佔16位元。對整個TCP報文段,即TCP頭部和TCP資料進行校正和計算,並由目標端進行驗證。

  

  ●緊急指標欄位:佔16位元。它是一個位移量,和序號欄位中的值相加表示緊急資料最後一個位元組的序號。

  

  ●選項欄位:佔32位元。可能包括"視窗擴大因子"、"時間戳記"等選項。

  

  3、UDP資料區段格式

  

  UDP是一種不可靠的、不需連線的資料報服務。源主機在傳送資料前不需要和目標主機建立串連。資料被冠以源、目標連接埠號碼等UDP前序欄位後直接發往目的主機。這時,每個資料區段的可靠性依靠上層協議來保證。在傳送資料較少、較小的情況下,UDP比TCP更加高效。

  

  如圖2-6所示,是UDP頭部結構(RFC 793、1323):

    

   圖2-6  UDP資料區段格式

  

  ●源、目標連接埠號碼欄位:佔16位元。作用與TCP資料區段中的連接埠號碼欄位相同,用來標識源端和目標端的應用進程。

  

  ●長度欄位:佔16位元。標明UDP頭部和UDP資料的總長度位元組。

  

  ●校正和欄位:佔16位元。用來對UDP頭部和UDP資料進行校正。和TCP不同的是,對UDP來說,此欄位是可選項,而TCP資料區段中的校正和欄位是必須有的。

  

  2.3 通訊端

  

  在每個TCP、UDP資料區段中都包含源連接埠和目標連接埠欄位。有時,我們把一個IP地址和一個連接埠號碼合稱為一個通訊端(Socket),而一個通訊端對(Socket pair)可以唯一地確定互連網路中每個TCP串連的雙方(客戶IP地址、用戶端口號、伺服器IP地址、伺服器連接埠號碼)。

  

  如圖2-7所示,是常見的一些協議和它們對應的服務連接埠號碼。

    

   圖2-7  常見協議和對應的連接埠號碼

  

  需要注意的是,不同的應用程式層協議可能基於不同的傳輸層協議,如FTP、TELNET、SMTP協議基於可靠的TCP協議。TFTP、SNMP、RIP基於不可靠的UDP協議。

  

  同時,有些應用程式層協議佔用了兩個不同的連接埠號碼,如FTP的20、21連接埠,SNMP的161、162連接埠。這些應用程式層協議在不同的連接埠提供不同的功能。如FTP的21連接埠用來偵聽使用者的串連請求,而20連接埠用來傳送使用者的檔案資料。再如,SNMP的161連接埠用於SNMP管理進程擷取SNMP代理的資料,而162連接埠用於SNMP代理主動向SNMP管理進程發送資料。

  

  還有一些協議使用了傳輸層的不同協議提供的服務。如DNS協議同時使用了TCP 53連接埠和UDP 53連接埠。DNS協議在UDP的53連接埠提供網域名稱解析服務,在TCP的53連接埠提供DNS地區檔案傳輸服務。

  

  2.4 TCP串連建立、釋放時的握手過程

  

  1、TCP建立串連的三向交握過程

  

  TCP會話通過三向交握來初始化。三向交握的目標是使資料區段的發送和接收同步。同時也向其他主機表明其一次可接收的資料量(視窗大小),並建立邏輯串連。這三向交握的過程可以簡述如下:

  

  ●源主機發送一個同步標誌位(SYN)置1的TCP資料區段。此段中同時標明初始序號(Initial Sequence Number,ISN)。ISN是一個隨時間變化的隨機值。

  

  ●目標主機發回確認資料區段,此段中的同步標誌位(SYN)同樣被置1,且確認標誌位(ACK)也置1,同時在確認序號欄位表明目標主機期待收到源主機下一個資料區段的序號(即表明前一個資料區段已收到並且沒有錯誤)。此外,此段中還包含目標主機的段初始序號。

  

  ●源主機再回送一個資料區段,同樣帶有遞增的發送序號和確認序號。

  

  至此為止,TCP會話的三向交握完成。接下來,源主機和目標主機可以互相收發資料。整個過程可用圖2-8表示。

    

   圖2-8  TCP建立串連的三向交握過程

  

  2、TCP釋放串連的四次握手過程

  

  TCP串連的釋放需要進行四次握手,步驟是:

  

  ●源主機發送一個釋放串連標誌位(FIN)為1的資料區段發出結束會話請求

http://zoufengfu168.blog.163.com/blog/static/5461055200991333616451/

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.