nginx源码层面探究request_time、upstream_response_time、upstream_connect_time与upstream_header_time指标具体含义

🚀 优质资源分享 🚀

学习路线指引（点击解锁）	知识定位	人群定位
🧡 Python实战微信订餐小程序 🧡	进阶级	本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。
💛Python量化交易实战💛	入门级	手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

背景概述

最近计划着重分析一下线上各api的HTTP响应耗时情况，检查是否有接口平均耗时、99分位耗时等相关指标过大的情况，了解到nginx统计请求耗时有四个指标：request_time、upstream_response_time、upstream_connect_time与upstream_header_time，在查找资料的过程中，发现无论是nginx官方文档还是热心网友们的分享，都并没有让自己感觉特别详细、明白地说清楚了这四个指标详细具体含义的资料，于是自己动手探究了一番nginx源码，尝试从其中找出这4个指标的代码级别具体含义。
特别说明：本文代码分析基于nginx 1.10.0版本，从源码层面分析一次完整HTTP请求log中request_time、upstream_response_time、upstream_connect_time与upstream_header_time四个指标的具体含义，本文中得出的相应结论仅基于个人学习、研究所得，非权威结论，如有不当之处欢迎指正、一起探讨。

一次完整HTTP请求/响应的各耗时阶段拆分

首先详细拆分一下一个完整HTTP请求(非keep alive)生命周期的多个阶段（以下C指代客户端，N指代nginx服务器，S指代上游server）：

1. C向N发起TCP三次握手建立连接成功，C开始向N通过TCP发送HTTP请求具体数据(header/body…)
2. N开始接收到C发送的数据到全部接收完成
3. N作为代理向S发起TCP三次握手并建立连接成功，N开始向S发送HTTP数据
4. S开始接收N发送的数据并全部接收完成
5. S业务代码根据业务规则进行处理完成并生成HTTP响应结果
6. S开始将响应结果发送给N
7. N开始接收响应结果并接收header部分完成
8. N接收S返回的全部响应结果完成
9. N开始向C返回全部的HTTP响应结果
10. C开始接收N返回的数据并全部接收完成
11. N向C发起四次挥手关闭TCP连接

其中1-2和9-11这5个阶段 的速度直接受到C到N之间的网络质量影响，服务端虽然可以通过降低传输数据量、使用更快的协议(如HTTP3.0基于QUIC)等降低传输耗时，但无法起到决定性的作用，一般可视为超出了可优化的控制范围。
3-8这6个阶段一般都发生在内网，即N与S都处于同一个机房(甚至同一个机架/同一台物理机上)，网络质量稳定且RTT基本在1ms内，网络耗时较少，正常情况下其主要时间应集中在阶段5–各种业务逻辑处理数据并生成结果–这也正是一般后端优化的目标阶段。

各耗时指标nginx官方解释 && 疑问

参考:http://nginx.org/en/docs/http/ngx_http_log_module.html

$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

request_time是N接收到C第一个字节数起至N向C发送完最后一个字节数止后日志记录的时间。
疑问：接收到第一个字节包括TCP三次握手的字节吗？发送完最后一个字节的具体定义是什么–N发送最后一个字节必须收到C的ACK才算发送完成？
参考: http://nginx.org/en/docs/http/ngx_http_upstream_module.html

$upstream_connect_time
keeps time spent on establishing a connection with the upstream server (1.9.1); the time is kept in seconds with millisecond resolution.