網路技術與思想漫談

單端連接埠彙總與環路
連接埠聚和旨在乙太網路鏈路上做負載或者提供冗餘備份，它和另一種方案有著根本的衝突，因為它不但可以做冗餘，還可以做負載，然而傳統乙太網路上根本就不可以做多重路徑負載平衡！以上說的另一種方案就是物理環路+STP的方案。因此在乙太網路部署連接埠彙總一定要注意，它最好是封閉的，也就是說，如果你在一台裝置上啟用了連接埠彙總，那麼對端裝置也要同樣的彙總，確保不發生環路，檢測手段有mac flapping警示資訊等

傳輸網路與IP網路
學校裡或者工作中，我們遇到的幾乎都是IP網路，從socket到網卡驅動調優。也許參加過Cisco，華為培訓的同學們可能聽說過框架轉送，ATM，X.25等，但是大體也只是聽說而已，並沒有親見。實際上，IP網路只是一套定址網路，真正傳輸資料的是IP網路層以下的技術，也就是上面說到的那些廣域網路技術，大體上，核心網路的拓撲並不像我們的公司那樣，基本上都是一些帶有自愈功能的大環結構，具體的封裝可以採用各種技術，但是幾乎沒有直接用IP封裝的，因為IP交換並不是真正的交換，而是需要額外的一些計算在裡面，這些額外的計算就是路由尋找和位址解析，核心網上的交換基本都是真正的交換，就是說通過簡單的映射匹配就能知道該往哪個連接埠傳輸資料，而這正是ATM，MPLS等技術的強項，因此我們習慣於把這些技術稱作封裝IP資料報的鏈路層技術，而實際上它們真的就是鏈路層技術嗎？如果上層承載的是IP網路，那麼它們確實是，如果上面承載的是傳輸層，那麼它們其實也可以被看作是網路層技術，事實也如此！這些廣域網路技術還不是真正的傳輸技術，它只是一種封裝，傳輸技術就和介質相關了，比如光纖上的SDH，SONET，銅線上的SDH等等。然而我們可以看到，SDH是可以直接傳輸IP報文的，因為它自己有幀封裝機制，淩亂了吧？
        要想真正理解網路的分層，我覺得可以通過OpenVPN的tun/tap模型來類比，把OpenVPN當成是一個物理層，那麼tap就是鏈路層，如果說tun只能承載IP資料報，那麼OpenVPN就是帶有幀封裝功能的物理層。

計算和傳輸之間的曖昧和較量
是什麼原因降低了使用者使用網路的體驗，是網速，因為核心網傳輸資源在雲環境下非常珍貴，所有的使用者都要分享這珍貴的資源，並且，使用者的流量類型五花八門...網路基礎設施的擴容建設必須提上議程，這是一個不爭的事實。另一方面，終端的類型越來越多，處理能力越來越強，這又衍生出了越來越多，越來越豐富的流量，底層網路傳輸能力的不足這件事越來越明顯！
        能不能讓處理器和網路之間配合一下，削平波峰和波穀呢？答案是肯定的！很多的網路加速方案的思想都和Linux的rsync思想差不多，就是儘可能通過執行設計精妙的演算法，儘可能少的傳輸資料，減少頻寬使用，取而代之的是傳輸少量的控制資訊，其思想和壓縮演算法也有些一致。這種加速方案的核心即，將複雜且占頻寬的資料編碼映射成簡單的索引，首先在傳輸資料前先傳輸索引，然後再使用動態演算法傳輸資料或者索引，下面舉一例子：
資料：汪迪有時去拉麵館就是說不是每天都去更不是每天中午都去，但是這同樣也不意味著他有時去的那一次當中每次去拉麵館都能吃完一碗拉麵，並且也並不肯定每次去吃的都是拉麵！
索引：拉麵館-1；每次-2...（數字編碼比漢字編碼簡單得多！！）
如果可能，傳輸的資料將會是1，2，而不是拉麵館，汪迪，中午等編碼。最終網路的壓力卸載給了CPU的計算，搜尋，插入...這裡的例子並沒有說明匹配規則以及不命中時的處理。

