HTTP 的全部工作，浓缩成一个模型就是四个字：一问一答。客户端发一个请求，服务器回一个响应，一问一答配成一对，一次 HTTP 对话就完成了。整个互联网上每天发生亿万次这样的问答，代理IP链路里的每趟转发也都是问答的传递。
这个模型简单到了极致，却撑起了整个万维网：每次网页刷新是一问一答，每次接口调用是一问一答，每次文件下载也是一问一答。理解了这个模型，HTTP 的其他细节就都有了挂靠的框架。
这篇讲请求响应模型：一次问答怎么配对、问答之间是否有关联、以及这个模型衍生出的几个重要特性。
一次问答的配对方式
请求与响应严格成对：客户端发一个请求，服务器必然回一个响应，不会多也不会少。请求里带着方法与路径，响应里带着状态码与内容，两端各说各话、各听各的，配对清晰、职责分明，这是 HTTP 通信最基本也最可靠的保证。
一问一答里的主动性
问答永远是客户端先开口：服务器不会主动推送内容，它只被动回应请求。所以想从网站拿数据，客户端必须自己发起请求；网站有更新，也要等客户端下次来问。这个「客户端主导」的设计，是 HTTP 模型的根本特征。
每问每答彼此独立
HTTP 里每一次问答都是独立事件：服务器不会记住你上一次问了什么，这一次的请求也不会自动带上之前的上下文。页面要分多次问答才能拼全（HTML 一次、图片又一次），它们之间靠客户端串联，服务器只负责逐次应答。
把问答模型再往实里想：打开一个网页，其实是一连串问答的组合——先问页面骨架，再问样式、脚本、图片，每个资源都是一次独立的请求与响应。网页显示得快不快，就看这一连串问答的总体表现，代理IP链路里每个问答都要经过转发层，链路质量直接影响整串问答的速度。
HTTP 的模型是一问一答：客户端发请求、服务器回响应，每对问答彼此独立，网页由一连串问答拼成。
问答模型的「问」有讲究：同样是要东西，有的是「给我看看」，有的是「帮我提交」——请求里那句动词决定了这次问答的性质，下一篇认识方法家族。
问答模型还有一个补充特性：一次问答不一定都成功。请求发出去可能石沉大海（超时），响应回来可能带着错误状态——但无论结果如何，「一问必有一答」的结构不变，服务器总会给出某种形式的回应，只是回应可能是错误说明而已。
把问答模型与代理IP场景连起来：走代理时，一问一答变成了两段——客户端与转发层一段、转发层与目标站一段。两段各自成问答、又首尾相接，链路慢往往就慢在中间这段额外问答的往返上，理解模型就能解释这类现象。
模型虽然简单，却衍生出了 HTTP 的全部生态——代理IP链路中见到的种种请求现象，都能回到这个模型里解释：方法定义问的方式，状态码定义答的结果，头部补充问答细节，版本优化问答的效率。先立住模型这个框架，后面每一个概念都能在这个框架里找到自己的位置。
把问答模型记成一句话：互联网上的一切内容获取，都是无数次一问一答的累积。代理IP链路中的每个请求也都是一问一答的组成部分，链路通畅时问答一气呵成，链路出问题时问答就会卡壳——观察问答在哪一步停下，代理IP链路的问题就定位在哪一环。