# HTTP有哪些特点
30 秒速记
- 灵活可扩展：报文格式简单，加个头字段就能加功能（缓存、认证、
CORS都是这么长出来的） - 能传任意数据：文本、图片、视频都行，靠
Content-Type说明是什么 - 可靠传输：
HTTP/1.1、HTTP/2跑在TCP上，HTTP/3跑在QUIC上，「可靠」是指数据尽量完整有序送到，不是业务一定成功 - 请求 - 应答：客户端问，服务器答，服务器不能凭空主动推
- 无状态：每个请求互不相关，登录态靠
Cookie/Token每次自己带上
HTTP 是一个简单、灵活、无状态的应用层协议，模式是客户端发请求、服务器回响应。 灵活体现在报文就是一行起始行加一堆头字段，想加功能就加头，Cache-Control、Authorization 都是这么来的；它也不挑内容，JSON、图片、视频都能传，用 Content-Type 告诉对方是什么。可靠是借了底层 TCP 的光，保证字节不丢不乱，但连接超时、服务器返回 500 照样会发生。最常被追问的是无状态：服务器不会记得你上一个请求是谁，所以登录后每个请求都得带上 Cookie 或 Token，状态是应用自己补的。
HTTP是灵活可扩展的，可以任意添加头字段实现任意功能；HTTP是可靠传输协议，基于TCP/IP协议“尽量”保证数据的送达；HTTP是应用层协议，比FTP、SSH等更通用功能更多，能够传输任意数据；HTTP使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求；HTTP本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息
原理拆解： HTTP 规定应用层消息如何表达和交换，客户端先发送请求方法、目标、头字段及可选消息体，服务器再返回状态码、头字段和可选消息体。消息体可以承载文本、图片或结构化数据，其含义通常由 Content-Type 描述。新增头字段能够传递缓存、认证和内容协商等元数据，但通信双方不理解某个扩展字段时，不代表其对应功能一定生效。底层采用 TCP 时可获得有序、校验和重传能力，这仍不保证服务器必然处理成功。
最小验证： 输入为一个独立的资源请求，要验证请求—应答结构、内容类型表达和单次请求不依赖历史记录。
GET /api/profile?id=42 HTTP/1.1
Host: api.example
Accept: application/json
X-Trace-Id: 7f3a91
Connection: close
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 24
X-Trace-Id: 7f3a91
{"id":42,"name":"Ada"}
GET 和请求目标表达客户端意图，200 表达处理结果，Content-Type 说明响应体是 JSON，自定义 X-Trace-Id 展示头字段的扩展方式。预期服务端仅凭本次请求即可返回指定资料；若资源需要登录，本次请求还必须显式携带认证信息，不能假设服务器记得前一次请求。
边界与排查： “无状态”指协议不强制保存会话历史，不代表应用不能借助 Cookie、令牌或服务端会话构造状态。“可靠传输”也不等于业务成功：连接可能超时，服务器可能返回 500，响应还可能在客户端收到前中断。排查时应分层观察域名解析、连接建立、请求是否完整发出、响应状态码与消息体；只有传输完成且业务响应符合约定，才能判定一次调用成功。
面试官追问
追问 1登录成功后刷新个人中心又变成未登录，产品说 HTTP 应该记得我登录过，怎么解释？
HTTP 本身不记事，每个请求都是陌生人。能「记住登录」全靠请求带凭证：要么服务端下发 Cookie、浏览器自动带，要么前端把 Token 存起来每次放进 Authorization。刷新后丢登录，一般是 Token 只放在内存里，或者 Cookie 的 Domain / Path 没覆盖到这个接口。
追问 2要给每个请求加链路追踪 ID，改协议流程还是加个头？
加头就够了，比如 X-Trace-Id 或标准的 traceparent，这正是 HTTP 可扩展的用法。要确认网关、代理会透传这个头，有的代理会剥掉不认识的头，那追踪就断了。
追问 3有人说 HTTP 只能传文本，图片接口出错时没法返回 JSON，对吗？
不对。HTTP 的 body 就是一串字节，传什么都行，关键是 Content-Type 要和内容对上：正常返回 image/png，出错返回 application/json 加 4xx 状态码，前端先看状态码再决定按图片还是 JSON 处理。
追问 4支付回调超时了，网络同学说走的是 TCP，请求肯定到了，订单肯定处理了，对吗？
不对。TCP 只保证连接正常时字节完整有序，连接中途断了、服务器处理到一半崩了、响应回来时超时，这些它都兜不住。业务成功得看服务端的处理结果，回调场景一般靠对方重试加我方幂等去重来保证。
追问 5想让服务端在订单状态变化时主动通知前端，普通 HTTP 请求能做到吗？
普通的一问一答做不到，服务器没收到请求就没法回。常见做法是轮询、SSE（服务器保持一个响应不结束，持续往里写事件）或者 WebSocket。只需要服务端单向推，SSE 最省事，它本身还是 HTTP。
