：如何判斷網(wǎng)站請求是否響應完畢？

某個網(wǎng)站，通過瀏覽器去訪問則會一直在加載中，直到超時。為什么這個網(wǎng)站會一直加載（頂部狀態(tài)欄轉(zhuǎn)圈），但是頁面展示正常？

瀏覽器不需要等待頁面完全加載完才去渲染。

所謂的“頁面加載”實質(zhì)就是一個 HTTP 請求。HTTP 雖然是一個文本協(xié)議，但也是基于 Socket 流式傳輸?shù)摹＜热皇橇魇降模欠斩司屯耆梢韵戎话l(fā)送一部分數(shù)據(jù)、但是卻不關閉這個流，這樣客戶端會認為沒有接收完而選擇繼續(xù)等待，直到超時。

當然了，這是對于 HTTP/1.1 之前（先忽略 Keep-Alive，它不是重點）。在 HTTP/2 有了多路復用之后，多個 HTTP 請求底下對應的可能是同一個 Socket，這樣就不能單純地把“Socket 關閉”和“響應接收完畢”劃等號了 —— A 請求的響應接收完了、B 請求的響應可未必也完了，此時 Socket 并不會關閉。

幸好制訂 HTTP 協(xié)議時早就考慮好了和底層協(xié)議脫鉤的事情，它是有 Content-Length 這個響應標頭的，它指示了響應體應該有的實際長度，那么當客戶端接收到符合的長度后，就認為本次 HTTP 的響應已經(jīng)接收完畢了。

那么反過來想，如果服務端返回了一個錯誤 Content-Length，比如返回了 100，但是響應體卻只有 99，客戶端就會認為本次請求還沒結(jié)束，那么它就會接著等。

你可以用 Wireshark 之類的抓包看一下（需要直接抓 TCP，而不是 DevTools/Fiddler/Charles 這種基于 HTTP 的，因為如上文所言，這個 HTTP 報文會被認為是“不完整的”，所以這些基于 HTTP 的抓包工具是不能正確解析的），觀察一下這個請求的實際收到的字節(jié)數(shù)是不是小于 Content-Legnth 的。

雖然未完整接收，但瀏覽器會先渲染接收到的那部分HTML。

比如我用 Fiddler 攔截了 www.baidu.com 的請求，把它的 Content-Type 改成了 999999，然后瀏覽器就會一直轉(zhuǎn)圈、但是會先渲染收到的那部分 HTML ：

查看原文