SpringBoot配置Transfer-Encoding时小响应仍拆分为2个TCP包问题

产生原因 #

该现象是Servlet容器处理分块传输的默认逻辑导致，和TCP层本身无关：

• 当接口配置了Transfer-Encoding: chunked分块传输编码后，Spring Boot内置的Tomcat/Undertow等容器会采用先写响应头、后写响应体的逻辑：先输出所有响应头并执行flush操作，再序列化返回的业务对象、输出响应体并执行第二次flush操作。两次独立的flush操作会触发两次TCP报文发送，哪怕响应体体积极小也会拆分。
• 分块传输的设计本身不需要提前计算响应总长度，因此容器不会等待响应体序列化完成后合并头和体统一发送，是该场景下拆包的核心原因。

解决方案 #

方案1：禁用分块传输，显式指定Content-Length（最稳妥） #

针对需要避免拆包的接口，提前序列化响应体，计算总长度后设置Content-Length响应头，容器检测到该头存在时会自动禁用分块传输，合并响应头和响应体一次性发送，代码示例如下：

@PostMapping("/home/getMsg")
public ResponseEntity<byte[]> login() throws JsonProcessingException {
    ChunkedRsp rsp = new ChunkedRsp("aaa","bbb","ccc");
    // 序列化响应对象为字节数组
    byte[] body = new ObjectMapper().writeValueAsBytes(rsp);
    return ResponseEntity.ok()
            .contentType(MediaType.APPLICATION_JSON)
            .contentLength(body.length)
            .body(body);
}

方案2：调整容器响应缓冲区大小（全局生效） #

如果需要保留分块传输能力，仅希望小响应不拆包，可以调大内置容器的输出缓冲区大小，只要响应头+响应体的总大小小于缓冲区阈值，容器会将内容全部写入缓冲区后再一次性flush，不会拆分。以Tomcat为例，在application.yml中添加配置即可：

server:
  tomcat:
    output-buffer-size: 65536 # 可根据业务小响应的平均大小调整，单位为字节

方案3：开启TCP_NODELAY参数（辅助优化） #

如果确实需要保留分块传输的两次写逻辑，可以开启Socket的TCP_NODELAY参数禁用Nagle算法，减少小包发送延迟。该方案不会从根本上避免拆包，仅适合对延迟要求较高的场景。

内容的提问来源于stack exchange，提问作者SevenHu