我想知道在兩種服務之間處理HTTP超時的兩種方法之間的權衡。服務A試圖呼叫服務B.在重試期間調整HTTP超時與退避
方法1時實現重試功能：這是典型的方法（例如以太網原）。執行固定超時時間爲T的請求。如果發生超時，請爲X休眠並重試請求。以指數形式增加X.方法2：不是在重試之間休眠，而是增加實際的HTTP超時值（例如，按指數規律）。在這兩種情況下，考慮一個最大限度。
對於以太網，這是有道理的，因爲它是網絡堆棧中的低層位置。但是，對於應用程序級別的重試機制，方法2更合適？在有高水平的網絡擁塞的情況下，我認爲＃2是一對夫婦更好的理由：
對此有何看法？
在高分組丟失的網絡上（例如蜂窩或接近其範圍限制的Wi-Fi），如果超時太短，您的請求將永遠超時。所以增加超時通常是一個好主意。
立即重試請求會立即生效，如果不重要，則等待一段時間可能沒有什麼區別（例如，如果您不再有網絡連接）。例如，在iOS上，最好的辦法是使用可達性，如果可達性確定網絡已關閉，則在沒有理由重試之前不會重試。
我的一般想法是，如果在3-5秒之後根本沒有收到服務器的任何響應，那麼對於短的請求（即不上傳/下載大文件），請並行開始第二個請求。無論哪個請求返回首標都會贏。取消另一個。保持超時90秒。如果失敗，看看你是否可以達到generate_204。
如果generate_204有效，問題可能是服務器問題。立即重試，但將服務器標記爲可疑。如果該重試第二次失敗（在成功的generate_204響應之後），請啓動等待服務器的指數退避（在最大時間間隔內設置上限）。
如果generate_204請求沒有響應，您的網絡已經死亡。等待網絡更改，只是偶爾嘗試（例如，每隔至少幾分鐘）。
如果網絡連接更改（即突然有Wi-Fi），請在幾秒鐘後重新啓動任何等待的連接。在那個時候沒有理由等待全職，因爲一切都改變了。
但顯然沒有正確的答案。這種方法相當有侵略性。其他人可能採取相反的做法。這完全取決於你的目標是什麼。
偉大的洞察力...通過這個閱讀有助於反思我的問題場景。我們確實有一個潛在的高丟包網絡，雖然它會由於流量負載而發生，而不一定是來自媒體的質量。本質上，場景需要分爲兩部分：A）連接建立和B），連續數據傳輸。 （A）和指數退避（即睡眠）可能更適合於（B），對於短連接超時連續重試將是理想的。 – Jmoney38
有沒有睡覺多點的時候，你可以做有益的工作，或者在使用較短的超時比你真的可以容忍的。我會用（2）。
以太網或任何東西使用（1）的想法似乎很奇特。你有引用嗎？
https://en.wikipedia.org/wiki/Exponential_backoff 以太網的使用的ExB的和應用程序的使用之間的區別是，一個應用程序正在嘗試實際上建立持續的通信信道（假定TCP）。 – Jmoney38
套接字或連接的HTTP超時？ –
好問題。我認爲這個論點可以用於超時。我會更新說明中的最後一個項目符號。 – Jmoney38
高網絡擁塞是否意味着消息需要更長時間才能交付，或者是否意味着某些消息只是被丟棄？它可能取決於網絡和應用程序。 – Trilarion