Go语言API客户端侧时长测量疑问及TCP传输机制咨询

一、client.Do与io.ReadAll的核心行为 #

• client.Do(req)：仅在收到服务端的HTTP响应头后立即返回，此时响应体可能只传输了部分内容，甚至还未开始传输。因此elapsedBeforeBodyRead仅统计到响应头接收完成的时间，涵盖TCP握手、请求发送、服务端生成响应头及部分初始响应体的传输耗时，这也是它始终小于服务端elapsedServer的原因——服务端此时仍在处理响应体的生成与发送。
• io.ReadAll(res.Body)：会持续从响应体流中读取数据，直到收到TCP层的EOF信号（服务端关闭连接写端）。只有该方法完成时，客户端才确认整个响应体接收完毕，因此elapsedAfterBodyRead是包含完整网络传输时间的有效总API时长。

二、服务端json.NewEncoder.Encode的工作流程 #

Encode是流式写入操作，流程如下：

1. 先将HTTP响应头（如Content-Type: application/json）写入连接输出缓冲区；
2. 序列化传入的map对象，将JSON内容分批次写入缓冲区；
3. 当缓冲区满或序列化完成时，触发TCP发送操作，将数据推送给客户端；
4. 序列化完成后，服务端HTTP框架会在请求结束阶段关闭连接写端，向客户端发送EOF。

注意：你代码中的serverTXtime仅统计Encode方法的执行时间，但TCP发送缓冲区中可能仍有未发送的数据，这部分异步发送的耗时并未被elapsedServer统计。

三、客户端总时长比服务端多25ms的原因 #

这个时间差来自几个关键环节：

• TCP传输收尾延迟：服务端elapsedServer截止到Encode返回，但此时TCP发送缓冲区可能还有剩余数据未发送，服务端需等待客户端ACK确认后才完成连接收尾，这部分时间未被服务端统计，但客户端elapsedAfterBodyRead包含了等待剩余数据传输及接收FIN包的时间。
• 客户端TCP/HTTP处理开销：客户端收到数据后，需经过操作系统TCP栈处理、HTTP协议解析，再将数据从内核态拷贝到用户态供io.ReadAll读取，这部分切换与拷贝的开销会占用少量时间。
• 虚拟化层额外延迟：虚拟机环境下，宿主机与虚拟机之间的虚拟网络层（如NAT、虚拟网桥）会带来数据包转发的额外开销，这部分延迟仅被客户端的计时捕获，服务端本地计时不会包含。

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