NetScaler SDWAN 的前世今生

时间：2017-02-20 23:31:27 阅读：281 评论：0 收藏：0 [点我收藏+]

论 NetScaler SDWAN 的前世今生

首先知道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://player.youku.com/player.php/sid/XMTYyODQ1MTU0MA==/v.swf

Citrix NetScaler SDWAN 并不是单单只有Virtual WAN 这一个选择。刚刚我们已经说过，对于多个应用争抢带宽的时候，你也许还是需要做QoS带宽管理，对于TCP 的应用，如果正合适的压缩字典的超常规发挥的话，用广域网优化技术也许效果会更好。比如基于大文件传输的CIFS , FTP , Http 等。这里还要说一句，对于Citrix自己的ICA 协议，NetScaler SDWAN 提供Citrix on Citrix 的解决方案。简单来说，就是“我们是一家人，我们都认识” NetScaler SDWAN 可以清楚知道ICA 每个通道的数据传输，并给出相应的优化。

管理员是不是需要了解那么多的底层技术，不，你不需要。你并不需要了解数据包到底是走哪条链路。你也不需要修改你现有的路由器的路由配置。你甚至不需要再增加防火墙 VPN 设备. 你只需要专注与你的应用，对于某个应用，它是实时的？交互式的？大文件传输的？基于哪个秉性，我们需要提供什么样的优化方式。QoS ? TCP 连接优化？压缩？虚拟链路复制传输？你只需要聚焦在你的应用，其它的交给我们就可以了。这就是软件定义网络传输的优势。一个管理平面定义所有的广域网优化技术。

说到这里还差一样，就是怎么优化到云端的应用那？当然这里就又要提到生态关系了。我们知道除了Citrix NetScaler SDWAN 提供的点对点的SDWAN ，还有很多运营服务商（在中国有提到是叫虚拟运营商）他们的Cloud 连接管理可以基于应用让你以最快的路径走到云端的服务。NetScaler SDWAN 当前选择了 Equinix 来做云端服务的优化。