谷歌瀏覽器network請(qǐng)求時(shí)間(stalled,DNS Lookup,Waiting)分析以及解決方案

network工具功能強(qiáng)大,能夠讓我看到網(wǎng)頁(yè)加載的信息,比如加載時(shí)間,和先后順序,是否是并行加載,還是堵塞加載。


在這里插入圖片描述

默認(rèn)情況下有八列:
  (1).Name:表示加載的文件名。
 ?。?).Method:表示請(qǐng)求的方式。
 ?。?).Status:表示狀態(tài)碼(200為請(qǐng)求成功,304表示從緩存讀?。?。
  (4).Type:表示文件的MIME Type的類型。
  (5).Initiator:表示發(fā)出這個(gè)文件請(qǐng)求的發(fā)出者。
  (6).Size:表示文件大小。
  (7).Time:表示每個(gè)請(qǐng)求的總時(shí)長(zhǎng)。
 ?。?).Timeline:以圖表的形式顯示元素的請(qǐng)求和加載情況。
  當(dāng)然內(nèi)容不僅僅先于以上8個(gè),右擊上面八個(gè)任意一個(gè)選項(xiàng)卡可以彈出一個(gè)菜單,可以查看更多內(nèi)容:

  
在這里插入圖片描述

(1).Stalled(阻塞)

一般常規(guī)的優(yōu)化包括:css、js合并壓縮、圖片壓縮、雪碧圖、靜態(tài)資源全部上CDN,一般這些都做了但是慢的話,這是時(shí)候問題一般出在Stalled阻塞了,如下圖:

在這里插入圖片描述

什么是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.

也即是從TCP連接建立完成,到真正可以傳輸數(shù)據(jù)之間的時(shí)間差。先讓我們要分析TCP連接為什么要等待這么久才能用?用Wireshark抓包發(fā)現(xiàn)(如下圖),TCP連接過程中有多次重傳,直到達(dá)到最大重傳次數(shù)后連接被客戶端重置。

在這里插入圖片描述

為什么會(huì)發(fā)生重傳呢?

The sender waits for an ACK for the byte-range sent to the client and
when not received, resends the packets, after a particular interval.
After a certain number of retries, the host is considered to be “down”
and the sender gives up and tears down the TCP connection.

TCP三次握手后,發(fā)送端發(fā)送數(shù)據(jù)后,一段時(shí)間內(nèi)(不同的操作系統(tǒng)時(shí)間段不同)接收不到服務(wù)端ACK包,就會(huì)以 某一時(shí)間間隔(時(shí)間間隔一般為指數(shù)型增長(zhǎng))重新發(fā)送,從重傳開始到接收端正確響應(yīng)的時(shí)間就是stalled階段。而重傳超過一定的次數(shù)(windows系統(tǒng)是5次),發(fā)送端就認(rèn)為本次TCP連接已經(jīng)down掉了,需要重新建立連接。 對(duì)比以下,沒有重傳的http請(qǐng)求過程。如下圖:


在這里插入圖片描述

stalled階段時(shí)TCP連接的檢測(cè)過程,如果檢測(cè)成功就會(huì)繼續(xù)使用該TCP連接發(fā)送數(shù)據(jù),如果檢測(cè)失敗就會(huì)重新建立TCP連接。所以出現(xiàn)stalled階段過長(zhǎng),往往是丟包所致,這也意味著網(wǎng)絡(luò)或服務(wù)端有問題。

另外,需要注意的是:瀏覽器對(duì)同一個(gè)主機(jī)域名的并發(fā)連接數(shù)有限制,因此如果當(dāng)前的連接數(shù)已經(jīng)超過上限,那么其余請(qǐng)求就會(huì)被阻塞,等待新的可用連接;此外腳本也會(huì)阻塞其他組件的下載,被阻塞的請(qǐng)求的stalled也會(huì)很長(zhǎng)。

總結(jié)一下:
1,單一服務(wù)發(fā)送時(shí)候stalled過長(zhǎng),往往是丟包所致,這也意味著網(wǎng)絡(luò)或服務(wù)端有問題。
2,多個(gè)服務(wù)并發(fā)導(dǎo)致stalled過長(zhǎng),是瀏覽器對(duì)同一個(gè)主機(jī)域名的并發(fā)連接數(shù)有限制,過長(zhǎng)的請(qǐng)求是被阻塞了,處在隊(duì)列中等待tcp連接

所以,stalled階段是瀏覽器得到要發(fā)出這個(gè)請(qǐng)求的指令,到請(qǐng)求可以發(fā)出的等待時(shí)間,一般是代理協(xié)商、以及等待可復(fù)用的TCP連接釋放的時(shí)間,不包括DNS查詢、建立TCP連接等時(shí)間等。

