运维123 - QUIC
type: channel
link: https://www.sddts.cn/index.php/tag/QUIC/
items: stan-smith GitHub 开源项目技术分析
items: TCP RTT 测量困境与技术分析

stan-smith GitHub 开源项目技术分析
type: item
date: 2026-01-25T02:58:26+00:00
description: stan-smith GitHub 开源项目技术分析一、概述1. 开发者简介stan-smith 是一位专注于开源工具开发的开发者，GitHub 用户名为 stan-smith，个人网站为 x0z.co。其 GitHub 主页显示他拥有 222 个关注者，关注了 5 个用户，管理着 24 个公开代码仓库。2. 技术特点根据其项目仓库分析，stan-smith 的技术栈主要集中在：系统级编程：RustWeb 开发：TypeScript脚本语言：Shell、Python领域专长：网络视频流、基础设施可视化、Linux 视频处理3. 核心项目其主推的三个开源项目包括：FossFLOW：网络基础设施可视化工具，获得 16.8k 星标SlingShot：基于 QUIC 的超低延迟视频流传输工具Dart：轻量级 V4L2 到 RTSP 视频流服务器二、核心项目技术分析1. FossFLOWA. 项目简介FossFLOW 是一个等距视角（isometric）的网络基础设施图表绘制工具，旨在让基础设施映射变得更加美观和愉悦。该项目基于已有的 MIT 许可证代码库构建。B. 技术架构graph TB User[用户] --> UI[Web UI] UI --> Editor[图形编辑器] Editor --> Engine[渲染引擎] Engine --> Canvas[HTML5 Canvas] Engine --> Export[导出模块] Export --> PNG[PNG 图片] Export --> SVG[SVG 矢量图] Export --> JSON[JSON 数据]C. 技术特点语言：TypeScript渲染方式：HTML5 Canvas视角：等距（Isometric）2.5D许可证：MIT社区影响力：16.8k stars，1.1k forksD. 应用场景网络拓扑图绘制云基础设施文档化DevOps 可视化技术文档插图2. SlingShotA. 项目简介SlingShot 是一个使用 Rust 编写的超低带宽视频传输工具，基于 QUIC 协议实现。其核心卖点是端到端延迟低于 100ms，且永久免费，避免了传统方案的五位数授权费用。B. 技术架构graph LR Source[视频源] --> Capture[采集] Capture --> Encoder[编码器] Encoder --> QUIC[QUIC 协议] QUIC --> Network[网络传输] Network --> QUIC QUIC --> Decoder[解码器] Decoder --> Display[显示端]C. 技术特点语言：Rust传输协议：QUIC（基于 UDP）延迟：Sub-100ms 端到端授权：完全开源免费许可证：开源许可证D. 竞争优势与商业视频流方案相比：成本：完全免费 vs 五位数授权费延迟：<100ms vs 通常 200-500ms协议：QUIC vs RTMP/RTSP3. DartA. 项目简介Dart 是一个轻量级的 V4L2 到 RTSP 视频流服务器，设计理念简单直接：插入采集卡，获得视频流。B. 技术架构graph TD V4L2[V4L2 设备] --> Dart[Dart 服务器] RTSP[RTSP 输入流] --> Dart Dart --> Transcode[转码] Transcode --> RTSPout[RTSP 输出] RTSPout --> Client[客户端]C. 技术特点语言：Rust输入：V4L2 设备或 RTSP 流输出：RTSP 流特性：高度可配置，具备合理的默认设置许可证：开源许可证D. 应用场景视频采集卡流化监控摄像头接入视频流转发服务三、其他项目概览1. PingPanelTUI（终端用户界面）运行时间检查工具，使用 Python 开发。语言：Python功能：检查服务可用性社区：47 stars，3 forks2. Tailscale 自动标签工具Shell 脚本实现的 Tailscale 自动标签管理工具。语言：Shell功能：自动化 Tailscale 设备标签管理社区：8 stars3. AnsiScaleShell 脚本工具，可能与终端 ANSI 转义序列缩放相关。语言：Shell社区：7 stars四、技术影响力分析1. 贡献统计根据 GitHub 贡献图：过去一年贡献：784 次2026 年 1 月：40 次提交，涉及 5 个仓库仓库创建：2026 年 1 月创建 3 个新仓库2. 社区认可GitHub 成就：Pair Extraordinaire、Pull Shark x2、Starstruck x4、YOLO、QuickdrawFossFLOW 项目成为…

