記一次TCP重發接口調用的問題

問題描述：基於微軟RDP協議，使用開源rdp庫與微軟skpye軟件進行基於tcp的p2p通信，因爲rdp協議傳輸原始圖片數據較大，調用公司內部ice p2p通信接口處會致使失敗。

錯誤思路：一開始是懷疑開源庫的問題，致使發送的圖像數據格式不對，致使發送失敗，懷疑是rdp協商的過程不一致，可是一開始協商是成功的，使用windows遠程桌面也能夠正常訪問rpd server。因而仔細看了庫的代碼，比對了流程，進行了簡單測試，排除掉了。其實一開始，我就懷疑咱們的ice模塊發送有問題，可是心想，公司ice模塊畢竟使用了那麼長時間，仍是有保障的。最後才知道公司大多數都是使用的udp的p2p通信。後來，我懷疑發送數據過快，會致使tcp協議緩衝區滿的狀況，因而調節了發送速率，對端能夠正常收到數據，抓包看rtp數據包也是正常的，可是這種處理方式顯然是錯誤的。因而和ice開發的同事討論，原來發送失敗，有返回錯誤碼，由於是對接公司的其餘模塊，發送模塊是以前就有的， 我以前也沒有考慮到，這個真是欠缺的，其實最先就該檢測返回失敗的錯誤碼，發送過快，確實致使tcp協議棧的緩衝區滿掉了，而後接口返回失敗，有一個重發機制，我須要重發數據包，最後我也進行重發了，可是仍是不行。 最後比對，在接口調用出把要發送的數據包保存成文件，而後再經過ice發送到網絡，同時進行tcp抓包，將發送的原始數據和抓包的數據比對了一下，定位到了問題的所在，每次重發的時候都會致使對端報錯，而後重發的包以前的一個包，和原始數據對不上號，果真，是咱們的ice模塊的重發機制有bug，至此，問題定位到了，能夠甩鍋了，開個玩笑，^_^

正確思路：發送失敗，看接口反饋信息，而後再去檢查數據的格式，最後再去看數據內容問題，協議問題。

涉及關鍵知識點：tcp協議棧緩存區大小的控制  應用層重發邏輯的設計  接口調用規範的設計