iphdr与tcphdr详解（skb_header_pointer函数分析）

linux 2.6.26 下获取tcp信息：  
tcph=skb_header_pointer(skb, protoff, sizeof(tcph), &tcph);    //skb_header_pointer是个库函数
skb_header_pointer函数
该函数本身很简单，定义如下：
/* #include <linux/skbuff.h>*/
static inline void *skb_header_pointer(const struct sk_buff *skb, int offset, int len, void *buffer)
{
 int hlen = skb_headlen(skb);
 if (hlen - offset >= len)
  return skb->data + offset;
 if (skb_copy_bits(skb, offset, buffer, len) < 0)
  return NULL;
 return buffer;
}
其中参数为：
skb：数据包struct sk_buff的指针
offset：相对数据起始头(如IP头)的偏移量
len：数据长度
buffer：缓冲区，大小不小于len

其中skb_headlen()定义为：
/* #include <linux/skbuff.h> */
static inline unsigned int skb_headlen(const struct sk_buff *skb)
{
 return skb->len - skb->data_len;
}
其中skb->len是数据包长度，在IPv4中就是单个完整IP包的总长，但这些数据并不一定都在当前内存页；skb->data_len表示在其他页的数据长度，因此skb->len - skb->data_len表示在当前页的数据大小。

/* net/core/skbuff.c */
/* Copy some data bits from skb to kernel buffer. */
int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len)
{
 int i, copy;
 int start = skb_headlen(skb);
 if (offset > (int)skb->len - len)
  goto fault;
 /* Copy header. */
 if ((copy = start - offset) > 0) {
// 拷贝在当前页面中的部分
  if (copy > len)
   copy = len;
  memcpy(to, skb->data + offset, copy);
  if ((len -= copy) == 0)
   return 0;
  offset += copy;
  to     += copy;
 }
// 拷贝本skb中其他碎片中的部分
 for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
  int end;
  BUG_TRAP(start <= offset + len);
  end = start + skb_shinfo(skb)->frags[i].size;
  if ((copy = end - offset) > 0) {
   u8 *vaddr;
   if (copy > len)
    copy = len;
   vaddr = kmap_skb_frag(&skb_shinfo(skb)->frags[i]);
   memcpy(to,
          vaddr + skb_shinfo(skb)->frags[i].page_offset+
          offset - start, copy);
   kunmap_skb_frag(vaddr);
   if ((len -= copy) == 0)
    return 0;
   offset += copy;
   to     += copy;
  }
  start = end;
 }
// 拷贝其他碎片skb中的数据部分
 if (skb_shinfo(skb)->frag_list) {
  struct sk_buff *list = skb_shinfo(skb)->frag_list;
  for (; list; list = list->next) {
   int end;
   BUG_TRAP(start <= offset + len);
   end = start + list->len;
   if ((copy = end - offset) > 0) {
    if (copy > len)
     copy = len;
    if (skb_copy_bits(list, offset - start,
        to, copy))
     goto fault;
    if ((len -= copy) == 0)
     return 0;
    offset += copy;
    to     += copy;
   }
   start = end;
  }
 }
 if (!len)
  return 0;
fault:
 return -EFAULT;
}

iphdr结构详解：
include <linux/ip.h>
struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8    ihl:4,
version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
__u8    version:4,
ihl:4;
#else
#error “Please fix ”
#endif
__u8    tos;
__be16 -tot_len;
__be16 -id;
__be16 -frag_off;
__u8    ttl;
__u8    protocol;
__be16 -check;
__be32 -saddr;
__be32 -daddr;
};

iphdr->version
     版本(4位)，目前的协议版本号是4,因此IP有时也称作IPv4。
iphdr->ihl
     首部长度(4位):首部长度指的是IP层头部占32 bit字的数目(也就是IP层头部包含多少个4字节 — 32位),包括任何选项。由于它是一个4比特字段,单位为4个字节，因此，一个IP包头的长度最长为“1111”，即15＊4＝60个字节,因此首部最长为60个字节。普通IP数据报(没有任何选择项)字段的值是5  5 * 32 / 8 = 5 * 4 = 20 Bytes
iphdr->tos
     服务类型字段(8位): 服务类型(TOS)字段包括一个3 bit的优先权子字段(现在已被忽略)，4 bit的TOS子字段和1 bit未用位但必须置0。4 bit的TOS子字段分别代表:最小时延、最大吞吐量、最高可靠性和最小费用。4 bit中只能设置其中1 bit。如果所有4 bit均为0,那么就意味着是一般服务。
例：
8个BIT的含义是：
000 前三位不用
0 表示最小时延，如Telnet服务使用该位
0 表示吞吐量，如FTP服务使用该位
0 表示可靠性，如SNMP服务使用该位
0 表示最小代价
0 不用
iphdr->tot_len
     总长度字段(16位)是指整个IP数据报的长度,以字节为单位。利用首部长度字段和总长度字段,就可以知道 IP数据报中数据内容的起始位置和长度。由于该字段长16比特（一个IP数据包的最大长度为2的16次方减1，即：65535个字节），所以在以太网中能够传输的最大IP数据包为65535个字节。总长度字段是IP首部中必要的内容,因为一些数据链路(如以太网)需要填充一些数据以达到最小长度。尽管以太网的最小帧长为46字节,但是IP数据可能会更短。如果没有总长度字段,那么IP层就不知道46字节中有多少是IP数据报的内容。
