硬核干貨:HTTP超時、重復請求必見坑點及解決方案

作者： JavaEdge 2020-11-12 07:46:34

網絡

HTTP調用即通過HTTP協議執行一次網絡請求。既然是網絡請求，就有超時的可能性（可能你的網卡，也可能服務器所處網絡卡），因此在開發中需要注意

[[351757]]

1 超時,無法避免的痛

HTTP調用即通過HTTP協議執行一次網絡請求。既然是網絡請求，就有超時的可能性(可能你的網卡，也可能服務器所處網絡卡)，因此在開發中需要注意：

框架設置的默認超時時間是否合理
過短，請求還未處理完成，你就急不可待了!
過長，請求早已超出正常響應時間而掛了
考慮網絡不穩定性，超時后可以通過定時任務請求重試
注意考慮服務端接口冪等性設計，即是否允許重試
考慮框架是否會像瀏覽器那樣限制并發連接數，以免在高并發下，HTTP調用的并發數成為瓶頸

1.1 HTTP調用框架技術選型

Spring Cloud全家桶

使用Feign進行聲明式的服務調用。

只使用Spring Boot

HTTP客戶端Apache HttpClient進行服務調用。

1.2 連接超時配置 && 讀取超時參數

雖然應用層是HTTP協議，但網絡層始終是TCP/IP協議。TCP/IP是面向連接的協議，在傳輸數據之前需要建立連接。所以網絡框架都會提供如下超時參數：

連接超時參數ConnectTimeout

可自定義配置的建立連接最長等待時間

讀取超時參數ReadTimeout

控制從Socket上讀取數據的最長等待時間。

1.3 常見踩坑點

連接超時配置過長

比如60s。TCP三次握手正常建立連接所需時間很短，在ms級最多到s級，不可能需要十幾、幾十秒，多半是網絡或防火墻配置問題。這時如果幾秒還連不上，那么可能永遠也連不上。所以設置特別長的連接超時無意義，1~5秒即可。

如果是純內網調用，還可以設更短，在下游服務無法連接時，快速失敗

無腦排查連接超時問題

服務一般會有多個節點，若別的客戶端通過負載均衡連接服務端，那么客戶端和服務端會直接建立連接，此時出現連接超時大概率是服務端問題

而若服務端通過Nginx反向代理來負載均衡，客戶端連接的其實是Nginx，而非服務端，此時出現連接超時應排查Nginx

讀取超時參數和讀取超時“坑點”

只要讀取超時，服務端程序的正常執行就一定中斷了?

案例

client接口內部通過HttpClient調用服務端接口server，客戶端讀取超時2秒，服務端接口執行耗時5秒。

調用client接口后，查看日志：

客戶端2s后出現SocketTimeoutException，即讀取超時

服務端卻泰然地在3s后執行完成

Tomcat Web服務器是把服務端請求提交到線程池處理，只要服務端收到請求，網絡層面的超時和斷開便不會影響服務端的執行。因此，出現讀取超時不能隨意假設服務端的處理情況，需要根據業務狀態考慮如何進行后續處理。

讀取超時只是Socket網絡層面概念，是數據傳輸的最長耗時，故將其配置很短

比如100ms。

發生讀取超時，網絡層面無法區分如下原因：

服務端沒有把數據返回給客戶端
數據在網絡上耗時較久或丟包

但TCP是連接建立完成后才傳輸數據，對于網絡情況不是特差的服務調用，可認為：

連接超時

網絡問題或服務不在線

讀取超時

服務處理超時。讀取超時意味著向Socket寫入數據后，我們等到Socket返回數據的超時時間，其中包含的時間或者說絕大部分時間，是服務端處理業務邏輯的時間

超時時間越長，任務接口成功率越高，便將讀取超時參數配置過長

HTTP請求一般需要獲得結果，屬同步調用。

