http調用,走的是http協議,但網絡層走的是TCP/IP協議
所以一定是需要先建立連接的,所以存在兩個超時參數:
1、連接超時 ConnectTimeout , 配置用戶建立連接的最長時間
2、讀取超時 ReadTimeout ,控制socket 上讀取數據的最長等待時間
連接超時設置的比較長的問題,會導致一直在嘗試進行連接,創建大量的線程,最終崩潰
如果是客戶端直接連服務端,那連接超時大概率是服務端的問題
如果是經過了一層nginx , 那連接超時就要考慮nginx的問題了
讀取超時: 如果讀取超時,那服務端的執行會中斷 ?
其實類似tomcat的web服務器都把服務端請求提交到線程池處理的,只要服務端收到了請求,網絡層的超時與斷開便不會影響服務端的執行
所以讀取超時,並不能說明服務器那兒沒干事兒
大部分的讀取超時,可以認為是服務器業務邏輯的時間
大部分的連接超時,可以認為是網絡問題或者服務不在線
通常讀取超時設置不超過30秒
重試 get,head請求在瀏覽器上會主動進行重試
最終總結:
誤區一 | 誤區二 | 概念 | ||
讀取超時 | 讀取超時時,服務端的執行也停止 其實不是,服務端的線程池接收到任務, 網絡的情況就與實際服務端操作無關了 |
讀取超時設置越長服務的成功率越高? 客服端遇到服務超時,可能會受到拖累而創建 大量線程,最終崩潰 |
可以把讀取超時的時間大概率認為是服務端業務處理時間 | |
連接超時 | 連接超時設置很大 |
連接的是哪兒? 有的是客戶端與服務端直接連接,所以超時 |
||
重試機制 | 對於get,head請求一般都會有個重試機制 API的設計里,如果是get請求一般是無狀態的 如果有狀態的接口一般不定義為get |
如果進行重試,一定要保證服務的冪等性 | ||
並發限制 | ||||
為啥沒有寫超時?
因為數據都寫入到TCP緩沖區,從緩沖區寫入到服務端,屬於本地的操作,不存在超時之說。