邊緣、萬物，與時效性網路

為什麼要把電腦搬得更近？

本階第一篇重新發明了傳輸層；第二篇把線路搬上了天空。這一篇要點出三條前沿共有的一件事：它們都把網路拉回實體世界，在那裡毫秒與焦耳是實實在在的東西，而非抽象概念。先從基礎階一個頑固的事實說起。頻寬、吞吐量與延遲是三個不同的量，而且頻寬再大也砍不掉延遲——你贏不過光速。一趟往返 3000 公里外雲端資料中心的路程，光是純粹的傳播，單程至少就要約 20 毫秒，這還沒算上排隊或處理。對影片串流來說那是看不見的；但對自駕車的煞車決定、或外科醫師的觸覺手套而言，那 40 毫秒無可避免的來回延遲是一道沒有任何升級能修好的死結。

邊緣運算是誠實的回應：如果你沒辦法讓光更快，那就讓距離更短。與其把每個請求都送往遙遠的雲端，你在網路的邊緣放置一小池一小池的運算與儲存——放在電信業者的本地機房、放在行動基地台，甚至放在大樓裡——讓工作在一兩跳之外就完成。這個想法你已經認識一半了。內容傳遞網路是一連串把內容快取在使用者附近的本地倉庫；邊緣運算正是同一個直覺，從「儲存檔案」延伸到「執行程式碼」。CDN 用「就近」回答了「資料放哪裡？」；邊緣則用同樣的方式回答「程式跑在哪裡？」。

規模達數十億的物聯網

活在邊緣的東西，有很大一部分是物聯網：不是筆電與手機，而是一大群微型裝置——一個土壤濕度感測器、一把門鎖、一支工廠振動探針、一台停車收費表。它的決定性特徵是「受限」與「數量」。每個裝置可能只有幾 KB 的記憶體，靠一顆得撐好幾年的鈕扣電池運作，並透過又慢又會掉包的無線電連線。而且它們有數十億個。兩個後果直接從前面的階別推導出來。第一，數十億個永遠開機的裝置，正是最終讓 IPv6 及其 2^128 個位址站得住腳的壓力，因為 IPv4 的 2^32 個位址老早就用光了，而 NAT 從來就只是位址耗盡的權宜之計，並不是供數兆個感測器棲身的家。第二，你為瀏覽器學的那些協定，在這裡太重了。

回想應用階學過的 HTTP：冗長的文字標頭、請求—回覆的形狀，而且每次交換都得發一個全新的請求。對一個每分鐘只回報一個數字的電池感測器來說，那很浪費——標頭可能比資料本身還大，而維持一條連線不斷會把電池耗光。於是物聯網改用輕如鴻毛的協定。最常見的是 MQTT，它的關鍵手法是捨棄請求—回覆，改用發布—訂閱模式。裝置之間不直接互相呼叫；感測器把訊息發布到中央代理器上一個具名的主題，任何訂閱了那個主題的用戶端就會收到一份副本。感測器永遠不需要知道誰在聽，聽的一方也永遠不需要知道是哪個感測器會開口。那個代理器是一間依「主旨欄」而非依「收件人」來分信的郵局。