若超時時間很長，在等待 Server 返回數據同時，Client 線程(通常為 Tomcat 線程)也在等待，當下游服務出現大量超時，程序可能也會受到拖累創建大量線程，最終崩潰。

對定時任務或異步任務，讀取超時配置較長問題不大
但面向用戶響應的請求或是微服務平臺的同步接口調用，并發量一般較大，應該設置一個較短的讀取超時時間，以防止被下游服務拖慢，通常不會設置讀取超時超過30s。

評論可能會有人問了，若把讀取超時設為2s，而服務端接口需3s，不就永遠拿不到執行結果?

的確，因此設置讀取超時要結合實際情況：

過長可能會讓下游抖動影響到自己

過短又可能影響成功率。甚至，有些時候我們還要根據下游服務的SLA，為不同的服務端接口設置不同的客戶端讀取超時。

1.4 最佳實踐

連接超時代表建立TCP連接的時間，讀取超時代表了等待遠端返回數據的時間，也包括遠端程序處理的時間。在解決連接超時問題時，我們要搞清楚連的是誰;在遇到讀取超時問題的時候，我們要綜合考慮下游服務的服務標準和自己的服務標準，設置合適的讀取超時時間。此外，在使用諸如Spring Cloud Feign等框架時務必確認，連接和讀取超時參數的配置是否正確生效。

2 Feign&&Ribbon

2.1 如何配置超時

為Feign配置超時參數的難點在于，Feign自身有兩個超時參數，它使用的負載均衡組件Ribbon本身還有相關配置。這些配置的優先級是啥呢?

2.2 案例

測試服務端超時，假設服務端接口，只休眠10min

Feign調用該接口：

通過Feign Client進行接口調用

在配置文件僅指定服務端地址的情況下：

clientsdk.ribbon.listOfServers=localhost:45678

得到如下輸出：

[21:46:24.222] [http-nio-45678-exec-4] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController:26  ] -  
    執行耗時：222ms 錯誤：Connect to localhost:45679 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1]  
        failed: Connection refused (Connection refused) executing  
            POST http://clientsdk/feignandribbon/server

Feign默認讀取超時是1秒，如此短的讀取超時算是“坑”。

分析源碼

自定義配置Feign客戶端的兩個全局超時時間

可以設置如下參數：

feign.client.config.default.readTimeout=3000 
feign.client.config.default.connectTimeout=3000

修改配置后重試，得到如下日志：

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] - 執行耗時：3006ms 錯誤：Read timed out executing POST http://clientsdk/feignandribbon/server

3秒讀取超時生效。

注意：這里有一個大坑，如果希望只修改讀取超時，可能會只配置這么一行：

feign.client.config.default.readTimeout=3000

測試會發現，這樣配置無法生效。

要配置Feign讀取超時，必須同時配置連接超時

查看FeignClientFactoryBean源碼

只有同時設置ConnectTimeout、ReadTimeout，Request.Options才會被覆蓋

想針對單獨的Feign Client設置超時時間，可以把default替換為Client的name：

feign.client.config.default.readTimeout=3000 
feign.client.config.default.connectTimeout=3000 
feign.client.config.clientsdk.readTimeout=2000 
feign.client.config.clientsdk.connectTimeout=2000

單獨的超時可覆蓋全局超時

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] -  
執行耗時：2006ms 錯誤：Read timed out executing  
POST http://clientsdk/feignandribbon/server

除了可以配置Feign，也可配置Ribbon組件的參數以修改兩個超時時間

參數首字母要大寫，和Feign的配置不同。

ribbon.ReadTimeout=4000 
ribbon.ConnectTimeout=4000

可以通過日志證明參數生效：

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] -  
執行耗時：4003ms 錯誤：Read timed out executing  
POST http://clientsdk/feignandribbon/server

同時配置Feign和Ribbon的參數

誰會生效?

