本文主要是介绍11丨性能脚本：用案例和图示帮你理解HTTP协议，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
当前使用得最为广泛的应用层协议就是HTTP了。我想了好久，还是觉得应该把HTTP协议写一下。
因为做性能测试分析的人来说，HTTP协议可能是绕不过去的一个槛。在讲HTTP之前，我们得先知道一些基本的信息。
HTTP（HyperText Transfer Protocol，超文本传输协议），显然是规定了传输的规则，但是它并没有规定内容的规则。
HTML（HyperText Marked Language，超文本标记语言），规定的是内容的规则。浏览器之所以能认识传输过来的数据，都是因为浏览器具有相同的解析规则。
希望你先搞清楚这个区别。
我们首先关注一下HTTP交互的大体内容。想了很久，画了这么一张图，我觉得它展示了我对HTTP协议在交互过程上的理解。
在这张图中，可以看到这些信息：
- 在交互过程中，数据经过了Frame、Ethernet、IP、TCP、HTTP这些层面。不管是发送和接收端，都必须经过这些层。这就意味着，任何每一层出现问题，都会影响HTTP传输。
- 在每次传输中，每一层都会加上自己的头信息。这一点要说重要也重要，说不重要也不重要。重要是因为如果这些头出了问题，非常难定位（在我之前的一个项目中，就曾经出现过TCP包头的一个option因为BUG产生了变化，查了两个星期，一层层抓包，最后才找到原因）。不重要是因为它们基本上不会出什么问题。
- HTTP是请求-应答的模式。就是说，有请求，就要有应答。没有应答就是有问题。
- 客户端接收到所有的内容之后，还要展示。而这个展示的动作，也就是前端的动作。在当前主流的性能测试工具中，都是不模拟前端时间的，比如说JMeter。我们在运行结束后只能看到结果，但是不会有响应的信息。你也可以选择保存响应信息，但这会导致压力机工作负载高，压力基本上也上不去。也正是因为不存这些内容，才让一台机器模拟成千上百的客户端有了可能。
如果你希望能理解这些层的头都是什么，可以直接抓包来看，比如如下示图：
从这个图中，我们就能看到各层的内容都是什么。当然了，这些都属于网络协议的知识范围，如果你有兴趣，可以去看一下《TCP/IP详解 卷1：协议》。
我们还是主要来说一说HTTP层的内容。同样，我希望通过最简单的示例的方式，给你解释一下HTTP的知识，而不是纯讲压力工具，或纯理论。
在我看来，只有实践的操作和理论的结合，才能真正的融会贯通。只讲压力工具而不讲原理，是不可能学会处理复杂问题的；空有理论没有动手能力是不可能解决实际问题的。
由于压力工具并不处理客户端页面解析、渲染等动作，所以，以下内容都是从协议层出发的，不包括前端页面层的部分。
JMeter脚本
在这里，我写了一个简单的HTTP GET请求（由于HTTP2.0在市场上还没有普及，所以这里不做特别说明的话，就是HTTP1.1）。
在前面的文章中，我已经写过了HTTP GET和POST请求。在这里只解释几个重要信息：
第一个就是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方法是怎么工作的呢？
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
也就是说，GET可以得到由URI请求（定义）的各种信息。同样的，其他方法也有清楚的规定。我们要注意的是，HTTP只规定了你要如何交互。它是交互的协议，就是两个人对话，如何能传递过去？小时候一个人手上拿个纸杯子，中间有根线，相互说话能听到，这就是协议。
第三个是Path，也就是请求的路径。这个路径是在哪里规定的呢？在我这个Spring Boot的示例中。
@RequestMapping(value = "pabcd")public class PABCDController {@Autowiredprivate PABCDService pabcdService;@Autowiredprivate PABCDRedisService pabcdRedisService;@Autowiredprivate 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; #打开gzipgzip_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知识之后，有些人肯定会有一种感觉，总觉得有什么内容没有讲到。对了，就是HTML。前面我们提到了，HTML是属于内容的规则，前端是个宏大的话题，以后有机会详聊。
其实对我们做性能测试的人来说，无需关心HTTP的内容，我们只要关心数据的流向和处理的逻辑就可以了。至于你是A业务还是B业务，在性能分析中都是一样的，逻辑仍然没有变化。
从性能测试的角度来看，如果你要模拟页面请求，最多也就是正常实现HTTP的方法GET、POST之类的。它发送和接收的内容，只要符合业务系统的正常流程就可以，这样业务才能正常运行。
比如说，前面提到的POST请求。如果我们发送了一段JSON。内容如下：
{"userNumber": "${Counter}","userName": "Zee_${Counter}","orgId": null,"email": "test${Counter}@dunshan.com","mobile": "18611865555"
}
代码中的Service负责接收User对象，同时转换它的是如下代码：
@Overridepublic 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的内容，只要能让业务跑起来即可。
这篇关于11丨性能脚本：用案例和图示帮你理解HTTP协议的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
