首先知道Citrix 思傑公司的人都知道Citrix 的網絡產品線 有兩款產品
ADC 應用交付平臺產品-NetScaler 另外還有一款廣域網優化的產品 這個名字可就變化頻繁了 – 從WANScaler – Repeater – CloudBridge 到NetScaler SDWAN 平臺產品。有很多人也許會產生一些困惑，是不是思傑公司有一個“改名部門”老是對着這款產品耗上了。其實不然，之所以這款產品的名字變更比較頻繁，正是因爲在思傑廣域網優化產品每年都會有新的技術和需求功能加入。爲了更好的與市場需求相契合，所以我們的理念以及與之結合的技術驅動力也在不斷地進步和與時俱進。
回想到在十幾年以前，當大多數企業的專線帶寬還停留在2M-10M 的時候，一方面帶寬資源非常寶貴，一方面企業在WAN 廣域網上 傳輸的應用也不是太多，有ERP, OA， 郵件服務。那時候視頻會議或是VoIP網絡電話剛剛興起。用戶最初需要解決的問題是應用爭搶帶寬的問題。大家還記得在2003年的時候，中國大陸地區非典肆虐的那2個月，很多公司不得不要求所有的員工禁止流動, 是的，禁止流動，因爲當時恐怖的狀況是人口的流動就會增加感染非典的風險。以至於很多的辦公大樓不得不關閉來做整棟大樓的消毒。這個時候，人們纔想到跨廣域網的協作工作模式。可是在那段時間以及之後的很長時間，人們發現，當應用一旦離開局域網來到廣域網以後，那麼就代表“不靠譜”和“不可爲”。首先你不知道你的廣域網中有哪些應用，哪些與你的業務有關，哪些與你的業務無關 （例如BT和迅雷下載，上網看電影，這些都會消耗你寶貴的帶寬資源）其次你不知道這些應用在廣域網中如何才能保證它的傳輸質量。所以在那個時候我們需要解決這2個問題。 QoS –帶寬管理 那時候應運而生。它也許來得正是時候。
帶寬管理（臺灣，香港地區有時候會叫 “頻寬管理”） 簡單得說它需要解決2個問題，第一：它需要知道網絡中（WAN）到底有哪些應用在傳輸，這個技術現在已經規範化了 DPI （Deep Packet Inspection ） 也就是當數據包經過設備若干次以後，偵測引擎可以依據之前的應用特徵庫來確定這是一個什麼應用。隨後基於這個應用來進行連接數，帶寬利用率，延時的分析。隨後基於這些分析的圖表來配置帶寬管理的策略。簡單地說也就是 應用的分類-分析-策略-報告 。這個方法從當時來說很管用。並且也行之有效。以至於現在它也仍然是企業網絡管理人員經常使用的手段之一。
可是它也有它的侷限性
侷限性之一： 只能控制出向（Outbound） 流量，不能控制進項（Inbound） 流量。這個問題解釋起來很容易。比方我們一個會議室裏大概有10個人，現在會議結束了。大家都要離開，那麼誰先離開就要看誰的優先級比較高。QoS 帶寬管理就是依據應用的優先級來排列 誰先離開，誰後離開。那麼這個時候問題就來了，假設這個會議室的前一個會議剛剛結束，我們有10個人要離開，可是下一個會議馬上就要開始了，會議室外面有30個人要進來。不巧的是，基本上帶寬管理設備就只能管理出去的人，不能控制進來的人。結果大家都被堵死在會議室的門口。因爲雖然我對出去的10個人離開會議室做了優先級的排列，可是我無法控制外面的人誰能等一等。我也不能控制誰這個30個人在公司樓下，地鐵，電梯廳來排序一下，誰先來，誰後來。
侷限性之二： 假設開會的每個人代表一種在WAN 中傳輸的應用。這個公司的會議室可以容納下超過100個人開會，可是門卻每次只能允許一個人通過。（局域網帶寬大，廣域網帶寬小）那麼你怎麼設定優先級那？現實環境下，你能說爲了保障視頻會議而讓VoIP 網絡電話的品質下降嗎？你能允許在公司用Polycom 視頻會議開會的時候，讓所有的員工不要用Skype for business(Lync) 來通話嗎？對於某些特殊的國家機構，你能允許在每月關賬，或是報稅的時間，讓員工不要上網嗎？
顯然以上兩點阻礙了QoS 後期的大發展，所以我們今天已經很少看到專業的QoS 廠商 還能單獨存在於這個市場。轉而變爲 ，我們看到路由器，防火牆廠商在將QoS 變爲一種功能集成到現有他們的產品中去。
廣域網優化產品-橫空出世。中國市場最早被廣域網優化產品喚醒應該是在2005年前後。那個時候帶寬管理已經走到了它的瓶頸期。廣域網優化產品通過兩邊都部署相同的壓縮字典方式，來對傳輸到廣域網的數據進行壓縮，隨後在另一邊的接收端再對數據進行解壓縮。假設如果對於數據能夠壓縮到原先的十分之一，那麼是不是代表WAN帶寬就可以無形中增長了 十倍。幾乎所有的廣域網廠商的設備呈現的報表都要包含這個WAN效能的圖表來反應使用某某廠家的廣域網優化設備以後能給用戶帶來的利益和好處。
結果在 2005年-2010年 ，5年時間裏，廣域網優化產品大賣特賣。企業用戶發現似乎再也不必被運營商高昂的專線費用綁架了。我們只需要投入有限的Cepax（固定成本支出） 就可以節約無限的Opex （運營成本）的支出。
結果：理想很豐滿，現實很殘酷
1： 有限的對TCP應用的優化，我們知道TCP 應用之所以在WAN中傳輸效率低下是因爲需要進行3次握手，沒辦法，它就是一個“悲觀主義者”它不相信和它傳輸的另外一端的狀態，所以每個session 都需要三次握手的驗證以後，才能傳輸。建立連接的3次握手每次都要穿過高延時的WAN廣域網。距離產生美，距離產生延時。如果在傳輸過程中有一個包丟失了，那麼就需要這整個session重傳。所以當用戶使用品質一般的WAN 鏈路（如CABLEInternet , XDSL ） 往往WAN帶寬都被重傳的數據包占據。廣域網優化設備說穿了就是一個TCP 協議的透明代理，它首先會在兩臺廣域網設備之間建立某種 高效地TCP 連接，這裏需要明確一點，我們有些Partner 在第一次聽到這個原理的時候，說這個和NetScaler ADC 的連接複用好像很相像。這是一個誤判，因爲這裏它們只做連接的代理，而沒有連接的複用。（NetScaler 的連接複用可是有專利的哦）所以實際每臺廣域網優化設備承載的連接數都要乘以 2 才行。這也是爲什麼我們在爲用戶做廣域網優化設備選型的時候，對用戶環境的連接數那麼在意。好了，回過頭來講TCP 連接代理吧，可能有些小夥伴要開始問了，那麼UDP 那？UDP 可是 傳輸的“樂觀主義者“ 只要確定對方的IP地址就把東西丟過去了。真的被言中了，對於大多數UDP 的協議，廣域網優化設備真的沒什麼太好的辦法，一個字 – 透傳 Passthrough .不做任何的優化處理了。我們知道 大多數企業視訊系統 都是走UDP傳輸的。
2：不是什麼應用都能被壓縮，壓縮會產生延時，廣域網優化設備 default 用的優化手段就是壓縮，這個從存儲技術領域的重複數據刪除演變過來的技術（很有趣的是，我發現很多廣域網優化設備的廠商售前很少提到這個技術，因爲生怕用戶會擔心數據的完整性的安全考慮，特別是和金融行業用戶聊起來的時候）不用似乎效果不大，用了生怕對實時的應用造成傷害。我之前碰到一個客戶，他們的廣域網優化設備聲稱可以對Citrix ICA 協議進行優化。結果用戶購買以後只要一開對ICA 的優化功能，不僅不能優化，反而會讓實際的訪問變慢，用戶的體驗很糟糕。買了那麼多設備，現在廢棄不用，這真是個讓他們頭疼的問題。而最近聽到的很多聲音，也確實有很多用戶在購買了某某品牌的廣域網優化設備以後，因爲後續問題太多，在1年或是2年以後不再使用了。這也不能怪罪廠商，畢竟用戶在廣域網中傳輸的應用每年都會有增加，不是每種應用都可以適應這種，先將TCP 連接劫持，數據壓縮，代理後再傳輸的模式。
3：雲的架構，讓很多廣域網優化解決方案無從下手。
現今 並不是所有的用戶都需要有數據中心纔可以發佈企業應用，或者用戶也並不一定要把所有的應用都放在自己的數據中心裏面。雲計算中的IaaS ,PaaS,SaaS 都可以在不同層面發佈構建應用發佈。這對於用戶來說是一個非常不錯的選擇，可是對於傳統的廣域網廠商來說，問題又來了。因爲所有的廣域網廠商都需要成對部署最起碼2臺設備，才能構建自己的解決方案。也許在IaaS 還可以，但是在SaaS 就比較麻煩。 比如 ，如何優化對微軟O365用戶的傳輸那？ 你並不知道O365 的服務器在哪裏？更何況 還有國際版和中國世紀互聯版。大家知道CitrixCloud 正在加緊在微軟的Azure 中落地。假設你是一個第三方的廣域網優化廠商，你能確定它們的應用在哪裏嗎？
4：一般廣域網優化廠商很難建立起自己的應用優化生態關係
Ecosystem 這個是不是有點扯，但是在廣域網優化設備的實際使用中。真的需要這個。打個比方，你如果不能識別Citrix ICA 協議的32個子通道，你就很難對Citrix ICA 協議進行有效的優化，儘管它外層套得是TCP 標準協議棧。同理，如果你不能和某種商業應用公司達成有效的合作方式，那麼就無法在應用層對數據流進行優化。而粗暴的壓縮字典因爲是工作在Byte 層面，所以這種優化方式就會適得其反。這個在剛剛已經描述過了，這裏就不再重複了。
好了，以上花了那麼長的篇幅的描述，只是爲了說明一件事情，那就是傳統的點對點優化解決方案似乎已經要走到頭了。以下是WOC (WAN Optimization controller)市場分析。這個市場幾乎已經開始沒有增長了。否則這個市場的領導廠家RiverBed也不會被私募收購後退市，另一家廠家 BlueCoat 在幾度易手後，一步步沉淪最後被塞門收購。雖然48億美金的這個價格還是小小的出乎了行家的預測。
大家看到哦，這個是一個下降的曲線，不是增長的曲線哦
好了，接下來我們要開噴SDWAN 了 。SDWAN 顧名思義 就是Software define WAN –軟件定義廣域網。初聽到這個名稱的人也許分爲2類，一類估計是被這兩年軟件定義什麼什麼的轟炸的已經麻木了。軟件定義存儲SDS ，軟件定義網絡SDN。軟件定義數據中心（不好意思我還真沒研究過這個是什麼簡寫）。所以軟件定義廣域網那就來吧。第二類可能覺得這肯定是一個噱頭，也許就是SDN 。
這裏我想說，Citrix 公司推出的SDWAN 肯定不是簡單的對原有的產品線改了一個名字而已。這個改變來自於新的技術實現模式。更確切地說，市場的需求推進了新的技術驅動力。
這裏我們用兩張圖來說明問題，第一在很多企業裏面，WAN 專線的開銷一直是個大頭
除了MPLS 線路擴展價格貴以外，還有一個問題。那就是在絕大多數地區，如果一個企業客戶提出申請要增加，修改或是遷移MPLS 線路的時候。平均需要90天才能做到。這個數字放在今天的IT 環境實再是有點離譜。因爲也許有些微應用，它的生命週期可能已經小於這個數字了。換句話說，等不到90天，這個應用也許就已經下架了。
另一個現象是，相對於高昂的專線成本，普通Internet的成本卻是那麼的cheap
好了接着上面的篇幅來說，衆所周知 ，廣域網中應用以後會變得越來越多，傳統的企業應用，視訊，大規模文件傳輸，特殊協議，加密訪問傳輸，移動Apps ，雲端，SaaS 等等。每天都困擾着企業IT 管理人員。因爲傳統廣域網優化設備一直遺留下來的問題，似乎現在除了擴充專線以外沒有其它的辦法。但是雲的架構又不能簡單擴專線了事。之前遇到一個外企的IT 管理人員，他說起他們最近正在招標100臺防火牆的項目。我覺得有點奇怪，因爲之前的他們所有分支機構的上網流量都要經過數據中心的安全設備，隨後經過統一出口上網。他說現在真的沒辦法，企業使用的SaaS 應用越來越多，很多部門也真的需要大量訪問Internet , 原有的專線帶寬真的捉襟見肘。之前也不是沒有考慮過用WOC 廣域網優化設備。可是發現能夠解決得問題就是能解決，不能解決的也就不能解決。在綜合考慮ROI 投資回報率之後，他們決定還是放棄了。升級專線帶寬，費用實再太高，ROI 回報率也不高。最後也是沒有辦法的辦法，招標防火牆項目。雖然這會嚴重破壞之前他們設計的整體架構的安全性。因爲有很多流量將會直接從分支出去，不經過安全監測了。
好，那麼針對這種情況，我們拋出SDWAN 的第一個技術實現理念： Hybrid WAN 混合廣域網模式。可以將專線/Internet / 4G 等不同類型和品質的廣域網線路混合在一起。Citrix 把這樣的功能叫做Virtual WAN .即一根虛擬鏈路綁定所有的物理鏈路。剛剛已經提到Internet 線路確實便宜。這樣可以增加帶寬，不錯。但是每條線路的品質是參差不齊的。專線（MPLS , ）的品質最好，普通Internet線路也許延時和專線差不多，但是丟包率卻很高。那麼在這裏我們就不是簡單的綁定那麼簡單。如何做到大家的傳輸品質是一樣的那？有一句老話，三個臭皮匠頂個諸葛亮。很幸運的是，NetSaler SDWAN 做到了這一點。
類似於廣域網優化的部署，我們同樣在跨廣域網的發送端和接收端都部署了一對Citrix NetScaler SDWAN 。但是我們來管3跟不同傳輸品質的internet 線路。假設我們將3根10M 的internet線路捆綁在一起成爲一根虛擬帶寬。它確實有丟包，可是有趣的是這3跟線路怎麼來傳輸應用數據。
舉例1：在線路1 傳輸的時候，應用A發生了一次丟包，SDWAN 接收方迅速偵測到了這次丟包，並且在第一時間要求將這個丟包補傳回來。這個時候它發現線路2 的品質最好，所以那個丟失的數據包會迅速從線路2傳送過來。而整個Session會話仍然有條不紊的在進行傳輸。記住這個時候NetScaler SDWAN是基於Packet數據包來判斷和優化的。和你使用TCP 還是UDP 無關。換句話說，用戶的應用不管是使用TCP 還是UDP 來進行傳輸都會被這種機制優化。另外有些用戶會說，這個之前我們知道的傳統的鏈路負載均衡有什麼區別？鏈路負載均衡可是基於會話來做負載的，也就是當會話斷了，那麼你就需要重新發起連接請求。可是NetScaler SDWAN 它不需要。之前丟包可是會造成整個會話重傳的。但是在NetScaler SDWAN 這裏根本就不算什麼事兒。這些細小的變化都不會阻礙會話的持續傳輸，甚至在整個會話傳輸的時候，Netscaler SDWAN 還會自己動態的調整在一個Session哪些Packet 可以走哪些鏈路。而多條鏈路也可以只是傳輸一個Session 會話。
舉例2：用戶的應用B 是需要實時傳輸的視訊系統。用戶不希望出現抖動和其它的“馬賽克”之類的現象。那麼我們可以啓動這個視訊會議的應用流量在2條或是更多的線路上同時複製傳輸。接收端的NetScaler SDWAN 當收到最早到的Packet以後，後到的同樣序號的packet就會被丟棄。假設應用B 的某個packet在internet 線路1 先到，那麼internet 線路2 接收到的同樣的packet就會被丟棄掉。但是下一個packet也許是線路2先到，那麼線路1的就會被丟棄掉。接收端的netscaler SDWAN設備就會將前後收到的Packet重新組裝成數據報文。這樣你傳輸的鏈路越多那麼你的傳輸品質就最好。
那麼它的效果到底如何那？這裏的一個“剪網線(Cut Technology)”DEMO視頻可以讓你在現場震撼一下.
http://v.youku.com/v_show/id_XMTU5MTA1MDY5Mg==.html
Citrix NetScaler SDWAN 並不是單單隻有Virtual WAN 這一個選擇。剛剛我們已經說過，對於多個應用爭搶帶寬的時候，你也許還是需要做QoS帶寬管理，對於TCP 的應用，如果正合適的壓縮字典的超常規發揮的話，用廣域網優化技術也許效果會更好。比如基於大文件傳輸的CIFS , FTP , Http 等。這裏還要說一句，對於Citrix自己的ICA 協議，NetScaler SDWAN 提供Citrix on Citrix 的解決方案。簡單來說，就是“我們是一家人，我們都認識” NetScaler SDWAN 可以清楚知道ICA 每個通道的數據傳輸，並給出相應的優化。
管理員是不是需要了解那麼多的底層技術，不，你不需要。你並不需要了解數據包到底是走哪條鏈路。你也不需要修改你現有的路由器的路由配置。你甚至不需要再增加防火牆 *** 設備. 你只需要專注與你的應用，對於某個應用，它是實時的？交互式的？大文件傳輸的？基於哪個秉性，我們需要提供什麼樣的優化方式。QoS ? TCP 連接優化？壓縮？虛擬鏈路複製傳輸？你只需要聚焦在你的應用，其它的交給我們就可以了。這就是軟件定義網絡傳輸的優勢。一個管理平面定義所有的廣域網優化技術。
說到這裏還差一樣，就是怎麼優化到雲端的應用那？當然這裏就又要提到生態關係了。我們知道除了Citrix NetScaler SDWAN 提供的點對點的SDWAN ，還有很多運營服務商（在中國有提到是叫虛擬運營商）他們的Cloud 連接管理可以基於應用讓你以最快的路徑走到雲端的服務。NetScaler SDWAN 當前選擇了 Equinix 來做雲端服務的優化。
在這裏可以看到，NetScaler SD-WAN 整合進了Equinix 平臺。當用戶需要連接到AWS , Google , Azure 的公有云服務的時候，你被先連接到 Equinix 離開你最近的Location ，然後他們會基於你的應用選擇最快的路徑來傳遞到雲端。
總結：
說道這裏你現在怎麼看Citrix NetScaler SDWAN 那？我想你可以有很多維度去認識它
1：它是下一代的網絡邊際設備，它擁有目前所有主流的路由算法，OSPF ,BGP, ISIS , 保證你可以部署在任何邊際網絡環境中，它的Virtual WAN 虛擬網絡可以智能地將多根物理線路做捆綁來智能傳送數據包。
2：它解決了之前十幾年以來廣域網優化設備一直無法解決的侷限性問題。
3：它承上啓下地繼承了之前的所有廣域網對應用的優化技術
4：它第一次將安全和廣域網優化放在了同一個管理平面。（後期我們會推出防火牆，SWG 安全網關的功能）
5：Citrix 正在積極地打造生態鏈，要知道Equinix 在中國也有不少的接入Location哦。而且未來這種合作可是有很多想象空間的。
所以我們……… happyselling Citrix NetScaler SDWAN ……….Enjoy your Life