中介盒的問題：一整櫃只會一招的盒子
本級的前兩篇，給了我們圖像的一半：軟體定義網路把作決定的「大腦」從交換器裡抽出來，集中到一個可程式化的控制器裡，再由它透過比對—動作表去編寫那些笨笨的轉送盒子。但是，把一個封包從 A 送到 B，並不是真實網路對流量所做的唯一一件事。一路上，封包會被檢視、過濾、計數、改寫、加密，並分散到多台伺服器去。執行這些工作的裝置，叫做中介盒（middlebox）——而在歷史上，每一種中介盒都是一台獨立、昂貴、只做一件事的專用設備。
走進一座傳統的資料中心，你會看到一個機架疊滿了這些專用盒子：某家廠商的防火牆、另一家的負載平衡器、一台入侵偵測系統、一台廣域網路加速器、一台 NAT 盒、一台 VPN 閘道。每一台都是它自己的客製硬體、跑著它自己的客製軟體，分開採購，一台接一台地接進路徑裡，要升級就得實體抽換整台機器。對大型網路的研究發現，中介盒的數量往往跟路由器與交換器一樣多——一張隱藏的、昂貴的、僵硬的「第二張網路」，與第一張並存著。
這之所以痛苦，原因跟 SDN 出現之前那些專有交換器之所以痛苦，是同一個。一台為某個尖峰負載而買的盒子，等流量轉移到別處時，沒辦法挪去他處重用。要加容量，得走採購流程、得派人到場，而不是改一行設定。而每一台設備，都是一座有著自己古怪介面的、獨立的管理孤島。SDN 教給我們的那一課——把固定功能的硬體和跑在上面的邏輯綁死，正是網路變僵硬的根源——套在中介盒上，跟套在交換器上一樣鋒利。
NFV 的點子：把功能從盒子上剝下來
關鍵的領悟在這裡。一台防火牆其實不是一塊金屬——它是一支讀取封包標頭、然後決定「放行」或「丟棄」的程式。一台負載平衡器，是一支挑選下一個請求該交給哪台伺服器的程式。這些邏輯，沒有一項真的需要客製晶片；它們只是恰好被焊死在一個機殼上出貨的、普通的軟體罷了。那麼，為什麼不把這「同一份」軟體，跑在一台尋常的商用伺服器上呢？就是那種已經把資料中心塞滿的、便宜的 x86 機器。這就是網路功能虛擬化（NFV）的全部點子。
當你把那支防火牆軟體拿來，當成一個虛擬機或容器跑在一台共享的伺服器上，得到的東西就叫做虛擬網路功能（VNF）。功能完全一樣——它照樣檢視、照樣過濾——但它現在只是一個「工作負載」，跟雲端裡其他任何一支應用程式沒兩樣。這個區別值得記清楚：SDN 把「轉送的控制」虛擬化，決定封包往哪走；NFV 把「網路功能本身」虛擬化，也就是一路上對封包做的那些處理。它們是兄弟，不是同一回事，而你用其中一個時，可以不用另一個。
服務串接：把功能依序串成一列
一旦功能只是軟體，一個新問題就打開了：一個封包該照什麼順序去拜訪它們？流量很少只需要一道處理。一個從公開網際網路進來的請求，也許得先穿過防火牆，再過一台負載平衡器去挑出一台後端，接著或許要過一台監看攻擊的入侵偵測系統，然後才總算抵達應用伺服器。這串有順序的功能序列，就叫做服務串接（service chain，有時稱服務功能鏈）。把它想成一條裝配線：封包是輸送帶上的零件，而每一個 VNF 都是一個工作站，做完它那一份工作，再把零件交下去。
在舊世界裡，那條鏈就是線材本身：你真的是把盒子 A 的輸出埠，接進盒子 B 的輸入埠，順序就凍結在那一條條銅線裡。要重排這條鏈，或者只讓一部分流量過入侵偵測系統，你得派一位技師帶著一條線過去。NFV 加上 SDN，把這件事化解掉了。因為功能是軟體、轉送又可程式化，這條鏈就變成一條由控制器縫合出來的「邏輯路徑」。你把「網頁流量走防火牆，再走負載平衡器」當成設定宣告出來，控制器就會裝上一批流表規則，把符合條件的封包，依序從一個 VNF 引導到下一個。
封包究竟是怎麼被引導著走完整條鏈的？老實說的機制是「封裝」：網路會在原始封包外面，再包一層額外的標頭——可能是像 VXLAN 這樣的網路疊加技術，也可能是一個專門打造的「網路服務標頭」（NSH）——這層標頭夾帶著一點點中介資料，說明這個封包屬於哪一條鏈、已經走到哪一站。每一個 VNF（或餵給它的那台虛擬交換器）讀出那段中介資料，做完自己的工作，把位置往前推一格，再把封包交給下一跳。這條鏈被編碼在外包的那層皮裡，而不是在線材裡。
Old way (cabled middleboxes, order frozen in copper):
Internet --> [Firewall box] --> [Load balancer box] --> [IDS box] --> Servers
NFV + SDN way (VNFs on commodity servers, chain = controller policy):
+--------------------- commodity servers ---------------------+
| [VNF: firewall] [VNF: load balancer] [VNF: IDS] |
+-------------------------------------------------------------+
^ ^ ^
Internet --> virtual switch steers packets station-to-station per chain ID
|__________ controller installs the steering rules ___|
Policy declared once: web-traffic -> firewall -> load-balancer -> IDS -> app跟著一個封包走完整條鏈
讓我們具體化，跟著一個進入資料中心的網頁請求走一遍——這座資料中心的政策是「先防火牆，再負載平衡器，然後送達」。重點是要看清楚 SDN 的「大腦」和 NFV 的「功能」是怎麼合作的——控制器決定路線，VNF 做實際的工作，而比對—動作規則把它們黏在一起。
- 一個要送往該網站的封包抵達邊緣交換器。它的流表規則比對到「新的網頁流量」，而動作不是「送達」，而是「送往防火牆 VNF」——控制器早已預載了這條引導規則，並把封包標上它所屬的那條鏈。
- 防火牆 VNF 拿封包的標頭去比對它的政策。放行嗎？它就把封包標記成「已通過第一站」，再交回給虛擬交換器。（不放行？封包就在這裡被丟掉，後面整條鏈一概不會跑。）
- 交換器讀出更新後的鏈中介資料，看到下一站是第二站，於是把封包轉送到負載平衡器 VNF——同樣是因為某條比對—動作規則這麼說，而不是因為有什麼東西實體上就那樣接著線。
- 負載平衡器 VNF 挑出一台健康的後端伺服器，改寫目的地讓封包朝它而去，並標記第二站完成。這條鏈走完了，於是交換器現在執行那個尋常的動作：把封包送達被選中的那台伺服器。
- 午餐時間流量暴增？俯瞰整張網路的控制器，會在閒置的伺服器上拉起第二個防火牆 VNF、第三個負載平衡器 VNF，並更新引導規則，把負載分散到它們身上——不用接線、不用採購單，幾秒鐘就完成。
請注意，正是SDN 控制器那「綜觀全網」的視野，讓最後一步的彈性成為可能。單一一台交換器，永遠沒辦法決定去拉起一個新的 VNF、再把整條鏈重新平衡，因為它看不到全貌。但那顆集中式的大腦可以。這正是第一篇所稱頌的同一項超能力——全域可見性——只不過現在不是用在路由上，而是用在「處理發生在哪裡」這件事上。
白牌盒子、自動化，與誠實的取捨
NFV 只是一場更大轉變的一角——這場轉變，是把網路當成軟體來對待。同一套哲學給了我們白牌交換器：沒有廠商鎖定的、裸的商用交換硬體，你想裝哪一套網路作業系統就裝哪一套——這在硬體上，等同於去買一台通用 PC，而不是一台被焊死封起來的機器。它也給了我們網路自動化：不再是登入每一台裝置、一行行打指令，而是把你「想要的網路」寫在文字檔裡，讓工具把那個「期望狀態」推送出去——正是那套曾經徹底改變伺服器管理的「基礎設施即程式碼」紀律。NETCONF 這類標準，加上 YANG 模型化語言，給了那些工具一條乾淨、結構化的途徑，去讀寫裝置的設定。
現在來算一筆誠實的帳，因為本級雖然承諾了彈性與可見性，卻也警告過有個「但書」。好處是真實而巨大的：你用幾秒鐘就能部署、串接、伸縮、重排的軟體，換掉了一整櫃凍結的設備；你獲得了一個綜觀全網的視野；你也擺脫了廠商鎖定。但天下沒有白吃的午餐。逐封包的軟體處理，比專用晶片慢，所以對延遲敏感、或超高傳輸量的鏈，可能還是會想要硬體加速。而那個賦予這一切力量的集中式控制器，同時也是一個讓人懸著心的單一焦點——如果它過載、有臭蟲、或被攻陷，就可能一口氣擾亂整張網路，這正是後面幾篇一再繞回來談的那個控制器瓶頸。