SSH每次按键发送100个数据包的原因是终端交互模式下的实时响应机制和网络延迟优化策略导致的。文章通过分析发现这是SSH协议设计上的特性，旨在提供流畅的交互体验，但也带来了不必要的网络开销。作者探讨了调试过程并提出了优化建议。

为什么SSH每次按键会发送100个数据包？

关键发现

作者在开发一款基于SSH的高性能游戏时，意外发现每次按键操作会触发约270个数据包传输（其中179个为36字节的"神秘数据包"）。通过抓包分析显示，这些数据包以约20ms间隔持续发送，导致CPU使用率异常升高。

问题根源

经调查发现，这是OpenSSH在2023年新增的击键时序混淆安全功能： 1. 通过发送大量虚假SSH2MSGPING数据包（称为"干扰包"）掩盖真实击键时间 2. 旨在防止攻击者通过输入间隔推断敏感信息 3. 客户端默认开启该功能，需服务器支持[email protected]扩展

解决方案

1. 客户端禁用：通过ObscureKeystrokeTiming=no参数关闭（但不适合普通用户）
2. 服务端优化：修改Go的SSH库，移除对[email protected]扩展的支持
   • 效果显著：CPU使用率从29.9%降至11.64%
   • 系统调用从3.1秒减少到0.66秒
   • 带宽消耗降低53%

调试过程启示

1. 使用LLM辅助分析（如Claude Code）能快速解析抓包数据，但需人工验证
2. 不同AI工具表现差异：ChatGPT曾错误判断为"正常SSH行为"
3. 保持人工介入既能享受AI效率，又能确保问题深度解决

技术细节

• 典型数据包分布：66%为36字节干扰包，34%为TCP确认包
• 每个按键触发约90个数据包/秒的传输速率
• 通过Go的replace指令轻松替换加密库依赖

该案例展示了安全功能与性能需求的平衡，以及AI辅助调试的新工作模式。作者最终通过修改底层协议支持，实现了超过50%的性能提升。

注：本文涉及的技术方案需谨慎评估安全影响，不建议直接在生产环境使用未经审计的加密库修改。

以下是评论内容的总结，保持不同观点的平衡性：

1. 关于SSH性能问题的讨论

   • 有评论质疑SSH的设计效率，指出其处理速度异常缓慢（评论9："SSH is bottlenecking in its code at ~500 Mbps per core which is ludicrously slow"）
   • 技术改进建议：使用TCPCORK或调整TCPNODELAY来优化数据包数量（评论2："Disabling TCP_NODELAY would reduce number of packets"）

2. 关于SSH安全性的争议

   • 强烈反对禁用击键混淆功能（评论4："please never do that in production...people broke SSH then a fix was found"）
   • 建议将补丁提交上游，在可信环境中可节省带宽（评论5："should be upstreamed as an option...save the bandwidth"）
   • 安全与性能的权衡讨论（评论8/12：对于终端游戏，"just offering telnet...where security does not matter"）

3. 对SSH游戏开发的质疑

   • 多则评论质疑通过SSH开发高性能游戏的合理性（评论7："WAT. Please no"；评论10："Found your problem"）

4. 网络延迟问题的抱怨

   • 批评企业忽视延迟问题（评论11："typical corporate attitude where latency never matters"）
   • 举例Adobe Dreamweaver等软件的延迟问题

5. 其他技术细节讨论

   • 通过禁用加密调试SSH行为的方法（评论8："patching in 'None' cipher support"）
   • 对Claude过度使用"smoking gun"术语的调侃（评论1："Claude overuses that term a lot"）

6. 用户学习收获

   • 有用户表示通过文章了解到SSH曾受击键计时攻击（评论3："unfamiliar with SSH being vulnerable to keystroke timing"）

[注：由于所有评论均无评分数据，故未包含认可度分析]