引言
在網絡發展速度如此之快的今天，傳統網絡的架構充滿了危機，主要有這四個問題：
- 傳統網絡部署管理困難。
- 分布式架構瓶頸出現。
- 流量控制難真正實現。
- 設備不可編程。
現在的網絡廠商
- 種類繁多的網絡廠商。
如何對網絡設備進行操作？
- 從圖中可以看到，不同廠商的網絡設備混雜在一起使用。
- 但是不同廠商的網絡設備要通過不同的方式進行部署（一般是通過Web和命令行），這就使得，對目前這種魚龍混雜的網絡進行統一配置，是一件很困難的事情。
- 但是它們的底層協議相同，互操作沒有問題。
如何管理這么多網絡設備？
- 目前我們通過搭建在服務器上的網管軟件來管理。
- 比如比如學校利用的就是網管軟件，架設在服務器中；網管軟件生成網絡的拓撲圖，知道哪一台PC在哪里，出現故障能夠進行報警。
- 主流的SNMP（網絡管理協議），更多側重於監控，而不是分配和部署。也就是說，如果網絡出出現故障，通過網管報警，還是需要人為修理。
問題一：傳統網絡布署和管理非常麻煩
網絡設備間如何協同工作？
- 網絡設備之間，大部分都是采用 路由交換協議等 網絡協議 來進行信息的交互。
- 協議的邏輯基礎：
- 鄰居建立
- 信息共享
- 選擇路徑
- 大部分網絡采用的是典型的分布式網絡架構：設備和設備之間相互交流路由信息，然后根據這些信息建立拓撲信息庫，按照一些選路的算法計算路徑。
- 說白了就是接力棒式的流程，你交給我，我交給他。
- 每個設備都有獨立的CPU，獨立運算。
- 協議是 網絡設備的語言，相當於人類溝通的語言。
如果網絡發生動盪，設備如何交互？
- 網絡設備以接力棒的形式不斷告訴下一跳鄰居設備，然后將故障的鏈路刪除。
- 但是可能會有多余的重復的信息。
當流量暴增或拓撲暴增時...
- 現在的雲計算，大數據等互聯技術的發展，導致網絡中的流量越來越多，幾乎以指數增長的形式上升，這使得底層網絡設備的數量不斷增加，壓力越來越大，路由收斂的時間越來越長，效率越來越低。
- 數據中心網（互聯網公司）、電信網（運營商），需要變革的意願最強。
問題二：分布式架構瓶頸
網絡帶寬分配如何解決？
- 目前的負載均衡，並不是真正的負載均衡！下面的案例很大可能出現！
前往同一個目的地的帶寬相同的路徑A和B，有可能 A 95%的帶寬都用於承擔數據了，壓力非常大，而 路徑B 的帶寬則只有20%利用率。
- 這張拓撲時數據中心里是非常容易發生的一件事情，當非常多的數據進來的時候，並沒有完全的實現路徑的負載均衡，這就很可能出現這種很危險的情況：某一個設備，在某一個瞬間壓力過大崩潰了。
- 因此，當今網絡最大的一個問題之一，就是流量的可視化。現在的流量控制設備，並不能做到對全網，全鏈路進行流量控制，進行合理的負載均衡。
有人可能會問，為什么不使得所有的 交換機和流量控制網絡設備，實時監控和共享鏈路狀態信息：是否擁塞，這樣的話就能構建成一幅實時的流量圖，根據這個流量圖來進行流量控制？
雖然這個想法很不錯，但是很遺憾，目前並沒有一項技術能夠支持構造實時的流量圖：大部分流量控制設備都是獨立進行控制的。
流量可視化難！
- 常規的網管軟件，只能對故障進行監視，無法實現全網全局的鏈路狀態檢測。
- 常規的流量控制軟件，只能實現區域化的流量控制，以及區域化的流量可視化。
- 理想化模型如下
問題三：流量控制是棘手難題！
能否自定義設備的轉發策略？
- 傳統的網絡設備，工作方式是固定的：不修改目的IP地址和源IP地址，交換機根據MAC地址表進行轉發，路由器根據路由表轉發(不修改目的IP地址，不修改源IP地址，只修改MAC地址)。
- 根據業務需求，也就是客戶需求，對轉發設備的策略進行自定義，這和傳統固定的轉發策略大為不同：傳統是廠商決定，用戶很難對固定的策略做出改變；而SDN允許用戶通過編程的方式，來實現自定義轉發策略，達到一些特定的目的。
能否將軟件運行在設備上？
- 我們買來設備的時候，里面的協議已經被訂好。我們不能通過安裝軟件的方式來增加設備的功能。就算能的話我們也要通過重裝OS等復雜的手段來實現。
問題四：無法按需，不可編程
