3、HTTP协议基础：请求与响应模型、常见状态码、Header与Body、Keep-Alive机制

做压测这么多年，我见过太多人上来就怼并发，结果连HTTP协议都没搞明白。说白了，你连请求是怎么发出去的、服务器怎么回你的都不清楚，那压测结果就是一堆废纸。今天咱们就把HTTP协议这块硬骨头啃下来。

3.1 请求与响应模型：一问一答的规矩

HTTP协议本质上就是个「你问我答」的模型。客户端发个请求，服务器给个响应。就这么简单。但这里有个关键点——每次请求都是独立的，服务器不会记住你上次说了啥。

我记得刚入行那会儿，有个同事死活想不通：为什么登录成功后刷新页面又让我登录？其实就是因为HTTP本身是无状态的。每次请求都是「初次见面」，服务器根本不认识你。

来看一个典型的请求-响应流程：

客户端 → 发送请求（包含方法、路径、Header、Body）
服务器 → 处理请求
服务器 → 返回响应（包含状态码、Header、Body）
客户端 → 解析响应，渲染页面或处理数据

嗯，这里要注意：一个请求对应一个响应，没有例外。如果你发现发了请求没收到响应，那要么是网络断了，要么是服务器挂了，要么就是超时了。

3.2 常见状态码：服务器在说什么？

状态码就是服务器给你的「暗号」。我建议你至少记住以下几类：

状态码	含义	我的经验
200	请求成功	最理想的结果，压测中90%以上应该是这个
301/302	重定向	我在项目中遇到过，压测脚本没处理重定向，结果一直报错
400	请求参数错误	多半是你传的参数不对，检查Header和Body
401	未授权	没带Token或者Token过期了
403	禁止访问	有权限但没资格，比如IP被限制了
404	资源不存在	路径写错了，或者接口被删了
500	服务器内部错误	服务器炸了，压测时出现这个要重点关注
502/503	网关/服务不可用	服务器过载了，压测常见现象

3.3 Header与Body：请求的「身份证」和「行李」

Header就像是请求的身份证，告诉服务器你是谁、你想干什么。Body则是你带的行李，里面装着具体的数据。

常见的Header字段：

• Content-Type：告诉服务器Body的格式，比如application/json、application/x-www-form-urlencoded
• Authorization：携带Token或认证信息
• User-Agent：标识客户端类型，压测时建议改成真实浏览器的值
• Cookie：携带会话信息
• Accept：告诉服务器你期望的响应格式

我个人习惯在压测脚本里把Header写得清清楚楚。你想想看，如果漏了Content-Type，服务器可能根本解析不了你的Body。

Body的常见格式：

• JSON格式：最常用，结构清晰，适合复杂数据
• 表单格式：key1=value1&key2=value2，简单直接
• 纯文本/二进制：上传文件时用

// 一个典型的POST请求示例
POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer xxxxxx

{
  "username": "test",
  "password": "123456"
}

3.4 Keep-Alive机制：别老重新握手

Keep-Alive，说白了就是让TCP连接别那么快断开。你想想看，每次请求都重新建立TCP连接，三次握手四次挥手，多浪费时间啊。

我记得有一次压测一个高并发接口，TPS死活上不去。后来发现是Keep-Alive没开，每次请求都新建连接。开了之后，TPS直接翻了一倍。

Keep-Alive的工作原理：

• 客户端在Header里加Connection: keep-alive
• 服务器处理完请求后，不关闭连接
• 客户端可以复用这个连接发下一个请求
• 连接空闲一段时间后自动关闭

在压测脚本里，我建议你一定要开启Keep-Alive。除非你测的就是短连接场景，否则别关。

3.5 本章知识体系

下面这张图帮你梳理了HTTP协议的核心知识点，建议保存下来随时看：

好了，HTTP协议基础就讲这么多。记住一句话：压测脚本写得好不好，很大程度上取决于你对协议的理解深不深。别急着上手写代码，先把这些基础吃透。