关于OpenLiteSpeed QUIC服务器请求耗时(%D)异常的技术问询

一、耗时波动的原因分析 #

1. 耗时达100ms的情况 #

• QUIC首次连接开销：如果是新建立的QUIC连接，需要完成TLS 1.3握手+QUIC连接协商，哪怕TLS1.3已做优化，首次连接的额外耗时叠加30ms基础RTT，总耗时很容易冲到100ms级别。
• 服务器排队延迟：服务器负载较高时，请求会进入等待队列，等待worker进程处理，小文件本身处理快，但排队时间会被计入%D指标，直接拉高总耗时。
• 网络临时波动：实际网络中偶尔会出现丢包、路由跳转、带宽突发占用的情况，导致数据包往返时间变长，最终反映在请求耗时上。

2. 耗时低至100μs的情况 #

• QUIC连接复用：如果复用了已建立的QUIC连接（包括0-RTT快速复用），无需重新握手，服务器收到请求就能立即响应，这时%D仅统计服务器内部处理时间（从接收请求到发送响应），不包含网络RTT，自然远低于基础RTT。
• 缓存直接命中：小文件如果存在服务器内存缓存（比如OpenLiteSpeed的静态文件缓存），无需读取磁盘，直接在内存中生成响应，内部处理时间极短，耗时就能压到微秒级。
• %D的统计范围：这个指标是从服务器收到请求第一个字节到发完响应最后一个字节的时间，不算请求传输到服务器的时间，也不算响应传输到客户端的时间。要是请求通过复用连接快速到达，服务器处理加发送响应的时间确实能做到100μs左右。

二、%D指标的计算逻辑说明 #

OpenLiteSpeed #

OpenLiteSpeed的%D基本兼容Apache的定义，但有针对QUIC的细节调整：

• 统计窗口是从服务器成功解析请求的时刻，到响应发送完成的时刻，单位为微秒。
• QUIC连接握手的时间不会计入单个请求的%D，仅统计请求本身的处理和发送时间；但首次连接的第一个请求，握手完成后才开始处理请求，%D还是从请求解析开始计算，不包含握手耗时。
• 官方参考：OpenLiteSpeed的日志格式遵循Apache规范，内核文档中有针对QUIC连接复用、请求调度的时间统计细节。

Apache HTTP Server #

Apache的%D定义清晰明确：

• 单位为微秒，统计从服务器接收请求第一个字节到发送响应最后一个字节的耗时。
• 仅包含服务器端的处理和发送时间，不涉及网络传输时间（请求到服务器、响应到客户端的时间均不算入）。
• 官方参考：mod_log_config模块文档明确了%D的计算逻辑，对于HTTP/3（QUIC）请求，计算逻辑与HTTP/1.1、HTTP/2完全一致。

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