网关高可用协议：HSRP、VRRP、GLBP、CASP

网络中网关设备负责完成大部分的高级处理，因此网关设备的高可用十分重要。常见的高可用协议包括 HSRP、VRRP、GLBP、CASP。基本原理都是在一个组里面选出一个主节点，拿到虚的网关 IP 和 虚 MAC。这些协议也可以提供 IP 节点的高可用保护。

HSRP

全称是 Hot Standby Routing Protocol，Cisco 家 98 年公开的专利协议，在 RFC 2281 中给出。

一主一从，其它为监听状态。组内多播到 224.0.0.2（v1）或 224.0.0.102（v2），虚地址不能跟物理地址重复，虚 MAC 地址为00-00-0c-07-AC-XX。

基本只有 Cisco 家设备支持。

VRRP

全称是 Virtual Route Rendundancy Protocol，IETF 的标准协议，在 RFC 3768 和 RFC 5798 中给出。设计思路是基于 HSRP，所以两者之间在概念上有很多相似之处，但并不兼容。

一主多从。组内 IP 多播到 224.0.0.18，IP 协议号为 112。虚地址可以复用物理地址，虚 MAC 为 00-00-5E-00-01-XX。

除了 Cisco，别家硬件支持的较多，另外有开源软件实现，Linux 上的 VRRPd。

用 VRRPd 配置的话很简单，指定网卡，本机的优先级，所属的组号和虚 IP 即可，例如

$ vrrp –i eth0 –p 24 –v 1 192.168.1.1

GLBP

GLBP 也是 Cisco 家的私有协议，基于 HSRP，最大的改进是考虑了负载均衡。特别之处的设计在于通过激活的虚网关（Active Virtual Gateway）来负责响应网络中的 ARP 请求，虚网关会根据权重来答复不同的成员的虚 MAC 地址。

组内多播到 224.0.0.2（v1）或 224.0.0.102（v2），协议基于 UDP，目标和源端口都是 3222。

最多同时可有 4 个转发网关。

CASP

全称是 Common Address Redundancy Protocol，非标准协议，最初是为了避免 HSRP 的专利风险，由 OpenBSD 在 2003 年完成的全新的设计，加强了安全性，带有负载均衡功能。

OpenStack 部署分布式应用的一个坑

之前基于 OpenStack 部署了一个云，运营下来一段时间下来还算正常，出现了各种问题也是意料之内，基本都很快搞定。

搞云计算的人嘛，就得懂得多一些、深一些不是：）

但有一天有个客户找上来反映了一个小问题，虽然最终解决掉，却引发了我的深思。

问题

客户的应用很简单，也是在我们的平台上申请了虚机，然后自己用 keepalived 为后面的某 db 业务提供 HA 保障。一切运行的都很正常，突然有一天，死活访问不通 db 了。

通过查看日志，发现故障发生前 keepalived 发生了切换，灾备节点被切换了。一开始怀疑是 keepalived 配置问题，检查后发现都正常，而且灾备节点确实也拿到地址了。我们搞运维的同学怀疑是网络问题，但底下排查了半天，也没找到原因，而且别的业务都跑的好好的。

分析和解决

出现问题肯定不会是莫名其妙的，我仔细回想了 VRRP 的原理和 Neutron 的实现。keepalived 基于 VRRP 来切换主从节点，被激活的节点会抢到配置的虚地址。然而，neutron 里面为了防止虚机作恶，会记录每个虚机启动时候分配的 IP 和 Mac，并用这个地址来过滤，避免出现篡改源地址的恶意流量。好了，那问题来了，neutron 并不知道某个虚地址其实是在两个 port 上都可能出现的，就会阻碍切换后的灾备节点流量通信。

