Mahimahi: Accurate Record-and-Replay for HTTP
Abstract：
本文介绍了Mahimahi，它是一个框架，用于记录来自基于HTTP的应用程序的流量，并在模拟的网络条件下对其进行重放。
文章内容：
我们通过以下方式评估Mahimahi：（1）分析500个站点上的HTTP / 1.1，SPDY和QUIC的性能，（2）使用Mahimahi理解这些协议不理想的原因，（3）开发Cumulus，一种云 基于浏览器的设计，旨在克服这些问题，使用Mahimahi通过扩展其外壳之一来实现Cumulus并对其进行评估，（4）使用Mahimahi来评估多个性能指标（页面加载时间和速度指标）上的HTTP多路复用协议， （5）描述其他人如何使用Mahimahi。
1 I NTRODUCTION
HTTP是当今客户端-服务器应用程序最常用的通信协议。
在受控的实验条件下评估这些应用程序的性能非常有用。 例如，浏览器开发人员可能希望评估对其文档对象模型（DOM）和JavaScript解析器的更改如何影响网页加载时间，而网络协议设计者可能希望了解QUIC等新的多路复用协议对应用程序级别的影响。 类似地，移动应用程序开发人员可能希望为不同无线网络上的用户交互确定用户感知的等待时间。
Mahimahi 框架可记录来自使用HTTP的应用程序的流量，然后在模拟的网络条件下重现该流量。可以与任何基于HHTP或HTTPS的应用程序共同使用。
Mahimahi与其他流记录和重现工具差别：
精度：处理多服务器的WEB应用时，为每个记录流时连接的服务器创建一个单独server.
Isolation：将其流量与主机其他系统分开，可以运行多个shell实例，不互相干扰。
可组合性与可扩展性：mahimahi为一组UNIX shells，用户在每个shell中运行客户端二进制文件，RecordShell允许用户记录其中产生的任何进程的所有HTTP通信。ReplayShell使用模拟应用程序服务器的本地服务器重播记录的内容。为了模拟网络状况，Mahimahi包括模拟固定网络传播延迟的DelayShell和模拟固定链路容量和可变容量的LinkShell。shell可以相互嵌套，用户可以模拟任意网络配置。mahimahi中shell的修改和增加十分简单。
使用mahimahi对网络多路复用协议进行评估。比较HTTP，SPDY,QUIC，发现三种协议均不理想。理解三种协议的缺点：web页面的source-level object dependencies使请求序列化。解决每个依赖关系需要一个RTT。
基于以上结论和发现，提出Cumulus，一个提高HTTP应用性能的系统（尤其对于长时间延迟路径）。Cumulus有两个组件： “Remote Proxy”在云服务器，“Local Proxy”在用户计算机运行的缓存HTTP的代理。Cumulus的页面加载时间不会随RTT增加而下降。
2 R ELATED W ORK
2.1 Record-and-replay tools
主流网页记录和重放工具： Google’s web-page-replay and Telerik’s Fiddler。所有来自浏览器的HTTP请求被发送到代理服务器，转发到对应原始服务器，响应也通过代理服务器。
缺点：<1>不满足Web应用的多服务器特性。
<2>不提供隔离性。模拟的网络环境（连接速率，连接延迟，DNS配置，代理地址）会影响主机上其他进程。
2.2 Emulation Frameworks
mahimahi使用 LinkShell和DelayShell，用户可以通过修改LinkShell改变网络中的算法。
mahimahi可以在模拟网络条件下记录和重现任何HTTP 客户-服务器应用。局限在于只能模仿一个连接到任意数量服务器的物理客户端。mahimahi支持客户端到所有服务器和多个客户端的共享链路，支持多路传输协议（如MPTCP）。不能模拟任意网络拓扑。
3 M AHIMAHI
mahimahi由4个UNIX shell组成。用户可在每个shell内运行二进制文件，每个shell在启动前创建一个网络namespace，一个网络namespace逻辑上是一个网络栈的拷贝。具有自己的路由，防火墙规则和网络设备。独立的namespace减少对主机其他部分的破坏。
RecordShell记录所有HTTP流。
ReplayShell 重放记录的HTTP内容。
DelayShell将所有来自shell的包按用户指定数量延迟。
LinkShell 根据用户指定的packet-delivery trace发送包模拟网络链路
四个shell在一个主机运行并且可以相互组合
3.1 RecordShell
RecordShell记录HTTP数据并将其以结构化格式存储在磁盘上，以供后续重播。 在启动时，RecordShell会在主机上生成一个中间人代理，以存储和转发于RecordShell中运行的应用程序之间的所有HTTP通信。 为了透明地运行，RecordShell添加了一个iptable规则，该规则将所有TCP流量从RecordShell内转发到中间人代理。
当RecordShell中的应用程序尝试连接到服务器时，它将连接到代理。 然后，代理建立与应用程序的TCP连接，使用SO ORIGINAL DST套接字选项确定连接的服务器地址。并代表应用程序连接到服务器。
运行在代理上的HTTP解析器捕获通过它的流量，以解析HTTP请求和来自TCP段的响应。
解析完一个HTTP请求及其相应的响应后，代理将请求与相关联响应写入磁盘。 在记录会话结束时，一个记录的目录由一组文件组成，每个文件代表在该会话期间的一对HTTP请求和响应。
使用相似方法处理SSL流量，将SSL连接拆分为两个部分。
3.2 ReplayShell
ReplayShell也在测试机器上运行，通过RecordShell记录内容模拟服务器端。通过为每个不同IP地址创建一个Apache 2.2.22服务器模拟多服务器场景。每个服务器使用Apache的mod ssl模块处理HTTPS流量。
为了透明独立的运行，ReplayShell为每个Apache服务器分配与记录中相同的IP和端口。
所有客户端请求均由ReplayShell的服务器处理，每台服务器都可以读取记录的所有内容。
每台服务器都使用Apache的mod_rewrite模块将所有传入请求重定向到CGI脚本。（每个server对应一个CGI脚本）
每个服务器上的CGI脚本将每个传入的HTTP请求与记录中所有请求-响应对进行比较，以找到匹配的请求并返回相应的响应。
传入的请求可能会受到客户端应用程序中存在的本地状态（例如，时间敏感的查询字符串参数）的影响，并且可能与任何记录的请求都不完全匹配。 我们使用匹配试探法来处理此类请求，该试探法要求请求的某些部分必须完全匹配，同时允许其他部分具有一定程度的不符合。
我们希望Host和User-Agent标头字段以及所请求的资源（没有查询字符串）与存储记录中的请求中相应值完全匹配。 如果记录中有多个请求在这些属性上匹配，则算法选择其查询字符串与传入查询字符串具有最大公共子字符串的请求。
3.3 DelayShell
DelayShell仿真具有固定的最小单向延迟的链接。
运行在DelayShell中的应用程序的所有数据包都存储在数据包队列中。
为在每个方向上通过链路的数据包维护一个单独的队列。
数据包到达时，将为其分配一个发送时间（delivery time），该时间是其到达时间与用户指定的单向延迟之和。
数据包在发送时间，将包从队列中发送。 在每个数据包的基础上强制执行固定的延迟。
3.4 LinkShell
LinkShell使用数据包传递trace来模拟链接，能够模拟时变链接（例如蜂窝链接）和具有固定链接速率的链接。
当数据包到达时，它将被放置在上行链路或下行链路数据包队列中。
LinkShell是trace驱动的，根据相应的数据包传递trace从每个队列释放数据包。
trace中的每一行都表示一个数据包传递：在仿真中发送MTU大小的数据包的时间。 每次代表传递1500个字节的能力。
因此，跟踪文件中的一行可以对应于大小为1500字节的几个数据包的发送。 如果在机会瞬间字节不可用，则会浪费发送机会。
LinkShell支持实时显示网络使用情况和每个数据包排队的延迟，从而对应用程序和网络协议的性能提供几乎即时的反馈。
<1>上行链路和下行链路容量根据pkt-delivery trace来计算的，而每个方向上的网络使用情况都是基于客户端应用程序尝试发送或接收的数据量。
<2>每个数据包的排队延迟是根据每个数据包保留在LinkShell的上行链路或下行链路队列中的时间计算的。
4 N OVELTY
4.1 Multi-server emulation for greater accuracy
在replayshell中模拟多服务器情况。
实验：不同方法与实际网络加载时间比较
4.2 Isolation
每个shell创建一个新namespace。避免相互影响。
可重现性。
保真度。收集数据开销低。
可组合性与可扩展性。