tcp的doff是高4位吗？。。。

donotgiveup

按照协议上,doff是0~3位。
但little endian,  定义是
__be16 res1:4,doff:4,...
抓包出来也是，一般是0x50，表示tcp头为20，那doff=5,应该是高4位啊。

求解。。。

Godbach

数据包时按照网络字节序来的

donotgiveup

网络字节序是多个字节之间的。一个字节之内的有影响吗？
而且明显doff就是高4位，和图解的不符合。


TCP Header Format

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Godbach

看一下 tcphdr 的定义

1. struct tcphdr {
   
2.         __be16        source;
   
3.         __be16        dest;
   
4.         __be32        seq;
   
5.         __be32        ack_seq;
   
6. #if defined(__LITTLE_ENDIAN_BITFIELD)
   
7.         __u16        res1:4,
   
8.                 doff:4,
   
9.                 fin:1,
   
10.                 syn:1,
    
11.                 rst:1,
    
12.                 psh:1,
    
13.                 ack:1,
    
14.                 urg:1,
    
15.                 ece:1,
    
16.                 cwr:1;
    
17. #elif defined(__BIG_ENDIAN_BITFIELD)
    
18.         __u16        doff:4,
    
19.                 res1:4,
    
20.                 cwr:1,
    
21.                 ece:1,
    
22.                 urg:1,
    
23.                 ack:1,
    
24.                 psh:1,
    
25.                 rst:1,
    
26.                 syn:1,
    
27.                 fin:1;
    
28. #else
    
29. #error        "Adjust your <asm/byteorder.h> defines"

复制代码

donotgiveup

struct tcphdr {
        __be16        source;
        __be16        dest;
        __be32        seq;
        __be32        ack_seq;
#if defined(__LITTLE_ENDIAN_BITFIELD)
        __u16        res1:4,
                doff:4,

在x86上，本机将__u16部分定义的打印出来，两个字节确实就是0x50 0x00.那么doff对应的也就是这个16位中的4~7位。

Godbach

就是保证网络传输的时候，你先看到 doff 的四个比特，然后才是 res1 的四个

donotgiveup

感谢版主的回复！！！

那是不是这样理解，网络传输的时候，先发送的字节的高位。
那么，如果发送一个0000 0101(0x50)的字节，发送的顺序为 1010 0000。
那接收方怎么保存这些字节，是保存为1010 0000？那么值就是0x0A。

那不是变了？还是说，针对tcp协议的部分有特殊处理？

Godbach

你说的这个问题其实牵涉到了字节序（Byte Order） 和 比特序（Bit Order ） 的问题，具体可以参考这篇文章：
http://www.linuxjournal.com/article/6788?page=0,0

Godbach

我大致看了上面的文章。
导致 Bit Field 定义时要考虑 Byte Order 的原因，在于NIC 将内存字节发送的网络上，也就是对于单个字节的传输，转换成 1 或 0 信号的时候，是先取高有效位，还是低有效位的问题。

Godbach

Bit Transmission/Reception Order

The bit transmission/reception order specifies how the bits within a byte are transmitted/received on the wire. For Ethernet, the order is from the least significant bit (lower wire address offset) to the most significant bit (higher wire address offset). This apparently is little endian. The byte order remains the same as big endian, as described in early section. Therefore, here we see the situation where the byte order and the bit transmission/reception order are the reverse.

The following is an illustration of Ethernet bit transmission/reception order:


We see from this that the group (multicast) bit, the least significant bit of the first byte, appeared as the first bit on the wire. Ethernet and 802.3 hardware behave consistently with the bit transmission/reception order above.