经验分享：如何将成人网站性能提升20倍

色情业是个大行业。互联网上没有多少网站的流量能和最大的色情网站相匹敌。

要搞定这巨大的流量很难。更困难的是，在色情网站上提供的很多内容都是低延迟的实时流媒体而不是简单的静态视频。但是对于所有碰到过的挑战，我很少看到有搞定过它们的开发人员写的东西。所以我决定把自己在这方面的经验写出来。

问题是什么？

几年前，我正在为当时全世界访问量排名26的网站工作 — 这里不是说的色情网站排名，而是全世界排名。

当时，该网站通过RTMP(Real Time Messaging protocol)协议响应对色情流媒体的请求。更具体地说，它使用了Adobe的FMS(Flash Media Server)技术为用户提供实时流媒体。基本过程是这样的：

1. 用户请求访问某个实时流媒体
2. 服务器通过一个RTMP session响应，播放请求的视频片段

因为某些原因，FMS对我们并不是一个好的选择，首先是它的成本，包括了购买以下两者：

1. 为每一台运行FMS的服务器购买Windows的版权
2. 大约4000美元一个的FMS特定版权，由于我们的规模，我们必须购买的版权量数以百计，而且每天都在增加。

所有这些费用开始不断累积。撇开成本不提，FMS也是一个比较挫的产品，特别是在它的功能方面（我过一会再详细说这个问题）。所以我决定抛弃FMS，自己从头开始写一个自己的RTMP解析器。

最后，我终于把我们的服务效率提升了大约20倍。

开始

这里涉及到两个核心问题：首先，RTMP和其他的Adobe协议及格式都不是开放的，这就很难使用它们。要是对文件格式都一无所知，你如何能对它进行反向工程或者解析它呢？幸运的是，有一些反向工程的尝试已经在公开领域出现了（并不是Adobe出品的，而是osflash.org，它破解了一些协议），我们的工作就是基于这些成果。

注：Adobe后来发布了所谓的“规格说明书”，比起在非Adobe提供的反向工程wiki和文档中披露的内容，这个说明书里也没有啥新东西。他们给的规格说明书的质量之低劣达到了荒谬的境地，近乎不可能通过该说明书来使用它们的库。而且，协议本身看起来常常也是有意做成具有误导性的。例如：

1. 他们使用29字节的整形数。
2. 他们在协议头上所有地方都采用低地址存放最高有效字节(big endian)的格式，除了在某一个字段（而且未标明）上采用低地址存放最低有效字节(little endian)的格式。
3. 他们在传输9K的视频时，不惜耗费计算能力去压缩数据减少空间，这基本上是没意义的，因为他们这么折腾一次也就是减少几位或几个字节，对这样的一个文件大小可以忽略不计了。

还有，RTMP是高度以session为导向的，这使得它基本上不可能对流进行组播。理想状态下，如果多个用户要求观看同一个实时视频流，我们可以直接向他们传回指向单个session的指针，在该session里传输这个视频流（这就是组播的概念）。但是用RTMP的话，我们必须为每一个要求访问特定流的用户创建全新的一个实例。这是完全的浪费。