[头文件]各种类型的数据报头部结构体

(1)IP报头格式

//定义IP首部 (netinet/ip.h)

typedef struct _iphdr{

unsigned char h_lenver; //4 位IP版本号+4位首部长度

unsigned char tos; //8位服务类型TOS

unsigned short total_len; //16位IP包总长度(字节)

unsigned short ident; //1 6位标识, 用于辅助IP包的拆装,本实验不用,置零

unsigned short frag_and_flags; //3位标志位+13位偏移位, 也是用于IP包的拆装,本实验不用,置零

unsigned char ttl; //8位IP包生存时间 TTL

unsigned char proto; //8位协议 (TCP, UDP 或其他), 本实验置ICMP,置为1

unsigned short checksum; //16位IP首部校验和,最初置零,等所有包头都填写正确后,计算并替换.

unsigned int sourceIP; //32位源IP地址

unsigned int destIP; //32位目的IP地址

}IP_HEADER;



(2)ICMP报头格式

//定义ICMP首部(netinet/ip_icmp.h)

typedef struct _icmphdr{

unsigned char i_type; //8位类型, 本实验用 8: ECHO 0:ECHO REPLY

unsigned char i_code; //8位代码, 本实验置零

unsigned short i_cksum; //16位校验和, 从TYPE开始,直到最后一位用户数据,如果为字节数为奇数则补充一位

unsigned short i_id ; //识别号(一般用进程号作为识别号), 用于匹配ECHO和ECHO REPLY包

unsigned short i_seq ; //报文序列号, 用于标记ECHO报文顺序

unsigned int timestamp; //时间戳

}ICMP_HEADER;


(3)TCP报头格式

//定义TCP首部(netinet/tcp.h)

struct tcphdr {

__be16  source;   //源地址端口

__be16  dest; //目的地址端口

__be32  seq; //序列号

__be32  ack_seq; //确认序列号

#if defined(__LITTLE_ENDIAN_BITFIELD)

__u16 res1:4,//保留

doff:4,  //偏移

fin:1,  //关闭连接标志

syn:1,  //请求连接标志

rst:1, //重置连接标志

psh:1, //接收方尽快将数据放到应用程标志

ack:1, //确认序列号标志

urg:1, //紧急指针标志

ece:1, //拥塞标志位

cwr:1; //拥塞标志位

#elif defined(__BIG_ENDIAN_BITFIELD)

__u16 doff:4,

res1:4,

cwr:1,

ece:1,

urg:1,

ack:1,

psh:1,

rst:1,

syn:1,

fin:1;

#else

#error "Adjust your defines"

#endif

__be16  window; //滑动窗口大小

__sum16  check; //校验和

__be16  urg_ptr; //紧急字段指针

};


解释:

tcphdr->source 

16位源端口号

tcphdr->dest  

16位目的端口号

tcphdr->seq 

表示此次发送的数据在整个数据报文段中的起始字节数。序号是32bit的无符号数。为了安全起见,她的初始值是一个随机生成的书,它到达32位最大值后,又从零开始。

tcphdr->ack_seq

指定的是下一个期望接收的字节,而不是已经正确接收到的最后一个字节。

tcphdr->doff

TCP头长度,指明了在TCP头部包含多少个32位的字。此信息是必须的,以为options域的长度是可变的,所以整个TCP头部的长度也是变化的。从技术上讲,

tcphdr->res1为保留位

tcphdr->window

是16位滑动窗口的大小,单位为字节,起始于确认序列号字段指明的值,这个值是接收端正期望接收的字节数,其最大值是63353字节。

TCP中的流量控制是通过一个可变大小的滑动窗口来完成的。window域指定了从被确认的字节算起可以接收的多少个字节。window = 0也是合法的,这相当于说,到现在为止多达ack_seq-1个字节已经接收到了,但是接收方现在状态不佳,需要休息一下,等一会儿再继续接收更多的数据,谢谢。以后,接收方可以通过发送一个同样ack_seq但是window不为0的数据段,告诉发送方继续发送数据段。