iphdr->id
     标识字段(16位)唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。（例如：Identification=363，表示IP包识别号为363。该部分占16个BIT，以十进制数表示。）iphdr->frag_off (16位)frag_off域的低13位 — 分段偏移(Fragment offset)域指明了该分段在当前数据报中的什么位置上。除了一个数据报的最后一个分段以外，其他所有的分段(分片)必须是8字节的倍数。这是8字节是基本分段单位。由于该域有13个位，所以，每个数据报最多有8192个分段。因此，最大的数据报长度为65,536字节，比 iphdr->tot_len域还要大1。iphdr->frag_off的高3位：
(1) 比特0是保留的，必须为0；
(2) 比特1是“更多分片”(MF — More Fragment)标志。除了最后一片外，其他每个组成数据报的片都要把该比特置1。
(3) 比特2是“不分片”(DF — Don’t Fragment)标志,如果将这一比特置1，IP将不对数据报进行分片,这时如果有需要进行分片的数据报到来，会丢弃此数据报并发送一个ICMP差错报文给起始端。
iphdr->ttl
     TTL(time-to-live) — 8位，生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置(通常为32或64),一旦经过一个处理它的路由器,它的值就减去1。当该字段的值为0时,数据报就被丢弃,并发送ICMP报文通知源主机。TTL(Time to live)域是一个用于限制分组生存期的计数器。这里的计数时间单位为秒，因此最大的生存期为255秒。在每一跳上该计数器必须被递减，而且，当数据报在一台路由器上排队时间较长时，该计数器必须被多倍递减。在实践中，它只是跳计数器，当它递减到0的时候，分组被丢弃，路由器给源主机发送一个警告分组。此项特性可以避免数据报长时间地逗留在网络中，有时候当路由表被破坏之后，这种事情是有可能发生的。
iphdr->protocol
     协议字段(8位): 根据它可以识别是哪个协议向IP传送数据。当网络层组装完成一个完整的数据报之后，它需要知道该如何对它进行处理。协议(Protocol)域指明了该将它交给哪个传输进程。TCP是一种可能，但是UDP或者其他的协议也是可能的。Proctol＝6（TCP），表示协议类型为TCP，协议代码是6。如果是UDP协议，则此处的协议代码应为17。如果是ICMP协议，则此处的协议代码应为1。该部分占8个BIT。(IPPROTO_TCP ,IPPROTO_UDP,IPPROTO_ICMP etc.)
iphdr->check
     首部检验和字段(16位)是根据IP首部计算的检验和码。它不对首部后面的数据进行计算。 ICMP、IGMP、UDP和TCP在它们各自的首部中均含有同时覆盖首部和数据检验和码。为了计算一份数据报的IP检验和,首先把检验和字段置为0。然后,对首部中每个16 bit进行二进制反码求和(整个首部看成是由一串16 bit的字组成),结果存在检验和字段中。当收到一份IP数据报后,同样对首部中每个16 bit进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全1。如果结果不是全1(即检验和错误),那么IP就丢弃收到的数据报。但是不生成差错报文,由上层去发现丢失的数据报并进行重传。
iphdr->saddr
     32位源IP地址
iphdr->daddr
     32位目的IP地址
网络字节序
     4个字节的32 bit值以下面的次序传输:首先是0~7bit,其次8~15bit,然后16~23bit,最后是24~31 bit。这种传输次序称作big endian字节序。由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序,因此它又称作网络字节序。

tcphdr结构详解：
sk_buff->tcphdr
/usr/src/linux-2.6.19/include/linux/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 <asm/byteorder.h> defines"
#endif
    __be16 window;
    __be16 check;
    __be16 urg_ptr;
};
     |----------------|----------------|-------------
     |     source     |     dest       |
     |----------------|----------------|
     |               seq               |
     |---------------------------------|
     |               ack_seq           | 20 Bytes
     |----|----|------|----------------|
     |doff|res1|      |     window     |
     |----|----|------|----------------|
     |     check      |     urg_ptr    |
     |----------------|----------------|-------------
     |             options             | 4 Bytes
     |---------------------------------|  

                    TCP头
tcphdr->source
     16位源端口号
tcphdr->dest
     16位目的端口号
tcphdr->seq
     表示此次发送的数据在整个报文段中的起始字节数。序号是32 bit的无符号数。为了安全起见，它的初始值是一个随机生成的数，它到达32位最大值后，又从零开始。
tcphdr->ack_seq
     指定的是下一个期望接收的字节，而不是已经正确接收到的最后一个字节。
tcphdr->doff
     TCP头长度，指明了在TCP头部包含多少个32位的字。此信息是必须的，因为options域的长度是可变的，所以整个TCP头部的长度也是变化的。从技术上讲，这个域实际上指明了数据部分在段内部的其起始地址(以32位字作为单位进行计量)，因为这个数值正好是按字为单位的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 用途暂时不明
    内核源代码在函数tcp_transmit_skb()中建立tcp首部。

 

转自：http://blog.csdn.net/ast_224/archive/2009/02/27/3943306.aspx