分享

F5是ADN (application deliver network)的领导厂商，它在Gartner ADN魔力象限的位置如图

ADN是一个新名词，wiki上的定义可以参考

http://en.wikipedia.org/wiki/Application_delivery_network

它基本上就是一个是综合了负载均衡(load balance)，广域网优化(wan optimization)，应用安全(application security)等技术的产品，主要关注的，还是应用层的性能优化。

F5以前主打的产品还是负载均衡，至于广域网优化，应用安全没怎么听说过，这里主要说说它的负载均衡产品。

在F5的产品介绍里面，负载均衡主要有以下几个部分：

1)  Global Traffic Manager

基于DNS请求的调度，把同一域名的请求，分配给不同服务器(ip地址），以达到负载分担的目的。

2) Local Traffic Manager

基于HTTP request的调度，把不同类型请求，分配给不同的服务器(ip地址），以达到负载分担的目的。

3) Link Controller

基于socket请求的调度，不同类型的连接，走不同的链路，以获得不同的服务体验。

具体的技术，可以看F5的技术文档，也可以搜网上的资料，我们这里需要考虑的是，这种产品的价值在什么地方？

加速？这是一个基本卖点。通过负载均衡算法，把客户端的请求分配到不同的服务器上，充分利用服务器的性能。或者通过把服务器的工作转移到负载均衡器上（比如ssl offload, http offload）等，减轻服务器的负担。这种设备部署在网络的关键路径上，对设备的可靠性要求很高，但它又想集成更多的功能，功能和可靠性是一对矛盾，解决不好，产品就是去了它存在的意义。

可用性？这才是重点。负载均衡器可以感知服务器或者链路的故障，能及时把流量切换到正常的服务器上，我认为这才是ADN设备存在的意义。原因就是它为用户提供了一个不可拒绝的价值：提高了服务的可用性，避免了宕机带来的尴尬。

session based的网关产品，通过什么来赚钱。有人说通过卖session，就像交换机，路由器卖端口一样。但是交换机，路由器的端口是实实在在的，而且能够产生价值，那session的价值是什么？首先，增加session并不需要多少成本，顶多就是增加一些内存而已，并没有什么难度。其次，并没有人要求per-session的服务质量。还有就是不同情况下，对session的要求是不一样的，比如在每秒连接数的测试中，要求快速创建session的能力；在并发session的测试中，要求session快速回收的能力；在application throughput的测试中，要求每个session的处理能力要高。对session的需求是差别很大，所以卖session只是一个构想，还没有成为现实。（也有很多设备厂商，有用户数，session数的license，不同的license收不同的钱，不知道这算不算一个好的business model，或者用户是否能接受这样的报价方式，还有待继续了解。相同的硬件，卖出不同的价钱，用户不觉得亏吗？）。

由于域名和ip地址分离，使得一个域名可以对应多个ip地址；一个ip地址也可以对应多个域名。这就导致基于ip的控制失效了，所以需要应用层的信息。这是一个demux的过程，目的就是要把traffic划分到某一个特定的类别里面去。基于这个类别，才能做真正有效的控制。

最近几年，F5又把战场扩展到了SSL VPN以及云存储领域，不过好像还没有什么太大的收获，它在SSL VPN魔力象限的位置如图：

当厂商在一个市场上处于领导地位后，扩展地盘也是正常的做法，而且不同市场上的产品，除了用户需求有差别外，用到的技术都比较类似，并没有不可逾越的鸿沟，但是在扩展自己的地盘之前，首先要解决这些问题

1) 平台。从单核到多核；从多核到多个chassis；从多个chassis到cluster；从cluster到cloud，这些跨越需要时间积累和修炼。有点像从“手中有剑，心中有剑”到“手中无剑，心中无剑”的过程，每一个跨越都是一个不小的挑战。

2) 用户。用户和市场是等同的，不了解用户，不了解市场是没办法做东西的。在Gartner的报告里面，非常强调对用户和市场的理解，只有充分理解用户需求，并为用户提供价值的厂商，才能在竞争中立足。

3) 资金。没有这个，一切就是免谈。对这个话题，我已经是无能为力。

最后要说一下，ADN和CDN( content delivery network)是完全不同的两个话题，不能混为一谈。更多信息，请看参考资料。

参考资料：

1：http://www.f5.com/

2：http://www.adntech.org/

3：http://en.wikipedia.org/wiki/Application_delivery_network

4：http://en.wikipedia.org/wiki/Content_delivery_network

5:  http://www.interop.com/newyork/2006/presentations/free/1104-knudsen.pdf

分享