在上一篇专栏文章中，我们开始研究WAN服务历史的结果．我们注意到，几乎所有的技术创新都在广域网优化技术，以及最近引进的WAN虚拟化它们的共同点是利用了最近摩尔定律(Moore’s Law)在廉价CPU和内存方面的价格/性能提升，而且它们都是有状态的。在这里，我们将进一步研究与数据网络，特别是广域网上的有状态性有关的问题。
一个依赖于状态的信息系统或协议被称为有状态．当它涉及到基于TCP/IP的网络时，所讨论的状态主要是通信基础设施是否意识到TCP/IP流或其他基于IP的流(如UDP)，或构建在TCP之上的更高级别流(如TCP)，并对其进行特殊处理HTTP，HTTPS或微软的SMB协议．路由协议(如OSPF或RIP)显然必须存储状态，但这些状态是较低层次的信息，用于解决网络可达性问题，并且分布在参与的系统中，因此单是路由协议的存在并不能使解决方案在这种意义上“有状态”。
相关:广域网服务历史的后果
从历史上看，数据网络中的状态性备受争议。当然，这在20世纪90年代是真实的，尤其是在互联网专家/纯粹主义者之间。这个想法是基于TCP/ ip的网络是用端到端参数设计原则(这与论文被一些东西从我的研究生的一天我在职业生涯中已经发现有用的),由于多个复杂的函数会发生在更高的层最终宿主,中间的网络应该做尽可能少让他们目的地以外的数据包。
事实上，回溯到十多年前，这种方法有很好的理由。就内存和处理能力而言，保持状态是非常昂贵的，而且内存成本和CPU MIPS的可用性是如此之高，以至于在TCP流上保持状态并不划算。当涉及到IP流时，路由器被专门设计成无状态的，创建了一个相对“哑”的网络，几乎所有的“智能”都在主机上——至少在涉及到应用程序和应用程序流时是这样。由于CPU和内存有限，无状态的中间盒是唯一合理的选择。在世纪之交，曾有一些公司试图销售基于流的核心路由器，但它们从未成功，几乎已经消失了。
我认为，对于高速服务提供者WAN核心来说，无状态仍然是唯一合理的方式，而且可能是“永远”的情况。当然，核心本身可能会从连接在一个网格中的路由器迁移到第1层或第2层的光核心，在那里，有一天所有的设备在核心边缘的第3层可以处理流状态。
毫无疑问，有状态性使设备更加复杂，使交付高可用性更加困难，使多供应商互操作性几何上更加困难，并且通常增加了应用程序在面对某些网络故障时“崩溃”的可能性。
因此，考虑到端到端争论所固有的效率，以及为基于TCP/ ip的网络创建有状态通信基础设施的其他潜在困难，为什么有状态解决方案变得如此普遍?
有争议的是，仅为安全起见，就需要有一个有状态的中介体，这至少对某些函数来说打破了端到端模型。毕竟，这就是有状态防火墙所做的。没有这样详细的状态，防火墙(或下一代防火墙、IPS或应用层防火墙……)根本不可能执行其功能。
现在，也许网络安全是一个独特的功能，需要有状态地打破端-端模型?也许吧。但应用程序开发人员确保他们的应用程序在环境与有状态的防火墙(之类的NAT功能更复杂的)和客户习惯了至少一个网络基础设施破坏底端模型——对于那些关心放在第一位。
对于IP广域网，事实是帧中继和MPLS过去(现在仍然)非常昂贵，因此，大多数最后一英里广域网管道是如此之细，再加上摩尔定律(Moore’s Law)的不可阻挡的发展，使得CPU性能和内存越来越便宜，这才是真正吸引企业开发和企业客户采用的原因。WAN Optimization和WAN Virtualization等技术存储TCP流状态并打破端到端模型。
有状态解决方案成功还有其他原因。广域网优化供应商(如Peribit和河床使它“更安全”做有状态。底层路由网络没有改变，避免了棘手的互操作性问题思科路由协议。用于覆盖解决方案的设备中的故障到连接以太网对使其在故障情况下“透明”。覆盖加上布线失败意味着供应商可能需要更长的时间来实现真正的高可用性解决方案，而且在较小的站点上没有大量冗余硬件的部署仍然可以提供可靠的网络连接。最后，底层网络是足够标准的——TCP/IP和以太网，通常使用基于intel的linux设备——因此实现这样的解决方案是划算且简单的。
WAN Optimization演示了相对于LAN速度和计算和存储技术的状态而言，WAN管道已经变得如此轻薄，以至于解决方案可以是有状态的，甚至包括硬盘访问，而且仍然是有意义的!
现在，重要的是要承认有状态解决方案的缺点和局限性。最大的两个问题是可伸缩性和互操作性。根据上面的观点，我认为对于大型网络，当然对于像Internet这样庞大而复杂的网络，网络核心应该是这样的不是有状态的TCP/IP流。
Re:伸缩性，毫无疑问，有状态解决方案的伸缩性不如无状态解决方案。在我看来，试图用一个有状态的解决方案来构建公共互联网本身将是一场灾难，而且成本要高得多。事实上，互联网是建立在前面提到的端到端论点之上的。要跟踪的流数量太大了，跨多个网络协调流处理会带来太多挑战。
快速转移话题，比较OpenFlow和SDN re的问题:伸缩性在这里可能很有用。注意，这并不是完全的苹果对苹果的比较，因为OpenFlow和SDN并不是关于在网络交换机中保持每个流的TCP状态，这里讨论的状态实际上更多的是关于网络和网络寻址。正如Omar Baldonado所指出的大开关网络博客,一个配置来统治所有是基于openflow的解决方案的一大优势。它是“整个网络”的集中存储和管理的单状态、单配置。这适用于单个数据中心，甚至是相当大的数据中心——2020欧洲杯预赛可以说是一个非常好的想法。但这是针对单个数据中心的。2020欧洲杯预赛这种集中式配置方法可以用于企业WAN域(这就是WAN虚拟化解决方案的来源)Talari网络我创建的公司就是这样做的)。它甚至可能适用于一个单一的互联网服务提供商的内部网络，尽管这是一个相当冒险的步骤，ISP采取。然而，它不太可能适用于公共互联网，因为网络所有权问题(例如，可伸缩性等因素)要求采用分布式方法，而不是将所有状态存储在一个中央位置。
回到有状态性:TCP流。在今天的企业广域网解决方案中，有状态性大概70%用于处理昂贵的广域网边缘管道问题，30%用于解决光速和基于拥塞的抖动和丢包问题。如果你有一个真正随机的任意广域网，在大多数地点都有千兆连接，状态解决方案可能不适合你(而且你可能是一个网络规模和复杂性像微软或谷歌…)但是，即使您拥有数百到数千个位置，如果像大多数公司一样，您将数据中心合并到少数几个位置，那么今天的技术使得有状态的企业广域网边缘问题解决方案是相当可行的。2020欧洲杯预赛正如我们将在以后的专栏文章中看到的，即使对于语音和视频会议这两个应用程序也是如此是any-any，由于WAN虚拟化技术和明智选择的托管设施的组合，两个关键部分下一代企业广域网(NEW)架构．
互操作性是一个合法的问题;通常情况下，在最大的创新阶段完成后，这一问题会随着时间的推移而得到解决，毫无疑问，当涉及TCP或应用程序状态时，这种软件密集型网络解决方案的互操作性会变得更加困难。但认为这是一个导火线部署之前,我们应该承认,在过去的25年里,尽管标准和各个组件的互操作性是可取的,在实践中,企业通常会买任何一个组件系统从单一供应商的各种理性的原因:可管理性、支持等。
在以后的专栏文章中，我们将讨论网络解决方案中的有状态性可以给企业WAN带来的更多具体优势。新架构组件广域网优化的特定于应用程序的协议通信改进和压缩/重复数据删除功能WAN虚拟化的有状态基础设施解决方案可以为企业WAN带来强大的功能，其中包括避免入站最后一英里拥塞和复制跨多个连接的实时或时间敏感的交互流。
安迪是一位有着25年数据网络经验的老手Talari网络他是广域网虚拟化技术的先驱，并担任其首位首席执行官。安迪是一本即将出版的关于下一代企业广域网的书的作者。