从性能角度帮你理解HTTP协议

因为做性能测试分析的人来说，HTTP 协议可能是绕不过去的一个槛。在讲 HTTP 之前，我们得先知道一些基本的信息。

HTTP（HyperText Transfer Protocol，超文本传输协议），显然是规定了传输的规则，但是它并没有规定内容的规则。

 HTML（HyperText Marked Language，超文本标记语言），规定的是内容的规则。浏览器之所以能认识传输过来的数据，都是因为浏览器具有相同的解析规则。

我们首先关注一下 HTTP 交互的大体内容。想了很久，画了这么一张图，我觉得它展示了我对 HTTP 协议在交互过程上的理解。

在这张图中，可以看到这些信息：

1、在交互过程中，数据经过了 Frame、Ethernet、IP、TCP、HTTP 这些层面。不管是发送和接收端，都必须经过这些层。这就意味着，任何每一层出现问题，都会影响 HTTP 传输。

2、在每次传输中，每一层都会加上自己的头信息。这一点要说重要也重要，说不重要也不重要。重要是因为如果这些头出了问题，非常难定位（在我之前的一个项目中，就曾经出现过 TCP 包头的一个 option 因为 BUG 产生了变化，查了两个星期，一层层抓包，最后才找到原因）。不重要是因为它们基本上不会出什么问题。

3、HTTP 是请求 - 应答的模式。就是说，有请求，就要有应答。没有应答就是有问题。

4、客户端接收到所有的内容之后，还要展示。而这个展示的动作，也就是前端的动作。在当前主流的性能测试工具中，都是不模拟前端时间的，比如说 JMeter。我们在运行结束后只能看到结果，但是不会有响应的信息。你也可以选择保存响应信息，但这会导致压力机工作负载高，压力基本上也上不去。也正是因为不存这些内容，才让一台机器模拟成千上百的客户端有了可能。

如果你希望能理解这些层的头都是什么，可以直接抓包来看，比如如下示图：

从这个图中，我们就能看到各层的内容都是什么。

在我看来，只有实践的操作和理论的结合，才能真正的融会贯通。只讲压力工具而不讲原理，是不可能学会处理复杂问题的；空有理论没有动手能力是不可能解决实际问题的。由于压力工具并不处理客户端页面解析、渲染等动作，所以，以下内容都是从协议层出发的，不包括前端页面层的部分。

JMeter 脚本

在这里只解释几个重要信息：

第一个就是 Protocol。

这个当然重要。从“HTTP”这几个字符中，我们就能知道这个协议有什么特点。 HTTP 的特点是建立在 TCP 之上、无连接（TCP 就是它的连接）、无状态（后来加了 Cookies、Session 技术，用 KeepAlive 来维持，也算是有状态吧）、请求 - 响应模式等。

第二个是 Method 的选项 GET。

HTTP 中有多少个 Method 呢？我在这里做个说明。在 RFC 中的 HTTP 相关的定义中（比如 RFC2616、2068），定义了 HTTP 的方法，如下：GET、POST、PUT、PATCH、DELETE、COPY、HEAD、OPTIONS、LINK、UNLINK、PURGE。

GET 方法是怎么工作的呢？

GET 可以得到由 URI 请求（定义）的各种信息。同样的，其他方法也有清楚的规定。我们要注意的是，HTTP 只规定了你要如何交互。它是交互的协议，就是两个人对话，如何能传递过去？小时候一个人手上拿个纸杯子，中间有根线，相互说话能听到，这就是协议。

第三个是 Path，也就是请求的路径。

