HTTP 1.0 vs 1.1：為何切換協議版本能解決路由器獲取白名單失敗？

現象描述

路由器透過 HTTP 1.1 請求 Web 端 Servlet 獲取白名單，本地測試正常，部署到伺服器後卻頻繁失敗。縮短白名單長度偶爾能成功，但極不穩定。將協議強制降級為 HTTP 1.0 後，問題神奇般消失。

根本原因分析

HTTP 1.0：短連線模式

每次請求皆建立新的 TCP 連線，處理完畢立即斷開。優點是實作簡單、伺服器無需維持狀態；缺點是大量短連線導致延遲與資源浪費，尤其在圖片多的頁面更明顯。

HTTP 1.1：持久連線與管線化

預設啟用 Connection: keep-alive，單一 TCP 連線可傳輸多個請求/回應，減少握手開銷。但引入了 Chunked Transfer Encoding、管線化、Host 標頭強制 等新機制，若中間設備（Proxy、防火牆、負載均衡器）處理不當，極易導致：

• 回應體未正確結束（缺少 Content-Length 或 Chunked 結束塊）
• 管線化請求阻塞導致超時
• 中間設備截斷長連線

為何降級到 1.0 即可解決？

HTTP 1.0 強制「請求-回應-關閉」的單次交易模式，繞過了所有持久連線與分塊傳輸的複雜度。對於單純的「請求白名單、回應 JSON」這類無狀態 API，短連線反而更穩健。

建議解決方案

1. 伺服器端明確回傳 Content-Length，避免 Chunked 編碼引發中間設備解析錯誤。
2. 關閉 Keep-Alive：在回應標頭加入 Connection: close，保留 HTTP 1.1 其他優勢（Host 標頭、壓縮、快取控制）同時避免長連線坑。
3. 檢查中間設備逾時設定：Nginx/APACHE keepalive_timeout、防火牆閒置逾時是否小於應用處理時間。
4. 啟用 HTTP/2：若基礎設施支援，多工與標頭壓縮徹底解決 1.1 的管線化缺陷。

結語

協議版本切換只是表象，核心在於傳輸層行為與中間設備的相容性。理解 HTTP 1.1 的持久連線機制，才能精準定位並徹底解決「本地正常、線上失效」的疑難雜症。