優(yōu)化措施:
  1、將資源合理分布到多臺(tái)主機(jī)上,可以提高并發(fā)數(shù),但是增加并行下載數(shù)量也會(huì)增大 開銷,這取決于帶寬和CPU速度,過多的并行下載會(huì)降低性能;
  2、腳本置于頁(yè)面底部;

(2)DNS Lookup(域名解析)

請(qǐng)求某域名下的資源,瀏覽器需要先通過DNS解析器得到該域名服務(wù)器的IP地址。在DNS查找完成之前,瀏覽器不能從主機(jī)名那里下載到任何東西。

優(yōu)化措施:   
1、利用DNS緩存(設(shè)置TTL時(shí)間);
2、利用Connection:keep-alive特性建立持久連接,可以在當(dāng)前連接上進(jìn)行多個(gè)請(qǐng)求,無需再進(jìn)行域名解析;

(3)Initial connection(初始化連接)

TCP建立連接的三次握手時(shí)間

(4)Request sent(發(fā)送請(qǐng)求)

請(qǐng)求第一個(gè)字節(jié)發(fā)出前到最后一個(gè)字節(jié)發(fā)出后的時(shí)間,也就是上傳時(shí)間。
發(fā)送HTTP請(qǐng)求的時(shí)間(從第一個(gè)bit到最后一個(gè)bit)

優(yōu)化措施:   
1、減少HTTP請(qǐng)求,可以使用CSS Sprites、內(nèi)聯(lián)圖片、合并腳本和樣式表等;
2、對(duì)不常變化的組件添加長(zhǎng)久的Expires頭(相當(dāng)于設(shè)置久遠(yuǎn)的過期時(shí)間),在后續(xù)的頁(yè)面瀏覽中可以避免不必要的HTTP請(qǐng)求;

(3)Waiting(等待響應(yīng))

請(qǐng)求發(fā)出后,到收到響應(yīng)的第一個(gè)字節(jié)所花費(fèi)的時(shí)間(Time To First Byte)。

通常是耗費(fèi)時(shí)間最長(zhǎng)的。從發(fā)送請(qǐng)求到收到響應(yīng)之間的空隙,會(huì)受到線路、服務(wù)器距離等因素的影響。

優(yōu)化措施:   
1、使用CDN,將用戶的訪問指向距離最近的工作正常的緩存服務(wù)器上,由緩存服務(wù)器直接響應(yīng)用戶請(qǐng)求,提高響應(yīng)速度;

(4)Content Download(下載)

收到響應(yīng)的第一個(gè)字節(jié),到接受完最后一個(gè)字節(jié)的時(shí)間,就是下載時(shí)間。
下載HTTP響應(yīng)的時(shí)間(包含頭部和響應(yīng)體)

優(yōu)化措施:
1、通過條件Get請(qǐng)求,對(duì)比If-Modified-Since和Last-Modified時(shí)間,確定是否使用緩存中的組件,服務(wù)器會(huì)返回“304Not Modified”狀態(tài)碼,減小響應(yīng)的大小;   
2、移除重復(fù)腳本,精簡(jiǎn)和壓縮代碼,如借助自動(dòng)化構(gòu)建工具grunt、gulp等;
3、壓縮響應(yīng)內(nèi)容,服務(wù)器端啟用gzip壓縮,可以減少下載時(shí)間;

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 1、TCP狀態(tài)linux查看tcp的狀態(tài)命令:1)、netstat -nat 查看TCP各個(gè)狀態(tài)的數(shù)量2)、lso...
    北辰青閱讀 9,710評(píng)論 0 11
  • 國(guó)家電網(wǎng)公司企業(yè)標(biāo)準(zhǔn)(Q/GDW)- 面向?qū)ο蟮挠秒娦畔?shù)據(jù)交換協(xié)議 - 報(bào)批稿:20170802 前言: 排版 ...
    庭說閱讀 12,366評(píng)論 6 13
  • 當(dāng) app 和服務(wù)器進(jìn)行通信的時(shí)候,大多數(shù)情況下,都是采用 HTTP 協(xié)議。HTTP 最初是為 web 瀏覽器而定...
    Flysss1219閱讀 1,422評(píng)論 0 4
  • Swift1> Swift和OC的區(qū)別1.1> Swift沒有地址/指針的概念1.2> 泛型1.3> 類型嚴(yán)謹(jǐn) 對(duì)...
    cosWriter閱讀 11,641評(píng)論 1 32
  • 個(gè)人認(rèn)為,Goodboy1881先生的TCP /IP 協(xié)議詳解學(xué)習(xí)博客系列博客是一部非常精彩的學(xué)習(xí)筆記,這雖然只是...
    貳零壹柒_fc10閱讀 5,192評(píng)論 0 8

友情鏈接更多精彩內(nèi)容