JMeter中Java与HttpClient4实现发送字节数差异及Java实现发送字节为0原因咨询

嘿，我来帮你拆解这个遇到的JMeter问题！先从Java实现的工作原理说起，再解释Sent bytes计数为0的原因，顺便也提一下HttpClient4报错的小细节。

一、JMeter里Java HTTP请求的底层逻辑 #

你用的Java实现（也就是JMeter的Java HTTP Request采样器），底层是靠JDK自带的java.net.HttpURLConnection来干活的，和HttpClient4用的Apache HttpClient库完全是两套东西：

• 它是Java原生的HTTP客户端，不用额外装第三方库，依赖JDK自己的网络栈，轻量化很多；
• 默认就带了一些优化，比如连接复用（有自己的连接池）、自动处理3xx重定向这些，这些默认行为和Apache HttpClient的配置思路不太一样；
• 碰到大请求体（比如你这1MB的JSON），它会自动选合适的传输模式——要么固定长度流，要么分块传输，不会傻乎乎把整个请求体都塞进内存里，这点对大请求很友好。

二、为啥Java实现的Sent bytes是0？ #

首先得明确：JMeter的Sent bytes是采样器主动捕获并记录的发送字节数，不是操作系统层面实际发送的字节数。出现0的情况，主要有这几个原因：

1. 统计范围不一样
   HttpClient4会把所有发送的字节都算上——包括HTTP头和1MB的请求体，所以你看到Sent bytes:1112854正好对应这个大小。但Java采样器的统计逻辑有点“偷懒”，默认可能只统计请求头，或者在流传输的情况下，没去统计请求体的字节。因为请求体是通过OutputStream直接写到底层socket里的，JMeter没去拦截这部分数据来统计。
2. 流传输的统计限制
   你发1MB的JSON时，HttpURLConnection自动用了流模式发送请求体（避免占内存），这种情况下JMeter的Java采样器没法准确抓到实际发送的请求体字节数。从你的采样结果看，Headers size in bytes是151，但Sent bytes是0，说明这个版本的采样器在这种场景下连请求头的统计都没做好，属于实现上的小bug。
3. 旧版本JMeter的已知问题
   你用的是2019年的JMeter版本，那个时候Java HTTP采样器的Sent bytes统计确实有bug，碰到大请求体的流传输场景，就会出现统计为0的情况。但你别担心，实际请求是发出去了的——毕竟响应码是200，服务端也返回OK了，只是JMeter没统计对而已。

三、顺便说下HttpClient4的报错 #

你碰到的Software caused connection abort: socket write error，一般是因为HttpClient4的socket配置（比如发送缓冲区大小、超时时间）和服务端的网络设置不匹配，导致发大请求体的时候连接被中断了。而HttpURLConnection的默认配置更适配通用场景，所以成功发出去了。

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