網路技術和軟體技術的鴻溝曾經越來越深,如今它們終於要走到一起了,軟體是勝出者!
1.網路技術一直掌握在巨頭手中
教科書上,我們可以知道很多關於TCP/IP的知識,以及協議處理的細節,然而除了可以藉助Linux這種開源的系統內建的協議棧實現之外,你很難深窺網路技術的內幕,一直以來,網路技術被Cisco這樣的企業壟斷著,而且它們的技術是和它們某個型號產品深度關聯的,離開了那款產品,也就離開了那門技術,於是乎,網路技術的培訓也就成了廠商產品的培訓,眾所周知的CCNA/NP,HCSE等認證如果你取得了,並不能說明你是網路技術的達人,因為很多的協議包括特有實現技術都是廠商私人的,比如Cisco HSRP,Cisco CEF...精通網路原理的人和精通裝置操作的人很大程度上成了兩個群體,而且還互相傾軋。網路技術很大程度上成了一中獨門匠藝,掌握了它的人於是也就趾高氣揚,不可一世,直到讓他知道你比他更趾高氣揚和不可一世。
總之,如今的網路大沒有到達標準化的階段,所標準化的,只是網路通訊協定。如今搞網路的,正和中世紀的鐵匠一樣。
2.軟體技術已經開放了很多年
教科書上,我們學到了C++,Java,設計模式,Web等知識,等到我們畢業了,工作中我們進一步的將學到的這些東西強化。30年前,懂編程的人被認為是高科技極客,並不多,那時他們掌握的是一種獨門匠藝,可是如今不一樣了,任何一個人都可以在App Store裡面貢獻一個收費或者免費的軟體,任何一個人,只要你肯花半天的時間來瞭解相關流程,都可以為Linux原始碼寫一行注釋,如今你想寫一個串口程式,你面對的東西已經不再是串口的電氣特性,而是一整套的API或者庫,就像組裝傢具一樣,螺母套螺絲,參照組裝說明文當,板材擺在正確的位置,就成了。
總之,軟體技術標準已經足夠開放,API的設計有一套成型的大家都公認的標準,只要參照標準行事,你就是軟體達人,如今的軟體技術人員(開發,測試...),正如現在的社會化流水線上的工人一樣。
3.網路技術和軟體技術
網路技術和軟體技術都是IT技術,可它們之間確實存在很大的鴻溝,網路技術很大程度是廠商驅動的,而軟體卻純粹是需求驅動的,當然上述說法這可能有些極端,然而話語不極端化,很難說清問題之所在。
你有一個點子,你可以快速寫出代碼實現它,僅僅代碼而已,沒什麼阻止你,如果你只懂一種語言,你可以用一種語言來完成。可是在網路上,你卻要受制於很多東西,你是一個精通Linux網路的人,面對的卻是一台Cisco的裝置,你發出了資料包,卻只能用traceroute來很不完整得跟蹤它...掌握網路技術的代價實在是太大了,縱使再好的特性,只要廠商不跟進,你自己很難去類比,去實現,你能做的,估計只能是用Linux來湊合了。
4.虛擬化和雲對網路提出的新要求
虛擬化技術為網路提出了新的需求,可是老牌廠商們還是遵循老路,採用基於網路層級的封裝技術來解決,於是出現了很多新詞,比如VN-TAG,VPLS,OTV,VXLAN,甚至標準化協會也提出了諸如LISP等新技術,雖然這些新技術很大程度上解決了大多數的問題,並且其背後的理論也足夠精妙,但是我們都知道,不管是老牌廠商還是標準化協會,它們都是既得利益者,誰也不想顛覆既有的標準,這,可以理解!
可是,封裝技術治標不治本啊,為何出現了如此多的封裝技術,且不多說上面那些新詞,僅拿VPN說事就夠了。之所以出現了這麼多的重封裝技術,並不是說邏輯意義上的遞迴層次劃分會使網路結構更清晰,而是說明這個本來就不安靜的世界上確實出現了很多很多的新需求,試問,30多年前的技術對於這些新的需求能hold住嗎?
5.傳統網路模型的不給力
上述畢,當今的網路已經無法滿足越來越多的新鮮需求,很多方面表現出吃力。
5.1.單點控制,沒有全域視圖
如今的網路技術幾乎都是集中在網路裝置這種硬體實體上,在管理上,第一,出現問題要排錯,不得不牽連幾十號人,一個一個點的登入排查,第二,要更新配置,不得不一個一個點的登入配置,沒有一個統一下發的機制,我不想再誇OpenVPN了...在協議處理上,姑且不談RIP這種向量協議,即是OSPF也需要把鏈路狀態洪泛到全部路由器才能使大家得到一致的視圖;在QoS上問題更嚴重,QoS本來就需要在全域來控制,MTU發現是一種類似QoS的技術,可傳統的網路除了諸如RSVP這種類似MTU發現這種自力更生的協議之外,沒有一種在配置層面的機制可以完成全程的QoS監控和管理,況且,就算有這種自力更生的協議,最終的結果也是被動的,如果一個路由器配置了只能給你1M的頻寬,你甚至都不能說你只需要0.5M就夠了這句話!
5.2.收斂問題多多
STP,RSTP,RIP,OSPF,...一旦發生抖動,或者新加入一台新裝置,大家都要折騰一番,某個環節出現了問題,你甚至都很難快速定位到底是哪裡出了問題。
5.3.擴充性太低
如果需要一台路由器提供對下遊雙機熱備裝置的冗餘,我們需要菱形的交叉連線,我們要做的是查閱該路由器的型號以確定是否可以支援新的介面模組,如果不支援那麼就需要更換路由器,如果支援,我們需要提供整個配置列表用來更新路由器的配置,比如配置Teaming等;如果一個網路新加入了一台裝置,可能需要對整個網路進行配置變更(近期我們的產品在實施,我可是深知其害,因此此文不是吹出來的),反之,撤掉一台裝置也同樣!
5.4.門檻太高
前文所述,如今的網路技術人員的技術水平幾乎都是和特定廠商綁定的,因此一般的企業不敢隨意變更裝置,這意味著整個支援小組的變更或者再培訓,而這些都是需要成本的。
6.轉寄和控制的分離
在講三層交換器課程的時候,我們都聽說過ASIC晶片,它其實是一種很傻的晶片,只會按照固定的程式來進行固定的動作,雖然有可程式化的ASIC出現,然而它並沒有持續編程能力,Cisco高端機型上,都存在一板子的ASIC晶片用來快速轉寄資料;和ASIC晶片處在另一個對立面的是CPU(別說GPU啊,它有時還更像ASIC),CPU核心晶片密集複雜,重複板塊並不多,它需要你為它持續注入代碼來為你快速計算出結果,比如路由計算和路由表hash查詢或者資料任意演算法加解密通常都是它來完成的,高端的Cisco機型除了具有ASIC晶片之外,還要具有一板子的高端CPU來提供快速計算能力,於是乎,高端機型的價值自然而然就上去了,掌握了操作它的人自然而然也就得瑟了,正如一個剛拿到駕照的小破孩開著一輛蘭博基尼會嘲笑一個二十年駕齡的老師傅一樣,那個小破孩可能不是富二代,可能只是一個賣車的,然而他要的是一種操控感,我想玩過Cisco 7400ASR的小破孩應該也有這種感覺吧。
CPU和ASIC同居一處的弊端是很多的,把它們拆開就成了SDN的核心,即CPU專門用於軟體的處理,而ASIC專門用於硬體的轉寄,它們之間通過傳統的網路通道來通訊,CPU計算出來的轉寄策略通過網路注入到ASIC晶片,於是,它們中的任何一個都是可以替換的,成本立即節省了,操控人員的職責立即分離了,門檻也降低了!喜歡較真的同學們注意了,我只是用ASIC晶片來舉例,真正的SDN並不一定非要用ASIC。
7.用代碼寫出網路
可程式化晶片最好的選擇是什嗎?是CPU!我們每一個IT人士都會對CPU編程,無論你寫一個編譯器,還是寫一個BASH指令碼,都是對CPU的編程,且看如下:
if [ $inport == 'E2' ] && [ $ip_src == '1.2.3.4' ]; then
set_outport E3;
fi
這是一個很簡單的指令碼片斷,一般人都看得懂,是不是比以下這個更清晰呢:
ip rule add form 1.2.3.4 in E2 tab e3
ip route add 0.0.0.0/0 dev E3 onlink;
以上是一個Linux版本的Policy routing的配置,如果你不懂Linux的iproute2,你就要花大量的時間來學習,另外還有Cisco,H3C等不同的配置方式。哪一種更簡單呢?我們希望的是將上述的BASH指令碼注入到ASIC晶片中,上述的BASH指令碼可以在一台普通的PC機器上編寫和運行,然後通過網路將其結果寫入到遠端的一台定製的交換器或者路由器上,我們可以在一台PC機上寫出無數的這樣的代碼,然後注入到不同的交換器和路由器,這個過程當然可以批量進行,這樣真正實現了控制和轉寄的分離,用代碼定義出了一個複雜的網路,而你根本就需要登入那些路由器和交換器,甚至也不要知道它們是什麼牌子的,就像一個程式員那樣,你只需要在那一台PC機上編程即可!
8.Cache思想-快速路經和慢速路徑
Cache思想無處不在,SDN中,類似LISP,也採用了Cache思想,如果支援SDN的交換器查到了遠端CPU注入的規則,那麼就按照規則指示的行為繼續,這個過程是很快的,如果沒有找到注入的規則,那麼就將資料包發送給遠端CPU,由CPU來處理這個資料包,處理完了之後,CPU會將處理結果以及資料包的匹配項會送給支援SDN的交換器,這個過程不用多說了吧。
9.分層模型不再是廠商實現裝置的依據
行文至此,我們需要插補一些關於網路通訊協定分層模型的東西,一句話,協議分層簡化了廠商為裝置功能的定位,分層模型的核心是裝置設計的簡化,當初互連網絡處於繈褓中之時,簡化實現要素是首要需求,比如三層裝置用來轉寄IP資料報,二層裝置用來轉寄幀,這些分層的裝置部署在不同邏輯層次的物理邊界,比如公司出口要部署一台路由器實現公司內外的網段隔離,部門之間要通過三層交換器這個怪胎來隔離不同的VLAN(三層交換器是打破分層模式裝置的首例!)。可是隨著需求的膨脹和技術的發展,這種設計越來越多的被打破,出現了N層交換器,出現了XXXoYY等封裝技術,劃分如此規則的層次還有意義嗎?
如果能用軟體寫出網路,SDN變成現實,那麼我覺得分層模型真的就不想以前那麼重要了,他留下來的唯一作用就是用來解析資料包用來匹配流表項最終確定如何來轉寄。既然它能完成資料包的匹配,那麼更好的方式也能完成,目前Openflow是基於10元組通配來定義一個流的,既然網路支援虛擬化了,你可以用任何的元組來定義一個流,只是TCP/IP已經流行多年,況且IPv6解決了物聯網(不是互連網)地址的問題,因此TCP/IP被證明還是一個成功的協議棧,因此SDN自然而然也就迎合了它,但是記住,SDN的出現,允許你自訂自己的網路通訊協定(此處沒有棧這個字,預設它不是分層的)。