clientsdk.ribbon.listOfServers=localhost:45678 
feign.client.config.default.readTimeout=3000 
feign.client.config.default.connectTimeout=3000 
ribbon.ReadTimeout=4000 
ribbon.ConnectTimeout=4000

最終生效的是Feign的超時：

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] -  
執行耗時：3006ms 錯誤：Read timed out executing  
POST http://clientsdk/feignandribbon/server

同時配置Feign和Ribbon的超時，以Feign為準

在LoadBalancerFeignClient源碼

如果Request.Options不是默認值，就會創建一個FeignOptionsClientConfig代替原來Ribbon的DefaultClientConfigImpl，導致Ribbon的配置被Feign覆蓋：

但若這么配置，最終生效的還是Ribbon的超時(4秒)，難點Ribbon又反覆蓋了Feign?不，這還是因為坑點二，單獨配置Feign的讀取超時無法生效：

clientsdk.ribbon.listOfServers=localhost:45678 
feign.client.config.default.readTimeout=3000 
feign.client.config.clientsdk.readTimeout=2000 
ribbon.ReadTimeout=4000

3 Ribbon自動重試請求

一些HTTP客戶端往往會內置一些重試策略，其初衷是好的，畢竟因為網絡問題導致丟包雖然頻繁但持續時間短，往往重試就能成功，

但要留心這是否符合我們期望。

3.1 案例

短信重復發送的問題，但短信服務的調用方用戶服務，反復確認代碼里沒有重試邏輯。

那問題究竟出在哪里?

Get請求的發送短信接口，休眠2s以模擬耗時：

配置一個Feign供客戶端調用：

Feign內部有一個Ribbon組件負責客戶端負載均衡，通過配置文件設置其調用的服務端為兩個節點：

SmsClient.ribbon.listOfServers=localhost:45679,localhost:45678

客戶端接口，通過Feign調用服務端

在45678和45679兩個端口上分別啟動服務端，然后訪問45678的客戶端接口進行測試。因為客戶端和服務端控制器在一個應用中，所以45678同時扮演了客戶端和服務端的角色。

在45678日志中可以看到，29秒時客戶端收到請求開始調用服務端接口發短信，同時服務端收到了請求，2秒后(注意對比第一條日志和第三條日志)客戶端輸出了讀取超時的錯誤信息：

[http-nio-45678-exec-4] [INFO ] [c.d.RibbonRetryIssueClientController:23  ] - client is called 
[http-nio-45678-exec-5] [INFO ] [c.d.RibbonRetryIssueServerController:16  ] - http://localhost:45678/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418 
[http-nio-45678-exec-4] [ERROR] [c.d.RibbonRetryIssueClientController:27  ] - send sms failed : Read timed out executing GET http://SmsClient/ribbonretryissueserver/sms?mobile=13600000000&message=a2aa1b32-a044-40e9-8950-7f0189582418

而在另一個服務端45679的日志中還可以看到一條請求，客戶端接口調用后的1秒：

[http-nio-45679-exec-2] [INFO ] [c.d.RibbonRetryIssueServerController:16  ] - http://localhost:45679/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418

客戶端接口被調用的日志只輸出了一次，而服務端的日志輸出了兩次。雖然Feign的默認讀取超時時間是1秒，但客戶端2秒后才出現超時錯誤。

說明客戶端自作主張進行了一次重試，導致短信重復發送。

3.2 源碼揭秘

查看Ribbon源碼，MaxAutoRetriesNextServer參數默認為1，也就是Get請求在某個服務端節點出現問題(比如讀取超時)時，Ribbon會自動重試一次：

解決方案

1.把發短信接口從Get改為Post

API設計規范：有狀態的API接口不應定義為Get。根據HTTP協議規范，Get請求適用于數據查詢，Post才是把數據提交到服務端用于修改或新增。選擇Get還是Post的依據，應該是API行為，而非參數大小。

