我意识到tcpdump [12]引用了标题长度字段。但是'＆amp; 80！= 0'是指？
答案 0 :(得分：1)
如果您参考各种与TCP相关的RFC，从RFC 793（原始）以及至少RFC 3540开始，引入ECN的那个，您将看到RFC3540的第5节中，TCP报头中的第13个字节（偏移量为0）基于组成TCP Header Length的4个比特，Reserved字段的3个比特，以及NS（或nonce sum）位。具体来说，tcp[12]正在查看这些位：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | | N |
| Header Length | Reserved | S |
| | | |
+---+---+---+---+---+---+---+---+
&运算符是bitwise AND运算符，但令人惊讶的是，这似乎没有记录在pcap-filter man page中。它采用tcp[12]指定的字节（如上所述）并执行按位AND 操作，其值为80（或0x50或01010000二进制），然后使用!= 0操作与非零进行比较。
由于01010000仅设置了2位，因此检查TCP标头长度字段是否包含一个值，以便设置上图中的位1或位3。由于Header Length字段代表＆＃34; TCP标头中32位字的数量。＆＃34; 基本上这意味着过滤器将返回TRUE（因此匹配数据包）如果TCP标头长度字段包含以下12个4位序列中的任何一个，并且实际上是以下TCP标头长度值（以字节为单位）：
Header Length | Effective Length (in bytes)
---------------+---------------------------
0 0 0 1 | 4 (1 * 4)
0 0 1 1 | 12 (3 * 4)
0 1 0 0 | 16 (4 * 4)
0 1 0 1 | 20 (5 * 4)
0 1 1 0 | 24 (6 * 4)
0 1 1 1 | 28 (7 * 4)
1 0 0 1 | 36 (9 * 4)
1 0 1 1 | 44 (11 * 4)
1 1 0 0 | 48 (12 * 4)
1 1 0 1 | 52 (13 * 4)
1 1 1 0 | 56 (14 * 4)
1 1 1 1 | 60 (15 * 4)
---------------+---------------------------
现在的问题是，＆＃34;为什么有人想要针对这12个特定值检查TCP标头长度字段？＆＃34; 这是一个很好的问题，我没有回答。我愿意打赌过滤器不是预期的，而不是'tcp[12] & 80 != 0'，而是使用'tcp[12] & 0x80 != 0'，这将有效地测试任何大于的{1}的TCP标头长度字段。或等于32个字节的长度（即32,36,40,44,48,52,56或60）。
如果您不知道，0x表示十六进制数字，因此0x80是十进制128，而二进制，这是10000000所以这只检查如果Header Length的最高有效位设置为1，那么当TCP Header Length字段是上面列出的以32开头的八个值之一时。