鍍金池/ 問答/HTML/ 瀏覽器所允許的http請求最長的響應時間?

瀏覽器所允許的http請求最長的響應時間?

最近遇到一個問題,就是前端發(fā)起http請求后,后端接近要10幾分鐘才能完整處理好并且響應回來,而瀏覽器在2分多種的時候,因為請求一直沒有響應而failed了,雖然后面讓后臺優(yōu)化流程去了。但是我卻有了一個疑問:
  1. 瀏覽器對于http請求的響應時間是否存在最大值呢?是否超出一定時間內(nèi)無響應就會掛起這個請求?
  2. 如果實在是需要設置可以允許超長的請求,有可能做到嗎?
多謝各位大神的賜教,為了方便大家理解為什么我會提這個問題,這里補充下業(yè)務的場景:
  • 用戶點擊按鈕進行批量導入,然后彈框讓其選擇excel表,選擇完畢前端直接將數(shù)據(jù)發(fā)給后端處理;
  • 后端拿到excel表,將里面的數(shù)據(jù)先一一和我們的數(shù)據(jù)庫匹配,然后再將數(shù)據(jù)和天眼查(或其他類似)的數(shù)據(jù)比對,比對完成再將核實后的數(shù)據(jù)保存下來返回給前端;
  • 問題所在:

       a.前端不會限制excel表格的大小,理論上excel可以無限大;
       B.測試過當excel里面存在超過5000條數(shù)據(jù)的時候,前端發(fā)起請求后,后端一直在處理,而瀏覽器在2分鐘左右的時候就因為請求沒有任何響應而failed,但是看了后端的代碼,他其實還在運行,簡單看了下,后端整個過程下來要運行接近20分鐘
  • 目前想法:

       a.作為前端,對于這種要用戶等待時間這么長的請求,我肯定是不同意的,會嚴重影響用戶體驗,已經(jīng)讓后端回去檢查
       B.過程中衍生了一個想法:萬一將來真的有一天需要做這種惡心的功能,前端是否有可能做得到?
    

最后,再一次謝謝各位賜教的大神!

回答
編輯回答
任她鬧

1.超時時間肯定有,并且存在多級設定

  • 比如7層的HTTP超時,在 Nginx、Apache 之類的設置
  • 也存在 4 層的 TCP 超時
  • 中間網(wǎng)絡節(jié)點,也存在超時的可能

2.不建議設置超長的請求

3.根據(jù)耗時的原因,來更換策略

  • 如果是運算類型的接口導致的速度慢,是不是可考慮緩存接口數(shù)據(jù),提前預生成接口數(shù)據(jù)
  • 如果是下載類型,需要實時生成下載文件的,可以改成多次請求,

    • 第一種請求先申請下載任務
    • 第二種請求開始輪訓下載任務是否準備好
    • 第三種請求才直接下載文件

補充內(nèi)容

超大型文件的上傳,前端也是可以處理的,利用 FileAPI 對文件進行分割上傳

https://www.html5rocks.com/zh...

PS:上傳文件和數(shù)據(jù)對比,其實也可以拆分成兩個接口。

  • 上傳的接口只管上傳,怎么快,怎么體驗好,怎么來。
  • 獲取對比后的數(shù)據(jù),這是一種運算類型的接口,也可以單獨出來。
2017年6月8日 09:54
編輯回答
假灑脫

參見tcp的超時
逐級遞增,同步請求無法控制的,異步可以設置超時時間

2017年12月15日 11:50
編輯回答
朕略傻

瀏覽器有默認連接超時,F(xiàn)irefox 好像是115秒,Chrome 好像是5分鐘還是6分鐘。

如果后端需要處理十多分鐘才能返回結果,那肯定是要異步返回結果。不可能同步,沒理由同步,就算瀏覽器不超時,你也沒必要同步返回,浪費資源。

要及時返回處理結果,你可以用 WebSocket 和 Ajax 輪詢實現(xiàn)。

用戶上傳文件,服務器成功接受文件后返回一個上傳成功的結果,然后前端給個 Loading 提示,然后定時輪詢,查詢后端處理結果,處理成功了就更新前端提示成功,沒有就繼續(xù) Loading 提示。

2017年4月19日 21:08