MQTT publish/subscribe through a broker
--------------------------------------------------
  sensor-A  --publish-->  topic: home/kitchen/temp = 21.4
  sensor-B  --publish-->  topic: home/kitchen/co2  = 540
                              |
                          [ BROKER ]   keeps last value, fans out copies
                              |
  phone app   --subscribe--> home/kitchen/#   (gets temp AND co2)
  logger      --subscribe--> home/+/temp       (gets every room's temp)

  + tiny binary header (~2 bytes), runs over TCP, optional TLS
  + 3 delivery levels: at-most-once / at-least-once / exactly-once

MQTT 透過代理器與主題名稱，把發送方與接收方解耦。訂閱者要的是一組主題的樣式，而不是某一台特定的裝置。

還有一個值得認識的手足：CoAP，受限應用協定。MQTT 在 TCP 之上模仿一條訊息匯流排，CoAP 則模仿 HTTP——它保留了你熟悉的 GET、PUT、POST 動詞與類似 URL 的位址——但它跑在 UDP 之上，用一個精簡的二進位標頭，好塞進最小的裝置裡。這正是你先前遇過的那種誠實設計抉擇的完美例子：UDP 不是壞掉的 TCP。CoAP 刻意放棄 TCP 的交握與可靠位元組串流，因為對一個只送一筆短讀數的感測器來說，建立連線的成本比資料本身還貴；CoAP 再把它真正需要的那一點點可靠性自己加回來。不同的工作、不同的傳輸層——這正是端到端原則的實際運作。

當「通常很快」還不夠好

現在把邊緣與萬物接到工廠地板、電網、或一輛車的內部線路上，一個普通網際網路從來就不是為了滿足的新需求就出現了。你研究過的網際網路是一種盡力而為的服務：它很努力地想快快送達每個封包，卻不對「究竟在何時」做任何承諾。當流量突增時，交換器會把訊框留在佇列裡，所以一個平常 50 微秒就穿過的封包，在突增期間可能要花 5 毫秒。對載入網頁來說，那種變動——抖動——無傷大雅。但對一支控制迴路必須每毫秒收到一道命令的機械手臂而言，單單一個遲到的封包不是「慢」；那是一個可能讓手臂崩潰的故障。問題不在平均延遲，而在最壞情況。

時效性網路，簡稱 TSN，是對普通乙太網路的一組擴充，它為真正需要的流量把盡力而為變成有上限的延遲——一個有保證的最壞情況——同時仍在同一條纜線上承載其他一切。它的招牌手法是「時間感知整形器」：每一台交換器與裝置共享一個同步的時鐘（精準到次微秒等級的一致），而網路依一個反覆循環、由許多微小時槽組成的排程運作，就像路口的紅綠燈。在保留給機械手臂那條串流的時槽裡，那些封包享有一條暢通的路、其他什麼都不准進入；普通的盡力而為流量則等它的輪次。因為時槽是事先保留的，那個關鍵封包永遠不會卡在別人某筆大量傳輸的佇列後頭，而它的抵達時間是可以證明的，而不只是「很可能」。

三條前沿，一個形狀

退一步看，這三條線索就編在了一起。邊緣運算把運算搬到資料附近，好讓那個期限在物理上搆得到。物聯網是產生那些資料、用 MQTT 與 CoAP 這類輕量協定交談的那一大群受限裝置——因為它們負擔不起笨重的網頁堆疊。時效性網路則是當「通常很快」會構成失敗時，負責承載那些最嚴苛串流的東西。把它們擺到工廠地板上，畫面就出來了：感測器透過 MQTT 發布到一台跑在邊緣的代理器，一條控制迴路在本地透過一條受 TSN 約束的鏈路閉合，而只有摘要會往上傳到遙遠的雲端。

一支振動感測器醒來、讀一個值，透過一則微小的 MQTT 訊息把它發布到本地網路上的一台代理器——電池幾乎沒被動到。
一台訂閱了該主題的邊緣伺服器就地執行分析，於是「危險讀數」的警報在一毫秒內就判定出來，而不是等一趟往返雲端之後。
如果那個警報必須讓一台機器停下來，停機命令會透過一條帶有保留時槽的 TSN 串流傳送，於是即使纜線正忙著別的流量，它的抵達期限仍有保證。
唯有在那之後，一份精簡的摘要才透過普通盡力而為的網際網路上傳到中央雲端，供儀表板、歷史紀錄與重新訓練模型之用。

要誠實面對代價，因為它們是每項好處的另一面。邊緣意味著要保護、更新並實體防護許多個小站點，而不是一座固若金湯的資料中心——防火牆不是防毒軟體，一千台邊緣機器就是一千個要打補丁的東西。物聯網意味著數十億台以「安全性出了名地不足」著稱的廉價裝置；別忘了一張有效的憑證證明的是身分、不是誠信，而許多裝置出廠時根本沒有任何真正的安全防護。而這些永遠開機的大群裝置都靠電力運轉，這正是為什麼網路永續性——所有這些設備的能源與碳成本——已從事後才想到的小事，變成一項設計上的約束。這條前沿不只是更快、更近；它也是更多必須做對的事。