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

从比特币到区块链的未来

很早就想写一写区块链（Blocking Chain）技术，作为比特币等一系列应用背后最核心的技术，它的前景充满了各种可能和挑战。最近身边不少人感兴趣，正好总结下。

起源和背景

相比区块链，更多人都听说过比特币。其实最早 08 年的时候比特币就已经问世了，但真正流行起来还是在 10 年后的事情。其官方网站是 bitcion。发明人（传言代号为中本村的澳大利亚人）到目前为止尚无法确认身份，但是一个团队的概率较大。

比特币是一种概念金融货币。主要是希望解决已有金融货币系统的几个问题：

• 被掌控在发行机构手中；
• 自身的价值无法保证；
• 无法匿名化交易。

搞金融的人都能想到，实际上，要设计这么一套系统，最关键的还是一套强大的交易记录系统和中立的货币发行机制。

首先，这个系统要能中立、公正、无法被篡改地记录发生过的每一笔交易。对比已有的银行系统，可以看出，现在的银行机制作为第三方，是有代价的提供了这样的服务，即如果交易双方都相信银行的数据库，那么就没问题了。可是如果是世界范围内流通的货币呢？有哪个银行能让大家完全信任它？于是，需要有一套分布式的数据库，在世界范围内都可以访问，而且都无法去控制。这也就是区块链设计的目的。

货币的发行则是通过比特币的协议来规定的，总量必须控制，发行速度会自动调整。既然总量一定，那么单个比特币的价值肯定会随着承认比特币的实体经济的加入而水涨船高。发行速度的调整则避免了通胀或者滞涨的出现。

原理

区块链的基本原理其实十分简单。

首先假设存在一个 P2P 的数据库（这方面的技术相对成熟），剩下来就是大家如何决策去添加数据上来。只允许添加、不允许删除避免了作伪的可能性。这个数据库的结构是一个链，由一个个块组成，这也是其名字的来源。新的数据要加入，必须作为一个新的块来加入。而这个块能否加入，可以通过一些手段来检验出来。

具体到比特币如何使用了区块链技术。比特币将每十分钟内所有的交易都打包在一起，这些信息组成一个块。然后，网络中所有的成员都可以试图来找到一个合法的块（比如基于当前的块的信息，加上时间、id，加上某些其它有用信息等），然后进行一些 hash 计算，并且找到的结果还得满足一定条件（比如小于某个值）。一旦算出来就可以进行全网广播，大家拿到这个算出来的结果，进行正向验证，发现确实符合条件了，就承认你算出来了。

因为算出来的概率要从数学上进行保证，比如每十分钟内大概就刚好算出来一个。所以保证了区块链每十分钟增加一个块。算出来的这个人将获取得到这个时间内所有交易产生的管理费和协议固定发放的奖励费（目前是 25 比特币）。也即俗称的挖矿。

挖矿

五年前，挖矿还是一个很有前途的行业。但是现在，建议还是不要考虑了，因为从概率上说，由于当前参与挖矿的计算力实在过于庞大（已经超出了大部分的超算中心），获得比特币的收益已经眼看要 cover 不住电费了。特别那些想着用云计算虚机来挖矿的想法，意义确实不大了。

从普通的 CPU、到后来的 GPU、到后来的 asic 矿机、到现在的 asic 数据中心。短短数间，比特币矿机的技术走完了过去的计算机的历程，并且还颇有创新之处。确实是哪里有利益，哪里的技术就飞速发展！

有哥们当年去内蒙古用近乎白给的价格租了当地的机房，打着创业幌子搞挖矿，不知道今日身家几何！

很自然的，有人会想到，如果我有很强大的计算力，所有的块我都算出来了，那是不是就能破坏比特币网络。确实如此，基本上拿到 1/3 的计算力，比特别网络就存在被破坏的风险了；拿到 1/2，概率上就掌控整个网络了。

想想看，你可以一直不承认别人的计算结果，只承认自己的，从概率上风险是很大的。这里，要区别分布式系统里面的拜占庭将军问题，这里完全是概率意义，并非数学证明。

