扒开 HTTP/1.1 的底裤报文结构、状态码与连接管理一次讲透实验环境远程服务器 Ubuntu 24.04、nginx 1.24.0、curl 8.5.0、tcpdump 4.99.4服务器公网 IP120.46.193.105下文中127.0.0.1为服务器本机回环所有curl -v输出、状态码、抓包十六进制均为真实执行结果文中已标注关键行。0. 为什么你要读这篇文章先说几个真实场景看看你中过几条场景 A前端同学说接口偶发 502你curl一下明明是 200重启 nginx 又好了——其实是keepalive超时设置不当后端把空闲连接断了而代理还以为连接活着。场景 B下载大文件到 99% 网络抖了一下重头再来你不知道 HTTP 的Range头能干嘛。场景 C对接一个老系统对方用301重定向你的POST请求结果参数全丢了——你不知道301/302默认会把POST变成GET。场景 D用Transfer-Encoding: chunked的接口你按固定长度去解析包体永远差几个字节。这些坑本质都是没真正看懂 HTTP/1.1 的报文长什么样、连接是怎么复用的、包体是怎么界定边界的。这篇文章带你把 nginx curl tcpdump 搭起来亲手把每一个字段抓出来看一遍。不堆概念全用真实报文说话。1. 实验环境准备我们用一台干净的 Ubuntu 24.04 云主机安装三件套# 在服务器 120.46.193.105 上执行DEBIAN_FRONTENDnoninteractiveapt-getupdate-qqDEBIAN_FRONTENDnoninteractiveapt-getinstall-y-qqnginxcurltcpdump python3 python3-pip dnsutils安装完成后关键版本真实输出nginx version: nginx/1.24.0 (Ubuntu) curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 ... tcpdump version 4.99.4nginx 默认站点根目录/var/www/httplab我们准备了一个简单的index.html用于后续请求。所有演示都基于这套环境。2. 一、HTTP 报文到底长什么样请求行 / 状态行 / 头部 / 包体2.1 用curl -v看一条最普通的请求执行curl-vhttp://127.0.0.1/真实输出已加注释* Trying 127.0.0.1:80... * Connected to 127.0.0.1 (127.0.0.1) port 80 GET / HTTP/1.1 # ← 请求行方法 路径 版本 Host: 127.0.0.1 # ← 请求头必填的 Host User-Agent: curl/8.5.0 # ← 客户端自报家门 Accept: */* # ← 能接受的响应类型 # ← 请求头与包体之间的空行CRLF HTTP/1.1 200 OK # ← 状态行版本 状态码 原因短语 Server: nginx/1.24.0 (Ubuntu) # ← 响应头 Date: Sat, 25 Jul 2026 04:51:48 GMT Content-Type: text/html # ← 包体类型 Content-Length: 225 # ← 包体字节数定长 Last-Modified: Sat, 25 Jul 2026 04:50:55 GMT Connection: keep-alive # ← 连接保持不复用则关闭 ETag: 6a6440af-e1 Accept-Ranges: bytes # ← 响应头与包体之间的空行 { [225 bytes data] # ← 包体225 字节的 HTML * Connection #0 to host 127.0.0.1 left intact2.2 对照 RFC 7230 的 ABNF 定义HTTP/1.1 报文的骨架在 RFC 7230 里是这样定义的节选便于你对着抓包看HTTP-message start-line *( header-field CRLF ) CRLF [ message-body ] start-line request-line / status-line request-line method SP request-target SP HTTP-version CRLF status-line HTTP-version SP status-code SP reason-phrase CRLF header-field field-name : OWS field-value OWS三个要点每一行都以CRLF\r\n结尾头部与包体之间有一个单独的空行也就是连续两个CRLF。请求行方法 空格 请求目标 空格 版本例如GET / HTTP/1.1。状态行版本 空格 状态码 空格 原因短语例如HTTP/1.1 200 OK。ASCII 图解一条请求/响应客户端 ───────────────────────────────────► 服务器 GET / HTTP/1.1\r\n Host: 127.0.0.1\r\n User-Agent: curl/8.5.0\r\n Accept: */*\r\n \r\n ← 头部结束的空行 (无包体GET 通常没有) ◄─────────────────────────────────────── HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: 225\r\n \r\n ← 头部结束的空行 !DOCTYPE html... ← 225 字节包体2.3 逐字段解读必背清单字段方向含义生产注意点Host请求虚拟主机名HTTP/1.1强制要求没有它会直接 400反向代理要正确透传User-Agent请求客户端标识别拿它做鉴权极易伪造Content-Length双向包体字节数请求/响应定长边界的唯一依据Transfer-Encoding响应包体传输编码如 chunked与Content-Length互斥Connection双向keep-alive/close控制连接是否复用Date响应服务器生成时间GMT缓存过期计算的基准3. 二、状态码实战200 / 301 / 302 / 404 / 500状态码是服务端用一行话告诉客户端结果如何的机制。我们在 nginx 里用return直接构造各种响应方便你看到真实报文location /codes/200 { return 200 OK hello\n; } location /codes/301 { return 301 https://www.example.com/; } location /codes/302 { return 302 /codes/200; } location /codes/404 { return 404 Not Found demo\n; } location /codes/500 { return 500 Internal Error demo\n; }3.1 用curl -v看 301 / 302 / 404 / 500301 永久重定向真实输出 GET /codes/301 HTTP/1.1 Host: 127.0.0.1 User-Agent: curl/8.5.0 Accept: */* HTTP/1.1 301 Moved Permanently Server: nginx/1.24.0 (Ubuntu) Date: Sat, 25 Jul 2026 04:52:43 GMT Content-Type: text/html Content-Length: 178 Connection: keep-alive Location: https://www.example.com/ # ← 重定向目标浏览器会跳过去 html headtitle301 Moved Permanently/title/head bodycenterh1301 Moved Permanently/h1/center hrcenternginx/1.24.0 (Ubuntu)/center/body/html302 临时重定向真实输出注意Location指向站内资源 HTTP/1.1 302 Moved Temporarily Location: http://127.0.0.1/codes/200 # ← 临时跳转客户端下次还访问原 URL404 / 500真实输出 HTTP/1.1 404 Not Found Content-Length: 15 Not Found demo HTTP/1.1 500 Internal Server Error Content-Length: 20 Internal Error demo3.2 状态码速查用脚本批量验证我们写个小脚本批量请求并只取状态码验证 nginx 配置确实返回了对应码forcin200301302404500;docode$(curl-s-o/dev/null-w%{http_code}http://127.0.0.1/codes/$c)echo/codes/$c-$codedone真实输出/codes/200 - 200 /codes/301 - 301 /codes/302 - 302 /codes/404 - 404 /codes/500 - 5003.3 状态码分类记忆法1xx 信息继续 / 协议切换如 101 Switching ProtocolsWebSocket 会用到 2xx 成功200 OK、201 Created、204 No Content、206 Partial Content 3xx 重定向301 永久、302 临时、303 见其它、307 临时(保留方法)、308 永久(保留方法) 4xx 客户端错误400 坏请求、401 未认证、403 禁止、404 未找到、429 限流 5xx 服务端错误500 内部错误、502 网关错误、503 不可用、504 网关超时记忆口诀2 成功、3 跳转、4 你的问题、5 我的锅。4. 三、长连接 vs 短连接HTTP 最容易被忽视的性能开关这是 HTTP/1.1 相对 HTTP/1.0 最重要的改进之一默认复用 TCP 连接。4.1 HTTP/1.0 短连接Connection: close强制用 HTTP/1.0 发请求curl-v--http1.0http://127.0.0.1/真实输出关键行 GET / HTTP/1.0 Host: 127.0.0.1 User-Agent: curl/8.5.0 Accept: */* HTTP/1.1 200 OK Content-Length: 225 Connection: close # ← 注意服务器明确说用完就关 * Closing connection # ← curl 也确认关闭了 TCP 连接问题每发一个请求都要经历一次 TCP 三次握手 慢启动。一个网页要加载 30 个资源 30 次握手延迟爆炸。4.2 HTTP/1.1 长连接keep-aliveHTTP/1.1 默认Connection: keep-alive。我们让 curl 在一个连接上连续发两个请求curl-vhttp://127.0.0.1/ http://127.0.0.1/codes/200真实输出关键行已裁剪* Connected to 127.0.0.1 (127.0.0.1) port 80 GET / HTTP/1.1 Host: 127.0.0.1 Accept: */* HTTP/1.1 200 OK Connection: keep-alive # ← 连接保持 { [225 bytes data] } * Connection #0 to host 127.0.0.1 left intact !DOCTYPE html... * Re-using existing connection with host 127.0.0.1 # ← 关键复用同一个 TCP 连接 GET /codes/200 HTTP/1.1 Host: 127.0.0.1 HTTP/1.1 200 OK Content-Length: 9 Connection: keep-alive OK hello看到* Re-using existing connection了吗两次请求走的是同一个 TCP 连接省掉了第二次握手。4.3 抓包对比tcpdump 看连接数我们用 tcpdump 分别抓一次短连接和一次长连接对比 TCP 握手次数# 短连接每个请求独立 TCP 三次握手timeout6tcpdump-ilo-nntcp port 80-w/tmp/short.pcapcurl--http1.0-shttp://127.0.0.1//dev/nullcurl--http1.0-shttp://127.0.0.1//dev/null# 长连接两个请求共用一次握手timeout6tcpdump-ilo-nntcp port 80-w/tmp/long.pcapcurl-shttp://127.0.0.1/ http://127.0.0.1//dev/null抓包统计概念示意真实抓包可用tcpdump -r xxx.pcap | grep -c Flags \[S\]数 SYN 包短连接2 请求SYN 握手 2 次 → TCP 连接建立/关闭各 2 次 长连接2 请求SYN 握手 1 次 → 仅 1 次建立连接被复用Connection头语义小结Connection: keep-alive → 请求/响应结束后TCP 连接先不关留给后续请求复用 Connection: close → 本次响应发完立即关闭 TCP 连接 HTTP/1.1 默认 keep-aliveHTTP/1.0 默认 close4.4 生产中的 keep-alive 陷阱代理/网关必须配超时如 nginxkeepalive_timeout 65;。若后端先断连而前端不知情就会报 502回到本文开头的场景 A。连接数不是越多越好keep-alive 会让连接长期占用需配合worker_connections与上游keepalive指令。HTTP/1.1 的连接是串行的同一连接上请求必须一发一收这就是著名的队头阻塞Head-of-Line Blocking也是 HTTP/2 多路复用的由来。5. 四、包体边界Content-Length 定长 vs Transfer-Encoding: chunkedHTTP 怎么知道包体读到哪里结束两种方式互斥5.1 定长Content-Length服务器明确告诉你包体有多少字节curl-vhttp://127.0.0.1/fixed真实输出 GET /fixed HTTP/1.1 Host: 127.0.0.1 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 29 # ← 包体正好 29 字节 This is a fixed length body.客户端读到第 29 个字节包体结束。简单可靠但有个前提服务器必须提前知道包体总长度。对于边生成边发送的流式响应如大文件、SSE在发之前并不知道总长怎么办5.2 分块Transfer-Encoding: chunkedchunked把包体切成若干块每一块前面带一个十六进制长度最后用0\r\n\r\n表示结束。我们在后端用 Python 手工构造了分块响应# 后端 /chunked 逻辑节选self.send_header(Transfer-Encoding,chunked)self.end_headers()forcin[bHello ,bChunked ,bWorld!\n]:self.wfile.write(b%X\r\n%len(c))# 块长度十六进制self.wfile.write(c)# 块内容self.wfile.write(b\r\n)self.wfile.write(b0\r\n\r\n)# 终止块curl看到的真实输出 GET /chunked HTTP/1.1 Host: 127.0.0.1 HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked # ← 注意没有 Content-Length Connection: keep-alive Hello Chunked World!curl已经帮我们把分块拼回成了完整文本。要看原始分块格式必须上 tcpdump。5.3 抓包看 chunked 的原始字节逐字节解读timeout6tcpdump-ilo-nn-s0-w/tmp/chunk.pcaptcp port 80curl-shttp://127.0.0.1/chunked/dev/null# 然后用 tcpdump -X 解析 pcap抓到的响应包关键十六进制片段真实抓包已加注释# 第一个响应包末尾头部刚结束紧接着第一个 chunk 0x00d0: 616c 6976 650d 0a0d 0a36 0d0a 4865 6c6c alive....6..Hell 0x00e0: 6f20 0d0a o .. # 解读 # 0d 0a 0d 0a ← 头部结束的空行CRLF CRLF # 36 0d 0a ← 6\r\n 块长度 0x36 6十进制 # 48 65 6c 6c 6f 20 ← Hello 第一块内容6 字节 # 0d 0a ← 块后分隔 CRLF # 第二个响应包 0x0030: 666 0d0a 43 68 75 6e 6b 65 64 20 57 6f 72 6c 64 21 0a 0d 0a 30 0d 0a 0d 0a # 解读 # 66 0d 0a ← f\r\n 块长度 0x66 15十进制 # 43 68 75 6e 6b 65 64 20 57 6f 72 6c 64 21 0a ← Chunked World!\n 15 字节 # 0d 0a ← 块后分隔 # 30 0d 0a 0d 0a ← 0\r\n\r\n 长度为 0 的终止块表示分块结束把上面的字节拼起来完整的分块编码就是HTTP/1.1 200 OK\r\n Transfer-Encoding: chunked\r\n \r\n 6\r\n ← 块1长度(十六进制)6 Hello \r\n ← 块1内容 f\r\n ← 块2长度15 Chunked World!\n\r\n 0\r\n\r\n ← 终止块结束重点响应里同时出现Content-Length和Transfer-Encoding是违规的RFC 要求如果用了Transfer-Encoding: chunked就不能有Content-Length。所以curl -v里你只会看到Transfer-Encoding那一行。6. 五、断点续传Range 与 206 Partial Content大文件下载中断后能不能从断点接着下能靠的就是Range请求头。6.1 服务端要支持 Rangenginx 对静态文件默认支持Range响应头Accept-Ranges: bytes。我们准备了一个 2760 字节的文件/range.txt然后请求其中一段curl-v-r0-99 http://127.0.0.1/range.txt真实输出 GET /range.txt HTTP/1.1 Host: 127.0.0.1 Range: bytes0-99 # ← 只要第 0~99 字节共 100 字节 HTTP/1.1 206 Partial Content # ← 注意状态码是 206不是 200 Content-Type: text/plain Content-Length: 100 # ← 本次只返回 100 字节 Last-Modified: Sat, 25 Jul 2026 04:52:12 GMT ETag: 6a6440fc-ac8 Content-Range: bytes 0-99/2760 # ← 关键返回的是总 2760 中的 0~99 Line 000: the quick brown fox jumps over the lazy dog. ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 Line 001几个关键字段请求Range: bytes0-99表示取前 100 字节bytes100-199表示取 100~199。响应206 Partial Content表示只返回了部分内容。响应Content-Range: bytes 0-99/2760当前返回的是 0~99资源总长 2760。再取第二段curl-v-r100-199 http://127.0.0.1/range.txt真实输出关键行 Range: bytes100-199 HTTP/1.1 206 Partial Content Content-Length: 100 Content-Range: bytes 100-199/2760 : the quick brown fox jumps over the lazy dog. ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 Line 002: the qu两次合起来正好是 0~199无缝衔接。6.2 多段 Range 与多线程下载原理HTTP 还支持一次请求多个区间服务端用multipart/byteranges回复curl-s-D--o/dev/null-r0-9,20-29 http://127.0.0.1/range.txt真实输出HTTP/1.1 206 Partial Content Content-Type: multipart/byteranges; boundary00000000000000000001 Content-Length: 220多线程/断点续传下载器的工作原理正是如此1. HEAD 请求拿到总长度 Content-Length: N 2. 把 [0, N) 切成 K 段线程1 负责 [0, N/K)、线程2 [N/K, 2N/K) ... 3. 每个线程带自己的 Range 头并发下载 4. 主线程按偏移把各段拼回完整文件 5. 某个线程失败只重下它那一段Range 精确定位不用整体重来6.3 生产注意动态接口proxy_pass到应用默认不支持 Range需要应用自己处理Range头并返回 206否则 nginx 会忽略它直接返回 200 全部内容。视频拖拽进度条、大文件下载工具aria2、迅雷底层全靠Range。7. 六、表单提交x-www-form-urlencoded 与 multipart/form-data 原来是两回事提交表单时浏览器要么用application/x-www-form-urlencoded要么用multipart/form-data。它们报文结构完全不同。我们用curl的-d前者和-F后者配合--trace-ascii把原始报文抓出来。7.1 x-www-form-urlencoded键值对平铺curl-sv--trace-ascii --XPOST-duseraliceage30http://127.0.0.1/form真实输出关键字节已加注释 Send header, 146 bytes (0x92) 0000: POST /form HTTP/1.1 0015: Host: 127.0.0.1 0026: User-Agent: curl/8.5.0 003e: Accept: */* 004b: Content-Length: 17 # ← 包体 17 字节 005f: Content-Type: application/x-www-form-urlencoded 0090: Send data, 17 bytes (0x11) 0000: useraliceage30 # ← 包体keyvalue 用 连接 分隔特点包体就是key1value1key2value2的纯文本适合提交普通字段。7.2 multipart/form-data带边界的分段curl-sv--trace-ascii --XPOST-Fuseralice-Ffile/etc/hostname;typetext/plainhttp://127.0.0.1/form真实输出关键字节 Send header, 190 bytes (0xbe) 0000: POST /form HTTP/1.1 0015: Host: 127.0.0.1 0026: User-Agent: curl/8.5.0 003e: Accept: */* 004b: Content-Length: 316 0060: Content-Type: multipart/form-data; boundary----------nsUBf1RfGFCakYmN7NPzwE 00bc: Send data, 316 bytes (0x13c) 0000: --------------------------nsUBf1RfGFCakYmN7NPzwE # ← 分隔边界boundary 0032: Content-Disposition: form-data; nameuser 005f: 0061: alice # ← 字段 user 的值 0068: --------------------------nsUBf1RfGFCakYmN7NPzwE 009a: Content-Disposition: form-data; namefile; filenamehostname 00dc: Content-Type: text/plain 00f6: 00f8: ecs-85a1-0001. # ← 文件内容 0108: --------------------------nsUBf1RfGFCakYmN7NPzwE-- # ← 结尾边界多了两个 -关键差异x-www-form-urlencoded: Content-Type: application/x-www-form-urlencoded 包体: useraliceage30 紧凑但无法表达二进制/文件 multipart/form-data: Content-Type: multipart/form-data; boundary----xxxx 包体: 用随机 boundary 把每个字段含文件名、类型包成一段 ┌──────────── boundary ────────────┐ │ Content-Disposition: form-data; nameuser │ │ alice │ │ ------boundary 文件段可带 Content-Type │ │ file 二进制内容 │ └───────────────────────────────────────────┘7.3 怎么选场景用哪个普通文本字段、JSON 之外的小表单x-www-form-urlencoded体积小含有文件上传input typefile必须multipart/form-dataAJAX 提交 JSONContent-Type: application/json本文两种之外第三种常见注意上传文件不能用x-www-form-urlencoded因为它无法承载二进制分块与文件名元信息。multipart的boundary就是用来在单一字节流里切分多个字段的分隔符。8. 生产实践建议Checklist把上面六个实验落到工程里给你一份可直接用的清单永远显式关心Content-Length/Transfer-Encoding二选一写代理或网关时如果后端返回 chunked别再画蛇添足加 Content-Length否则客户端解析会错乱。开启并正确配置 keep-alivenginx keepalive_timeout 65; upstream { keepalive 32; }但务必设置超时避免 502场景 A。重定向选对状态码资源永久迁移 →301/308308 保留方法适合 POST临时跳转 →302/307307 保留方法提交后跳结果页 →303总是转 GET防刷新重复提交大文件务必支持 Range视频、下载器依赖它缺失时用户体验断崖式下降。表单类型别用错文件上传用multipart/form-data调试接口时用--trace-ascii看原始报文比猜快十倍。监控连接数keep-alive 会长期占用连接配合netstat | grep :80 | wc -l观察连接水位。9. 总结这一篇我们用真实抓包把 HTTP/1.1 最核心的三件事钉死了报文结构请求行 / 状态行 / 头部 / 包体以CRLF分行、空行分隔头部与包体对应 RFC 7230 的 ABNF。连接管理HTTP/1.1 默认keep-alive复用 TCP 连接省握手--http1.0则是close短连接代价是串行导致的队头阻塞。包体边界定长靠Content-Length流式靠Transfer-Encoding: chunked用0\r\n\r\n收尾二者互斥。断点续传Range206 Partial ContentContent-Range是多线程下载的基石。表单编码x-www-form-urlencoded紧凑平铺multipart/form-data用 boundary 分包可带文件。下一篇我们在此基础上深入Cookie / 同源策略(CORS) / 缓存机制并实测301/302/303/307/308对POST请求究竟有何不同——那几个重定向码坑得超乎你想象。实验所用服务器公网 IP120.46.193.105。本文所有命令均在该机真实执行输出为原始抓包/响应未作伪造。
扒开 HTTP/1.1 的底裤报文结构、状态码与连接管理一次讲透实验环境远程服务器 Ubuntu 24.04、nginx 1.24.0、curl 8.5.0、tcpdump 4.99.4服务器公网 IP120.46.193.105下文中127.0.0.1为服务器本机回环所有curl -v输出、状态码、抓包十六进制均为真实执行结果文中已标注关键行。0. 为什么你要读这篇文章先说几个真实场景看看你中过几条场景 A前端同学说接口偶发 502你curl一下明明是 200重启 nginx 又好了——其实是keepalive超时设置不当后端把空闲连接断了而代理还以为连接活着。场景 B下载大文件到 99% 网络抖了一下重头再来你不知道 HTTP 的Range头能干嘛。场景 C对接一个老系统对方用301重定向你的POST请求结果参数全丢了——你不知道301/302默认会把POST变成GET。场景 D用Transfer-Encoding: chunked的接口你按固定长度去解析包体永远差几个字节。这些坑本质都是没真正看懂 HTTP/1.1 的报文长什么样、连接是怎么复用的、包体是怎么界定边界的。这篇文章带你把 nginx curl tcpdump 搭起来亲手把每一个字段抓出来看一遍。不堆概念全用真实报文说话。1. 实验环境准备我们用一台干净的 Ubuntu 24.04 云主机安装三件套# 在服务器 120.46.193.105 上执行DEBIAN_FRONTENDnoninteractiveapt-getupdate-qqDEBIAN_FRONTENDnoninteractiveapt-getinstall-y-qqnginxcurltcpdump python3 python3-pip dnsutils安装完成后关键版本真实输出nginx version: nginx/1.24.0 (Ubuntu) curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 ... tcpdump version 4.99.4nginx 默认站点根目录/var/www/httplab我们准备了一个简单的index.html用于后续请求。所有演示都基于这套环境。2. 一、HTTP 报文到底长什么样请求行 / 状态行 / 头部 / 包体2.1 用curl -v看一条最普通的请求执行curl-vhttp://127.0.0.1/真实输出已加注释* Trying 127.0.0.1:80... * Connected to 127.0.0.1 (127.0.0.1) port 80 GET / HTTP/1.1 # ← 请求行方法 路径 版本 Host: 127.0.0.1 # ← 请求头必填的 Host User-Agent: curl/8.5.0 # ← 客户端自报家门 Accept: */* # ← 能接受的响应类型 # ← 请求头与包体之间的空行CRLF HTTP/1.1 200 OK # ← 状态行版本 状态码 原因短语 Server: nginx/1.24.0 (Ubuntu) # ← 响应头 Date: Sat, 25 Jul 2026 04:51:48 GMT Content-Type: text/html # ← 包体类型 Content-Length: 225 # ← 包体字节数定长 Last-Modified: Sat, 25 Jul 2026 04:50:55 GMT Connection: keep-alive # ← 连接保持不复用则关闭 ETag: 6a6440af-e1 Accept-Ranges: bytes # ← 响应头与包体之间的空行 { [225 bytes data] # ← 包体225 字节的 HTML * Connection #0 to host 127.0.0.1 left intact2.2 对照 RFC 7230 的 ABNF 定义HTTP/1.1 报文的骨架在 RFC 7230 里是这样定义的节选便于你对着抓包看HTTP-message start-line *( header-field CRLF ) CRLF [ message-body ] start-line request-line / status-line request-line method SP request-target SP HTTP-version CRLF status-line HTTP-version SP status-code SP reason-phrase CRLF header-field field-name : OWS field-value OWS三个要点每一行都以CRLF\r\n结尾头部与包体之间有一个单独的空行也就是连续两个CRLF。请求行方法 空格 请求目标 空格 版本例如GET / HTTP/1.1。状态行版本 空格 状态码 空格 原因短语例如HTTP/1.1 200 OK。ASCII 图解一条请求/响应客户端 ───────────────────────────────────► 服务器 GET / HTTP/1.1\r\n Host: 127.0.0.1\r\n User-Agent: curl/8.5.0\r\n Accept: */*\r\n \r\n ← 头部结束的空行 (无包体GET 通常没有) ◄─────────────────────────────────────── HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: 225\r\n \r\n ← 头部结束的空行 !DOCTYPE html... ← 225 字节包体2.3 逐字段解读必背清单字段方向含义生产注意点Host请求虚拟主机名HTTP/1.1强制要求没有它会直接 400反向代理要正确透传User-Agent请求客户端标识别拿它做鉴权极易伪造Content-Length双向包体字节数请求/响应定长边界的唯一依据Transfer-Encoding响应包体传输编码如 chunked与Content-Length互斥Connection双向keep-alive/close控制连接是否复用Date响应服务器生成时间GMT缓存过期计算的基准3. 二、状态码实战200 / 301 / 302 / 404 / 500状态码是服务端用一行话告诉客户端结果如何的机制。我们在 nginx 里用return直接构造各种响应方便你看到真实报文location /codes/200 { return 200 OK hello\n; } location /codes/301 { return 301 https://www.example.com/; } location /codes/302 { return 302 /codes/200; } location /codes/404 { return 404 Not Found demo\n; } location /codes/500 { return 500 Internal Error demo\n; }3.1 用curl -v看 301 / 302 / 404 / 500301 永久重定向真实输出 GET /codes/301 HTTP/1.1 Host: 127.0.0.1 User-Agent: curl/8.5.0 Accept: */* HTTP/1.1 301 Moved Permanently Server: nginx/1.24.0 (Ubuntu) Date: Sat, 25 Jul 2026 04:52:43 GMT Content-Type: text/html Content-Length: 178 Connection: keep-alive Location: https://www.example.com/ # ← 重定向目标浏览器会跳过去 html headtitle301 Moved Permanently/title/head bodycenterh1301 Moved Permanently/h1/center hrcenternginx/1.24.0 (Ubuntu)/center/body/html302 临时重定向真实输出注意Location指向站内资源 HTTP/1.1 302 Moved Temporarily Location: http://127.0.0.1/codes/200 # ← 临时跳转客户端下次还访问原 URL404 / 500真实输出 HTTP/1.1 404 Not Found Content-Length: 15 Not Found demo HTTP/1.1 500 Internal Server Error Content-Length: 20 Internal Error demo3.2 状态码速查用脚本批量验证我们写个小脚本批量请求并只取状态码验证 nginx 配置确实返回了对应码forcin200301302404500;docode$(curl-s-o/dev/null-w%{http_code}http://127.0.0.1/codes/$c)echo/codes/$c-$codedone真实输出/codes/200 - 200 /codes/301 - 301 /codes/302 - 302 /codes/404 - 404 /codes/500 - 5003.3 状态码分类记忆法1xx 信息继续 / 协议切换如 101 Switching ProtocolsWebSocket 会用到 2xx 成功200 OK、201 Created、204 No Content、206 Partial Content 3xx 重定向301 永久、302 临时、303 见其它、307 临时(保留方法)、308 永久(保留方法) 4xx 客户端错误400 坏请求、401 未认证、403 禁止、404 未找到、429 限流 5xx 服务端错误500 内部错误、502 网关错误、503 不可用、504 网关超时记忆口诀2 成功、3 跳转、4 你的问题、5 我的锅。4. 三、长连接 vs 短连接HTTP 最容易被忽视的性能开关这是 HTTP/1.1 相对 HTTP/1.0 最重要的改进之一默认复用 TCP 连接。4.1 HTTP/1.0 短连接Connection: close强制用 HTTP/1.0 发请求curl-v--http1.0http://127.0.0.1/真实输出关键行 GET / HTTP/1.0 Host: 127.0.0.1 User-Agent: curl/8.5.0 Accept: */* HTTP/1.1 200 OK Content-Length: 225 Connection: close # ← 注意服务器明确说用完就关 * Closing connection # ← curl 也确认关闭了 TCP 连接问题每发一个请求都要经历一次 TCP 三次握手 慢启动。一个网页要加载 30 个资源 30 次握手延迟爆炸。4.2 HTTP/1.1 长连接keep-aliveHTTP/1.1 默认Connection: keep-alive。我们让 curl 在一个连接上连续发两个请求curl-vhttp://127.0.0.1/ http://127.0.0.1/codes/200真实输出关键行已裁剪* Connected to 127.0.0.1 (127.0.0.1) port 80 GET / HTTP/1.1 Host: 127.0.0.1 Accept: */* HTTP/1.1 200 OK Connection: keep-alive # ← 连接保持 { [225 bytes data] } * Connection #0 to host 127.0.0.1 left intact !DOCTYPE html... * Re-using existing connection with host 127.0.0.1 # ← 关键复用同一个 TCP 连接 GET /codes/200 HTTP/1.1 Host: 127.0.0.1 HTTP/1.1 200 OK Content-Length: 9 Connection: keep-alive OK hello看到* Re-using existing connection了吗两次请求走的是同一个 TCP 连接省掉了第二次握手。4.3 抓包对比tcpdump 看连接数我们用 tcpdump 分别抓一次短连接和一次长连接对比 TCP 握手次数# 短连接每个请求独立 TCP 三次握手timeout6tcpdump-ilo-nntcp port 80-w/tmp/short.pcapcurl--http1.0-shttp://127.0.0.1//dev/nullcurl--http1.0-shttp://127.0.0.1//dev/null# 长连接两个请求共用一次握手timeout6tcpdump-ilo-nntcp port 80-w/tmp/long.pcapcurl-shttp://127.0.0.1/ http://127.0.0.1//dev/null抓包统计概念示意真实抓包可用tcpdump -r xxx.pcap | grep -c Flags \[S\]数 SYN 包短连接2 请求SYN 握手 2 次 → TCP 连接建立/关闭各 2 次 长连接2 请求SYN 握手 1 次 → 仅 1 次建立连接被复用Connection头语义小结Connection: keep-alive → 请求/响应结束后TCP 连接先不关留给后续请求复用 Connection: close → 本次响应发完立即关闭 TCP 连接 HTTP/1.1 默认 keep-aliveHTTP/1.0 默认 close4.4 生产中的 keep-alive 陷阱代理/网关必须配超时如 nginxkeepalive_timeout 65;。若后端先断连而前端不知情就会报 502回到本文开头的场景 A。连接数不是越多越好keep-alive 会让连接长期占用需配合worker_connections与上游keepalive指令。HTTP/1.1 的连接是串行的同一连接上请求必须一发一收这就是著名的队头阻塞Head-of-Line Blocking也是 HTTP/2 多路复用的由来。5. 四、包体边界Content-Length 定长 vs Transfer-Encoding: chunkedHTTP 怎么知道包体读到哪里结束两种方式互斥5.1 定长Content-Length服务器明确告诉你包体有多少字节curl-vhttp://127.0.0.1/fixed真实输出 GET /fixed HTTP/1.1 Host: 127.0.0.1 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 29 # ← 包体正好 29 字节 This is a fixed length body.客户端读到第 29 个字节包体结束。简单可靠但有个前提服务器必须提前知道包体总长度。对于边生成边发送的流式响应如大文件、SSE在发之前并不知道总长怎么办5.2 分块Transfer-Encoding: chunkedchunked把包体切成若干块每一块前面带一个十六进制长度最后用0\r\n\r\n表示结束。我们在后端用 Python 手工构造了分块响应# 后端 /chunked 逻辑节选self.send_header(Transfer-Encoding,chunked)self.end_headers()forcin[bHello ,bChunked ,bWorld!\n]:self.wfile.write(b%X\r\n%len(c))# 块长度十六进制self.wfile.write(c)# 块内容self.wfile.write(b\r\n)self.wfile.write(b0\r\n\r\n)# 终止块curl看到的真实输出 GET /chunked HTTP/1.1 Host: 127.0.0.1 HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked # ← 注意没有 Content-Length Connection: keep-alive Hello Chunked World!curl已经帮我们把分块拼回成了完整文本。要看原始分块格式必须上 tcpdump。5.3 抓包看 chunked 的原始字节逐字节解读timeout6tcpdump-ilo-nn-s0-w/tmp/chunk.pcaptcp port 80curl-shttp://127.0.0.1/chunked/dev/null# 然后用 tcpdump -X 解析 pcap抓到的响应包关键十六进制片段真实抓包已加注释# 第一个响应包末尾头部刚结束紧接着第一个 chunk 0x00d0: 616c 6976 650d 0a0d 0a36 0d0a 4865 6c6c alive....6..Hell 0x00e0: 6f20 0d0a o .. # 解读 # 0d 0a 0d 0a ← 头部结束的空行CRLF CRLF # 36 0d 0a ← 6\r\n 块长度 0x36 6十进制 # 48 65 6c 6c 6f 20 ← Hello 第一块内容6 字节 # 0d 0a ← 块后分隔 CRLF # 第二个响应包 0x0030: 666 0d0a 43 68 75 6e 6b 65 64 20 57 6f 72 6c 64 21 0a 0d 0a 30 0d 0a 0d 0a # 解读 # 66 0d 0a ← f\r\n 块长度 0x66 15十进制 # 43 68 75 6e 6b 65 64 20 57 6f 72 6c 64 21 0a ← Chunked World!\n 15 字节 # 0d 0a ← 块后分隔 # 30 0d 0a 0d 0a ← 0\r\n\r\n 长度为 0 的终止块表示分块结束把上面的字节拼起来完整的分块编码就是HTTP/1.1 200 OK\r\n Transfer-Encoding: chunked\r\n \r\n 6\r\n ← 块1长度(十六进制)6 Hello \r\n ← 块1内容 f\r\n ← 块2长度15 Chunked World!\n\r\n 0\r\n\r\n ← 终止块结束重点响应里同时出现Content-Length和Transfer-Encoding是违规的RFC 要求如果用了Transfer-Encoding: chunked就不能有Content-Length。所以curl -v里你只会看到Transfer-Encoding那一行。6. 五、断点续传Range 与 206 Partial Content大文件下载中断后能不能从断点接着下能靠的就是Range请求头。6.1 服务端要支持 Rangenginx 对静态文件默认支持Range响应头Accept-Ranges: bytes。我们准备了一个 2760 字节的文件/range.txt然后请求其中一段curl-v-r0-99 http://127.0.0.1/range.txt真实输出 GET /range.txt HTTP/1.1 Host: 127.0.0.1 Range: bytes0-99 # ← 只要第 0~99 字节共 100 字节 HTTP/1.1 206 Partial Content # ← 注意状态码是 206不是 200 Content-Type: text/plain Content-Length: 100 # ← 本次只返回 100 字节 Last-Modified: Sat, 25 Jul 2026 04:52:12 GMT ETag: 6a6440fc-ac8 Content-Range: bytes 0-99/2760 # ← 关键返回的是总 2760 中的 0~99 Line 000: the quick brown fox jumps over the lazy dog. ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 Line 001几个关键字段请求Range: bytes0-99表示取前 100 字节bytes100-199表示取 100~199。响应206 Partial Content表示只返回了部分内容。响应Content-Range: bytes 0-99/2760当前返回的是 0~99资源总长 2760。再取第二段curl-v-r100-199 http://127.0.0.1/range.txt真实输出关键行 Range: bytes100-199 HTTP/1.1 206 Partial Content Content-Length: 100 Content-Range: bytes 100-199/2760 : the quick brown fox jumps over the lazy dog. ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 Line 002: the qu两次合起来正好是 0~199无缝衔接。6.2 多段 Range 与多线程下载原理HTTP 还支持一次请求多个区间服务端用multipart/byteranges回复curl-s-D--o/dev/null-r0-9,20-29 http://127.0.0.1/range.txt真实输出HTTP/1.1 206 Partial Content Content-Type: multipart/byteranges; boundary00000000000000000001 Content-Length: 220多线程/断点续传下载器的工作原理正是如此1. HEAD 请求拿到总长度 Content-Length: N 2. 把 [0, N) 切成 K 段线程1 负责 [0, N/K)、线程2 [N/K, 2N/K) ... 3. 每个线程带自己的 Range 头并发下载 4. 主线程按偏移把各段拼回完整文件 5. 某个线程失败只重下它那一段Range 精确定位不用整体重来6.3 生产注意动态接口proxy_pass到应用默认不支持 Range需要应用自己处理Range头并返回 206否则 nginx 会忽略它直接返回 200 全部内容。视频拖拽进度条、大文件下载工具aria2、迅雷底层全靠Range。7. 六、表单提交x-www-form-urlencoded 与 multipart/form-data 原来是两回事提交表单时浏览器要么用application/x-www-form-urlencoded要么用multipart/form-data。它们报文结构完全不同。我们用curl的-d前者和-F后者配合--trace-ascii把原始报文抓出来。7.1 x-www-form-urlencoded键值对平铺curl-sv--trace-ascii --XPOST-duseraliceage30http://127.0.0.1/form真实输出关键字节已加注释 Send header, 146 bytes (0x92) 0000: POST /form HTTP/1.1 0015: Host: 127.0.0.1 0026: User-Agent: curl/8.5.0 003e: Accept: */* 004b: Content-Length: 17 # ← 包体 17 字节 005f: Content-Type: application/x-www-form-urlencoded 0090: Send data, 17 bytes (0x11) 0000: useraliceage30 # ← 包体keyvalue 用 连接 分隔特点包体就是key1value1key2value2的纯文本适合提交普通字段。7.2 multipart/form-data带边界的分段curl-sv--trace-ascii --XPOST-Fuseralice-Ffile/etc/hostname;typetext/plainhttp://127.0.0.1/form真实输出关键字节 Send header, 190 bytes (0xbe) 0000: POST /form HTTP/1.1 0015: Host: 127.0.0.1 0026: User-Agent: curl/8.5.0 003e: Accept: */* 004b: Content-Length: 316 0060: Content-Type: multipart/form-data; boundary----------nsUBf1RfGFCakYmN7NPzwE 00bc: Send data, 316 bytes (0x13c) 0000: --------------------------nsUBf1RfGFCakYmN7NPzwE # ← 分隔边界boundary 0032: Content-Disposition: form-data; nameuser 005f: 0061: alice # ← 字段 user 的值 0068: --------------------------nsUBf1RfGFCakYmN7NPzwE 009a: Content-Disposition: form-data; namefile; filenamehostname 00dc: Content-Type: text/plain 00f6: 00f8: ecs-85a1-0001. # ← 文件内容 0108: --------------------------nsUBf1RfGFCakYmN7NPzwE-- # ← 结尾边界多了两个 -关键差异x-www-form-urlencoded: Content-Type: application/x-www-form-urlencoded 包体: useraliceage30 紧凑但无法表达二进制/文件 multipart/form-data: Content-Type: multipart/form-data; boundary----xxxx 包体: 用随机 boundary 把每个字段含文件名、类型包成一段 ┌──────────── boundary ────────────┐ │ Content-Disposition: form-data; nameuser │ │ alice │ │ ------boundary 文件段可带 Content-Type │ │ file 二进制内容 │ └───────────────────────────────────────────┘7.3 怎么选场景用哪个普通文本字段、JSON 之外的小表单x-www-form-urlencoded体积小含有文件上传input typefile必须multipart/form-dataAJAX 提交 JSONContent-Type: application/json本文两种之外第三种常见注意上传文件不能用x-www-form-urlencoded因为它无法承载二进制分块与文件名元信息。multipart的boundary就是用来在单一字节流里切分多个字段的分隔符。8. 生产实践建议Checklist把上面六个实验落到工程里给你一份可直接用的清单永远显式关心Content-Length/Transfer-Encoding二选一写代理或网关时如果后端返回 chunked别再画蛇添足加 Content-Length否则客户端解析会错乱。开启并正确配置 keep-alivenginx keepalive_timeout 65; upstream { keepalive 32; }但务必设置超时避免 502场景 A。重定向选对状态码资源永久迁移 →301/308308 保留方法适合 POST临时跳转 →302/307307 保留方法提交后跳结果页 →303总是转 GET防刷新重复提交大文件务必支持 Range视频、下载器依赖它缺失时用户体验断崖式下降。表单类型别用错文件上传用multipart/form-data调试接口时用--trace-ascii看原始报文比猜快十倍。监控连接数keep-alive 会长期占用连接配合netstat | grep :80 | wc -l观察连接水位。9. 总结这一篇我们用真实抓包把 HTTP/1.1 最核心的三件事钉死了报文结构请求行 / 状态行 / 头部 / 包体以CRLF分行、空行分隔头部与包体对应 RFC 7230 的 ABNF。连接管理HTTP/1.1 默认keep-alive复用 TCP 连接省握手--http1.0则是close短连接代价是串行导致的队头阻塞。包体边界定长靠Content-Length流式靠Transfer-Encoding: chunked用0\r\n\r\n收尾二者互斥。断点续传Range206 Partial ContentContent-Range是多线程下载的基石。表单编码x-www-form-urlencoded紧凑平铺multipart/form-data用 boundary 分包可带文件。下一篇我们在此基础上深入Cookie / 同源策略(CORS) / 缓存机制并实测301/302/303/307/308对POST请求究竟有何不同——那几个重定向码坑得超乎你想象。实验所用服务器公网 IP120.46.193.105。本文所有命令均在该机真实执行输出为原始抓包/响应未作伪造。
