官方文档解释：
$request_time
request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client
腾讯云文档日志说明：
响应时间（毫秒），指节点从收到请求后响应所有回包再到客户端所花费的时间 |
|---|
从以上两个解释大概能看出都是发送到客户端的时间，客户端一般理解为访问的用户，用户接收到所有包就是下载完了文件，那么这个时间是不是就可以理解为用户下载的时间呢？
让我们来看下面这个实例：
用户反馈是不是下载速度过快，并给出这样的两条日志
用户下载速度的计算方式是：response_length * 8.0 / 1024.0 / 1024.0 / ($request_time/ 1000.0)
如果这个$request_time时间真的网民下载所有包的时间，那么这个计算方式并没有问题，然而上述公式的计算结果约为1000Mbps！！
再根据UA能看出第一条日志使用的终端为Redmi Note 7 Pro，这是一个4G手机，理论的网速最大也只有300Mbps，那么问题出在了哪里呢？
重新审视用户的计算公式：response_length * 8.0 / 1024.0 / 1024.0 / ($request_time/ 1000.0)
response_length：发送的字节数，单位byte，最后计算结果为bps（bit/s）单位的话要乘8没有问题（1byte=8bit）
连续除以两个1024，这是单位转换，将B转为MB，也没有问题
$request_time在括号里除以1000，是将ms转为s，也没有问题
那么排除掉所有可能，就是你了，$request_time
让我们做个简单的试验
1.准备环境
新建一个域名并配置加速，并在域名下建一个10M的文件，抓取下载查看实际的下载时间与日志比对
2.开始测试
抓取测试
对应日志3.分析与结论
从上述简单的测试中能看出实际的下载时间在7s左右，但是日志中记录的$request_time只有5s多，相差很大
现在我们已经明显得知$request_time的时间并非用户的实际下载时间了，也就说明文档中解释的client（客户端）并非终端的用户，因此日志中的$request_time并不能被用来计算下载速度。