这个路径是在哪里规定的呢？在我这个 Spring Boot 的示例中。

   @RequestMapping(value = "pabcd")
    public class PABCDController {
        @Autowired
        private PABCDService pabcdService;
        @Autowired
        private PABCDRedisService pabcdRedisService;
        @Autowired
        private PABCDRedisMqService pabcdRedisMqService;
        @GetMapping("/redis_mq/query/{id}")
        public ResultVO<User> getRedisMqById(@PathVariable("id") String id) {
            User user = pabcdRedisMqService.getById(id);
            return ResultVO.<User>builder().success(user).build();
        }

看到了吧。因为我们定义了 request 的路径，所以，我们必须在 Path 中写上/pabcd/redis_mq/query这样的路径。

第四个是 Redirect，重定向。HTTP 3XX 的代码都和重定向有关，从示意上来看，如下所示。

用户发了个 URL A 到服务 A 上，服务 A 返回了 HTTP 代码 302 和 URL B。 这时用户看到了接着访问 URL B，得到了服务 B 的响应。对于 JMeter 来说，它可以处理这种重定向。

第五个是 Content-Encoding，内容编码。

它是在 HTTP 的标准中对服务端和客户端之间处理内容做的一种约定。当大家都用相同的编码时，相互都认识，或者有一端可以根据对端的编码进行适配解释，否则就会出现乱码的情况。

默认是 UTF8。但是我们经常会碰到这种情况。当我们发送中文字符的时候。比如下面的名字。

当我们发送出去时，会看到它变成了这种编码。如下图所示：

如果服务端不去处理，显然交互就错了。如下图所示：

这时，只能把配置改为如下：

我们这里用 GBK 来处理中文。就会得到正确的结果。

你就会发现现在用了正常的中文字符。在这个例子，有人选择用 URL 编码来去处理，会发现处理不了。这是需要注意的地方。

第六个是超时设置。在 HTTP 协议中，规定了几种超时时间，分别是连接超时、网关超时、响应超时等。

如下所示，JMeter 中可以设置连接和响应超时：

在工具中，我们可以定义连接和响应的超时时间。但通常情况下，我们不用做这样的规定，只要跟着服务端的超时走就行了。但在有些场景中，不止是应用服务器有超时时间，网络也会有延迟，这些会影响我们的响应时间。如果 HTTP 默认的 120s 超时时间不够，我们可以将这里放大。

在这里为了演示，我将它设置为 100ms。我们来看一下执行的结果是什么样。

从栈的信息上就可以看到，在读数据的时候，超时了。

超时的设置是为了保证数据可以正常地发送到客户端。做性能分析的时候，经常有人听到“超时”这个词就觉得是系统慢导致的，其实有时也是因为配置。

通常，我们会对系统的超时做梳理，每个服务应该是什么样的超时设置，我们要有全局的考量。比如说：

超时应该是逐渐放大的（不管你后面用的是什么协议，超时都应该是这个样子）。而我们现在的系统，经常是所有的服务超时都设置得一样大，或者都是跟着协议的默认超时来。

在压力小的时候，还没有什么问题，但是在压力大的时候，就会发现系统因为超时设置不合理而导致业务错误。

如果倒过来的话，你可以想像，用户都返回超时报错了，后端还在处理着呢，那就更有问题了。

而我们性能测试人员，都是在压力工具中看到的超时错误。如果后端的系统链路比较长，就需要一层层地往后端去查找，看具体是哪个服务有问题。所以在架构层级来分析超时是非常有必要的。

 第七个，在上图中，还有一个参数是客户端实现（Client Implementation）。其中有三个选项：空值、HTTPClient4、Java。

官方给出如下的解释。

JAVA： 使用 JVM 提供的 HTTP 实现，相比 HttpClient 实现来说，这个实现有一些限制，这个限制我会在后面提到。

HTTPClient4：使用 Apache 的 HTTP 组件 HttpClient 4.x 实现。

空值：如果为空，则依赖 HTTP Request 默认方法，或在jmeter.properties文件中的jmeter.httpsample定义的值。

用 JAVA 实现可能会有如下限制。

• 在连接复用上没有任何控制。就是当一个连接已经释放之后，同一个线程有可能复用这个已经释放掉的连接。
• API 最适用于单线程，但是很多设置都是依赖系统属性值的，所以都应用到所有连接上了。
• 不支持 Kerberos Authentication（这是一种计算机网络授权协议，用在非安全网络中，对个人通信以安全的手段进行身份认证）。
• 不支持通过 keystore 配置的客户端证书。
• 更容易控制重试机制。
• 不支持 Virtual hosts。
• 只支持这些方法： GET、POST、HEAD、OPTIONS、PUT、DELETE 和 TRACE。
• 使用 DNS Cache Manager 更容易控制 DNS 缓存。

第八个就是 HTTP 层的压缩。

我们经常会听到在性能测试过程中，因为没有压缩，导致网络带宽不够的事情。当我们截获一个 HTTP 请求时，你会看到如下内容。

这就是有压缩的情况。在我们常用的 Nginx 中，会用如下常见配置来支持压缩：

    gzip  on;   #打开gzip
    gzip_min_length 2k; #低于2kb的资源不用压缩
    gzip_comp_level 4; #压缩级别【1-9】值越大，压缩率就越高，但是CPU消耗也越多，根据我们在网上看到建议，大部分都是建议设置为中间4、5之类的，这里我建议大家根据自己的项目实际情况，在压力测试之后给出适合的值。
    gzip_types text/plain application/javascript;  #设置压缩类型
    gzip_disable "MSIE [1-6]\.";  # 禁用gzip的条件，支持正则

在 RFC2616 中，Content Codings 部分定义了压缩的格式 gzip 和 Deflate，不过我们现在看到的大部分都是 gzip。不过在压缩这件事情上，我们在压力工具中并不需要做什么太多的动作，最多也就是加个头。

 第九个就是并发。

在 RFC2616 中的 8.1.1 节明确说明了为什么要限制浏览器的并发。大概翻译如下，有兴趣的去读下原文：

• 少开 TCP 链接，可以节省路由和主机（客户端、服务端、代理、网关、通道、缓存）的 CPU 资源和内存资源。
• HTTP 请求和响应可以通过 Pipelining 在一个连接上发送。Pipelining 允许客户端发出多个请求而不用等待每个返回，一个 TCP 连接更为高效。
• 通过减少打开的 TCP 来减少网络拥堵，也让 TCP 有充足的时间解决拥堵。
• 后续请求不用在 TCP 三次握手上再花时间，延迟降低。
• 因为报告错误时，没有关闭 TCP 连接的惩罚，而使 HTTP 可以升级得更为优雅（原文使用 gracefully）。
• 如果不限制的话，一个客户端发出很多个链接到服务器，服务器的资源可以同时服务的客户端就会减少。

HTTPS 只是加了一个 S，就在访问中加了一层。

因为证书是个非常标准的产品，加在中间，就是加密算法和位数也会对性能产生影响。如果执行场景时报：javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake，就应该把证书也加载进来。

其实对我们做性能测试的人来说，无需关心 HTTP 的内容，我们只要关心数据的流向和处理的逻辑就可以了。

从性能测试的角度来看，如果你要模拟页面请求，最多也就是正常实现 HTTP 的方法 GET、POST 之类的。

它发送和接收的内容，只要符合业务系统的正常流程就可以，这样业务才能正常运行。

比如说，前面提到的 POST 请求。如果我们发送了一段 JSON。内容如下：

{
    "userNumber": "${Counter}",
    "userName": "Zee_${Counter}",
    "orgId": null,
    "email": "test${Counter}@dunshan.com",
    "mobile": "18611865555"
}

代码中的 Service 负责接收 User 对象，同时转换它的是如下代码：

@Override
    public String toString() {
        return "User{" +
            "id='" + id + '\'' +
            ", userNumber='" + userNumber + '\'' +
            ", userName='" + userName + '\'' +
            ", orgId='" + orgId + '\'' +
            ", email='" + email + '\'' +
            ", mobile='" + mobile + '\'' +
            ", createTime=" + createTime +
            '}';
    }

然后通过 Service 的 add 方法 insert 到数据库中，这里后面使用的 MyBatis：

    Boolean result = paRedisService.add(user);

而这些，都属于业务逻辑处理的部分，我们分析时把这个链路都想清楚才可以一层层剥离。

总结

对于 HTTP 协议来说，我们在性能分析中，主要关心的部分就是传输字节的大小、超时的设置以及压缩等内容。

在编写脚本的时候，要注意 HTTP 头部，至于 Body 的内容，只要能让业务跑起来即可。