基於 TCP 的 HLS 為何還會延遲或卡頓？

雖然 HLS（HTTP Live Streaming）是基於 TCP 傳輸協定，能保證資料不丟失且順序正確，但它天生具有「緩慢啟動、嚴格順序交付」的特性，會導致：啟播延遲（Startup Delay）、再傳延遲（Retransmission Delay）、突發性網路問題容易影響流暢性。

RTT（Round Trip Time）過高

RTT 是封包從客戶端傳送到伺服器再回來的總耗時。

  • RTT 高 → Initial connection 慢：尤其 HTTPS handshake 或 CDN 的 chunk 請求階段會很明顯。
  • 多個小請求的串流格式（如 HLS）會被放大影響：每一個 chunk 的請求都需經過 RTT，總延遲會堆疊。
  • 特別在行動網路、跨國連線或無線環境中更加明顯。

RTT 的 Jitter 抖動太大

Jitter 是 RTT 不穩定的程度，代表封包延遲的波動。

  • Jitter 大會讓播放器難以預估緩衝策略：有時一秒就到、有時五秒才到，容易導致 buffer underrun。
  • 突發性卡頓：使用者會感受到畫面忽快忽慢、甚至直接暫停。

什麼情況可能導致 RTT Jitter 抖動太大?

不同的 Wi-Fi 頻段互相干擾（例如 Wi-Fi 2.4G）、使用者用了 VPN、使用者家中的路由分享器有問題

封包遺失

  • TCP 會自動重傳遺失的封包，但這個過程需要時間（可能是 1~2 個 RTT），若太頻繁就會出現卡頓。
  • HLS 每個 segment 是一段完整影片資料，只要裡面一個封包遺失，整個 segment 都得延遲等待重傳。
  • 常見原因：Wi-Fi 資訊干擾、基地台負載過高、用戶端硬體問題。

ISP 節點擁塞與路由問題

  • ISP 節點擁塞：特定時間流量爆炸，例如晚上高峰時段（家戶上網尖峰）或國際頻寬塞車。
  • 路由不穩：有時資料會繞遠路、經過不穩定節點（如跨國或轉接多層）導致延遲大增。
  • 解法：使用 CDN（Content Delivery Network）就近供應內容，可大幅改善延遲。

串流產業中常被提及的，就是 Netflix 透過自建 CDN，減少來自 ISP 網路節點的延遲與擁塞。像是在美西、日本或泰國，Netflix 會引導使用者的請求向就近的 Open Connect CDN 節點請求影片內容，以避開跨區傳輸與 ISP 節點壅塞問題。

QoS 限速

ISP 對某些串流服務（例如 Netflix、YouTube）會降速：這種「合理流量管理」會對串流造成很大影響。

例如，行動網路方案有時會偷偷限制影音類型：即便總速率夠快，但針對影音的封包請求會被限速。

可以切換不同網路（例如從家中 WiFi 切成手機網路）比較網路。

即便使用光世代，仍有可能遇到 QoS 限速！

中華電信有分幾種光纖牽線，例如 FTTB (Fiber To The Building 光纖到樓)、FTTH (Fiber To The Home, 光纖到家)。如果是採用 FTTB，那可能會是拉到社區弱電間機房，接下來中華電信會用 Ethernet 網路線（通常是 Cat5e 或 Cat6），從機房一路拉進大樓家裡牆壁的網路孔，然後使用者從牆壁網路孔插上自己的路由器，就可以上網了。

在這種狀況下，是有可能發生QoS 限速的！即便每戶帳單都是中華電信光世代且各用不同方案，但是最後出去都是用同個光纖。

QoS 限速是根據「流量的目的地」還是「來源」來控制的？這取決於電信設備商的 ISP 策略，有可能是網路請求的「目的地導向」封包分類為主。

前陣子看了幾位技術社群領袖推薦小賴老師《給網站工程師的網路課》心得，於是也心癢癢跑去報名，一個下午複習了網路通訊概論。

在複習過程中記下不少關鍵字和筆記，而後有了這篇文章（注意：此篇筆記有八成是我自己寫，剩的兩成有使用 AI 潤飾）