HttpClient超時設置無效？突破20秒限制的正確姿勢

問題現象

設置`SocketTimeout=60000`（60秒），實際請求在約21秒超時；只有設置<21秒時生效。

根本原因

HttpClient 4.x 默認使用連接管理器的連接請求超時（`ConnectionRequestTimeout`）默認值較小，且DNS解析、建立連接、TLS握手等階段受系統級超時限制（Linux默認TCP連接超時約20秒）。

完整超時配置體系

RequestConfig config = RequestConfig.custom()
    .setConnectTimeout(60000)           // 建立連接超時（TCP三次握手）
    .setSocketTimeout(60000)            // 數據傳輸超時（讀取數據間隔）
    .setConnectionRequestTimeout(60000) // 從連接池獲取連接超時
    .setRedirectsEnabled(true)          // 允許重定向
    .build();

PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
cm.setMaxTotal(200);
cm.setDefaultMaxPerRoute(50);
// 關鍵：設置連接管理器級別的驗證超時
cm.setValidateAfterInactivity(10000);   // 空閒連接驗證間隔

CloseableHttpClient client = HttpClients.custom()
    .setDefaultRequestConfig(config)
    .setConnectionManager(cm)
    .evictIdleConnections(30, TimeUnit.SECONDS) // 定期清理空閒連接
    .build();

系統級超時突破（Linux）

若仍受限於內核TCP超時（`/proc/sys/net/ipv4/tcp_syn_retries` 默認6次 ≈ 127秒，但某些環境默認更小），可通過以下方式：

1. 代碼中設置TCP層面keepalive（需JDK 11+ `SocketOption`支持）
2. 調整系統參數（需root）：`sysctl -w net.ipv4.tcp_syn_retries=8`
3. 推薦方案：在業務層實現分塊請求/斷點續傳/輪詢狀態，將長耗時操作異步化，避免單次HTTP請求過長

錯誤代碼分析

原代碼中`setStaleConnectionCheckEnabled(true)`已棄用，且未設置`ConnectionRequestTimeout`，導致從池獲取連接時使用默認值（可能極小）。

最佳實踐清單

• 三大超時**全部顯式設置**，且值一致
• 連接池大小根據並發量調整，避免獲取連接排隊超時
• 啟用空閒連接驗證與清理，防止死連接
• 長耗時業務**異步化**：HTTP 202 Accepted + 輪詢/回調
• 監控實際耗時分布（Prometheus + Grafana），動態調整超時閾值