無線上的 TCP（TCP over wireless）

TCP 是撐起網頁與大多數 app 的主力協定，它誕生於有線連結的年代——並帶著一個深層假設，這個假設在空中會悄悄出錯。那個假設是：如果一個封包不見了，網路一定是壅塞了，所以有禮貌的回應就是放慢。在電線上這通常是對的，因為電線很少弄壞位元；遺失幾乎總是代表某個路由器的佇列滿溢了。但在無線上，這個邏輯就崩解了。

回想經典 TCP 如何運作：它把送出速率一路往上加，直到看見遺失，把那次遺失當成壅塞訊號，急遽砍掉送出速率，然後再慢慢爬回來（這就是它的壅塞控制）。問題在於，無線連結遺失封包的原因和壅塞毫無關係——無線電干擾、訊號衰落、多路徑錯誤、或你在細胞間移動時交遞造成的短暫空檔。TCP 無法把無線電造成的遺失和佇列滿溢造成的遺失分開，於是它偏偏在不該踩煞車時猛踩，讓連結沒被用滿、使用者盯著卡住的畫面，儘管其實還有大把容量。

為什麼重要、又能怎麼辦：光是這一個混淆，就是行動下載感覺遲緩或一頓一頓的主要原因。有好幾種解法，各有取捨。Wi-Fi 與蜂巢式網路上的連結層重送，會悄悄重送遺失的訊框，把大部分無線電錯誤對 TCP 藏起來，讓 TCP 很少看到它們——這是最常見也最有效的做法，雖然它可能增加延遲。較新的壅塞控制演算法如 BBR，會推測真正的瓶頸速率與往返時間，而不是把每次遺失都當成壅塞，在易遺失的連結上表現更好。而像 QUIC 這類承載現代網頁流量的協定，從設計之初就把行動與遺失納入考量。誠實的結論是：TCP 沒有壞，但它「遺失等於壅塞」這個有線年代的假設，是許多無線效能不佳的根源，而良好的行動網路在很大程度上，就是在設法繞過它。