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