那么有没有办法防护呢？

除了尽量避免计算力放到同一个组织手里，没太好的办法，这是目前 pow （proof of work）的协议规定的。

也有人觉得为了算一个块，大部分计算力（特别到最后根本没算出来的）其实都浪费了。

有人提出用所谓的 pos，即大节点作为多个节点代理人的模式来节约计算力。那怎么选大节点？又容易导致“富则越富”问题。呵呵，这就是完全民主 vs 选举人制度嘛。

个人认为，无论 pow 还是 pos，都无法解决问题。要从根本上解决，得引入随机代理人制度，通过算法在某段时间内只让部分节点参加计算，然后要发放一部分“普世奖励”给所有在线节点。

安全

既然区块链一个可能的应用前景是金融系统，那么安全自然是讨论最多、挑战最多的话题。区块链的实现是开源的，基于了现有的成熟的密码学算法。但这是否就能确保其安全呢？

未必。有如下几个方面是很难逃避的。

首先是，攻击区块链系统是否是犯罪？攻击银行系统是要承担后果的。但是目前还没有任何法律保护区块链以及基于它的实现。

其次是软件实现的潜在漏洞是无法避免的。考虑到使用了几十年的 openssl 还带着那么低级的漏洞（heart bleeding），而且是源代码在大家眼皮底下。这背后曾经发生过啥，让人遐想连篇。金融系统自身到底有没有必要开源，也值得商榷。

另外，区块链所有交易都是公开可见的。搞大数据的人听了是不是开始激动起来了，呵呵，这里面能分析的东西还真不少，而且规模够大、影响力够大……

还有就是作为一套完全的分布式系统，区块链缺乏足够的调整机制，一旦运行起来，真的无人能控制。即使是让它变得更公平、更完善的修改，只要有部分既得利益者合起来反对，那就无法加入进去。这让比特币本身的价值也蒙上了一层阴影。

展望

无论如何，区块链确实是第一个试图做公开、中立、匿名化的分布式数据库的系统。它的出现，让大家意识到除了互联网这样的基础设施外，数据库系统也可以成为公共基础设施。而且像比特币这样的例子，给与了区块链更多的遐想空间。如果交易无法造价，信息无法造价，世界是不是会多了一些算法来保证的公平呢？这是又一次用技术给人类发展带来进步的福利。

不提这种去中心化的金融系统是否现实（个人认为至少 5-10 年后的事情了），在跨国交易、跨组织合作日益频繁的今天，区块链、比特币都是很好的一些尝试和参考。

集群负载均衡技术概述

集群负载均衡技术（Load Balancing）是目前互联网后端服务的关键技术，是互联网系统演化到现在这样巨大规模的基础。

客观地说，负载均衡是一个门槛相当不低的领域，已有技术主要包括硬件方案和软件方案。简单说，硬件方案性能好，但是昂贵；软件方案性能差，但是成本相对可控。

硬件方案代表为F5、Ctrix、A10、Redware 等 LB 厂商的产品，每年市场营收额高达百亿。

开源的软件实现方案也有不少，知名的包括 HAProxy、Nginx、LVS 等。

在实际大规模高性能的场景下，往往很难靠单一方案实现可靠的负载均衡服务。

很多 LB 厂家现在已经不再使用“负载均衡设备”这个术语了，改叫做应用分发（ADC、ADN）设备（甚至直接叫做 4-7 层交换机），但在这些设备中的最为基础和关键的技术仍然是对海量流量进行处理的负载均衡技术。

实际上，从客户端是否能感知或参与负载均衡的过程来区分，可以首先将负载均衡技术大概分为两大类：客户端可感知的负载均衡和客户端透明的负载均衡。当然，两类技术又可以进一步地结合起来使用。

客户端可感知负载均衡

顾名思义，客户端主动参与负载均衡过程，可以感知负载均衡存在。

典型的例子是一些客户端应用，需要动态获知服务地址。从这个意义上看，不少 P2P 应用都属于该范畴。

