我收到了一些基於用戶活動的網絡應用。應用程序發送的平常負載是100-200字節，所以基本上沒有繁重的任務。這些任務通常沒有任何問題（統計數據爲99.9％或請求沒有問題），但除了這些聯網活動之外，我的應用也將心跳發送回我們的服務器（這些服務器位於亞馬遜的EC2（us-east1-如果那會很重要））。 Heartbeat每10秒發送一次，作爲通過HTTPS的普通POST請求 - 這對我來說並沒有什麼作用，因爲故障率遠遠高於正常網絡活動的情況 - 在我最近的7小時測試中，25％的心跳請求失敗但我甚至看到了35％的下降），並且通常保持在這個速度。當我禁用SSL時，錯誤率在我的測試設備上保持在8％。如果這些失敗會落入任何模式（即每個第4等可能意味着某些基於速率的過濾，或者會在接近每個整整一小時或每一天時失敗，這可能意味着某種請求上限被設置在某處），這可能不是真正的大問題）。但是沒有發生這種情況 - 有時10-15個請求可能會連續失敗，這對心跳不利。此外，爲了讓事情變得更糟，目前我看到請求失敗，我可以使用同一設備連接到服務器，而且這種工作沒有問題）。此問題發生在任何受支持的Android版本（2.2+）上。追蹤網絡「穩定性」問題的根源
我使用最近的httpclientandroidlib做HTTP請求，所以我開始懷疑lib是一個罪魁禍首，所以我切換到Android Asynchronous HTTP Client，但它沒有真正改變。我主要是越來越異常，如：
NoHttpResponseException: The target server failed to respond The target server failed to respond URL: https://xx.xx.xx.xx/heartbeat/
和啓用SSL連接也：
javax.net.ssl.SSLException: Read error: ssl=0x784bc588: I/O error during system call, Connection reset by peer Read error: ssl=0x784bc588: I/O error during system call, Connection reset by peer URL: https://xx.xx.xx.xx/heartbeat/
我基本上是想先追查元兇，因此，瞭解該應用程序運行在移動網絡上居多，我對任何有關如何進一步解決這個問題的建議表示歡迎，因爲此刻我陷入了一些困境。
您是否完全檢查了服務器的性能？ –
「通過對等方重置連接」這可能是服務器問題。爲了說清楚你可能會用WireShark來追蹤它。 http://www.wireshark.org/ – Devrim
你的圖書館的新選擇有一些有趣的問題：https：//github.com/loopj/android-async-http/issues – flup