摘要：開發(fā)環(huán)境前端后臺(tái)瀏覽器部署系統(tǒng)問題現(xiàn)象在現(xiàn)有項(xiàng)目的基礎(chǔ)之上增加了兩個(gè)頁(yè)面，但是在使用的過程中發(fā)現(xiàn)，當(dāng)連續(xù)操作幾次之后頁(yè)面會(huì)變得奇慢無(wú)比，查看接口調(diào)用發(fā)現(xiàn)接口請(qǐng)求長(zhǎng)時(shí)間處于狀態(tài)，但是等分鐘左右接口還是會(huì)返回應(yīng)答結(jié)果。

前端：Vue 2.0
后臺(tái)：Node Express
瀏覽器：Chrome
部署系統(tǒng)：Linux

在現(xiàn)有項(xiàng)目的基礎(chǔ)之上增加了兩個(gè)頁(yè)面，但是在使用的過程中發(fā)現(xiàn)，當(dāng)連續(xù)操作幾次之后頁(yè)面會(huì)變得奇慢無(wú)比，查看接口調(diào)用發(fā)現(xiàn)接口請(qǐng)求長(zhǎng)時(shí)間處于pending狀態(tài)，但是等1-2分鐘左右接口還是會(huì)返回應(yīng)答結(jié)果。如下圖所示：

通過反復(fù)復(fù)現(xiàn)該問題（在各個(gè)頁(yè)面之間不同切換，觸發(fā)請(qǐng)求），發(fā)現(xiàn)了一個(gè)規(guī)律，就是每次在第7次頁(yè)面切換的時(shí)候，所有接口都會(huì)被阻塞并在1分多鐘之后才返回。

看看這1分多鐘究竟花在了哪里？

從上圖可以看到，整個(gè)接口請(qǐng)求的大部分時(shí)間都花在了Stalled階段。現(xiàn)在的問題是Stalled是啥意思？下面是一段比較淺顯的解釋：

Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation.Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome’s maximum six TCP connection per origin rule.

從上面的解釋看，可能有兩個(gè)原因：

TCP連接出問題了，一直無(wú)法建鏈成功；

TCP連接是OK的，但是一直被占用無(wú)法使用。

首先看第一個(gè)問題，TCP連接是否正常？

$ lsof -i:8700
COMMAND   PID     USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
node    26315 mumingv   12u  IPv4 449215145     0t64  TCP *:8700 (LISTEN)
node    26315 mumingv   16u  IPv4 449217569     0t64  TCP localhost:8700->172.24.186.14:54064 (ESTABLISHED)
node    26315 mumingv   17u  IPv4 449217570     0t64  TCP localhost:8700->172.24.186.14:54065 (ESTABLISHED)
node    26315 mumingv   18u  IPv4 449217580     0t64  TCP localhost:8700->172.24.186.14:54066 (ESTABLISHED)
node    26315 mumingv   19u  IPv4 449217581     0t64  TCP localhost:8700->172.24.186.14:54067 (ESTABLISHED)
node    26315 mumingv   20u  IPv4 449226874     0t64  TCP localhost:8700->172.24.186.14:54574 (ESTABLISHED)
node    26315 mumingv   21u  IPv4 449217583     0t64  TCP localhost:8700->172.24.186.14:54069 (ESTABLISHED)

上圖中，8700是網(wǎng)站的服務(wù)端口號(hào)，172.24.184.14是Chrome瀏覽器所在Mac的IP。在復(fù)現(xiàn)問題的過程中一直執(zhí)行lsof -i:8700持續(xù)進(jìn)行觀察發(fā)現(xiàn)，當(dāng)在第7次頁(yè)面切換的時(shí)候，這里的TCP連接數(shù)量不再增加，維持在6個(gè)左右且狀態(tài)都是ESTABLISHED（已建立）。所以可以基本排除TCP連接的問題。

