【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源工程（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Ubuntu】【远程开发】内网穿透：连接可靠性（二）
讨论了 TCP keepalive 的历史背景，以及不能用它来做保活和检测断联的原因，接着分析到了 SSH 应用层保活机制，下面继续
内网穿透
之前分析到了 SSH 保活机制的两个核心效果：
- 端到端连接链路检测：上篇 blog【Ubuntu】【远程开发】内网穿透：连接可靠性（二） 已介绍
- 中间网络设备的防空闲断连：很多中间设备，比如 NAT 网管，状态防火墙，负载均衡器等会维护连接跟踪表，为节省资源，这些中间设备会对长时间无材料交互的 TCP 连接设置超时（一般 60~300s 比较常见），一旦超时，中间设备往往会悄悄丢弃该连接的状态，后续通信将失败（在用户这里就表现为卡住或突然断开）
SSH 保活机制通过定期发送保活包（即使只是几个字节的 SSH 控制消息），让中间设备认为连接仍在活跃使用中，因此连接跟踪表项不会被老化删除，针对此种老化删除机制，不需对端回复也能起到一定作用（但 OpenSSH 的保活默认要求回复，故而实际上还是会触发双向流量），即使对端宕机，有出站流量，仍可能刷新其状态，从而延长其超时时间就是只要保活包能发出（即使得不到回应），在中间设备看来仍，但不如双向交互可靠，双向交互可以确保双向链路都健康
所以总结一下，SSH 保活机制的设计精髓在于，凭借加密的 SSH 协议保活消息（被中间路由设备视为合法的业务流量），主动探测对端存活状态（相当于应用层心跳，并且 SSH 要求对端必须回复，这个点后面介绍），并且维持中间网络设备的连接状态（定期产生流量，提醒中间路由设备别把这个安静的连接给抛弃了），在实际运维中，比如跳板机，云环境，移动网络或高 NAT 场景（中间有很多路由设备）下使用 SSH，这个保活机制几乎是必需的
OK，上面分析完 SSH 保活机制的原理，下面开始分析 SSH 保活机制的配置，有两个关键配置项 ServerAliveInterval 和 ServerAliveCountMax，首先说第一个 ServerAliveInterval，在终端输入
man ssh_config可以找到配置项 ServerAliveInterval 的描述如下
有几个点：
- 首先，
ServerAliveInterval定义了一个空闲超时时间，单位是秒，判断空闲的标准是从服务端没有收到任何数据（包括 Shell 输出，StdErr，保活响应等），一旦超过该时间还是没有资料，SSH 客户端会主动通过已建立的加密通道发送一个探测消息，目的是请求服务端回应，即应用层心跳，这个探测消息走的是已加密的 SSH 通道，不是新建连接或明文包，安全高效 ServerAliveInterval默认值为 0，表示禁用保活探测（这意味着一旦网络中间设备因为空闲断开连接，SSH 客户端不会主动发现，用户就会卡在假连接状态，这也就是很多用户遇到 SSH 突然卡住的原因）- 在 Debian 系列（包括 Ubuntu），如果启用了
BatchMode yes配置项（批处理模式，通常用于自动化脚本），则ServerAliveInterval默认值为 300s，也就是 5 分钟，这是发行版的补丁行为，不是 OpenSSH 官方默认，因为自动化脚本往往长时间运行，更容易因空闲被中间设备断开，而启用BatchMode yes暗示这是自动化脚本，不是交互式任务，Debian 团队认为应默认启用保活以提高鲁棒性，如果在其他系列的 Linux 上使用 BatchMode 批处理，没有这种自动设置，需要自己手动设置
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Ubuntu】【远程开发】内网穿透：连接可靠性（四）