協定解析Bug分析

問題

源自郵件協定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）協定解析有些字段或者标記位是可選項，比如大多是情況使用者不去選擇則該字段就沒有意義。但是作為程式員的我們要考慮到一旦使用者選擇的情況，做好分支判定處理。

協定解析必須嚴格參考協定文檔，考慮相當全面，馬虎不得。

作者：銘毅天下

轉載請标明出處，原文位址：

http://blog.csdn.net/laoyang360/article/details/40480235