SSL與軟體UI外觀
都說SSLVPN不需要安裝用戶端，實際上也還是需要用戶端的，那就是瀏覽器，正是因為大多數的瀏覽器實現都將內建SSL作為 了一種標準來實現，所以看起來就是不需要用戶端了。我並不是在批評SSL，相反，正是瀏覽器越來越多的取代了其他的用戶端，SSLVPN才風靡。這說明大 多數的資料都可以在瀏覽器中來操作，大多數（如果不是所有的話）的應用都可以基於WEB來實現。
        人們越來越關注的是資料本身而不是操作資料的手段和介面，曾經，幾乎每一個軟體用戶端都有換膚功能，我也為用java 1.4.2不調用Native method寫一個不規則視窗而幾個晚上不睡覺，可是現在這些不再被人們所關注了，所有的操作基本都能靠四四方方規規矩矩的瀏覽器來完成，人們不再對軟體的UI形狀有過高的要求，而是把這種要求直接付諸硬體，現在不是有物聯網了嘛，一個很炫的手錶，不規則形狀的播放器，它們要比在顯示器上顯示一個類比的很炫的鐘錶，不規則的播放器要有吸引力的多！

乙太網路的路由
乙太網路就不是一個交換網路，在從源到目標的過程中，它的幀頭就是可以利用的最底層了，你無法利用物理層的豐富的“首部”欄位吧，乙太網路幀頭本身也沒有什麼太豐富的欄位，因此它是簡單的。實際上完全可以實現一個基於MAC地址的類似IP路由那樣的路由機制，然而它最終將比IP路由更加難以管理，因為你知道，IP路由的掩碼/首碼的作用多麼的巨大，可是MAC地址卻是完全沒有規律的，不能進行路由匯聚和子網劃分，路由條目將完全是明細路由，在乙太網路這樣的地址空間支援比較好的主動路由定址，將是多麼的困難，困難之處並不是人們認識到的那樣：增加乙太網路的複雜性，而是乙太網路的地址空間本來就不是用來路由定址的，每一個MAC地址都是基於全球唯一性來指定的，而不是在一張設計的網路拓撲中被指定的。
        路由式乙太網路是一定要設計出來的，乙太網路上急需多重路徑負載平衡轉寄，動態最短路徑轉寄，這一切單憑被動的STP是做不到的，相反由於STP的存在，一些本應該可以轉寄流量的備份路徑卻被當做環路的元兇被kill掉，STP難道就不能智能一些，識別一下流量的細節？

負載平衡/虛擬化與IP地址
如果說上一個小節得出了MAC地址不適合被路由因此必須設計新的地址空間以及新的封裝頭這個結論是MAC不如IP的另一個說法的話，那麼可以說IP還真是五十步笑百步。為什麼這麼說呢？諸多的路由協議不是在已有的IP網路上工作得很好嗎？事實是，在沒有引入負載平衡虛擬機器，備份技術時是工作的很好，因為IP地址本身就被設計用來定址，尋找世界上處在任何地點的全球唯一的IP節點，然而負載平衡和虛擬化打破了這個全球唯一標識的定義，對於負載平衡而言，邏輯上對外呈現的是一個IP節點，可是物理上參與定址的卻是多個IP節點，你要考慮最終將資料送到哪一個IP節點，這就分出了層次，而IP協議並不支援這種分層，在技術上，內網NAT技術以及Linux的IPVS等等諸如此類的技術修補性地解決了這個問題。虛擬機器技術從另一個角度說明了IP定址的不合理性，我們經常在區域網路內拷貝虛擬機器，可是在拷貝完了之後很多時候都要修改其IP地址，否則就會IP地址衝突，事實上，虛擬機器還是那樣虛擬機器，之所以要有多個虛擬機器是因為我要麼想提供一個負載平衡功能，要麼想提供一個備份功能，對外僅僅呈現一個IP地址，也就是說把IP節點的角色和位置分開，這種需求其實可以用VPN+NAT來滿足，舉個最簡單的例子，北京和上海兩大備份中心均可以使用192.168.1.13這個表示角色的地址（如果不使用私人地址，那也就不用NAT了），到底資料被路由到哪裡由VPN封裝策略決定，事實上封裝可以解決一切定址問題，但是卻並不漂亮。以上的需求呼喚出來的是另一種協議，那就是LISP，它提供了雙IP定址結構，仔細看看它的面孔就會發現它和IPSec多麼的相似，只是內層資料不加密而已，內部的IP頭指示角色，外部的IP頭負責定址，它之所以不被稱作VPN是因為它更標準些罷了。

