PCAP发送ARP包之多出的字节
-------------------------------------------------------------------------------------------------------------------
最近接触了一些计算机网络的底层协议，试着做了一个发送和接收ARP报文的demo，刚开始没注意，后来使用wireshark抓包才发现，发送出去的arp包全是无效的，难怪局域网中没有主机响应。我百度了数篇讲解ARP发包的博客，没有一个发现这个问题的，有的甚至就是直接复制的别人的源码。
-------------------------------------------------------------------------------------------------------------------
问题出现的根源在于cpu的内存优化策略，关于内存优化的详细解释你们可以看一下这篇博客https://blog.csdn.net/cyousui/article/details/17655051?utm_source=blogxgwz2
-------------------------------------------------------------------------------------------------------------------
构造的ARP包结构如图
arp报文结构
图中标明了初始化的数据
按理说发送的数据应该能被解析为一个arp广播请求，但是实际就是如下图的状况
arp-detect-error
arp-error-detail
很明显，报文无法被解析，但是能被判定为是一个arp报文，图中也可以清楚看出，目的mac地址和源mac地址以及协议类型都能被正确识别，但是值本应该是0001的arp操作类型字段却变成了0000,。是初始化出错了吗？仔细看这段报文的十六进制编码，你会发现，在08 06 00 00后面就有00 01的编码，而且后面的编码和初始化的数据一致，只是在本地mac地址编码后面又多出了两个00 00，从这里可以得出结论：00 00这个编码是被强行加进来的，并不是读取错误导致的。
但是这两字节的数据时怎么被加进去的呢？看下面这张程序运行时的内存值图你就清楚了。
detec-memory-error
这是我在arp包刚初始化结束的断点查看到的内存分布图，这说明，我在初始化后数据就已经被加了两字节的00数据。而罪魁祸首就是内存对齐和补齐策略，因为我是创建的32位程序，所以默认的是4字节补齐。因为arp包中的第三个字段结束后才14字节，所以系统就自动加了2字节的数据补齐16字节，使之变成4的整数倍。
既然问题找到了，那解决办法就好找了。
直接在代码的开头声明 按照1字节对齐就能解决这个问题。
#pragma pack(push) // 保持对齐方式
#pragma pack(1) // 设定1字节对齐
-------------------------------------------------------------------------------------------------------------------
设置以后的内存分布图是这样的
arp-memory-success
没有多余的数据了
-------------------------------------------------------------------------------------------------------------------
wireshark抓取的arp正确报文是这样的
wireshark-success
