寫在前面
這個問題其實是發生在兩年前了，當時解決之后，沒有完全整理結果。后來發現這個問題很典型，且頻發，而且也有其他人也遇到此類問題。于是趕緊整理了一套解決方案，希望一樣受到這種問題困擾的童鞋能夠迅速解決這種問題。
問題現象：
http://xxx.xx.xxx.xxx:9080/xxxxx/user_login?name=xxx&password=xxxx&app_mac={"imei":"xxxxxxxx"}
上述接口為登錄接口，請求時iOS返回正常，Android在各種網絡中均無法成功。
經過初步的測試，get、post、帶參數、不帶參數、使用Android手機自帶的瀏覽器均無法成功。
排查和實驗：
PC開啟一個http代理（Charles軟件）進行抓包分析，發現無論手機連接了什么網絡（3G4GWIFI），只要走了代理，請求必然成功。
為了排除是手機網絡問題，手機共享熱點給PC，另一個手機通過PC代理進行請求，依然成功；
手機直接連接另一個手機共享的熱點，請求失敗；
手機連接PC共享的熱點，請求失敗；
截至到此，代理的方式抓包已經無法分析問題，放棄；
后來，連接上PC的熱點，使用WireShark以及tcpdump進行抓包，經過對比兩種請求過程（一種是代理請求，一種是直接請求），發現：
代理請求時，tcp三次握手正常，http通訊正常；
使用任意網絡，取消代理進行請求，tcp只有第一次握手，也就是客戶端發起建立連接的請求，但是服務端沒有響應，最終超時斷開連接。
綜上所述，雖然現象是Android不行，iOS可以。但是從網絡連接情況看，與http請求方式無關，因此與應用層無關，這看來不是修改app可以解決的問題。問題應該是出在服務器的9080端口的某些限制，也或者是進入9080端口之前的一些防火墻或者其他的入站規則限制等。感覺需要從服務端抓包調試此問題，客戶端這邊抓包已經盡力了~
另外，在下午5點半左右的時候，突然發現所有的網絡都可以請求成功了，沒有任何限制了。推測可能是服務端的規則臨時做了修改。（其實后來推測應該是運營商網絡的不同時間段的調整）
新一波排查
過了一個星期，此問題一直無法解決，領導們著急了，要求必須全力解決。其實，我的內心是崩潰的：只在客戶端排查也無能為力啊~還好找到了服務端部署人員，我們配合一起抓包。希望能對比出一個TCP包從客戶端到達最終服務端究竟經歷了什么變化，找出是哪一步導致TCP連接建立失敗。
- 服務器ssh過去，準備好tcpdump，抓取網卡所有數據包，做好準備；
- 客戶端同時使用tcpdump（事先使用root權限導入了Android手機），adb shell連接后，做好準備；
- 一聲令下，兩邊均開啟tcpdump抓取，然后Android客戶端發出http請求，等待超時異常產生后，終止抓包；
- 匯總了一下我們兩邊的抓包數據做了對比。并沒有發現什么關鍵性的不同（事實上TCP報文中的時間戳字段是有變化的，我們沒有注意到），但是發現了一個問題，服務端nginx所在的物理機已經收到了這個網絡包，但是轉發給目標物理機時，超時沒有收到回復。就此，我們認為，可能是轉發部分有什么問題，或者目標物理機之間有什么防火墻限制；
重大發現和最終解決方案
- 經過分析后，我們發現了網上的一個相似病例，大體意思是，服務器系統的TCP參數配置了校驗時間戳，而發送的TCP報文時間戳是錯誤的，就會自動丟棄！
- 發現新大陸的我們馬上先抓包對比Android和iOS的請求包，發現iOS發送的TCP報文中未攜帶時間戳字段，而Android發送的TCP報文中就會攜帶時間戳字段，而服務端收到的TCP報文中，Android的TCP報文中的時間戳已經變了，懷疑可能是網絡通道中，比如運營商路由等操作對TCP報文的時間戳字段進行了改寫，從而導致問題；而iOS的TCP報文，由于沒有攜帶時間戳，到達服務器時，依然是沒有攜帶時間戳的，故推斷可能是運營商路由不會給未添加TCP時間戳的報文強加時間戳。這也是為什么iOS請求可以成功，而Android不可以成功。因為Android默認帶了時間戳，然后就被篡改了，然后服務器收到了錯誤時間戳的TCP報文，直接拋棄。
- 找到問題所在了，先從客戶端進行實驗。使用Android系統的設備，獲取root權限，修改下面參數：
/proc/sys/net/ipv4/tcp_timestamps - 控制timestamp選項開啟/關閉，改為0
/proc/sys/net/ipv4/tcp_tw_recycle - 減少timewait socket釋放的超時時間
- 修改了內核參數的Android設備，請求接口一切順利通暢！調查到這里我們已經可以斷定，iOS系統內核的TCP參數應該是配置了不開啟時間戳校驗的，因此發送的TCP報文中也不會攜帶時間戳，也不會遇到被篡改的問題，也就不會遇到被服務器丟包的問題。
- 后來聯系遠端服務器運維人員，修改了服務器的內核參數，再重新使用普通Android設備測試，一切正常！
本文參考
其中的原理，簡單的說，就是服務器系統的內核參數配置會校驗時間戳，Android系統默認配置了開啟，這樣TCP報文就會攜帶時間戳，而iOS不會默認不會攜帶時間戳，故出現這種異常。具體原理可以參考這篇博文(http://blog.csdn.net/starean/article/details/10813367)對Linux內核代碼的簡單分析。
