三民區一棟學生套房，房東林小姐一個晚上接到八通投訴電話，內容都很像：「網路時快時慢，一到晚上就特別卡。」她自己在管理室測速，白天量起來明明有五百多兆，晚上再測卻只剩零星幾十兆，連開個網頁都要轉半天。查了老半天才發現，三樓某位房客習慣半夜掛著下載大型遊戲跟連續劇，一個人就把整棟的線路吃掉一大半。林小姐很無奈：「我又不能跑上去管他用網路做什麼。」
這句話其實已經講到重點了——她不需要管住戶用網路做什麼，她需要的是一套會自動把頻寬分得公平的機制。而這件事，遠比「幫每戶設個上限」要細膩得多。這篇我們就從底層機制講起，把分租套房的頻寬工程說清楚，讓做工程的、做採購的看了都能點頭。
先搞懂：為什麼「先搶先贏」對安靜的住戶特別不公平
一條家用寬頻分給十幾戶，本質上是一份共享資源。在沒有任何規則的預設狀態下，網路就是「先搶先贏」——但這裡有個很多人不知道的技術細節：搶得凶的人，靠的往往不是下載開得大，而是「同時開很多條連線」。
網路上的傳輸協定（TCP）有個特性，它會自己不斷試探還能塞多少資料進去，一路把可用頻寬吃到滿為止。當十幾戶的流量擠在同一個佇列裡排隊，而路由器又只是老實地「先到先送」（FIFO），那麼誰開的連線多、誰就佔到多。一個掛著下載工具、同時拉幾十條連線的房客，對上一個只開一條連線滑手機的房客，實際分到的頻寬可能是幾十比一。這不是誰道德有問題，而是預設機制本來就會這樣運作。你要對抗的，是機制，不是人。
晚上特別慢的真相，多半不是「頻寬不夠」，而是緩衝膨脹
這裡要先破一個很普遍的誤會。房東直覺會想：晚上大家都在用，所以頻寬不夠，卡是正常的。但實際去量會發現，很多時候吞吐量根本沒滿，延遲卻先爆掉了——這個現象有個專門的名字，叫緩衝膨脹（bufferbloat）。
機制是這樣的：當流量的瓶頸落在對外那條線（WAN）上，路由器一時送不出去的封包，會先被塞進一個很大的緩衝區排隊。問題是這個緩衝區往往被設計得太大，單單一個大檔下載就能把它塞滿。這時候你要開視訊、傳 LINE、開網頁，你的封包只能乖乖排在那一長串下載封包後面，一等就是好幾十甚至上百毫秒。體感就是——明明測速數字不難看，可是點什麼都「頓一下」。
有多嚴重？根據主動佇列管理的公開實測，在爆量的情境下，把佇列延遲從幾十毫秒壓到一毫秒以下是做得到的。換句話說，林小姐那棟樓晚上的卡，很可能不是再加大頻寬就能解決的，而是要處理「封包在緩衝區排太久」這件事。這也是為什麼單純升級到更大的月租方案，常常錢花了卻沒感覺——因為病根不在頻寬總量，在佇列。
兩種限速手段的取捨：整形 vs 監管
知道病根之後，再來談工具。替住戶限速，技術上有兩條路，取捨完全不同。
流量整形（traffic shaping）
整形的做法，是把超量的封包先排隊、延後送出，把流量平滑地控制在設定速率內。它背後通常用一個叫「權杖桶（token bucket）」的計量方式，除了設定速率，還能允許短暫的突發流量，對一般上網體驗比較友善。它不會粗暴地切斷任何連線，只是讓超量的流量稍微等一下再走。
限速監管（policing / rate limiting）
監管的做法比較硬：超過上限的封包直接丟棄，不排隊、不緩衝。它適合用在流量進來的那一端做硬性把關。但用在住戶身上要很小心——傳輸協定看到封包被丟，會以為塞車了而重傳，如果丟得太粗暴，反而會引發一連串重傳，有效傳輸量（goodput）不升反降，住戶的體感就是「明明有給我限速額度，怎麼還是這麼不順」。
工程上的判準其實很清楚：對住戶做每戶分配，主力應該用整形這一類會排隊、會緩衝的做法；監管式的硬丟包，留給少數需要硬性上限、或要壓制濫用行為的場合。兩者不是誰取代誰，而是各自用在對的位置。
比「死限速」聰明：保證下限，加上可借用的上限
很多房東一聽到限速，想到的是給每戶一個固定的天花板，比如十戶就一戶砍到五十兆封頂。這種「死限速」有個很浪費的副作用：半夜只剩一兩戶在用的時候，其他人的額度全空著，正在用的人卻還是卡在自己那五十兆的上限，動彈不得。一條五百兆的線，結果永遠只發揮得出一小部分。
比較成熟的做法，是採用階層式的頻寬管理（業界常見的是一種叫做 HTB、階層式權杖桶的機制），同時替每戶設定兩個數字：
- 保證速率（rate）：不管多擠，這一戶都拿得到的最低保障。這是公平的底線。
- 可借用上限（ceil）：當整條線還有餘裕時，這一戶可以往上衝到的天花板。
兩個數字一搭配，行為就變聰明了：大家都在用的尖峰時段，每戶至少守得住自己的保證速率，誰也擠不掉誰；而一旦有幾戶沒在用，空出來的頻寬會自動借給正在用的人。這樣既守住了公平，又不會白白浪費半夜的閒置頻寬。這才是分租套房該追求的狀態——公平，但不浪費。
真正解決「隔壁一下載我就卡」的，是公平佇列
限速解決的是「總量怎麼分」，但要解決前面講的緩衝膨脹，要讓安靜的住戶在別人狂下載時也不卡，得靠公平佇列與主動佇列管理（AQM）。這幾年開源社群把這一塊做得相當成熟，底下幾個名字，值得你的施工廠商聽得懂。
受控延遲（CoDel）
這是一套被正式寫成公開標準（RFC 8289）的演算法。它的聰明之處在於，不去計較佇列「有多長」，而是去量每個封包「在佇列裡待了多久」（停留時間）。它設一個目標值——大約五毫秒——只要偵測到有一段持續塞住的排隊超過這個目標，就開始適度丟包、送出「該慢一點了」的訊號，一旦延遲降回目標以下就立刻收手。整套幾乎不需要手動調參，設計上就是為了把延遲穩穩壓在低點。
公平佇列版的 CoDel（FQ-CoDel）
再往前一步（對應公開標準 RFC 8290），它會把同時在跑的各條流量自動分進不同佇列，再輪流公平地送出。效果非常直接：一條在跑的大檔下載，被關進屬於它自己的佇列，塞不到你開視訊、滑手機那條互動流量。這就是「隔壁在下載，你卻不卡」背後的技術底氣。
更全面的整合方案（CAKE）
一個最容易被忽略的關鍵：上傳才是隱形殺手
絕大多數房東，甚至不少廠商，都只盯著下載限速，卻放掉了上傳，這是個很大的漏洞。台灣不少家用線路是上下行不對稱的，上傳頻寬遠比下載小。當某一戶在大量上傳（雲端備份、開直播、P2P 分享），那條窄窄的上傳很容易被塞爆；而上傳一塞，連帶把「回覆訊號（ACK）」也卡住，結果連下載都跟著垮掉。你會看到很反直覺的畫面：明明沒人在下載，大家卻一起變慢——罪魁禍首其實是某戶的上傳。所以真正認真做頻寬管理，上行、下行都得整形，某些情況下，上傳甚至比下載更該優先處理。
為什麼整形一定要抓在線路速度的八到九成
這是實務上最關鍵、也最常被做錯的一個設定。很多人會想：線路有五百兆，那整形就設五百兆，把資源用好用滿。但這樣做，整套佇列管理會直接失效。
房型、牆材、鄰頻干擾、回程與同時上線人數都會改變結果，沒有通用的涵蓋率或滿意度增幅。完工時應在尖峰時段逐房量 RSSI、重傳、延遲與實際吞吐，再依問題點調整 AP、頻道與有線回程。
房東最容易踩的幾個坑
- 只限下載、不限上傳：上傳一塞，回覆訊號被卡，下載照樣垮。上下行一定要一起管。
- 整形設到滿（100%）：瓶頸被推到電信端，你的佇列管理全數失效，等於白設。
- 拿硬丟包當主力：對住戶用粗暴的監管式丟包，容易引發重傳，體感反而更差。
- 只綁單一 IP 來限速：一戶常有手機、筆電、電視好幾台裝置，又多半用浮動 IP；應該以「每戶」為單位（用子網或每主機聚合）來分，而不是綁死一個 IP。
- 在區網交換器上做限速：樓內的 Gigabit 交換器幾乎不會是瓶頸，限速要做在對外的閘道那一關，位置做錯等於沒做。
- 迷信一個萬用數字：每戶該保證多少、上限開多寬、要不要分時段，得看線路實速、戶數與住戶屬性，學生宿舍跟商務套房的用法差很多。
那到底該怎麼抓？一個務實的起手式
沒有萬用配方，但有一套可依循的邏輯。第一步，先做一次「負載下的延遲」檢測——分別量閒置時跟滿載下載時的延遲差多少，這就能照出緩衝膨脹的嚴重程度，同時也是驗收有沒有改善最直接的指標。第二步，拿實測（不是方案標示）的真實速率乘以零點八五到零點九，當作整形器的總量。第三步，把這個總量拆成每戶的保證速率（守住公平），上限（ceil）則放寬到可以借用閒置頻寬（避免浪費），再依物件屬性決定要不要加上分時段規則。最後，套上公平佇列與主動佇列管理，把「隔壁一下載你就卡」這件事從根本上處理掉。
講到這裡就會懂，林小姐那八通投訴電話，其實不是要她去加大頻寬，也不是要她去偷看住戶在幹嘛，而是她缺了一套把頻寬分得又公平又不浪費的工程設定。廷皓科技在高雄替分租套房、學生宿舍與商辦規劃過各種頻寬分配方案，從線路健檢、每戶保證頻寬、公平佇列到遠端調校，都能用月約代管的方式幫你長期顧著。想讓您的套房做到「每戶都順、沒人吵架」，歡迎找我們做一次完整的頻寬規劃。
