源自邮件协议RPC（远程过程调用）处理的Request请求数据包的bug。
一、Bug描述
腾讯收购的Foxmail客户端可以作为outlook客户端的替代品与Exchange服务端进行交互完成邮件收发。而我们所要做的就是让邮件经过我们代理的优化处理。
这时候问题来了，Outlook客户端经由我们代理没有任何问题；但是换成Foxmail就会有错误弹窗，错误号：0x000006BE。但是如果不经过代理，Foxmail收发邮件一切正常。
很明显，是代理出了问题。
二、不知道如何排查？
又是面对不熟悉的6万行以上的代码，又是不熟悉的框架，又是文档混杂，又是项目进度非常赶……
还好是必现的环境，还好还有日志、还有wireshark的分析。
初始的时候由于不知道虚拟机开启了混杂模式，导致wireshark抓的数据包有大量的Retransmit数据包以及很多out of order（失序）数据包。所以抓住的点是某个包被重传了两次，然后找日志哪个包重传了两次？
由于日志里确实没有找到重传数据包，再来怀疑之前的分析？这才找到了混杂模式导致了误分析。特将混杂模式和普通模式定义列举如下：
混杂模式就是接收所有经过网卡的数据包，包括不是发给本机的包，即不验证MAC地址。普通模式下网卡只接收发给本机的包（包括广播包）传递给上层程序，其它的包一律丢弃。一般来说，混杂模式不会影响网卡的正常工作，多在网络监听工具上使用。
三、根本原因
最后思路还是结合日志分析抓包，看到对于RPC的请求数据包（request）的加密数据长度和日志打印不一致，顺着代码去读，发现是Foxmail较outlook多了一个比特标记位置为1（此为根本原因），导致多出了表示回话UUID的16个字节的数据。在数据处理中取长度和取数据段结构体赋值的时候导致偏移出错。
四、阶段小结
虽然找到偏移出错的根本原因，但是要彻底解决bug还有很长的路要走。代理中有几十处能搜到的和偏移有关的数据项，有些变量不能见名识意，还需要跟读代码逻辑。
深刻体会到协议解析常犯的两个错误：
1）对于协议的解析，马虎不得，偏移一个比特可能剩余的解析会全部出错；
2）协议解析有些字段或者标记位是可选项，比如大多是情况用户不去选择则该字段就没有意义。但是作为程序员的我们要考虑到一旦用户选择的情况，做好分支判定处理。
协议解析必须严格参考协议文档，考虑相当全面，马虎不得。
