網速測試
四個數字,量得誠實,方法全部攤開給你看。
不上傳任何檔案
大約 20 秒。你按下之前不會開始。
0Mbps
量測細節
- 這次測試總共用掉的資料量
- —
- 下載
- —
- 傳輸資料量
- —
- 量測窗口
- —
- 丟棄的暖機
- —
- 穩態區間桶數
- —
- 並發連線數
- —
- 含暖機的平均
- —
- 結束原因
- —
- 上傳
- —
- 傳輸資料量
- —
- 量測窗口
- —
- 丟棄的暖機
- —
- 穩態區間桶數
- —
- 並發連線數
- —
- 瀏覽器當場產生的隨機位元組
- —
- 伺服器確認收到的位元組
- —
- 保守對照值(確認位元組 ÷ 整段窗口)
- —
- 延遲
- —
- 往返樣本
- —
- 最小 / 最大
- —
吞吐量是穩態區間切成短桶後的中位數,慢啟動那一段已被丟棄,並且使用多條並發連線。頭條數字背後的每一個原始數值都列在上面。
上傳測試送出的是瀏覽器當場產生的隨機資料,不是你的檔案。這一頁完全沒有檔案輸入欄位,而收到的位元組會被逐塊讀掉並丟棄。
這個測試同時用多條連線量吞吐量,丟掉慢啟動那一段,回報穩定區間的中位數而不是一個方便的平均值。完整的量測細節就放在頁面上,你可以自己驗算。
測速能告訴你什麼、不能告訴你什麼
它量的是一件事:這台裝置、透過這條連線、在此刻,能以多快的速度與最近的邊緣節點之間搬移資料。這個數字確實有用,但它跟業者賣給你的速度不是同一件事。你的方案描述的是「進到建築物的那條線」的容量;從那一點之後 —— Wi-Fi 這一跳、路由器、家裡其他人正在看的串流 —— 全都夾在你跟那個數字之間。
Wi-Fi 是最常見的瓶頸,而且領先幅度很大。一台隔兩個房間、擠在壅塞 2.4 GHz 頻道上的裝置,量出來可能只有同一條線接網路線時的零星幾分之一,而線路本身沒有任何問題。如果結果讓你意外,先用網路線、或站在路由器旁邊再測一次,再下關於業者的結論。換個時間再測也值得:共享型接取網路在晚間尖峰會變慢。
這個測試是怎麼量的
有四件事決定了「一個站得住腳的量測」與「一個看起來合理的數字」之間的差別。第一,多條並發連線:單一條 TCP 串流受往返時間與視窗大小限制,所以在高延遲線路上,一條連線無論如何都填不滿一條快的管子。第二,暖機階段被丟棄 —— TCP 擁塞控制從很小的視窗開始成長,任何傳輸的開頭那一段都比穩態慢,把它算進去只會把結果往下拉。
第三,回報的數字是穩定區間切成短桶之後的中位數,而不是平均值。平均值會讓某一個被干擾的瞬間 —— 鄰居開始下載、Wi-Fi 掉一拍、手機換基站 —— 拉走頭條數字;中位數不會。第四,下載素材是密碼學隨機位元組,不可壓縮。如果測試資料可以被壓縮,我們與你之間的任何代理都能在傳輸中壓縮它,於是我們會拿「壓縮後的位元組數」去除以原始大小所需的時間,得出一個比實際吞吐量高好幾倍的假數字。結果面板同時顯示總位元組數、量測窗口、被丟棄的暖機長度與每一個桶的數值,所以頭條數字可以從原始資料被重新算出來。
延遲與抖動比那兩個大數字更重要
延遲是一筆極小請求的往返時間 —— 網路「有回應」本身要花多久。抖動是這個時間在相鄰樣本之間變動了多少。對任何需要即時互動的事情來說,這兩個對體驗的影響遠大於吞吐量。一通視訊通話只需要幾 Mbps;讓它斷斷續續的是延遲與抖動。一旦頻寬足夠你正在做的事,再多的頻寬不會改變任何體驗,而抖動一有問題,你立刻就聽得出來。
一條速度其實很快的線路卻有高抖動,通常指向 Wi-Fi 干擾,或是 bufferbloat —— 路徑上某處過大的佇列在大量傳輸時被填滿,把後面所有東西都延遲了。一個好用的診斷:在有一個大檔案正在下載的時候跑這個測試。如果延遲在負載下急遽上升,那不是線路太慢,是它的佇列行為很糟;現代路由器固件通常有佇列管理選項可以解決。
上傳測試是我們唯一會接收資料的地方
Breezo 成立的前提是你的檔案永遠不離開你的裝置,而上傳量測必須誠實地跟這個前提對齊,不能含糊帶過。要量上傳吞吐量,另一端就必須有東西可以接收位元組,這件事沒有辦法繞過。所以這一頁確實會送出資料 —— 以下是它送出的到底是什麼。
Payload 是在送出的那一刻、由你的瀏覽器用密碼學隨機產生器當場產生的隨機位元組。它不是檔案,也從來不碰你的儲存空間:這一頁完全沒有檔案輸入欄位,所以頁面上不存在任何能讀取檔案的東西,連誤觸都不可能。位元組抵達後被逐塊讀掉然後丟棄 —— 不寫入磁碟、不轉發、不保留。端點只回一個數字:它收到幾個位元組,結果面板會拿它跟你瀏覽器送出的量互相對照。我們的驗收腳本更進一步,每一次執行都驗證「隨機產生器產生的位元組數不少於實際 POST 出去的位元組數」—— 只要有任何程式路徑試圖送出別的東西,這條測試會立刻失敗。
怎麼讀你的結果
速度以每秒百萬位元(Mbps)表示,那是業者宣傳用的單位。你的下載工具顯示的是每秒百萬位元組(MB/s),大約是這個數字的八分之一 —— 把這兩個搞混,是人們誤以為自己只拿到付費速度零頭的最常見原因。粗略參考:視訊通話大約 3 Mbps 以上就順、高畫質串流大約 5 以上、4K 大約 25 以上,而只有大型遊戲或影片下載這種日常任務,才真的用得到幾百。
有兩個限制值得說明。這個測試會在固定的資料量上限停止,避免在計量或行動網路上吃掉不合理的流量 —— 也就是說,在很快的線路上量測窗口會偏短,結果偏保守而不是偏樂觀。另外,任何量測都只是一個快照:單一個數字告訴你的,遠少於在一天中不同時段跑三次,在共享或行動網路上尤其如此,因為負載每小時都在變。
常見問題
為什麼測出來比我付費的速度低?
通常是 Wi-Fi,不是線路。距離、牆壁與頻道壅塞會吃掉大量吞吐量,家裡其他人在用也一樣。先用網路線、或站在路由器旁邊重測,再怪業者。也請確認單位 —— 業者講的是位元(Mbps),下載工具顯示的是位元組(MB/s),後者小八倍。
為什麼每次跑出來的數字都不一樣?
因為它量的是一個共享且持續變動的系統的即時狀態。網路負載、Wi-Fi 環境、到最近邊緣節點的路徑,每分鐘都在變。上下幾十個百分比是正常的;跑三次取中間那次。
這個測試會上傳我的檔案嗎?
不會。上傳量測送出的是瀏覽器在那一刻當場產生的隨機位元組,而且這一頁完全沒有檔案輸入欄位,所以連誤讀檔案都不可能。收到的位元組會立刻被丟棄,不儲存任何東西。
這個測試會用掉多少流量?
有上限,實際用量會在執行後顯示在量測細節裡。設上限是為了不讓測試吃掉行動或計量網路不合理的份額。在很快的線路上,是這個上限結束了測試,所以結果偏保守。
延遲與抖動多少算好?
延遲低於大約 30 ms,連遊戲都很舒服;到大約 100 ms 對一般瀏覽與通話都還可以。抖動比平均值更重要:低於大約 10 ms 算好,而持續偏高的抖動通常代表 Wi-Fi 干擾或 bufferbloat,不是頻寬不足。
其他工具
- JPG 轉 PDF照片進去,一個 PDF 出來 —— 全程不上傳。
- PDF 轉 JPG每一頁變成一張圖,解析度你決定。
- PDF 轉 PNG無損的頁面,透明度保留。
- 合併 PDF多份文件進去,一份文件出來。
- 分割 PDF一頁一個檔,而且不必把文件交出去。
- HEIC 轉 JPG照片不會離開你的裝置。
- 圖片壓縮把檔案變小,不必把檔案交出去。
- WebP 轉 JPG給那些到現在還是打不開 .webp 的軟體。
- PNG 轉 JPG檔案小很多 —— 前提是圖片是照片。
- JPG 轉 PNG從這裡開始無損 —— 但請先讀這段。
- HEIC 轉 PNG當你需要透明度,或需要一份無損副本。
- JPG 轉 WebP相同品質設定下,檔案明顯更小。
- PNG 轉 WebP唯一同時保留透明度又能變小的常見目標格式。
- WebP 轉 PNG給「需要透明度」加上「軟體打不開 .webp」的情況。
- AVIF 轉 JPG把最新的格式,轉成什麼都讀得懂的那一個。
- AVIF 轉 PNG當這個 AVIF 的透明度不能丟的時候。
- GIF 轉 PNG脫離 256 色與 1 位元透明度。
- BMP 轉 JPGBMP 把每個畫素原封不動存下來,省下的空間非常可觀。
- SVG 轉 PNG向量變畫素是單行道,所以尺寸要選好。
- 壓縮 JPGMozJPEG,跑在你自己的處理器上。
- 壓縮 PNG真的無損。不是偽裝成無損的減色。
- 壓縮 WebP本來就是高效率格式 —— 再榨一點出來。
- QR Code 產生器靜態編碼。不轉址、不追蹤、不會過期。
- 字數統計中文算得對,而且文字不會離開這一頁。
- PNG 轉 SVG產出可以編輯的真路徑,不是把點陣圖藏進 .svg 檔案裡。
- 我的 IP 位址一頁看完。而且我們一個字都不記錄。