校園網絡質量測量系統設計與部署

文/章思宇 沈海云 賴學亮

網絡質量監測對掌握校園網運行狀況、發現網絡故障、優化用戶上網體驗、評價網絡建設成效等均有重要意義。目前，用戶接入側的質量作為影響用戶上網體驗的關鍵因素之一，仍是校園網質量監測的難點所在。對于此，在用戶接入位置部署撥測探針，或請用戶主動進行測速，依舊是校園網質量監測的最常用手段。

系統設計

基于瀏覽器的網絡測量

現代的瀏覽器提供Performance API接口，允許使用JavaScript 獲得與當前頁面相關的性能信息。通過getEntries 或getEntriesByType 函數獲取“resource”類型的記錄，可得到頁面上各資源加載的高精度時間線信息，包括域名查詢的開始和結束時間、連接開始和結束時間、請求開始時間、響應開始和結束時間等。Performance API 提供的時間戳精度可達5 微秒。

本文基于瀏覽器的網絡質量主動測量系統，利用Performance API 獲取頁面主動發起的HTTP 請求的精確處理時間，以此來計算網絡延遲和資源下載速度。開源的測速軟件LibreSpeed 亦采用了類似的方法在瀏覽器里進行網絡測速。系統使用的API 功能在IE 11 瀏覽器，2015 年之后的Chrome、Firefox 瀏覽器和Android 系統版本，以及2017 年之后的iOS 系統版本中可得到支持，對用戶當前普遍在用的瀏覽器和手機設備具有較好的兼容性。

測量延遲和抖動

為測量網絡延遲，系統利用JavaScript從用戶瀏覽器主動發起Ajax 請求，服務器迅速返回響應，然后通過瀏覽器Performance API 獲得該請求和響應的時間戳。由于HTTP 請求和響應尺寸較小，在一個TCP 報文中即可容納，因此忽略瀏覽器和Web 服務器處理請求消耗的少量時間后，瀏覽器發送請求（requestStart）與收到響應（responseStart）的時間差可基本代表客戶端與服務器之間的網絡延遲。

為驗證該方法與ICMP ping 測量延遲和抖動的結果差異，在校園網內分別使用ICMP ping 和該方法發送10 次請求，對比Wireshark 報文分析和瀏覽器Performance API 計算結果差異。測試主機上使用Wireshark 計算10 次ICMP ping 的平均延遲為0.33 ms，抖動0.05 ms。Wireshark計算10 對HTTPS 請求響應報文的平均時間差為0.66 ms，抖動0.11 ms。瀏覽器Performance API 計算得到10 次HTTPS 請求響應的平均時間差為2.02 ms，抖動0.48 ms。對比結果顯示，Web 服務器和瀏覽器引入的處理耗時約1.7 ms，對抖動影響小于0.5 ms，該差異對監測接入質量較差用戶的影響輕微，因為這些用戶的延遲和抖動通常可達數十毫秒。

系統通過HTTP Keep-alive 保持連接，避免每次請求均新建TCP 連接增加耗時。同時，通過URL 添加隨機GET 參數，并在HTTP 響應頭設置Cache-Control 的no-store屬性來避免緩存。

測量下載速率

系統使用瀏覽器Performance API 測量從服務器加載特定尺寸資源所需時間，估算用戶網絡的下載速率。由于頁面跳轉會中斷后臺資源加載，必須選取合適的下載尺寸和超時時間以尋求測試成功率和結果準確性的平衡。經真實用戶終端試驗，每次測試下載5 MB 數據、最多等待20 秒時間，可取得95%以上的測試成功率。

在高帶寬網絡下，受TCP 擁塞控制算法慢啟動機制影響，5 MB 數據的平均下載速率可能明顯低于實際帶寬。為了驗證校園網環境下5 MB尺寸測速的準確性，我們在百兆、千兆校園有線網和無線網下分別進行多次實驗。使用百兆校園有線網，5 MB 數據下載平均速率為91.2 Mbps，千兆有線網下平均為410.1 Mbps。在校園無線網下，使用LibreSpeed 測得下行帶寬約為273 Mbps 時，5 MB 數據下載平均速率為227.3 Mbps。該結果顯示雖然5 MB下載平均速率會與實際帶寬有一定差距，但已能基本反映用戶網絡下載速度優劣。

系統實現與部署

系統對外呈現一個HTML 頁面，可通過iframe 嵌入校園網站或應用系統，用戶訪問這些網站或系統時后臺可自動進行網絡測量。

瀏覽器停留在嵌入本系統的網站頁面期間，系統持續進行每秒1 次的延遲測量，每10 秒上傳一次統計數據。為避免下載測速功能消耗用戶手機移動數據流量，系統只對使用學校校園網的用戶，以及PC系統用戶開展下載測速。同時，同一終端（根據相同IP 地址和User-Agent 識別）在6 小時內只進行一次測速。

