手機網(wǎng)站建設(shè)TCP層面的時延對于網(wǎng)頁瀏覽整體時延的影響分析
日期 : 2019-06-25 17:28:24
TCP層面的時延對于網(wǎng)頁瀏覽整體時延的影響分析。當(dāng)前, 主流門戶網(wǎng)站首頁的頁面元素數(shù)量均在120個以上, 因此TCP會話的數(shù)量也相應(yīng)較多。根據(jù)統(tǒng)計, 各TCP會話的平均下載字節(jié)數(shù)為24.2KB, 消耗時延均值為390ms。與DNS會話相對應(yīng), 這些TCP會話也是分批次執(zhí)行的, 每批次的會話存在一定的并行關(guān)系。本次測試大致可將會話粗略分為八個批次, 則TCP會話所消耗的時間可近似計算為3.12s, 這與實際的TCP會話消耗時長基本一致。
接下來, 進一步對單個TCP會話的時延消耗開展分析。此處牽涉到TCP滑動窗口概念的簡述。基于TCP下載服務(wù)器數(shù)據(jù)時, 需要UE告知服務(wù)器側(cè)當(dāng)前可接收的數(shù)據(jù)總量, 即UE的TCP接收窗口大小。在非智能機時代, UE的初始接收窗口普遍較小 (15KB以下) 。因此在初次TCP下載時, 服務(wù)器一次性下發(fā)的數(shù)據(jù)包字節(jié)數(shù)就被限制在15KB以下。UE接收完成后擴大接收窗口, 允許服務(wù)器在下一回合下載中并行發(fā)送更多數(shù)據(jù)包, 這就是慢啟動過程。
而當(dāng)今智能機的初始接收窗口大小已達到40KB以上。本次測試所用的蘋果7達到了256KB。那么較大的初始接收窗口是否為下載帶來了巨幅性能提升呢?事實并不樂觀, 實際上服務(wù)器發(fā)送窗口的取值為, 接收端通告的接收窗口和發(fā)送端的擁塞控制窗口的最小值。當(dāng)前多數(shù)主流網(wǎng)站服務(wù)器的發(fā)送初始擁塞窗口默認(rèn)值均為15KB左右, 因此限制了數(shù)據(jù)包下載速率的提升。
根據(jù)統(tǒng)計, 本次測試各TCP會話的平均下載字節(jié)數(shù)為24.2KB, 是無法在首批次的下載過程中傳遞完畢的, 需經(jīng)歷兩個下載批次。因此單TCP會話的耗時可計算為TCP建鏈耗時+2個批次的數(shù)據(jù)下載耗時, 即193ms (3.5×RTT) , 但該值與本節(jié)開頭所列出的TCP會話消耗時延均值 (390ms) 存在約200ms的偏差。
接下來, 進一步對單個TCP會話的時延消耗開展分析。此處牽涉到TCP滑動窗口概念的簡述。基于TCP下載服務(wù)器數(shù)據(jù)時, 需要UE告知服務(wù)器側(cè)當(dāng)前可接收的數(shù)據(jù)總量, 即UE的TCP接收窗口大小。在非智能機時代, UE的初始接收窗口普遍較小 (15KB以下) 。因此在初次TCP下載時, 服務(wù)器一次性下發(fā)的數(shù)據(jù)包字節(jié)數(shù)就被限制在15KB以下。UE接收完成后擴大接收窗口, 允許服務(wù)器在下一回合下載中并行發(fā)送更多數(shù)據(jù)包, 這就是慢啟動過程。
而當(dāng)今智能機的初始接收窗口大小已達到40KB以上。本次測試所用的蘋果7達到了256KB。那么較大的初始接收窗口是否為下載帶來了巨幅性能提升呢?事實并不樂觀, 實際上服務(wù)器發(fā)送窗口的取值為, 接收端通告的接收窗口和發(fā)送端的擁塞控制窗口的最小值。當(dāng)前多數(shù)主流網(wǎng)站服務(wù)器的發(fā)送初始擁塞窗口默認(rèn)值均為15KB左右, 因此限制了數(shù)據(jù)包下載速率的提升。
根據(jù)統(tǒng)計, 本次測試各TCP會話的平均下載字節(jié)數(shù)為24.2KB, 是無法在首批次的下載過程中傳遞完畢的, 需經(jīng)歷兩個下載批次。因此單TCP會話的耗時可計算為TCP建鏈耗時+2個批次的數(shù)據(jù)下載耗時, 即193ms (3.5×RTT) , 但該值與本節(jié)開頭所列出的TCP會話消耗時延均值 (390ms) 存在約200ms的偏差。
相關(guān)文章
精彩導(dǎo)讀
熱門資訊