當(dāng)然，也可以通過netstat命令查詢TCP連接狀態(tài)。
$ netstat -tunpa | grep 8700
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8700                0.0.0.0:*                   LISTEN      27765/node          
tcp        0      0 10.95.199.140:8700          172.24.186.14:65413         ESTABLISHED 27765/node          
tcp        0      0 10.95.199.140:8700          172.24.186.14:65412         ESTABLISHED 27765/node          
tcp        0      0 10.95.199.140:8700          172.24.186.14:65421         ESTABLISHED 27765/node          
tcp        0      0 10.95.199.140:8700          172.24.186.14:65420         ESTABLISHED 27765/node          
tcp        0      0 10.95.199.140:8700          172.24.186.14:65419         ESTABLISHED 27765/node          
tcp        0      0 10.95.199.140:8700          172.24.186.14:65422         ESTABLISHED 27765/node          

再來(lái)看第二個(gè)問題，TCP連接被誰(shuí)占用了不釋放？

看看是不是有其他請(qǐng)求占用了這些TCP連接，查看所有請(qǐng)求，果不其然：

原來(lái)每次在頁(yè)面切換的時(shí)候，瀏覽器都會(huì)默認(rèn)發(fā)送一個(gè)請(qǐng)求獲取一次網(wǎng)頁(yè)圖標(biāo)，這個(gè)不是前端業(yè)務(wù)邏輯主動(dòng)調(diào)用的XHR請(qǐng)求，但對(duì)于后端來(lái)說也是一次GET請(qǐng)求。

實(shí)際上，如果沒有要求顯示特定網(wǎng)頁(yè)圖標(biāo)的話，后端隨便返回一個(gè)信息就好了，不用非得準(zhǔn)備一個(gè)網(wǎng)頁(yè)圖標(biāo)。瀏覽器拿不到圖標(biāo)的話會(huì)顯示一個(gè)默認(rèn)圖標(biāo)。

問題找到了，看看為啥后端為啥沒有返回圖標(biāo)并加以解決就好了。具體到這個(gè)項(xiàng)目，是在node express的app.js入口文件中沒有注冊(cè)相應(yīng)的處理邏輯。

// 接口路由
loadRouter(app, "/project-name", path.join(__dirname, "app/controllers"));

// 靜態(tài)頁(yè)面
app.use("/project-name", express.static(path.join(__dirname, "webroot", "project-name")));

// favicon.ico和其他不支持的請(qǐng)求
app.get("*", function(req, res) {
    if (req.path === "/favicon.ico") {
        return;  // ！！！這里不能直接return，需要返回具體的內(nèi)容，否則會(huì)阻塞express框架返回應(yīng)答消息！！！
    }   
    throw new PathError();
});

知道問題后，修改就很簡(jiǎn)單了。

app.get("*", function(req, res) {
    if (req.path === "/favicon.ico") {
        res.json({"status":0, msg:""});  // 這里隨便返回個(gè)內(nèi)容就行，不影響瀏覽器使用默認(rèn)圖標(biāo)進(jìn)行展示
    }   
    throw new PathError();
});

至此，問題解決。

TCP連接資源數(shù)量有限，如果不限制數(shù)量的話，所有TCP全部被占用的話系統(tǒng)就“無(wú)法提供服務(wù)”了。一般瀏覽器的并發(fā)TCP連接數(shù)量都在5、6個(gè)左右，對(duì)于Chrome來(lái)說是6個(gè)。至于為什么是這么多，這是各瀏覽器自行設(shè)置的，沒有標(biāo)準(zhǔn)。具體解釋參考：官方文檔。

一般按照如下幾步進(jìn)行排查即可：

瀏覽器端看XHR請(qǐng)求，判斷XHR請(qǐng)求本身是否有異常；

瀏覽器端看ALL請(qǐng)求，判斷非XHR請(qǐng)求是否有異常；

服務(wù)器端查看服務(wù)本身是否正常；

服務(wù)器端查看服務(wù)建立的TCP連接是否正常；

抓包查看TCP交互和業(yè)務(wù)請(qǐng)求交互報(bào)文是否有異常。

Network Issues Guide

Understanding Resource Timing

chrome的timeline中stalled問題解析