同一個 Wi-Fi 下瀏覽器傳檔案有多快:典型速度與預期
在同一條 Wi-Fi 上,決定傳輸耗時的更多是檔案本身,而不是工具:在狀態良好的 5 GHz 線路上,100 MB 的檔案幾秒鐘就能傳完,而 1 MB 的檔案一生大部分時間都花在準備上。這一頁彙整了 Lan-Share、LocalSend、PairDrop 按檔案大小可以預期的速度、真正限制速度的因素,以及一套用校驗值測量自己網路的四步方法。
操作步驟
把兩台裝置放到同一個 Wi-Fi 上
兩端都加入 5 GHz 網路,待在同一個房間,任何一端的 VPN 都關掉。頻段、距離和干擾對數字的影響比任何工具都大,把它們保持不變——兩次測速才有可比性。
產生帶校驗值的測試檔案
建立 1 MB、10 MB、100 MB 三個檔案——任何確定性產生器都行;Lan-Share 開源儲存庫自帶一個(scripts/test-file.mjs)。傳送前記下每個檔案的 SHA-256 校驗值,這樣到達的內容才能逐位元組核對。
配對兩端,每個大小各傳三次
用 8 位數連接碼讓瀏覽器與瀏覽器配對,然後把每個檔案連續傳送三次。碼錶從接收端開始拉取檔案那一刻啟動,到最後一個位元組抵達那一刻停止。三輪能抹平尖峰;取中間那一輪。
校驗位元組,取中位數
先對每個收到的檔案算雜湊、與原件比對,再承認這一輪——悄悄重新編碼或截斷檔案的傳輸是失敗的一輪,不是快的一輪。三款工具都逐位元組原樣傳送檔案,所以正確的一輪和快的一輪是同一輪。
一條健康的 5 GHz 網路上的典型結果(估計值,不是實驗室記錄)
| 檔案大小 | 典型耗時 | 典型速率 |
|---|
| 1 MB | 1–3 s | 主要是建立連線的延遲 |
|---|
| 10 MB | 2–6 s | 10–35 MB/s |
|---|
| 100 MB | 3–10 s | 10–35 MB/s |
|---|
為什麼是一個區間,而不是每個工具一個數
三款工具以同樣的方式走同一條 Wi-Fi:檔案一塊一塊地經本地網路從裝置到裝置,路徑上沒有雲端中轉。在同一網路裡,它們的落點彼此重疊,這就是表格按檔案大小只給一個區間、而不是三個的原因——同一個下午裡工具之間的差異,和不同網路之間的差異相比只是雜訊。
這些區間描述的是健康的家用網路:較新的路由器、5 GHz、兩台裝置在同一個房間、沒有 VPN。換到 2.4 GHz、加上幾堵牆,或者要和三台正在看影片的裝置共享電波,同一個檔案就要花上好幾倍的時間——沒有任何工具能豁免物理定律。
怎麼讀這些數字
1 MB 那一列主要是延遲,不是速度:對這麼小的檔案,配對開銷、建立連線和等最後一個封包占了大頭,把它當地板而不是吞吐值來讀。100 MB 那一列才誠實——到那個體量,傳輸已經進入穩態速率。
速度單位是 MB/s(每秒百萬位元組),不是 Mb/s(每秒百萬位元):拿路由器標稱的百萬位元數除以八再比較。標稱 600 Mb/s 的 Wi-Fi 線路最多承載約 75 MB/s,實際傳輸還遠低於這個數——Wi-Fi 是共享的半雙工介質,每一次重傳都要付出時間。
什麼會拖慢傳輸
最常見的元兇是 2.4 GHz 頻段:吞吐只有 5 GHz 的零頭,還要吸收所有鄰居的干擾。其次是距離——手機放在另一個房間,速率就能掉一半。任何一端開著 VPN,本地流量都要多穿一層隧道;而在公共或辦公網路裡,用戶端隔離能徹底封死裝置間傳輸。
網路之外,傳輸路徑本身也關鍵。Lan-Share 以 256 KB 分塊、8 MB 在途視窗搬檔案,既讓管線保持滿載,又不撐爆瀏覽器記憶體;點對點直連路徑會在連線詳情裡顯示為 Direct。一旦工具退回經伺服器中繼,速度上限就變成那台伺服器的頻寬,不再是你的 Wi-Fi。
為什麼這些是區間,而不是實驗室記錄
這些數字是對典型健康網路的預期,不是測試實驗室裡記下的實測——硬體差異太大,一張表承諾不了更多。真實測量會隨路由器、公寓、手機世代和當天的情況而變。
這正是上面那套四步方法的用途:在你自己的網路上、用你自己的帶校驗值檔案,十分鐘左右就能拿到可信的數字——這裡的區間則告訴你,測出來的值正不正常。
該選哪一個
既然區間彼此重疊,就按省事程度來選:Lan-Share 開瀏覽器就能用,兩端什麼都不裝;LocalSend 需要兩台裝置都裝它的 App,換來自動發現;PairDrop 同樣只在瀏覽器裡跑,配對卻依賴一個公共中繼。各工具的細節在 LocalSend 替代方案和 PairDrop 替代方案比較裡。
想深入了解瀏覽器對瀏覽器這套方法本身——包括完全斷網的離線情形——看「不上網也能傳檔案」指南;兩台電腦的場景看「兩台電腦互傳檔案」指南。
疑難排解
- 傳輸速度只有本頁數值的一小部分
原因 裝置在 2.4 GHz 頻段上,離路由器太遠,或者手機隔著幾堵牆只剩微弱訊號。
解決方法 把兩台裝置挪到路由器的 5 GHz SSID 上,放進同一個房間,再測一次。如果路由器給兩個頻段起了不同名字,明確選 5 GHz 那個,別依賴頻段引導。
- 速度起初很快,傳大檔案中途卻垮下來
原因 網路裡另一台裝置開始了自己的大流量傳輸,或者傳送端手機開始過熱降頻。
解決方法 暫停網路裡的其他下載和串流,把手機從殼裡拿出來、從無線充電器上拿開,再跑一次。如果總是在同一個位置垮掉,試試把路由器 5 GHz 的通道寬度設為 80 MHz。
- 開著 VPN,傳輸慢如牛步或乾脆失敗
原因 VPN 把流量繞經外部伺服器,檔案先離開家裡的網路再折回來;有些 VPN 用戶端乾脆直接封鎖本地子網路流量。
解決方法 本地傳輸時把兩端的 VPN 都關掉。如果規定不允許,看看 VPN 用戶端有沒有「允許本地存取」設定,把它打開。
- 在飯店、辦公室或校園 Wi-Fi 上,兩台裝置互相看不見
原因 這類網路開啟用戶端隔離:已連線的裝置之間無法互相定址,無論用哪家工具,直連都無從談起。
解決方法 開一個手機熱點,讓兩台裝置都加入——熱點是張沒有隔離的私有網路。「手機開熱點傳檔案」指南從頭到尾講的就是這條路。
常見問題
同一個 Wi-Fi 下,瀏覽器傳檔案有多快?
在健康的 5 GHz 網路上,看上面表格裡的區間就行:10 MB 只要幾秒鐘,100 MB 大約 3 到 10 秒,折算下來就是穩定的 10–35 MB/s。經驗法則:拿路由器標稱的百萬位元數除以八,再預期它的一半到三分之二。
為什麼傳輸速度比路由器標稱的低?
標稱值是理想條件下單向無線線路的裸速率。真實傳輸要和確認封包、重傳封包共享空口,要穿過其他裝置的流量,每個分塊還要付協定開銷。訊號一弱 Wi-Fi 就降檔,單憑距離就能把吞吐砍掉一半。
這些工具有誰會壓縮檔案來提速嗎?
沒有。三款工具都逐位元組原樣傳送檔案——途中沒有任何重新編碼,這正是上面那套校驗值方法成立的原因。況且壓縮只在慢線路上才有用:本地 Wi-Fi 網路裡,線路很少會慢到值得靠重新編碼去省時間。
檔案大小會影響傳輸速度嗎?
會,在小檔案那頭。1 MB 的傳輸大部分時間都花在準備上——配對、打開資料通道、等最後一個封包——所以它的等效速度遠比工具的真實吞吐難看。從幾十 MB 往上,速率就穩定下來,檔案大小不再影響結果。
瀏覽器分頁真的能和原生 App 一樣快嗎?
兩者跑在同一條 Wi-Fi 上的同一個 WebRTC 資料通道上,線路並不在乎你用的是哪一個。瀏覽器多了一道記憶體天花板,這正是分塊傳輸加背壓重要的原因;但在家用網路裡,封頂的是 Wi-Fi,不是分頁。在兩者上各跑一遍四步方法,在你自己的硬體上比較。