系統僅采集IP 地址、User-Agent 和網絡延遲、下載速率，不采集用戶名等其他信息。其中，IP 地址和User-Agent 在各網站服務器訪問日志中均有留存，因此引入本系統不增加個人信息的采集。瀏覽器同源策略確保了通過iframe 嵌入的本系統無權訪問父頁面內容，因此不會對嵌入本系統的網站和應用系統產生安全風險。系統首頁將系統功能和數據采集情況向用戶說明，并提供退出網絡測量的方法和聯系方式。

應用成效

網絡測量數據采集

基于瀏覽器的網絡質量主動測量系統部署在上海交通大學云平臺，并在網絡信息中心網站首頁、線上辦事服務大廳頁面進行了嵌入。

根據對2021 年9 月全月運行數據的統計（如圖1 所示），系統平均每天測量終端3.24 萬個（根據不同IP 地址和User-Agent計算），其中移動終端（安卓和iOS 系統）占74.9%，桌面終端占25.1%。被測終端來自校園有線網的占11.6%，校園無線網占55.5%，校外網絡占32.9%。當前部署情況下，平均每日測量的校園網終端已達2.17萬個，基本實現了較廣范圍測量的目標。

圖1 2021 年9 月每日測量終端統計

2021 年9 月全月系統采集延遲測量記錄2.04 億條（見表1），每條包含10 次延遲測量值，相當于采集了總共20.4 億個ping 值。延遲測量記錄81.2%為校園網內終端產生，97.1%為桌面終端，說明桌面用戶在測量嵌入的網站頁面停留時間較長，平均每個終端每天8119 秒，而移動終端用戶平均每天頁面停留僅79 秒。全月系統采集下載測速記錄68.2 萬條，90.3%為校園網內測速。

表1 2021 年9 月測量記錄統計

校園網接入質量分析

利用系統采集的測量數據，可開展多維度的校園網接入質量分析。

表2 按網絡類型做總體比較，通過校園有線網接入的終端，網絡穩定性（通過延遲、抖動和請求失敗率評價）及下載速率優于校園無線網。有線網終端通過5 MB 數據下載測得平均下載速率127.55 Mbps，無線網平均為68.15 Mbps。根據之前的分析，實際下行帶寬要比該數值更高。

表2 按網絡類型測量均值

全月測量覆蓋校園有線網IP 地址共1.44 萬個，下載測速顯示30.6%的IP 地址取得100 Mbps 以上的下載速率，為終端全面支持千兆的用戶，其余用戶盡管校園網提供了千兆接入能力，但用戶終端或自購路由器仍只支持百兆。根據是否有移動終端，或不同類型操作系統的PC 同時接入，分析得知約66.7%的校園有線網IP 地址使用了自購的NAT 路由器，且其中98%以上為無線路由器（有移動終端接入）。

表3 將校園無線網分為3 個區域進行比較。區域A 建設于2018 年以前，以WiFi 5 無線AP 為主，有少量WiFi 4 AP；區域B 建設于2018 至2019 年間，全部為WiFi 5 無線AP；區域C 建設于2020 至2021 年間，以WiFi 6 無線AP 為主，有少量WiFi 5 AP。測量結果顯示，近四年建設的區域B、C 用戶接入穩定性優于更早建設的區域A，其中區域B 的穩定性最優。采用了WiFi 6 設備的區域C 用戶下載速率得到顯著提升，平均下載速率是區域A 的2 倍，比區域B 也提升了59%。

表3 校園無線網按區域均值

校園有線網用戶接入質量與大樓建成及用戶入住年限有關。表4 選擇校內4 個區域的有線網進行比較，區域D 為啟用超過十年的某學院大樓，區域E 為2020 年啟用的學院大樓，區域F 為大四學生宿舍，區域G 為大一學生宿舍。結果顯示，無論是學院大樓還是學生宿舍，較新啟用和入住的區域（E、G），因用戶設備更新、布線質量更好，支持千兆的用戶比例及區域整體的下載速率都要更高。

表4 校園有線網按區域均值

除了評價校園網整體質量外，利用系統采集的數據對個體區域進行逐一深入分析，可定位低速、低穩定性用戶集中的區域，為校園有線、無線網絡和布線系統改造計劃的制訂提供數據支撐。

本文設計并實現了一套基于瀏覽器的輕量級網絡質量主動測量系統，并在校園網內開展了較大規模的實驗驗證，平均每天主動測量終端3.24 萬個，采集的數據在分析校園網整體質量、評價有線與無線網升級改造成效、發現區域和個體用戶網絡質量異常方面發揮了實際價值。與現有網管和測速工具相比，本文方法的優勢在于：1.基于瀏覽器測量延遲、抖動和下載速率，對桌面和移動終端普遍適用；2.測量全部從真實用戶終端發起；3.可快速開展大范圍測量，且對用戶無感；4.長時間后臺測量可發現偶發的網絡抖動。