每台路由器裡藏著的兩份工作
早在路由那一級，你就見過一個不起眼的區分，而它原來正是這一級的整個地基：轉送與繞送（routing）的差別。轉送是肌肉活——一個封包抵達，盒子在表裡查出它的目的地，再把它推往正確的連接埠，每秒做上數十億次。繞送是大腦活——一開始就跑像 OSPF 那樣的演算法，算出表裡那些條目「應該」長什麼樣。兩份真正不同的工作，有著非常不同的速度與非常不同的需求。
這兩份工作甚至有名字。那層接觸每一個封包、又快又粗的肌肉，叫做資料平面（有時也叫轉送平面）。那層較慢、較聰明、決定規則的，叫做控制平面。在傳統路由器裡，兩個平面都住在同一個封閉的盒子內：控制平面是跑在路由器自己那顆小 CPU 上的軟體，它就近設定旁邊的資料平面晶片。每個盒子都是一座孤島——自己思考、和鄰居交談、再對「東西該往哪送」得出自己的結論。
為什麼每個盒子一顆大腦是個問題
傳統設計——每個盒子都是自治的孤島——出奇地強韌，這正是它撐起網際網路數十年的原因。但它有三個惱人的弱點。其一，沒有任何單一盒子能看見整張網路；每一個都從鄰居那裡拼湊出一幅局部的畫面，像一座沒有人有地圖的小鎮，大家都靠問下一個街角的人來導航。其二，每家廠商的盒子都是封閉的設備：控制平面軟體是燒進去的，你只能一台命令列盒子接著一台地去設定。其三，要改變網路的行為，就得手動登入上百個盒子、再祈禱它們全都意見一致。
現在想像相反的情況。假設有一個程式握有整張網路的即時地圖——每一台交換器、每一條鏈路、每一份負載——並能以這個上帝視角算出轉送規則，再直接把它們推進盒子裡。它能在一條鏈路斷掉時立刻繞道，因為它一眼就同時看見各處的故障。它能靠改一個程式、而非碰一百個盒子，來落實一條全新的政策。而且它不在乎那些盒子是誰家的硬體，只要它們會講一種共通的語言。這個握有網路全域視野的單一程式，就是軟體定義網路（SDN）的核心。
SDN 架構：控制器、交換器，與兩道門
SDN 把網路重組成三層，像三明治那樣疊起來。最底下坐著資料平面：一隊又笨又快、根本不帶繞送大腦的交換器——它們只是拿進來的封包去比對一張規則表，然後動作。最上面坐著大腦，也就是SDN 控制器：一個邏輯上中央的程式（實務上是一個容錯的叢集），握有網路全域地圖、算出每一條規則。控制器向下對交換器說話，向上對那些告訴它「網路該做什麼」的應用程式說話。這兩段對話，各自透過一道定義良好的門進行，這些門叫做介面。
+---------------------------------------+
| Network apps: routing, firewall, |
| load balancer, traffic engineering | (the "what")
+---------------------------------------+
^ northbound API
| (e.g. REST)
+---------------------------------------+
| SDN CONTROLLER |
| network-wide map + brain (control) |
+---------------------------------------+
| southbound API
v (e.g. OpenFlow)
+--------+ +--------+ +--------+ +--------+
| switch | | switch | | switch | | switch | (the "muscle":
+--------+ +--------+ +--------+ +--------+ data plane only)朝下、面向交換器的那道門，是南向 API——控制器用來在資料平面裡安裝、讀取、刪除規則的協定。最有名的南向協定是 OpenFlow，緊接著的下一篇指南會把它拆開細講；現在你就把它想成控制器對交換器的遙控器。朝上、面向應用程式的那道門，是北向 API——通常是一個親切的程式介面（常是 REST API），讓一個負載平衡應用或防火牆應用能說出它的願望，卻完全不必懂 OpenFlow、也不必懂任何交換器的晶片。
封包實際上是怎麼被處理的：比對與動作
暫時把控制器拿開，看一個封包打到一台 SDN 交換器上。這台交換器握著一張流表（flow table）：一份有序的規則清單，每一條都是一組比對—動作（match-action）配對。比對的部分說「這條規則管的是哪些封包」——它能一次看好幾個標頭欄位，而不只是經典路由器在乎的那個目的 IP。一條比對可能讀作「任何目的地為 10.0.0.0/8、且是 TCP 連接埠 443、且從第 2 埠進來的封包」。動作的部分說「對符合的封包做什麼」：從第 5 埠轉送出去、丟棄、洪泛、上送給控制器，或改寫某個欄位。
- 一個封包抵達交換器。交換器讀出表所在乎的那些標頭欄位（從哪個輸入埠進來、來源與目的位址、協定與連接埠號等等）。
- 交換器由上而下掃過它的流表，找出第一條比對模式吻合這個封包的規則——這正是你在繞送那裡見過的最長前綴比對精神，只是一次推廣到了許多欄位。
- 它執行那條規則的動作：從選定的連接埠轉送出去、丟棄、洪泛、改寫某個標頭欄位，或把封包上送（punt）給控制器。
- 如果「沒有」任何規則吻合——一種控制器從沒料到的全新資料流——交換器的預設通常是把封包送給控制器，問一句：「這個我該怎麼辦？」
- 控制器以它的全網視野做出決定，再透過南向 API 把一條新的流表規則裝下去。從那一刻起，那條資料流之後的每一個封包，都由交換器獨力以全速處理，不再需要往返控制器。
最後這一點，是整個設計優雅的核心，值得牢牢記住。又慢又聰明的控制器，只在一條新資料流的第一個封包時被諮詢；一旦它寫好規則，又笨又快的交換器就自己處理剩下的。也要留意這種比對比起經典路由器一般化了多少。傳統路由器純粹依目的 IP 轉送。一台比對—動作交換器卻能同時依來源、依連接埠號、依輸入埠來判斷——於是「同一份硬體」可以當路由器、當交換器、當防火牆、當負載平衡器，僅僅取決於控制器寫了什麼規則。功能如今成了軟體。
從盒子到積木：VNF、P4、自動化與白牌交換器
一旦你接受「網路功能不過是軟體」，一連串想法便接踵而至，這一級剩下的篇幅就在拆解它們。最直接的是網路功能虛擬化（NFV）：如果防火牆是軟體，那又何必買一台專用的防火牆設備？把它當作一個虛擬網路功能來跑——一般伺服器上、虛擬機或容器裡的一支普通程式。於是「讓一條資料流先穿過防火牆、再穿過負載平衡器、再穿過入侵偵測器」就只是服務鏈接：控制器把流量串過一連串軟體功能，完全不必重新接線。第三篇指南專講這個。
OpenFlow 讓控制器能設定一台交換器的規則，但交換器的本事——它能比對哪些標頭欄位、能採取哪些動作——仍由晶片的設計者寫死。下一次躍進是可程式化資料平面：一台連「封包處理行為」本身都能由你自己定義的交換器，用的是一種叫 P4 的語言。用 P4 你描述一種自訂的標頭格式、以及處理管線該如何剖析它、對它動作；於是同一份硬體能講一種在晶片做出來時還不存在的協定。第四篇指南會探討這個；現在你只要記住這條軌跡——先是把規則變得可程式化，如今連跑規則的那台機器也變得可程式化。
還有兩條線把這幅圖補完。網路自動化把整張網路當成程式碼：不再對著盒子敲命令，而是在一個檔案裡宣告你想要的組態（用 NETCONF 當協定、用 YANG 當描述「哪些可設定」的資料模型），再由工具可重現地把它推送出去——網路向軟體工程借用了基礎設施即程式碼的習慣，這是第五篇指南的主題。而撐起這一切的，是白牌交換器：便宜、廠商中立、出廠時不附綁定控制軟體的硬體，正因為在 SDN 的世界裡大腦住在控制器、而不在盒子裡。智慧一旦搬出去，硬體就變成了大宗商品。
取捨：強大，與一個全新的擔心點
把大腦集中起來，替你買到兩樣大東西。第一是彈性：行為就是軟體，所以一條新政策或新繞送方案是改一段程式，而不是把整隊硬體扛去升級。第二是可見性：因為控制器本就握著網路全域地圖，它便是「同時看見並推理一切」的天然所在——這正是為什麼 SDN 不是從公開的網際網路、而是從資料中心內部起步的：那裡每一台交換器都由同一個業者擁有，他們正想要這種上帝視角來把網路榨到極致。
但天下沒有白吃的午餐，誠實要求我們把代價講明。把大腦搬到一個地方，你就製造了一個新的、出大錯的所在。如果控制器掛了，交換器還能繼續轉送嗎？（能，照它們手上已有的規則——但它們無法因應任何新狀況。）如果控制器很慢，每一條新資料流的第一個封包都要等一趟往返它的來回，這可能很傷。如果攻擊者攻進了控制器，他就攻進了一切。所以這台集中式控制器，同時是 SDN 最大的優點、也是它最常被討論的弱點——一個潛在的瓶頸與單點故障。實務上那「單一」控制器其實是個複製、分散的叢集，正是為了鈍化這個問題，而這本身就是一道很硬的工程難題。