用一个数字衡量 KL 的存在
下面 4 项指标来自全球分布的 38 个观测点对生产网络的近 30 日统计。
挑一台设备，30 秒装好
下面是 4 个平台的官方客户端直链。所有安装包均经过数字签名，下载完成后建议核对 SHA256。
它为什么不是又一个"普通加速器"
快连在做两件很多人不愿意做的事：把链路质量做成可观测数据，把节点切换做成零感知的连续行为。
协议自研，可观测
KL-Transport 不是套壳 WireGuard——它自研拥塞控制、自适应 MTU，并把每一次握手、每一次切线都打点上报。
智能路由，零感知
在视频会议进行中，链路可能已经被切过 4 次，只是因为你没掉过一个包。我们做的是"如果你不知道，那就对了"。
全平台同步
同一账号在 4 台设备同时登录，配置自动同步——你在工位电脑加了自定义节点，地铁上打开手机客户端就能看到。
工程师是用户
团队成员自己是重度远程协作用户，每周六晚复盘上周切线日志——不是产品经理拍脑袋调优，是用户被卡过所以修掉。
凌晨 2 点 47 分，旧金山客户突然听不见我的声音
视频会议开到第 41 分钟，旧金山那边的客户突然听不见我说话。我以为是 USB 耳机接触不良，摘下来换到笔记本的 3.5mm 接口，重新接听，还是没有声音。屏幕共享正常，对方能看到我打开的 Figma 文件，但麦克风那条数据流始终没过去。挂了电话发 Slack 过去，对方的回复是一行字："it's not on our side"。那一刻我意识到——这是快连在切线。我用旧金山客户这条链路跑了 11 个月了，过去 7 天因为运营商 BGP 抖动被自动切换过 3 次，但我一次都没察觉，因为 TCP 重传掩盖了抖动。直到今天视频会议这种对丢包零容忍的场景出现，问题才暴露。
我们做的事情里有一个非常反直觉的部分：频繁切线本身不是问题，没切线才是问题。大多数同类产品会尽量维持一条"看上去稳定"的链路，代价是这条链路一旦真的劣化，它会一直劣化下去直到丢包率超过 5% 才被动切换——这中间你已经和旧金山客户开了 5 分钟的会。我们的 KL-Transport 反而更激进：监测到 P99 延迟连续 6 秒高于阈值 1.4 倍，就立刻切，哪怕切换过程会带来 200ms 的瞬时中断。200ms 的瞬时中断视频会议里几乎察觉不到，但连续 30 秒的劣化你一定察觉得到。
// 切线频率和掉线体感之间，是一段反直觉的曲线。客户端要做的是"看不见"，不是"不发生"。
写到这里我顺手打开客户端看了一眼今天的切线记录：过去 12 小时里，旧金山链路被切换过 7 次，其中 5 次是因为目标机房 BGP 抖动，2 次是因为我从地铁站切换到 WiFi。这 7 次切线里没有任何一次让我的视频会议出现可感知中断——其中 4 次发生在会议之外的 1 秒间隔，剩下 3 次发生在会议沉默的段落里。我们对"沉默段落"的检测不是靠 NLP，而是靠 RTP 的 silence suppression 标志位——视频会议协议本身就会告诉你"这一帧没有声音"。关于客户端怎么装、装哪一版、SHA256 怎么对，下面那个客户端下载页里写得很细。