网络延迟的均值往往具有欺骗性。一条平均延迟40ms的链路，如果延迟在10ms到120ms之间剧烈波动，实际体验可能比一条稳定在55ms的链路更差。抖动（Jitter）正是描述这种波动的核心指标，尤其在VoIP、视频会议、在线游戏等实时场景中，它的重要性甚至超过平均延迟。本文将用Ruby从零实现一套RTT采集与统计分析工具，并基于QoS服务质量框架建立可量化的评估模型。
一、RTT数据采集：两种探测方式的选择
测量往返时间（Round-Trip Time）最直接的思路是发送探测包并记录应答时间。在Ruby中有两种常见做法：一是调用系统自带的ping命令解析输出，二是直接建立TCP连接测量握手耗时。前者依赖外部命令，但能利用ICMP协议的轻量特性；后者纯Ruby实现，不需要额外权限，而且TCP握手时间更能反映真实应用的连接体验。
先看TCP探测方式的实现。利用Socket.tcp并配合Timeout模块，可以测量从发起连接到握手完成的耗时：
require 'socket'
require 'timeout'
def tcp_rtt(host, port = 443, timeout = 2)
start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
begin
Timeout.timeout(timeout) do
socket = Socket.tcp(host, port, connect_timeout: timeout)
socket.close
end
rescue Timeout::Error, Errno::ECONNREFUSED, Errno::ETIMEDOUT
return nil
end
elapsed = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
(elapsed * 1000).round(3) # 转换为毫秒
end
这里有两个细节值得注意。首先，计时必须使用Process.clock_gettime(Process::CLOCK_MONOTONIC)而不是Time.now，因为单调时钟不受系统时间同步（NTP跳变）的影响，长周期采集时更可靠。其次，连接被拒绝（ECONNREFUSED）虽然说明端口不通，但TCP握手依然完成了往返，严格来说这个时间也可以计入RTT统计，不过为了数据纯净，上面的代码将其视为无效样本。
解析ping命令输出的方式则适合需要ICMP探测的场景。以Linux为例，可以逐行读取ping的输出并用正则提取时间值：
def icmp_rtt(host, count = 10)
rtts = []
IO.popen(["ping", "-c", count.to_s, "-i", "0.2", host]) do |io|
io.each_line do |line|
if line =~ /time=([\d.]+)\s*ms/
rtts << $1.to_f
end
end
end
rtts
end
这种方式的缺点是依赖平台，Windows的ping输出格式就完全不同，正则需要另行适配。对于跨平台工具，建议优先采用TCP探测方案，或者引入纯Ruby的ICMP gem。两种方式采集到的数据形态一致，都是一个浮点数数组，后面的统计分析可以完全复用。
二、方差、标准差与百分位数：抖动的统计学刻画
拿到RTT样本序列之后，下一步是计算统计量。平均数只能反映中心趋势，而抖动的本质是样本的离散程度，需要用方差和标准差来刻画。方差是各样本与均值之差的平方的平均值，标准差是方差的平方根，单位与原始数据一致（毫秒），因此标准差更便于直观理解。对于实时业务，还有一个关键指标是百分位数：99分位延迟（P99）代表最差的1%请求的延迟上界，它对用户体验的影响远大于平均值。
下面是一个完整的统计类实现，一次性输出所有核心指标：
class RttStats
attr_reader :samples
def initialize(samples)
@samples = samples.reject { |s| s.nil? || s <= 0 }
end
def mean
@mean ||= @samples.sum / @samples.size.to_f
end
def variance
return 0.0 if @samples.size < 2
@variance ||= @samples.sum { |s| (s - mean) ** 2 } / (@samples.size - 1)
end
def stddev
Math.sqrt(variance)
end
# RFC 3550 风格的相邻样本抖动
def jitter
return 0.0 if @samples.size < 2
diffs = @samples.each_cons(2).map { |a, b| (b - a).abs }
diffs.sum / diffs.size.to_f
end
def percentile(p)
return 0.0 if @samples.empty?
sorted = @samples.sort
rank = (p.to_f / 100 * (sorted.size - 1)).ceil
sorted[rank]
end
def loss_rate(total_sent)
sent = [total_sent, @samples.size].max
((sent - @samples.size) / sent.to_f * 100).round(2)
end
def report
{
count: @samples.size,
mean: mean.round(2),
stddev: stddev.round(2),
jitter: jitter.round(2),
p50: percentile(50).round(2),
p95: percentile(95).round(2),
p99: percentile(99).round(2),
min: @samples.min.round(2),
max: @samples.max.round(2)
}
end
end
这里需要区分两种抖动的定义。RTP协议（RFC 3550）中的抖动是相邻包延迟差的指数加权平均，反映的是短时间内的波动；而标准差衡量的是整体分布的离散程度。两者数值可能差异明显：如果延迟呈现缓慢的周期性起伏（比如白天高峰、夜间低谷混合采样），相邻样本差异小但标准差大。评估实时业务时建议同时输出这两个值，jitter方法实现的正是相邻差均值这种简化版本。
另外注意方差计算使用了n-1作为分母（样本方差），而不是n（总体方差）。因为采集到的RTT只是链路真实行为的抽样，除以n-1的贝塞尔校正能让估计量无偏。当样本数只有几十个时，这个差异是不可忽略的。
三、滑动窗口与异常值过滤
长时间运行探测时，链路状况会随时间变化，全局统计会掩盖阶段性问题。例如前五分钟链路正常，之后路由切换导致劣化，全局平均值可能依然好看。解决方案是引入滑动窗口，将数据切分为连续的时间片分别统计，观察指标随时间的演化趋势。
def sliding_window_stats(rtts, window_size = 20, step = 10)
results = []
(0..(rtts.size - window_size)).step(step) do |i|
window = rtts[i, window_size]
stats = RttStats.new(window)
results << { range: (i...(i + window_size)), mean: stats.mean.round(2), jitter: stats.jitter.round(2) }
end
results
end
异常值处理也需要谨慎。偶发的DNS重查、GC停顿或者虚拟机调度可能导致个别样本异常偏高，直接纳入计算会严重扭曲标准差。常用做法是使用中位数绝对偏差（MAD）过滤：计算所有样本与中位数之差的绝对值的中位数，超过某个倍数（通常取3倍）的样本视为离群点。相比直接用标准差的3-sigma法则，MAD对异常值本身不敏感，更稳健。
def filter_outliers(samples, threshold = 3.0)
median = samples.sort[samples.size / 2]
mad = samples.map { |s| (s - median).abs }.sort[samples.size / 2]
return samples if mad == 0
kept, dropped = samples.partition { |s| (s - median).abs / mad <= threshold }
warn "剔除 #{dropped.size} 个离群样本: #{dropped.inspect}"
kept
end
需要强调的是，剔除离群点适合分析常态链路质量，但在评估最差体验（P99）时应使用原始数据，因为离群样本恰恰是用户真实会遇到的卡顿时刻。两种口径各有用途，报告中最好分别呈现。
四、QoS服务质量评估模型：从数据到评分
有了统计指标，最后一步是把它们翻译成可理解的服务质量结论。ITU-T的Y.1540建议将网络性能划分为多个等级，对延迟、抖动、丢包分别设定阈值。例如交互式语音通常要求单向延迟不超过150ms、抖动不超过30ms、丢包率不超过1%。我们可以参考这些标准，为每个维度建立分段计分函数，再加权汇总成总分。
class QosEvaluator
# 分段计分：低于good满分，高于bad零分，中间线性过渡
def self.score(value, good, bad)
return 100.0 if value <= good
return 0.0 if value >= bad
(bad - value) / (bad - good).to_f * 100
end
WEIGHTS = { mean: 0.2, jitter: 0.3, p99: 0.3, loss: 0.2 }
def self.evaluate(stats, total_sent)
scores = {
mean: score(stats.mean, 50, 200),
jitter: score(stats.jitter, 20, 80),
p99: score(stats.percentile(99), 100, 400),
loss: score(stats.loss_rate(total_sent), 0.5, 5)
}
total = scores.sum { |k, v| v * WEIGHTS[k] }
grade = case total
when 85..100 then "优秀"
when 70...85 then "良好"
when 50...70 then "一般"
else "较差"
end
{ scores: scores.transform_values { |v| v.round(1) }, total: total.round(1), grade: grade }
end
权重的设置应与业务类型匹配。语音和游戏类业务对抖动极度敏感，可以把jitter的权重提高到0.4以上；文件传输类业务则更关心吞吐和丢包，延迟波动影响较小。上面的分段线性计分函数实现简单且可解释性强——每个阈值都有明确的业务含义，方便根据SLA协议调整参数。如果需要更精细的模型，也可以在score函数中引入非线性曲线，例如对超过阈值的劣化进行指数级惩罚。
最后把这些组件串成完整的探测循环，每隔固定间隔采样一次，持续采集后输出综合报告：
host = ARGV[0] || "bbccb.com"
samples = []
total_sent = 60
total_sent.times do |i|
rtt = tcp_rtt(host)
samples << rtt if rtt
puts format("[%02d/60] RTT: %s ms", i + 1, rtt || "超时")
sleep 0.5
end
stats = RttStats.new(samples)
puts "统计报告: #{stats.report.inspect}"
puts "QoS评估: #{QosEvaluator.evaluate(stats, total_sent).inspect}"
这套工具的实现不到两百行Ruby代码，却能输出从原始RTT到综合评分的完整链路画像。实际部署时，还可以将滑动窗口的统计结果写入时序数据库，配合Grafana做可视化监控，当抖动指标连续多个窗口超过阈值时触发告警，这就从一次性的测试脚本演进成了持续运行的链路质量监控系统。