基本的过程可以为，客户端先向某个控制（Control）服务器发起请求，获取业务（Service）服务器地址（域名或者 IP 地址）的列表。获取列表成功后，本地按照某种均衡策略向这些业务服务器发出请求。

这样做的好处显而易见，可以降低对服务器端进行负载均衡的要求，甚至服务端可以不需要再进行负载均衡，简单资源池即可。

技术难点主要在于客户端和服务端之间的信息同步。比如业务服务器池调整后信息怎么及时更新到客户端；某些负载均衡策略需要获取实时服务器的状态信息，等等。

具体实现上，往往需要客户端和服务端进行一些配合。针对某些特定的业务场景，可以进行一些调整和优化，例如 Yahoo 就在某些互联网业务中使用了这种模式。

桌面时代的客户端往往受控性差，情况比较复杂，这种模式实现难度较大。

现在移动互联网发展起来后，客户端 APP 的可控性大大提高，比较看好这种模式的应用前景。

客户端透明负载均衡

客户端透明负载均衡实际上又包括很多层面的技术，这里都统归为一类。不同实现可能放在不同地方（运营商或者服务商等），但原理都是一致的，核心都是借用了“Overlay”的思想（计算机行业的所有问题，基本都可以通过引入新的层来实现）。

下面从客户端发出请求后的完成流程来看，可以在哪些步骤实现负载均衡。

DNS 层

首先，客户端会向某个业务服务器的域名发起请求，要先解析这个域名为具体的 IP 地址。

域名解析这块能做的事情很多，但大致上要么是运营商本地应答，要么运营商扔给服务商的域名服务器。

如果是前者（一般情况下）的话，运营商会通过本地 cache 进行查询，无命中则扔给上层域名服务或者服务商。

域名解析的过程直接决定了进行 LB 的效果。这里就有问题了，由于域名是由运营商进行维护答复的，一旦发生变化，服务商怎么去快速地调整呢，传统域名更新的方式可达数分钟甚至数小时的时延。

一种思路是跟运营商去谈，所有相关请求都服务商自己来处理或者怎么能合作进行快速更新；一种是将请求想办法绕开运营商，隧道给自己（又是一种 Overlay），腾讯的 HttpDNS 就是这个思路，域名解析不走传统 DNS 协议，而是通过 HTTP 请求来实现。

总结下，基于 DNS 的 LB 方式是比较简单直接，容易实现的，但是存在问题也不少，主要有多级 DNS 结构不可控，容易分布不均匀，和难以及时刷新等等。

IP 层

拿到 IP 之后，客户端可以发起请求到对应的 IP 地址，之后就等着接收到源地址为该 IP 的响应数据包。很自然的，可以在 LB 上替换掉这个地址，发给后端的真实服务池。这也是目前大量三层负载均衡器的基本原理。

实践中，前面挡一层 DNS 均衡，后面进行三层负载均衡，已经可以支持很大规模的场景了。

典型的，LVS 是这一类的软件方案，但具体实现上，LVS 支持三种模式：NAT（Network Address Translation）、DR（Direct Routing）、TUN（IP Tunneling）。NAT 就是把 LB 做 NAT 网关；DR 和 TUN 是想办法把流量转发给后端服务器，让后面服务器自己处理，形成三角路由。

首先，负载均衡器上会带有一个 VIP（用户看到的服务地址）和 DIP（用于探测后端服务的存活），后端真实服务器上会有 RIP。

NAT 模式下，请求和响应流量都经过负载均衡器，性能会差一些。

通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。

DR 模式下通过改写请求报文的目的 MAC 地址为某个真实服务器的 MAC（ARP 请求肯定不能自动响应了），将请求发送到真实服务器。而真实服务器将响应直接返回给客户。该模式扩展型号，但要求 LB 与真实服务器可以二层连通。这种模式因为性能好，用的很多。

TUN 是解决 DR 无法跨网络的问题，不是拿 MAC 做转发，而是封装完整包做 IP 转发，比 DR 处理要复杂。

此外，肯定要保证 Session 一致性，可以根据 IP 头和 TCP 头记录之前决策，保证流调度到同一台机器。实践中，支持十几台到数十台后端服务器比较合适。