MPLS比IP快在哪裡
MPLS部署在電訊廠商層級的網路上，被稱為一種交換網路，或者一種2.5 Layer網路，它比純IP快是因為純IP網路的路由尋找過程中的計算過程比較耗時，而尋找並交換標籤卻是很快的，MPLS利用動態路由協議產生的路由以及標籤分發協議產生一個標籤交換表，並不是被動得在資料實際到來的時候在產生映射，而是主動的在資料到來前就產生，這樣在路由資料的時候，就可以直接用了，並且基於標籤的交換式傳輸，本身效率就很高。實際上，MPLS並不是新的東西，標準IP網路路由的最長掩碼匹配規則只是一種最原始的回退手段，很多的實現都要比這個高效，比如Cisco的CEF技術，即使Linux也可以使用Netfilter提供的介面來實作類別似CEF的技術，MPLS與這些技術的不同之處在於，它是一種標準化的協議，而不僅僅是一種最佳化手段，標準和最佳化的區別在於，雖然可能標準化的MPLS協議對交換式網路的最佳化可能還沒有CEF這類最佳化手段高，但是標準可以衍生出很多其它的最佳化手段，標準可以獲得最多數裝置的直接支援。

封裝，還是封裝
封裝會將OSI模型搞得七零八落嗎？很多人多說是的，但是並不絕對！標準的封裝是下層封裝上層，可是出現上層封裝下層並不是說打破了OSI模型，要記住這種封裝並不是處於一個邏輯層次上的，舉例說明，VPN的封裝可以是IP封裝以太幀，然而IP是定址層面上，而以太幀則是VPN的P層面上的。總之，封裝這個設計實在是太好了，它幾乎可以解決網路上的任何問題，基於這種思想，越來越多的協議被設計出來，起初是GRE，VPN，後來有了MPLS，LISP等，它們要麼解決安全問題，要麼解決相容問題，要麼解決效能問題以及可擴充問題，相反那些不是基於封裝而被設計的協議，比如STP等，可擴充性就沒那麼強了，不過這並不絕對，路由協議也不是基於封裝的，然而它卻工作的很好，特別是和協議無關的路由協議，比如ISIS。

Cache思想和LISP
CPU在讀資料的時候，會嘗試去Cache讀取，如果沒有Line命中，才會將請求發到匯流排上去。這種思想在互連網上也是有的，特別是物聯網鋪開以後，快速轉寄資料就成了最根本的原則，而快速轉寄的最大瓶頸就是路由尋找和策略路由計算，如果節點數量增加，核心裝置的路由條目勢必增大，計算就更慢了。LISP做的比較好，LISP裝置內部儲存一些映射條目，用於直接轉寄資料的路由依據，在所有的LISP裝置之上，又有一個BGP網路，負責在沒有條目命中的時候查詢路由。之所以設計這麼一個層次是因為LISP將節點角色和位置分開了，因此即使兩個角色處於同一個網段，它們實際上的位置也可能相距萬裡，LISP路由條目是一個角色/位置下一跳的映射，不再支援匯聚，沒有匯聚，路由條目就會大大增加，因此LISP裝置的路由條目索性就乾脆退化成Cache吧，僅僅保留很少的條目做到快速轉寄，而將所有沒有命中的資料包統一發送到它的一個BGP鄰居那裡去，由它來完成慢速路由，然後回送一個Cache更新。
        LISP的精妙之處在於解耦合了很多因素，比如角色/位置的解耦合，明細路由條目匹配/路由尋找計算的解耦合，一台LISP裝置僅僅需要負責尋找條目，將不命中的包發給自己的BGP鄰居，接收路由條目這些操作即可，路由計算之類的慢速操作由專門的裝置來完成。那麼它和VPN封裝有區別嗎？資料層面上沒什麼太大的區別，但是在設計思想上區別就大了。

VPN的控制粒度
IPSec控制的粒度很粗，因為IP協議本身只提供逐跳傳送服務，並不針對任何上層協議進行任何的假設。因此，如果想用IP層的VPN來實現應用程式層的控制，你就不得不求救於外部的類似擴充access-list的東西，即使這樣，acl也不一定能幫你太多，畢竟它只能控制到五元組的粒度，Linux的iptables string match也許可以幫到你，但是那樣的深度解析難度太大，iptables近期推出的L7 match效果也不如想象的那麼好，因此基本上外援是無效的，所以用IP層的VPN來控制應用程式層服務，效果不好。最好的還是要用應用程式層本身的存取控制來實現VPNNetwork Access Control，記住，這是以下技術PK的年代：a.網路層的FW策略可以控制ssh登入；b.sshd的設定檔也可以控制ssh的登入！

網路系統管理員和系統管理員的交叉
程式員在互連網上創造價值，系統管理員企圖傳播這種價值，而網路人員使得這種價值得以傳播，三者缺一不可。進入虛擬化時代以後，網路系統管理員和系統管理員就有了交叉，比如網管不單單是完成布線，配置連接埠策略等等就完事了，因為虛擬化時代的連接埠也許也是虛擬，網管不得不“侵入”到系統管理員的領地，去配置一些虛擬化管理層面上的東西，因此網管不可一世的年代也隨之而去。