tcphdr->check

是检验和,覆盖了整个的TCP报文段,这是一个强制性的字段,一定是由发送端计算和存储,并由接收端进行验证。

tcphdr->urg_ptr

这个域被用来指示紧急数据在当前数据段中的位置,它是一个相对于当前序列号的字节偏移值。这个设施可以代替中断信息。

fin, syn, rst, psh, ack, urg为6个标志位

这6个位域已经保留了超过四分之一个世纪的时间而仍然原封未动,这样的事实正好也说明了TCP的设计者们考虑的是多么的周到。它们的含义如下:

tcphdr->fin fin位被用于释放一个连接。它表示发送方已经没有数据要传输了。

tcphdr->syn 同步序号,用来发起一个连接。syn位被用于建立连接的过程。在连接请求中,syn=1; ack=0表示该数据段没有使用捎带的确认域。连接应答捎带了一个确认,所以有syn=1; ack=1。本质上,syn位被用来表示connection request和connection accepted,然而进一步用ack位来区分这两种情况。

tcphdr->rst 该为用于重置一个已经混乱的连接,之所以会混乱,可能是由于主机崩溃,或者其他的原因。该位也可以被用来拒绝一个无效的数据段,或者拒绝一个连接请求。一般而言,如果你得到的数据段设置了rst位,那说明你这一端有了问题。

tcphdr->psh 接收方在收到数据后应立即请求将数据递交给应用程序,而不是将它缓冲起来直到整个缓冲区接收满为止(这样做的目的可能是为了效率的原因)

tcphdr->ack ack位被设置为1表示tcphdr->ack_seq是有效的。如果ack为0,则该数据段不包含确认信息,所以,tcphdr->ack_seq域应该被忽略。

tcphdr->urg 紧急指针有效

tcphdr->ece 用途暂时不明

tcphdr->cwr 用途暂时不明


(4)UDP报头格式

//定义UDP首部(netinet/udp.h)

struct udphdr {

 __u16 source;

 __u16 dest;

 __u16 len;

 __u16 check;

};


(5)ETHERNET报头格式

//定义ETHERNET首部(net/ethernet.h)

struct ether_header{

u_char ether_dhost[6];

u_char ether_shost[6];

u_short ether_type;

};

#define ETHERTYPE_PUP 0x0200/* PUP protocol */

#define ETHERTYPE_IP 0x0800/* IP protocol */

#define ETHERTYPE_ARP 0x0806/* Addr. resolution protocol */

#define ETHERTYPE_TRAIL 0x1000/* Trailer packet */

#define ETHERTYPE_NTRAILER 16

#define ETHERMTU 1500

#define ETHERMIN (60-14)


(6)arp报头格式

//定义arp首部(net/ethernet.h)

struct ether_arp{

struct arphdr ea_hdr;/* fixed-size header */

u_char arp_sha[6];/* sender hardware address */

u_char arp_spa[4];/* sender protocol address */

u_char arp_tha[6];/* target hardware address */

u_char arp_tpa[4];/* target protocol address */

};


#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


struct arpcom{

struct ifnet ac_if;/* network-visible interface */

u_char ac_enaddr[6];/* ethernet hardware address */

struct in_addr ac_ipaddr;/* copy of ip address- XXX */

};



struct arptab {

struct in_addr at_iaddr;/* internet address */

u_char at_enaddr[6];/* ethernet address */

u_char at_timer;/* minutes since last reference */

u_char at_flags;/* flags */

struct mbuf *at_hold;/* last packet until resolved/timeout */

};


#ifdef KERNEL 

u_char etherbroadcastaddr[6];

structarptab *arptnew();

intether_output(), ether_input();

char*ether_sprintf();

#endif

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,029评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,238评论 3 388
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,576评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,214评论 1 287
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,324评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,392评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,416评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,196评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,631评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,919评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,090评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,767评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,410评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,090评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,328评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,952评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,979评论 2 351

推荐阅读更多精彩内容