TCP/IP协议头部结构体
标签:
信息安全it |
分类: 在,进化 |
TCP/IP协议头部结构体(转)
网络协议结构体定义
-
//
i386 is little_endian. -
#ifndef
LITTLE_ENDIAN -
#define
LITTLE_ENDIAN (1) //BYTE ORDER -
#else
-
#error
Redefine LITTLE_ORDER -
#endif
-
//Mac头部,总长度14字节
-
typedef
struct _eth_hdr -
{
-
unsigned char dstmac[6]; //目标mac地址 -
unsigned char srcmac[6]; //源mac地址 -
unsigned short eth_type; //以太网类型 -
}eth_hdr;
-
//IP头部,总长度20字节
-
typedef
struct _ip_hdr -
{
-
#if LITTLE_ENDIAN -
unsigned char ihl:4; //首部长度 -
unsigned char version:4, //版本 -
#else -
unsigned char version:4, //版本 -
unsigned char ihl:4; //首部长度 -
#endif -
unsigned char tos; //服务类型 -
unsigned short tot_len; //总长度 -
unsigned short id; //标志 -
unsigned short frag_off; //分片偏移 -
unsigned char ttl; //生存时间 -
unsigned char protocol; //协议 -
unsigned short chk_sum; //检验和 -
struct in_addr //源IP地址srcaddr; -
struct in_addr //目的IP地址dstaddr; -
}ip_hdr;
-
//TCP头部,总长度20字节
-
typedef
struct _tcp_hdr -
{
-
unsigned short src_port; //源端口号 -
unsigned short dst_port; //目的端口号 -
unsigned int seq_no; //序列号 -
unsigned int ack_no; //确认号 -
#if LITTLE_ENDIAN -
unsigned char reserved_1:4; //保留6位中的4位首部长度 -
unsigned char thl:4; //tcp头部长度 -
unsigned char flag:6; //6位标志 -
unsigned char reseverd_2:2; //保留6位中的2位 -
#else -
unsigned char thl:4; //tcp头部长度 -
unsigned char reserved_1:4; //保留6位中的4位首部长度 -
unsigned char reseverd_2:2; //保留6位中的2位 -
unsigned char flag:6; //6位标志 -
#endif -
unsigned short wnd_size; //16位窗口大小 -
unsigned short chk_sum; //16位TCP检验和 -
unsigned short urgt_p; //16为紧急指针 -
}tcp_hdr;
-
//UDP头部,总长度8字节
-
typedef
struct _udp_hdr -
{
-
unsigned short src_port; //远端口号 -
unsigned short dst_port; //目的端口号 -
unsigned short uhl; //udp头部长度 -
unsigned short chk_sum; //16位udp检验和 -
}udp_hdr;
-
//ICMP头部,总长度4字节
-
typedef
struct _icmp_hdr -
{
-
unsigned char icmp_type; //类型 -
unsigned char code; //代码 -
unsigned short chk_sum; //16位检验和 -
}icmp_hdr;
全面的网络协议结构体定义
-
-
//计算机网络各种协议的结构
-
#define
ETHER_ADDR_LEN 6 //NIC物理地址占6字节 -
#define
MAXDATA 10240 -
-
#define
ETHERTYPE_IP 0x0800 //IP Protocal -
#define
ETHERTYPE_ARP 0x0806 //Address Resolution Protocal -
#define
ETHERTYPE_REVARP 0x0835 //Reverse Address Resolution Protocal 逆地址解析协议 -
-
//ethernet
-
typedef
struct ether_header -
{
-
u_char ether_dhost[ETHER_ADDR_LEN]; -
u_char ether_shost[ETHER_ADDR_LEN]; -
u_short ether_type; -
}ETH_HEADER;
-
-
//ether_header
eth; -
-
//arp
-
typedef
struct arphdr -
{
-
u_short ar_hrd; -
u_short ar_pro; -
u_char ar_hln; -
u_char ar_pln; -
u_short ar_op; -
}ARP_HEADER;
-
-
-
//IP报头
-
typedef
struct ip -
{
-
u_int ip_v:4; //version(版本) -
u_int ip_hl:4; //header length(报头长度) -
u_char ip_tos; -
u_short ip_len; -
u_short ip_id; -
u_short ip_off; -
u_char ip_ttl; -
u_char ip_p; -
u_short ip_sum; -
struct in_addr ip_src; -
struct in_addr ip_dst; -
}IP_HEADER;
-
-
-
//TCP报头结构体
-
typedef
struct tcphdr -
{
-
u_short th_sport; -
u_short th_dport; -
u_int th_seq; -
u_int th_ack; -
u_int th_off:4; -
u_int th_x2:4; -
u_char th_flags; -
u_short th_win; -
u_short th_sum; -
u_short th_urp; -
}TCP_HEADER;
-
#define
TH_FIN 0x01 -
#define
TH_SYN 0x02 -
#define
TH_RST 0x04 -
#define
TH_PUSH 0x08 -
#define
TH_ACK 0x10 -
#define
TH_URG 0x20 -
-
-
//UDP报头结构体*/
-
typedef
struct udphdr -
{
-
u_short uh_sport; -
u_short uh_dport; -
u_short uh_ulen; -
u_short uh_sum; -
}UDP_HEADER;
-
-
//=============================================
-
-
-
typedef
struct ether_arp -
{
-
struct arphdr ea_hdr; -
u_char arp_sha[ETHER_ADDR_LEN]; -
u_char arp_spa[4]; -
u_char arp_tha[ETHER_ADDR_LEN]; -
u_char arp_tpa[4]; -
}ETH_ARP;
-
#define
arp_hrd ea_hdr.ar_hrd -
#define
arp_pro ea_hdr.ar_pro -
#define
arp_hln ea_hdr.ar_hln -
#define
arp_pln ea_hdr.ar_pln -
#define
arp_op ea_hdr.ar_op -
#define
ARPHRD 1 -
-
-
//tcp与ip生成的报头
-
typedef
struct packet_tcp -
{
-
struct ip ip; -
struct tcphdr tcp; -
u_char data[MAXDATA]; -
}TCP_IP;
-
-
-
//udp与ip生成的报头
-
typedef
struct packet_udp -
{
-
struct ip ip; -
struct udphdr udp; -
}UDP_IP;
-
-
-
//ICMP的各种形式
-
//icmpx,x==icmp_type;
-
//icmp报文(能到达目的地,响应-请求包)
-
struct
icmp8 -
{
-
u_char icmp_type; //type of message(报文类型) -
u_char icmp_code; //type sub code(报文类型子码) -
u_short icmp_cksum; -
u_short icmp_id; -
u_short icmp_seq; -
char icmp_data[1]; -
};
-
//icmp报文(能返回目的地,响应-应答包)
-
struct
icmp0 -
{
-
u_char icmp_type; //type of message(报文类型) -
u_char icmp_code; //type sub code(报文类型子码) -
u_short icmp_cksum; -
u_short icmp_id; -
u_short icmp_seq; -
char icmp_data[1]; -
};
-
//icmp报文(不能到达目的地)
-
struct
icmp3 -
{
-
u_char icmp_type; //type of message(报文类型) -
u_char icmp_code; //type sub code(报文类型子码),例如:0网络原因不能到达,1主机原因不能到达... -
u_short icmp_cksum; -
u_short icmp_pmvoid; -
u_short icmp_nextmtu; -
char icmp_data[1]; -
};
-
//icmp报文(重发结构体)
-
struct
icmp5 -
{
-
u_char icmp_type; //type of message(报文类型) -
u_char icmp_code; //type sub code(报文类型子码) -
u_short icmp_cksum; -
struct in_addr icmp_gwaddr; -
char icmp_data[1]; -
};
-
struct
icmp11 -
{
-
u_char icmp_type; //type of message(报文类型) -
u_char icmp_code; //type sub code(报文类型子码) -
u_short icmp_cksum; -
u_int icmp_void; -
char icmp_data[1]; -
};
IP协议
IP协议(Internet
Protocol)是网络层协议,用在因特网上,TCP,UDP,ICMP,IGMP数据都是按照IP数据格式发送得。IP协议提供的是不可靠无连接得服务。IP数据包由一个头部和一个正文部分构成。正文主要是传输的数据,我们主要来理解头部数据,可以从其理解到IP协议。
IP数据包头部格式(RFC791)
http://hi.csdn.net/attachment/201006/10/0_1276179829C9TC.gif
Example Internet Datagram Header
上面的就是IP数据的头部格式,这里大概地介绍一下。
IP头部由20字节的固定长度和一个可选任意长度部分构成,以大段点机次序传送,从左到
右。
TCP协议
TCP协议(TRANSMISSION CONTROL
PROTOCOL)是传输层协议,为应用层提供服务,和UDP不同的是,TCP协议提供的可靠的面向连接的服务。在RFC793中是基本的TCP描述。关于TCP协议的头部格式内容的说明:
TCP Header FORMat
http://hi.csdn.net/attachment/201006/10/0_1276179877HHHd.gif
TCP Header FORMat
跟IP头部差不多,基本的长度也是20字节。TCP数据包是包含在一个IP数据报文中的。
好了,简单介绍到此为止。来看看我捕获的例子吧。这是一次FTP的连接,呵呵,是cuteftp默认的cuteftp的FTP站点,IP地址是:216.3.226.21。我的IP地址假设为:192.168.1.1。下面的数据就是TCO/IP连接过程中的数据传输。我们可以分析TCP/IP协议数据格式以及TCP/IP连接的三次握手(ThreeWay-Handshake)情况。下面的这些十六进制数据只是TCP/IP协议的数据,不是完整的网络通讯数据。
第一次,我向FTP站点发送连接请求(我把TCP数据的可选部分去掉了)
192.168.1.1->216.3.226.21
IP头部: 45 00 00 30 52 52 40 00 80 06 2c 23 c0 a8 01 01 d8 03 e2
15
TCP头部:0d 28 00 15 50 5f a9 06 00 00 00 00 70 02 40 00 c0 29 00
00
来看看IP头部的数据是些什么。
第一字节,“45”,其中“4”是IP协议的版本(Version),说明是IP4。“5”是IHL位,表示IP头部的长度,是一个4bit字段,最大就是1111了,值为12,IP头部的最大长度就是60字节。而这里为“5”,说明是20字节,这是标准的IP头部长度,头部报文中没有发送可选部分数据。
接下来的一个字节“00”是服务类型(Type of
Service)。这个8bit字段由3bit的优先权子字段(现在已经被忽略),4 bit的TOS子字段以及1
bit的未用字段(现在为0)构成.4
bit的TOS子字段包含:最小延时、最大吞吐量、最高可靠性以及最小费用构成,这四个1bit位最多只能有一个为1,本例中都为0,表示是一般服务。
接着的两个字节“00
30”是IP数据报文总长,包含头部以及数据,这里表示48字节。这48字节由20字节的IP头部以及28字节的TCP头构成(本来截取的TCP头应该是28字节的,其中8字节为可选部分,被我省去了)。因此目前最大的IP数据包长度是65535字节。
再是两个字节的标志位(Identification):“5252”,转换为十进制就是21074。这个是让目的主机来判断新来的分段属于哪个分组。
下一个字节“40”,转换为二进制就是“0100
0000”,其中第一位是IP协议目前没有用上的,为0。接着的是两个标志DF和MF。DF为1表示不要分段,MF为1表示还有进一步的分段(本例为0)。然后的“0
0000”是分段便移(Fragment Offset)。
“80”这个字节就是TTL(Time To
Live)了,表示一个IP数据流的生命周期,用Ping显示的结果,能得到TTL的值,很多文章就说通过TTL位来判别主机类型。因为一般主机都有默认的TTL值,不同系统的默认值不一样。比如WINDOWS为128。不过,一般Ping得到的都不是默认值,这是因为每次IP数据包经过一个路由器的时候TTL就减一,当减到0时,这个数据包就消亡了。这也时Tracert的原理。本例中为“80”,转换为十进制就是128了,我用的WIN2000。
继续下来的是“06”,这个字节表示传输层的协议类型(Protocol)。在RFC790中有定义,6表示传输层是TCP协议。
“2c 23”这个16bit是头校验和(Header Checksum)。
接下来“c0 a8 01 01”,这个就是源地址(Source
Address)了,也就是我的IP地址。
转换为十进制的IP地址就是:192.168.1.1,同样,继续下来的32位“d8 03 e2
15”是目标地址,216.3.226.21
好了,真累啊,终于看完基本的20字节的IP数据报头了。继续看TCP的头部吧,这个是作为IP数据包的数据部分传输的。
TCP头部:0d 28 00 15 50 5f a9 06 00 00 00 00 70 02 40 00 c0 29 00
00
一来就是一个两字节段“0d 28”,表示本地端口号,转换为十进制就是3368。第二个两字节段“00
15”表示目标端口,因为我是连接FTP站点,所以,这个就是21啦,十六进制当然就是“00
15”。
接下来的四个字节“50 5f a9 06”是顺序号(Sequence
Number),简写为SEQ,SEQ=1348446470下面的四个字节“00 00 00
00”是确认号(Acknowledgment Number),简写为ACKNUM。
继续两个字节,“70 02”,转换为二进制吧,“0111 0000 0000
0010”。这两个字节,总共16bit,有好多东西呢。第一个4bit“0111”,是TCP头长,十进制为7,表示28个字节(刚才说了,我省略了8字节的option数据,所以你只看见了20字节)。接着的6bit现在TCP协议没有用上,都为0。最后的6bit“00
0010”是六个重要的标志。这是两个计算机数据交流的信息标志。接收和发送断根据这些标志来确定信息流的种类。下面是一些介绍:
URG:(Urgent Pointer field
significant)紧急指针。用到的时候值为1,用来处理避免TCP数据流中断
ACK:(Acknowledgment
fieldsignificant)置1时表示确认号(AcknowledgmentNumber)为合法,为0的时候表示数据段不包含确认信息,确认号被忽略。
PSH:(Push
Function),PUSH标志的数据,置1时请求的数据段在接收方得到后就可直接送到应用程序,而不必等到缓冲区满时才传送。
RST:(Reset the
connection)用于复位因某种原因引起出现的错误连接,也用来拒绝非法数据和请求。如果接收到RST位时候,通常发生了某些错误。
SYN:(Synchronize sequence
numbers)用来建立连接,在连接请求中,SYN=1,ACK=0,连接响应时,SYN=1,ACK=1。即,SYN和ACK来区分Connection
Request和Connection Accepted。
FIN:(No more data from
sender)用来释放连接,表明发送方已经没有数据发送了。
这6个标志位,你们自己对号入座吧。本例中SYN=1,ACK=0,当然就是表示连接请求了。我们可以注意下面两个过程的这两位的变换。
后面的“40 00 c0 29 00
00”不讲了,呵呵,偷懒了。后面两次通讯的数据,自己分开看吧。我们看看连接的过程,一些重要地方的变化。
第二次,FTP站点返回一个可以连接的信号。
216.3.226.21->192.168.1.1
IP头部: 45 00 00 2c c6 be 40 00 6a 06 cd ba d8 03 e2 15 c0 a8 01
01
TCP头部:00 15 0d 28 4b 4f 45 c1 50 5f a9 07 60 12 20 58 64 07 00
00
第三次,我确认连接。TCP连接建立起来。
192.168.1.1->216.3.226.21
IP头部: 45 00 00 28 52 53 40 00 80 06 2c 2a c0 a8 01 01 d8 03 e2
15
TCP头部:0d 28 00 15 50 5f a9 07 4b 4f 45 c2 50 10 40 b0 5b 1c 00
00
好,我们看看整个Threeway_handshake过程。
第一步,我发出连接请求,TCP数据为:SEQ=50 5f a9 06,ACKNUM=00 00 00
00,SYN=1,ACK=0。
第二步,对方确认可以连接,TCP数据为:SEQ=4b 4f 45 c1,ACKNUM=50 5f a9
07,SYN=1,ACK=1。
第三步,我确认建立连接。SEQ=50 5f a9 07, ACKNUM=4b
4f45c2,SYN=0,ACK=1。
可以看出什么变化么?正式建立连接了呢,这些东西是什么值?
我接收从216.3.226.21->192.168.1.1的下一个数据包中:
SEQ=4b 4f 45 c2,ACKNUM=50 5f a9
07,SYN=0,ACK=1这些都是很基础的东西,对于编写sniffer这样的东西是必须非常熟悉的。这里只讲解了TCP/IP协议的一点点东西,主要是头部数据的格式。(T002)
===============================================================================
附加图片,直观具体,帮助理解
http://hi.csdn.net/attachment/201006/10/0_1276178389LWzr.gif
http://hi.csdn.net/attachment/201006/10/0_1276178797if7B.gif
http://hi.csdn.net/attachment/201006/10/0_1276178808gCiE.gif
http://hi.csdn.net/attachment/201006/10/0_1276178827nNM7.gif
http://hi.csdn.net/attachment/201006/10/0_1276178816gTDd.gif
http://hi.csdn.net/attachment/201006/10/0_1276178358SXyD.gif
http://hi.csdn.net/attachment/201006/10/0_1276178373iI0Y.gif

加载中…