常見誤區：Get請求的參數包含在Url QueryString中，會受瀏覽器長度限制，所以一些開發會選擇使用JSON以Post提交大參數，使用Get提交小參數。

2.將MaxAutoRetriesNextServer參數配為0，禁用服務調用失敗后在下一個服務端節點的自動重試。在配置文件中添加一行即可：

ribbon.MaxAutoRetriesNextServer=0

問責

至此，問題出在用戶服務還是短信服務?

也許雙方都有問題吧。

Get請求應該是無狀態或者冪等的，短信接口可以設計為支持冪等調用
用戶服務的開發同學，如果對Ribbon的重試機制有所了解的話，或許就能在排查問題上少走彎路

最佳實踐

對于重試，因為HTTP協議認為Get請求是數據查詢操作，是無狀態的，又考慮到網絡出現丟包是比較常見的事情，有些HTTP客戶端或代理服務器會自動重試Get/Head請求。如果你的接口設計不支持冪等，需要關閉自動重試。但，更好的解決方案是，遵從HTTP協議的建議來使用合適的HTTP方法。

4 并發限制爬蟲抓取

HTTP請求調用還有一個常見的問題：并發數的限制，導致程序處理性能無法提升。

4.1 案例

某爬蟲項目，整體爬取數據效率很低，增加線程池數量也無謂，只能堆機器。

現在模擬該場景，探究問題本質。

假設要爬取的服務端是這樣的一個簡單實現，休眠1s返回數字1：

爬蟲需多次調用該接口抓取數據，為確保線程池不是并發瓶頸，使用了一個無線程上限的newCachedThreadPool，然后使用HttpClient執行HTTP請求，把請求任務循環提交到線程池處理，最后等待所有任務執行完成后輸出執行耗時：

使用默認的PoolingHttpClientConnectionManager構造的CloseableHttpClient，測試一下爬取10次的耗時：

雖然一個請求需要1s執行完成，但線程池可擴張使用任意數量線程。

按道理，10個請求并發處理的時間基本相當于1個請求的處理時間，即1s，但日志中顯示實際耗時5秒：

4.2 源碼解析

PoolingHttpClientConnectionManager源碼有兩個重要參數：

defaultMaxPerRoute=2，即同一主機/域名的最大并發請求數為2。我們的爬蟲需要10個并發，顯然是默認值太小限制了爬蟲的效率。
maxTotal=20，即所有主機整體最大并發為20，這也是HttpClient整體的并發度。我們請求數是10最大并發是10，20不會成為瓶頸。舉一個例子，使用同一個HttpClient訪問10個域名，defaultMaxPerRoute設置為10，為確保每一個域名都能達到10并發，需要把maxTotal設置為100。

HttpClient是常用的HTTP客戶端，那為什么默認值限制得這么小?

很多早期的瀏覽器也限制了同一個域名兩個并發請求。對于同一個域名并發連接的限制，其實是HTTP 1.1協議要求的，這里有這么一段話：

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
HTTP 1.1協議是20年前制定的，現在HTTP服務器的能力強很多了，所以有些新的瀏覽器沒有完全遵從2并發這個限制，放開并發數到了8甚至更大。
如果需要通過HTTP客戶端發起大量并發請求，不管使用什么客戶端，請務必確認客戶端的實現默認的并發度是否滿足需求。

嘗試聲明一個新的HttpClient放開相關限制，設置maxPerRoute為50、maxTotal為100，然后修改一下剛才的wrong方法，使用新的客戶端進行測試：

輸出如下，10次請求在1秒左右執行完成。可以看到，因為放開了一個Host 2個并發的默認限制，爬蟲效率得到了大幅提升：

4.3 最佳實踐

若你的客戶端有比較大的請求調用并發，比如做爬蟲，或是扮演類似代理的角色，又或者是程序本身并發較高，如此小的默認值很容易成為吞吐量的瓶頸，需要及時調整。

責任編輯：姜華來源： JavaEdge

HTTP