问题定位到，就好解决了，直接改 iptables 规则，或者开启 Allowed-Address-Pairs (https://review.openstack.org/#/c/38230/) 即可。

进一步思考

从应用的角度看，VRRP 这种切换地址机制毫无问题；从 OpenStack 角度看，你申请一个虚机配置好了地址后，我只允许已知地址的流量出来，也是正常的。但偏偏两个结合到一起就有了问题。这根子上还是在于上层应用和底层平台之间的整合出现了偏差。其实系统就是这样，俩都正常的组件，放一起不出问题的概率很小，这也是为啥接口设计很关键。

我们一直说，要懂业务，要理解业务，其实也是避免设计出的产品跟真实的需求出现偏差。

首先，客户往往并不懂技术（甚至自己都不懂业务），这意味着他们很难用准确的语言描述清楚自己的真正需求（甚至自己都不知道真正需求是啥）。这就需要提供服务的团队要做到比客户更懂自己的业务，这是赢得客户信任的一个极大的优势。懂得从客户需求到业务流程到底下各种技术栈的灵活运用，这才是优秀的技术人员。

另外，就是产品的形态很重要，为什么现在云有 IaaS、PaaS、SaaS 等多种分类，其实这不同的产品形态都是针对不同的客户群体，满足不同的业务需求。呈现细节越少，意味着灵活性越差，但客户使用难度会降低。但无论是那种形态，都应该有严格的范围限制和操作保障，要让完全不懂技术的人能成功操作，甚至各种误操作也能纠正过来。在这点上，OpenStack 是做得很差的，这也是为什么基于 OpenStack 做云服务，首要任务是替换掉 Horizon。极简设计和极繁设计，无所谓高低，合适最好。

最后就是要选择合适的工具。现在开源特别发达，甚至同一个应用场景会出现数个优秀的开源产品，光看特性都是很吸引人。这个时候，选择就很重要了，最看重啥特性？二次开发的难度有多大？针对需求选这个是否合适？选择对了，事半功倍，反之往往陷入各种坑难以自拔。

分布式系统中的算法设计（一） -- 一致性 Hash

Hash 大家都知道，把某个要存储的内容的索引 key 通过某个规则计算一下，算出来一个值，这个值往往范围比原来小，且概率意义上不会冲突。

由于 Hash 计算复杂度往往比查找要快，被大量应用到各种大规模的系统中，特别是分布式系统。具体实践中有几个典型的问题。

问题来源

一致性 Hash 讨论地已经很多，基本故事就是分布式存储系统中，通过 Hash 来决定内容存到哪个节点上。

典型的比如 cache 系统，后面放若干节点，查找某个 key，hash 到某个节点，再进一步检索。

最简单的自然是按照节点数量取个模，理想状态下不会有啥问题。

但是如果发生如下情况，就无法正常工作了。 加节点（一般是有计划的） 减节点（可能突然故障，无法预知）

所以提出了一致性 hash，即考虑如下四个方面的算法： 平衡性(Balance)：哈希结果尽可能分布到所有的节点，这样可以使得所有的节点都得到利用； 单调性(Monotonicity)：加入新的节点后，已经分配节点的 hash 结果 被映射到原有的或者新的节点上去，而不会被映射到其他节点； 分散性(Spread)：同样内容尽量避免 hash 到不同节点； 负载(Load)：不同内容避免 hash 到同样节点。

简单的说，就是有一个算法，首先分配尽量均匀，其次，当节点个数变化的时候，尽量维持原来内容的映射，并进行局部调整。

能满足的算法有很多，这里介绍两个比较经典的。

基于环的实现

该算法最初于 1997 年在论文 Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web 中提出。算法复杂度为 O(log(n))。

主要设计思想为：构造一个环（顺序标上编号比如 0 ~ 2^32-1），将已有节点编号并分配到这个环上，分割环为不同的段。

对每个内容，hash 后是一个独一无二的数字，这个数字肯定会落入某个段上，按照固定方向往前找到的第一个节点编号即为要分配到的节点。

考虑两个相邻的节点 A 和 C，如果要在中间添加一个节点 B，那么 AB 段上内容会从 C 节点重新分配到 B 节点。反之，如果删除掉 B 节点，那么 AB 段上内容会再次分配到 C 节点上。

这种算法很好的满足性质 2-4，唯独平衡性没有解决。即当节点个数不多的时候，内容可能会集中在某些段，划分到部分节点上。要解决这个问题也很简单，把一个节点虚拟为多个虚节点，提高整体节点个数，然后再分散放到环上。这样就提高了平衡性。

基于概率转移的实现

该算法最初于 2014 年在论文 A Fast, Minimal Memory, Consistent Hash Algorithm 中由 Google 工程师 John Lamping 和 Eric Veach 提出。算法复杂度为 O(log(n))。

主要设计思想为：假设原先有 n 个节点，新加上一个节点后，每个 key 都有 1/n+1 的概率转移到新的节点上，n/n+1 的概率留在原先分配的节点。

举个例子，原先有 1 个节点，再加一个节点，那么已有内容有 1/2 的概率跳转到到第二个节点。原先有 2 个节点（每个里面有 1/2 的内容），再加一个节点，则已分配内容应该有 1/3 的概率转移到新的节点。

一个简单的实现代码为：

int ch(int key, int num_buckets) {
    random.seed(key) ;
    int b = 0; // This will track ch(key, j +1) .
    for (int j = 1; j < num_buckets; j++) {
        if (random.next() < 1.0/(j+1)) b = j ;
    }
    return b;
}

即根据 key 生成 num_buckets-1 个（0~1.0）的伪随机数，依次检查随机数序列：

• 第一个随机数 <1/2，则放第二个节点；
• 第二个随机数 <1/3，则放第三个节点；
• ...

注意伪装随机数序列由 key 唯一确定。意味着同样的内容在多次分配中，分配结果将是一致的。

另外，可以计算出如果当前分配为 b，下一个结果 j >= i 的概率（即 b+1 到 i-1 的过程都不发生跳变）

P(j>=i) = (b+1)/i

最终优化为如下代码：

int32_t JumpConsistentHash(uint64_t key, int32_t num_buckets) {
    int64_t b = -1, j = 0;
    while (j < num_buckets) {
        b = j;
        key = key * 2862933555777941757ULL + 1;
        j = (b + 1) * (double(1LL << 31) / double((key >> 33) + 1));
    }
    return b;
}

这个算法依赖于伪随机算法的输出，特点有： 分布均匀性由伪随机算法决定，而跟 key 自身均匀性无关，实践均匀性远好于基于环的算法； 不需要对 key 进行计算，复杂度低，实践计算时间也比基于环的算法好。

算法没解决的问题：当中间减掉节点的时候，序号会发生变化，变为 0...n-1。因此需要在外面维护一个映射关系，动态映射到原先的节点上。

Linux 中的网桥技术

Linux Bridge

最经典的网桥实现，基本上参考一个传统硬件交换机的功能来实现，自学习转发表，支持 STP。

物理网卡可以绑定到 LB 上，通过混杂模式将所有包转发到 LB 上，LB 按照传统二层交换机功能进行转发。

LB 也支持 Vlan 隔离，以及常见封装协议。

MacVLan

首先，不要被名字误导，其实跟 vlan 没啥关系。

在一个物理网卡 ethX 上可虚拟出多个 MacVLan 设备，系统看到的是类似 xxx@ethX 命名格式的虚拟网卡。相对网桥来说更加轻量级。

每个 MacVLan 设备拥有不同的 mac 地址和 IP 地址，只有匹配到某个 MacVLan 设备的地址的流量才会发给该设备，模拟 vlan 隔离效果。

创建方式（忽略 mac 地址则会自动随机创建）：

#  ip li add link eth0 macvlan0 address 9a:cb:eb:26:a7:8d type macvlan mode bridge

一共支持四种模式：VEPA、Private、Bridge 和 Passthrough。前三种都是参考 EVB 标准。

VEPA （Virtual Ethernet Port Aggregator）

默认模式，需要外部交换机支持 VEPA/802.1Qbg。多个虚拟机指定同一个接口（例如 eth0），通过该接口连接到外部的物理网络。本地之间的访问需要先绕到外部的物理（也可以配置为软交换机）交换机，然后由外部交换机进行转发，再绕回来。是 EVB标准的一种。

注：VEPA/802.1Qbg，即需要外部交换机支持 Reflective Relay，或者发夹（Hairpin）模式，即从一个接口发上来的流量还能扔回去。

Private

类似 VEPA，但本地几个 MacVLan 接口之间不能相互访问，即使外部交换机支持 Reflective Relay 也不成。除非虚机处在不同的子网，经过外面网关的转发再绕回来。要求源和目的都配置为 private 模式。这种模式是不是很眼熟？多租户的公有云里面应该用处挺大。

Bridge

通过一个虚拟的网桥来连通本地的多个 MacVLan 接口，本地通信不需要发送到外部交换机。这种情况下，虚拟网桥知道每个接口的 Mac 地址，不需要实现学习和 STP 功能，比传统网桥简单且高效。

当然，要求源和目的虚机都配置为 bridge 模式。

Passthrough

独占物理网卡，并配置为 promiscuous 模式。一般一个网卡上只允许绑定一个 MacVlan 设备。本地无法直接交换，得靠外面交换。

MacvTap

如果把 MacVLan 设备再关联上一个 tap 设备，从物理网卡到达的网包不交给内核网络栈处理，而直接发给 tap 文件，就叫做 MacVTap，方便用户态应用直接处理网络流量。

OpenvSwitch

除了拥有 LB 的传统二层交换机功能，OpenvSwitch 最强大的是对 SDN 的支持：独立的 ovsdb，复杂的流表控制，支持外部控制器，基于 Linux TC 实现的 QoS 等。

SR-IOV

硬件虚拟化，网卡支持 SR-IOV，则一个物理网卡 PF，可以直接虚拟为多个 VF。网卡内自带嵌入式交换机，功能简单，但性能高。通过 PCI-passthrough 可以直接把 VF 挂载到虚拟机中作为网卡，也可以通过 macvtap 的 passthrough 模式再加一层桥接。

转载请注明：http://blog.csdn.net/yeasy/article/details/50728243

HTTP/2 你需要知道的知识

HTTP/2 是 HTTP 协议的第二个正式版本，于 2015 年 5 月 15 日正式发布，到现在短短半年时间里已经获得了大量的关注和实现支持。本文将介绍其核心的理念和相关知识要点。

可以通过访问 Akamai HTTP/2 测试页 来体会性能提升效果。本地测试结果差一个数量级 。

为何要有 HTTP/2

主要目标是优化性能，次要目标是安全性和互操作性。其实也是因为现在越来越多的 Web 应用，对性能等方面的需求。

最早的 HTTP/1.0 （RFC 1945，1996 年发布）中每个资源（文本、图片）默认要单独创建一个 TCP 连接来传输。创建一个 TCP 连接的时间成本是比较高的。

HTTP/1.1 （RFC 2616，1999 年发布，最近替代的是 2014 年 RFC 7230）是目前互联网世界的主流协议，通过优化对 TCP 连接的使用来提高效率，主要改进包括：

• 默认采用持久化连接：同一个网页上的所有资源可以共用一个 TCP 连接；
• 请求的流水化：多个请求可以不用等前面请求完成就一次性顺序发出（但应答消息还得顺序返回）；
• 其它特殊头字段（Host、Keep-Alive、Range 等）支持更多语义。

注：RFC 7230 中去掉了一个域名最多 2 个连接的限制。

来源

项目主页在 http2.github.io。

HTTP/2 规范内容是基于 Google 提出的 SPDY 的 3 号草案，这也是为何实现如此之快。

Google 后来基于 SPDY 提了一个 QUIC 协议，试图基于 UDP 来实现类似 HTTP/2 的效果。

注：UDP 和 TCP 之争由来已久，只能说两者各有适合的场景，不能简单对比。

具体内容

核心思路是在继续遵循 HTTP 规范的前提下，（通过多路复用等手段）进一步提高对 TCP 连接的利用率，减少无谓的等待时间；同时采用头部压缩减少传输量。

实现上，在应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层（分为 Header 帧和 Data 帧）。加层的做法果然是 IT 行业的瑞士军刀。

跟 HTTP/1.1 比，没变的：

• HTTP 方法
• HTTP 状态码
• HTTP 语义

意味着原先基于 HTTP 设计的 API 照样可用。

改进的地方主要包括：

• 用二进制流（Stream）代替原先的文本格式，一个连接可以并发多个流；
• 流支持优先级和对其他流的依赖；
• 流通过单独的窗口来控制流量；
• 流可以通过重置帧来中断前面发出的消息；
• 头部信息支持压缩（HPACK）；
• 除了客户端请求，服务器端也可以主动推送资源（例如页面中的各种元素资源）；
• TLS 规范中是可选的，但实现上 Chrome 和 Firefox 仅支持 TLS。

其中，HPACK 是采取基于字典（包括预置的静态字典和动态添加的动态字典）的压缩机制 + Haffman 编码进行编码。原来的域值现在只需要使用对应索引号即可。

相关规范

相关的两个 RFC：

• Hypertext Transfer Protocol version 2 - RFC7540
• HPACK - Header Compression for HTTP/2 - RFC7541

前者是 HTTP/2 主体内容的规范，后者是头部压缩技术（HPACK）的规范。

正式版本之前先后经过 0~17 等 18 次草稿。

一般，通过 h2-x 表示是协议的第几版本草稿，h2 默认表示正式版。

技术组

包括 IETF HTTP Working Group 和 IETF Httpbis。

前者是关于 HTTP 协议的官方机构；后者 2007 年成立，负责更新 HTTP/1.1 规范，是 RFC 7230 的提出者。

支持 HTTP/2 的项目

除了知名浏览器，其它项目包括 Apache HTTP Server 2.4.17+，Nginx，Chromium，curl，Jetty，Netty，Nodejs ，Wireshark等。

此外，部分国外网站也已经默认开启 HTTP/2 支持。

这里有 完整列表。

扩展阅读

• HTTP/2 Explained
• Nginx HTTP/2 White Paper