应用层

用户访问资源需要通过 URI，一个 IP 地址上可能支持数个 URI，在三层均衡的同时，可以根据这些 URI 来制定具体的分发策略，比如访问 Front_IP:80/app1 的流量可能会被分配到 Back_IP1:80/app1；而到 Front_IP:80/app2 的流量被分配到Back_IP1:80/app2 等等。

这种应用层均衡，特点当然是最灵活，可以多级划分，但因为要看应用层的信息，计算复杂性大一些，对均衡器要求也比较高，很少有能做高性能的。

OpenStack Summit 2015 Tokyo 有感

本次峰会是 10.27 ~ 10.30，四天在东京的品川站附近召开，6000 多人参会，几百个主会 speak 和各个项目的 design summit。

因为要做一个有关容器和网络的 speak，所以，虽经波折，最终还是按时参加了峰会。业余玩社区确实挑战比较大。

整体感受是，时间很紧，内容很多，身体压力很大。虽然只挑了最核心最热门的话题去听，也是从早到晚急匆匆地从一个会场赶到另一个（好几个 building）。一天下来，疲劳的很。

社区，不只是技术

开源项目的成功，除了技术外，往往还有很多很重要的因素。

比如怎么运营社区，怎么跟商业公司合作，怎么处理各个团队的关系……

毫无疑问，OpenStack 到今天能这么火，在各个方面做得都是非常优秀的。

本届大会，基本上越大的主题演讲 topic 都越浅显一些，但是人满为患；design summit 则集中到具体项目进行设计的讨论，反而人气没那么旺。

参加的人员，技术人员仍然是主体，但是非技术人员也不少见。

云，其实本质上不是个技术的事情。呵呵呵~

容器和网络是热点

OpenStack 社区对容器还是很积极的一个主动拥抱态度，各个项目都在考虑虚拟化对象是容器的新场景。

实际上，无论是 Docker 系列，K8s、Mesos，都有一些相对完整的 solution，无需 IaaS 的支持，自己就可以玩得很好。

但 OpenStack 社区还是希望底下用自己，所以努力提供新的 API 来支持这些 solution。

两边的定位有 overlap，肯定会冲突。底层平台必须要主动考虑上层 workload，考虑应用特性。这个是生产关系决定的。

网络话题这次被广泛关注，大会报告中有好几个都在谈网络（包括 SDN 和 NFV）。这次来参会的公司也有不少是网络公司，不过技术上新的东西不多。

比较搞笑的是，这次峰会的超级用户奖颁给了 NTT（sponser 了现场的网络接入），然而 wifi 接入体验比较一般（本来多好的宣传机会！）。

两个值得关注的项目，kuryr 还有 ovs 自己搞的 ovn 等开始亮相社区，都挺有意思，定位思路很清晰，不像 Magnum，做起来的问题不大。

围绕 neutron，问题不少，但是老框架在这里，能周旋的余地很少。怎么能跟别的项目更好的集成，怎么提供更好的性能，都是很现实的问题。

强调下，云计算的技术基础是计算虚拟化，然而成功能否，根本取决于网络。

到现在还没意识到这点的，基本可以歇了。

比较遗憾的是，有一些传统网络厂商，没能很好的抓住云计算这波机会。亡羊补牢，为时未晚，还可以考虑抓紧时间布局物联网。

技术周期趋向成熟

基本上，新的项目 focus 的 scope 都圈得比较小。

很多人开始关注实际的部署和运维方面的一些问题（再次强调下我的观点，云环境中，ops 将变得比 dev 更重要！）。

这很正常，最多的 80% 的需求也是最基本的，剩下 20% 不好做，不是通用需求，但往往是差异化和体现技术实力的点。

很多人会松了口气，趋向成熟，意味着再也不用跟着后面折腾太多升级了。

成熟后怎么能再健康的发展下去，是每一个成功社区都会碰到的问题，现在已经有点由盛转衰的意味，虽然不明显。

国内力量不可小觑

