计算机网络： HTTP为什么说是无状态的？｜阿里巴巴算法面经解析

60 秒回答模板

HTTP 说无状态，是指从协议语义上看，服务端处理完一个请求后，不会因为 HTTP 协议本身自动记住这个客户端之前请求过什么、登录过谁、购物车里有什么。下一次请求到来时，服务端仍然把它当作一个独立请求处理，请求必须通过 URL、请求方法、请求头、Cookie、请求体、Token 等信息把处理所需上下文带过来。这里的“无状态”不是说服务端不能保存任何数据，也不是说 TCP 连接不能复用，而是说 HTTP 协议不维护请求之间的业务会话状态。实际 Web 系统需要登录、鉴权、购物车、风控、推荐等连续体验，所以会在应用层引入 Cookie、Session、JWT、Redis、数据库等机制来补状态。无状态的好处是服务端实例之间耦合低，负载均衡、水平扩容、故障切换更容易；代价是每次请求都要携带身份或上下文信息，业务状态需要额外设计和保护。

考点 无状态的精确定义

主线 请求自包含是关键

易错点 把无状态误解成服务端绝对不能保存数据库、缓存或 Ses…

深入解析

无状态的精确定义

HTTP 的无状态，是指 HTTP 协议本身不要求服务端为同一个客户端保存跨请求的业务上下文。一次请求包含方法、路径、头部、查询参数、请求体等信息，服务端据此生成响应；响应完成后，协议层不规定服务端必须记住这次请求对下一次请求意味着什么。因此，同一个用户连续请求两个接口，HTTP 并不会天然知道它们属于同一次登录会话或同一个购物流程。

请求自包含是关键

无状态协议要求每次请求尽量自包含，也就是服务端处理当前请求所需的信息，要么直接在请求里，要么能由请求携带的标识查到。比如访问订单详情时，请求里需要有订单标识和身份凭证；服务端不能只因为之前某次请求查过订单列表，就自动推断这次请求属于同一用户、同一订单。面试中要强调“独立处理当前请求”这一点，而不只是背一句“HTTP 不保存状态”。

Cookie、Session、JWT 是补状态

真实业务需要连续状态，所以应用层会额外设计状态机制。Cookie 是浏览器按域名保存并随请求自动携带的小段数据；Session 通常是服务端保存会话数据，客户端只带一个 sessionId；JWT 则常把身份和声明放在签名令牌里，由客户端每次携带。它们解决的是登录态、鉴权、用户上下文等问题，但这些都属于应用层方案，并不改变 HTTP 协议本身无状态的性质。

Keep-Alive 不等于有状态

HTTP Keep-Alive 或 HTTP/2 的连接复用，解决的是传输效率问题，即多个请求可以复用同一个 TCP 连接，减少握手和建连成本。它并不代表 HTTP 开始记住业务状态。即使两个请求走同一条连接，服务端也不会仅凭连接复用就知道用户已登录、购物车有哪些商品、上一步表单填写了什么。连接状态是网络传输层面的资源状态，业务状态是应用语义层面的上下文，两者不能混为一谈。

无状态带来的扩展性

无状态让服务端实例更容易水平扩展。因为单个 HTTP 请求只要携带足够信息，负载均衡器就可以把不同请求分发到不同机器，服务端不必强依赖某一台机器保存的本地会话。即使某台实例故障，请求也可以切到其他实例处理。大型系统通常把状态外置到数据库、缓存、对象存储或统一鉴权服务中，从而降低应用服务器之间的耦合。

业务补偿与工程代价

无状态并不意味着业务没有状态，而是状态需要显式建模。登录需要 Token 或 Session，购物车需要数据库或缓存保存条目，支付流程需要订单状态机，接口鉴权需要每次校验凭证。这样带来的代价是请求头可能变大、鉴权逻辑会重复执行、Session 存储和过期策略要设计、Token 泄露和刷新机制要处理。优秀回答应同时讲出无状态的收益和业务系统为此付出的补偿成本。

易错点

把无状态误解成服务端绝对不能保存数据库、缓存或 Session 数据。
把 Cookie、Session、JWT 说成 HTTP 协议自带的状态能力。
把 Keep-Alive 的 TCP 连接复用误认为 HTTP 记住了用户业务状态。
只背“HTTP 是无状态的”，却没有说明每个请求为什么必须自包含。
忽略无状态带来的扩展性收益，以及登录、购物车等业务补状态成本。

面试官追问

既然 HTTP 无状态，为什么网站还能记住我已经登录？

因为网站额外使用了应用层状态机制。常见做法是登录成功后给浏览器写入 Cookie，Cookie 中携带 sessionId 或 Token，之后浏览器每次请求都会带上它。服务端根据这个标识查询 Session、校验 JWT 或访问缓存，从而恢复用户身份。记住登录的是应用设计，不是 HTTP 协议自动记忆。

Session 会不会让 HTTP 变成有状态协议？

不会。Session 只是服务端应用保存会话数据的一种方案，HTTP 请求仍然是独立发送和处理的。客户端通常每次请求带 sessionId，服务端再根据这个 id 找到会话内容。状态存在应用服务器、缓存或数据库中，并不是 HTTP 协议规定或维护的跨请求状态。

Keep-Alive 和 HTTP 无状态是否矛盾？

不矛盾。Keep-Alive 表示多个 HTTP 请求可以复用同一个 TCP 连接，避免每次请求都重新建立连接。它保存的是连接资源，不保存登录用户、业务步骤、购物车内容等应用上下文。即使连接复用，每个请求仍需要携带足够的业务信息，服务端仍按独立请求处理。

无状态为什么适合分布式系统？

因为服务端不需要依赖本机内存保存某个客户端的历史上下文，负载均衡器可以把请求分发到任意健康实例。只要状态外置到 Redis、数据库、统一认证服务或由 Token 承载，不同实例都能处理同类请求。这降低了扩容、发布、故障切换的复杂度。

无状态会带来哪些安全或性能问题？

无状态通常要求每次请求携带身份凭证或上下文标识，因此需要防止 Cookie 被盗、Token 泄露、重放攻击和权限校验遗漏。性能上，服务端可能需要频繁校验 Token 或查询 Session 存储。工程上通常会配合 HTTPS、过期时间、刷新令牌、签名校验、缓存和统一鉴权中间件来控制风险。