Chrome Devtools中HTTP響應低於500字節的高「接收時間」

在Windows 7和Windows 7上的Chrome 15（穩定）上使用devtools Network選項卡時，我看到HTTP「響應」是> 100ms，但響應是302重定向或小圖像（信標） - 有效負載低於500字節（標題+內容）。Chrome Devtools中HTTP響應低於500字節的高「接收時間」

捕捉上Wireshark的TCP流量清楚地顯示發送在一個TCP數據包的完整的HTTP響應，所以接收時間應已經0。一個很好的例子，服務器是CNN首頁，或有很多的任何各大網站廣告和跟蹤信標。

這帶來了幾個問題：

什麼被定義爲「接受」，在鉻devtools？這是從第一個數據包到最後一個數據包的時間？
客戶機/操作系統中的哪些因素影響「接收」時間，在網絡/服務器通信之外？

在我的測試中，我使用了Windows XP的虛擬機，而Windows 7 在桌面上（四核，8GB RAM）。

來源

2011-12-12 Drit

「接收時間」是didReceiveResponse（「響應頭接收到的」）和didReceiveData之間的時間（「響應的數據塊接收的」）WebURLLoaderClient事件由網絡層報，所以一些內部處理開銷可應用。
在一般情況下，請記住HTTP協議是面向流的，所以TCP數據包之間的數據劃分是不可預測的（一半報頭可能進入一個數據包，其餘數據和響應主體可能會得到進入下一個，但這似乎不是你的情況。）
只要有可能，請使用最新版本的Chrome。它很可能包含較少的錯誤，包括網絡層:-)

來源

2011-12-29 11:35:50

亞歷克斯即使在Chrome的最新版本中也會發生相同的行爲。我的另一個擔心是，如果使用wireshark進行監控，您會注意到DevTools打開時TCP數據包的行爲會發生變化。客戶端確認以某種方式延遲。 – Drit

Nagle算法和延遲ACK算法是兩種擁塞控制算法，默認情況下在Windows機器上啓用。這些會在小型有效載荷的流量中引入延遲，以試圖減少TCP/IP的一些不適感。

當接收到小的有效載荷時，延遲的ACK將在Chrome的網絡選項卡中導致〜200ms的附加「接收」時間。這裏是一個網頁，解釋算法以及如何在Windows上禁用它們：http://smallvoid.com/article/winnt-nagle-algorithm.html

來源

2012-07-05 15:22:29 Jarrod

Chrome Devtools中HTTP響應低於500字節的高「接收時間」

回答

相關問題