TCP RTT 测量困境与技术分析
type: item
date: 2026-01-17T23:35:58+00:00
description: TCP RTT 测量困境与技术分析一、核心问题1. 问题本质TCP 传输算法（包括拥塞控制算法、传输加速算法等）非常依赖 RTT（Round Trip Time，往返时间）进行决策，但 RTT 的测量准确性却与网络质量正向相关。2. 核心矛盾网络质量好时，不过度依赖 RTT 的精确测量网络质量不好，需要精确 RTT 测量时，RTT 却测不准这种矛盾源于 TCP 协议本身的设计缺陷，包括 Delayed ACK 机制和重传歧义问题。二、RTT 测量的技术挑战1. Delayed ACK 影响A. 机制说明Delayed ACK 是 TCP 接收端的一种优化机制，接收端收到数据后不立即发送 ACK，而是等待一段时间（通常 200ms）或等到收到第二个数据段时再发送 ACK，目的是减少 ACK 数量，提高网络效率。B. 测量偏差接收端收到 2 个段后回复一个 ACK，该 ACK 包含对两个段的确认。在这种情况下：可用第一个段计算 srtt（用于 RTO 计算的 RTT）可用第二个段计算 ca_rtt（用于拥塞控制的 RTT）原因在于：第一个段包含了主机 Delayed 时间第二个段直接触发了 ACK，没有主机时间影响C. 测量示意图sequenceDiagram participant S as 发送端 participant R as 接收端 S->>R: 数据段1 (时间t1) Note over R: Delayed ACK 等待 S->>R: 数据段2 (时间t2) R->>S: ACK (确认段1和段2) Note over S: srtt ≈ ACK时间 - t1 包含 Delayed 时间 ca_rtt ≈ ACK时间 - t2 更接近纯网络时延2. 重传歧义问题A. 问题描述当网络质量不好、频繁丢包时，如果发送端无法区分 ACK 或 SACK 是针对原始数据还是重传数据，时间信息将被丢弃，不再用于 RTT 计算。B. 困境加剧丢包重传时，没有 Delayed ACK 影响（接收端会立即确认）但遇到重传歧义，无法确定 ACK 对应原始发送还是重传恰恰在频繁丢包时，RTT 对拥塞控制最重要，但却测不到C. 重传歧义示意图graph LR A[发送数据包] --> B{是否丢失?} B -->|未丢失| C[收到 ACK] B -->|丢失| D[重传数据包] C --> E[正常计算 RTT] D --> F{能否区分原始/重传?} F -->|能区分| G[可计算 RTT] F -->|不能区分| H[丢弃时间信息]三、Linux 的解决方案1. 双 RTT 机制Linux 内核实现了两类 RTT，从源码注释可见设计意图：struct tcp_sacktag_state { ... /* Timestamps for earliest and latest never-retransmitted segment * that was SACKed. RTO needs the earliest RTT to stay conservative, * but congestion control should still get an accurate delay signal. */ u64 first_sackt; u64 last_sackt; }A. srtt（Smoothed RTT）用途：计算 RTO（重传超时时间）特点：偏保守，避免激进重传策略：使用最早的时间戳B. ca_rtt（Congestion Control RTT）用途：拥塞控制算法特点：侧重精度，度量网络时延策略：使用最新的时间戳，最小化主机影响2. Timestamp 选项兜底TCP Timestamp 选项可用于解决重传歧义：每个数据包携带发送时间戳（TSval）ACK 携带回显时间戳（TSecr）即使发生重传，通过时间戳仍可计算 RTT3. 多种花活儿方案为在丢包重传场景下获取 RTT，Linux 实现了多种技巧：A. DSACK 方案包含 old seg 来重传，用 DSACK 明确区分，计算 RTTB. Probe 方案用新数据 probe，明确对该数据的 SACK，计算 RTTC. 不连续数据 Probe用不连续数据 probe（新的或旧的），明确对该数据的 SACK/ACK，计算 RTTD. 简单示例若将 una ～ una + MSS 作为一个数据包传输并被标记为丢失：重传 una ～ una + fk（0 < fk < MSS）记录当前时间戳保留 una + fk ～ una + MSS 为空洞等待接收端回复 ACK若 ACK 等于 una + fk 且等于重传数据包的 end_seq则 now_us - skb.ts_us …