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

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

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

所謂的“頁(yè)面加載”實(shí)質(zhì)就是一個(gè) HTTP 請(qǐng)求。HTTP 雖然是一個(gè)文本協(xié)議，但也是基于 Socket 流式傳輸?shù)?。既然是流式的，那服?wù)端就完全可以先只發(fā)送一部分?jǐn)?shù)據(jù)、但是卻不關(guān)閉這個(gè)流，這樣客戶端會(huì)認(rèn)為沒有接收完而選擇繼續(xù)等待，直到超時(shí)。

當(dāng)然了，這是對(duì)于 HTTP/1.1 之前（先忽略 Keep-Alive，它不是重點(diǎn)）。在 HTTP/2 有了多路復(fù)用之后，多個(gè) HTTP 請(qǐng)求底下對(duì)應(yīng)的可能是同一個(gè) Socket，這樣就不能單純地把“Socket 關(guān)閉”和“響應(yīng)接收完畢”劃等號(hào)了 —— A 請(qǐng)求的響應(yīng)接收完了、B 請(qǐng)求的響應(yīng)可未必也完了，此時(shí) Socket 并不會(huì)關(guān)閉。

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

那么反過來想，如果服務(wù)端返回了一個(gè)錯(cuò)誤 Content-Length，比如返回了 100，但是響應(yīng)體卻只有 99，客戶端就會(huì)認(rèn)為本次請(qǐng)求還沒結(jié)束，那么它就會(huì)接著等。

你可以用 Wireshark 之類的抓包看一下（需要直接抓 TCP，而不是 DevTools/Fiddler/Charles 這種基于 HTTP 的，因?yàn)槿缟衔乃裕@個(gè) HTTP 報(bào)文會(huì)被認(rèn)為是“不完整的”，所以這些基于 HTTP 的抓包工具是不能正確解析的），觀察一下這個(gè)請(qǐng)求的實(shí)際收到的字節(jié)數(shù)是不是小于 Content-Legnth 的。

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

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

查看原文