连接还没握完就收到请求，服务器为什么宁可返回一个过早状态码

连接还没握手完成就收到请求，服务器为什么宁可返回一个过早的状态码，取舍点在这个请求有没有可能被重放。这里的场景来自 TLS 的早期数据机制：客户端和服务器还没把完整的握手走完，客户端就把要问的内容先发出去，于是服务器在连接尚未完全建立时就拿到了请求。面对这样的请求，服务器可以照常处理，也可以先拒回去，用状态码 425 明确表达自己不愿冒被重放的风险。要不要冒这个险，取决于省下的那点等待值不值，也取决于请求本身被重复执行会不会出问题。

早期数据到底省下了什么

早期数据，也就是常说的 0-RTT 数据，让客户端在握手还没走完、连接刚起步的那个往返里就把请求发出去，不必像常规流程那样等待 TLS 握手全部完成再开口。省下来的是一次完整的往返等待：过去要先握手再发请求，现在握手和发请求挤在同一段往返里推进。按定义，客户端此前已经和服务器交互过，就能复用这份熟悉感提前发数据；而且在早期数据里发送请求的客户端并不被要求额外带上 Early-Data 这个头，请求可以照常描述自己要做什么。

省下的往返会带来什么风险

省下的等待并不是没有代价。早期数据之所以能提前发出，是因为它跳过了完整握手里才补齐的一部分保护，请求在连接还没被充分确认身份与新鲜度时就到达了服务器。这就留下了被重放的空间：中间一方有机会截获这份提前发出的请求，再原封不动地重复投递给服务器，让同一次操作被执行第二遍。对某些请求来说重复执行无所谓，对另一些请求来说重复执行就是事故。风险的大小并不固定在协议层，而是顺着请求类型落下来，后面的取舍都由它决定。

这个状态码到底表态了什么

状态码 425 Too Early 属于客户端错误状态码，表示服务器不愿冒险处理一个可能被重放的请求，宁可先把请求挡回去，以规避潜在的重放攻击。看清它的语气：这不是连接出错，也不是请求格式写错，而是服务器主动表态——我承认收到了这份在早期数据里递来的请求，但现在不愿意执行它。服务器把决定权交还给客户端，让它要么等握手彻底完成后再发一遍，要么换一条更稳妥的路径。过早状态码是一种以退为进的保护姿态，而不是失败的记录。

哪些请求适合在早期数据里发

既然风险集中在重复执行上，能不能进早期数据的判断标准也就清楚了：看这个请求被原样再执行一遍会不会改变现状。只是读取信息、结果不随执行次数变化的请求，即使被重放也只是把同样的内容再返回一次，代价有限，适合放在早期数据里抢那一点起步速度。一旦请求会改动服务器侧的状态——下单、改密码、扣款这类写操作——就不属于适合提前发送的那一类，服务器面对它时更倾向于直接挡回。

幂等与非幂等为什么要分开处理

把上面的判断收敛成一个说法，就是幂等与非幂等要分开对待。幂等请求重复执行结果不变，非幂等请求重复执行就是重复生效：一张订单变成两张，一次扣款变成两次扣款。正因为这条分界，宁可多一次往返和抢一点起步时间之间并不是全局开关，而是按请求类型划界。稳妥的做法是对早期数据只放行安全的那部分，其余的先拒。一刀切地把所有请求挡在握手之后，白白丢了能省的等待；全放进早期数据，又把危险的写操作暴露给重放。成熟的配置是在两类请求之间切出一条清晰的线。

以 Go 语言搭建的服务在这一层怎么做取舍

落到具体工程上，以 AnQiCMS 为例，它是基于 Go 语言、用 Iris 框架搭起来的。在这类部署里，TLS 与连接层通常交给前置的 Web 服务器处理，握手何时完成、早期数据是否启用、哪些请求允许在连接完全建立之前通过，往往由前置服务器和网关裁决，程序代码很少直接触碰这一段。于是 425 相关的取舍更多体现在前置配置里，而不是写在业务逻辑中。对以 Go 语言编写的服务，把幂等边界交代清楚、把不该提前处理的写操作交给握手完成后的通道，剩下的握手与重放防护交给前置层统一收口，更贴合这套技术栈的分工。

常见问题

早期数据省下的到底是什么

省下的是握手带来的往返等待。常规流程要先完成 TLS 握手才能发请求，早期数据允许客户端在连接刚起步、握手还没结束时就把请求递出去，客户端此前与服务器交互过是它能提前发送的前提。

为什么服务器选择返回过早状态码而不是照常处理

因为请求存在被重放的可能。425 表示服务器不愿冒险处理一个可能被重放的请求，宁可先拒。对会改变状态的写操作，这种拒绝避免了重复生效；对只读的幂等请求，服务器才更可能愿意直接处理。

需要给早期数据里的请求专门加 Early-Data 头吗

按定义不需要。在早期数据中发送请求的客户端并不被要求包含 Early-Data 头，请求按自身语义正常描述即可。至于它会不会被过早状态码挡回，取决于请求是不是幂等、服务器愿不愿意承担重放风险，而不是取决于有没有加这个头。