market place，国内公司（特别创业公司）见到不少。除了传统方案和硬件厂商，就是日本本地企业和国内企业，甚至国内企业感觉比日本企业还多一些。

而且来的人好多，一下子就是好几十号人，庞大的队伍！

做应用的企业没见到……，不过有一些很有特色的小企业，比如 cumulix 啊、puppet、solinea 啊，哈哈哈~

这次本地报告也不少，竟然还出现了用日语讲报告的情况。

各种基于 OpenStack 的方案，各种特点。

乐观看，大家都尽量兼容 OpenStack，又努力做出自己的特色；悲观看，差异化和成长空间可能有限。

日本的文化和生活

日本是一个很有意思的地方，学习了东方和西方的文化，糅合在一起，难免有不少纠结的地方。

也许是意识到这种文化的缺位，对于传下来的和服啊、武士道啊、艺伎表演啊，就都十分重视。

但日本文化上其实是封闭的，现在年青一代很少愿意去接触外面的世界。整个日本社会就像是一个精密的大机器，每个人按照职责努力的工作。七八点上班，十一二点下班，很少有跳槽，很少有变化，压力太大，森严的规矩，老龄化……日本的年轻人，不容易！

生活成本低、贫富差距不大，这些西方社会普遍的特色，也造成了日本现在已经进入了高度稳定甚至停滞期。

云计算的第二个十年 -- IT 行业的新变化

如果从概念的提出（2006 年由 IBM、Google 联合提出）算起，云计算即将步入第二个十年。

在第一个十年里，云计算从被质疑到成为新一代 IT 标准，从单纯技术上的概念到影响到整个业务模式。

虽然到目前为止，还有很多不成熟的地方值得探索，但云计算在第一个十年里已经正式确立了它的地位，已经被广泛接受并实践。

在云时代的下一个十年里，IT 行业又会发生哪些变化呢？

ops 将变得比 dev 更重要

在过去，无论是企业还是个人市场，新产品的研发能力是最核心的，运营团队一贯被视为“第二梯队”。

造成这种局面的原因很复杂，根子上是基础设施的缺乏。大量的重复性、非标准化、非核心的研发任务，造成 dev 在整个生产链中的核心地位，造成运营团队话语权的缺失。

在云时代，随着基础设施服务的成熟和标准化，新产品研发的效率和复杂度将大大下降。反而是产品上线后，怎么应对不同时间、不同场景的需求变得更为重要。运营能力将直接决定云的质量。

所以，即使是研发团队，也一定要具备一定的运维能力。devops 的紧密结合，才能具备在云时代的快速应变能力。

PaaS 将变得比 IaaS 更重要

如果说 IaaS 是云计算一切服务的基础，那么 PaaS 将变成未来云计算服务的核心。

IaaS 的定位是提供基础架构能力，从整个云计算栈上看，无论是提供裸机、虚机还是容器，这只是对物理计算资源进行单纯的抽象和管理，并不具备任何面向业务属性。而 PaaS 则在基础架构的基础上进一步抽象计算资源为软件业务能力。

如果以盖房子为例子，IaaS 相当于提供了砖头和水泥。而 PaaS 则进一步的整合这些基础材料为墙板、横梁。显然，施工团队更喜欢直接用后者。

同时，由于 PaaS 更贴近应用，也具有更多话语权。

那么，比 PaaS 再上一层的 SaaS 是否更有优势呢？理论上是没错的，但是实际上在下一个十年里，公有 SaaS 成为主流的可能性不大。一方面是大量的企业的应用并不具有太强的通用性，需要定制化开发；另一方面是过度耦合到第三方服务的隐患。

私有 SaaS 会有，但是一定种类不会太多。办公类、娱乐类将成主体。

通用平台将越来越少

由于搭建和运维云成本的进一步降低，云将成为家家户户都可以创建的资源，面向公共服务的通用云平台将进一步集中，成为两三家的业务。

另外一方面，面向通用计算的云平台将很难获利。反而是某些具有特色服务的专有云将大量出现。

这些特色应该至少包括安全性、高性能、跟托管业务紧耦合的一些辅助服务，例如域名、CDN 等等。