调整VPN关联的TCP重传参数之前，不能直接照搬网上的通用配置修改系统默认值，必须先完整记录当前链路的全量基线状态，红梅APP否则调整后出现异常根本无法回溯还原，甚至可能把原本只是偶发卡顿的VPN连接弄成完全无法连通。所有记录操作优先选择低影响的只读检查，全程不要改动现有运行参数。
当前VPN链路的基础连通基线
这类记录操作完全不会影响现有连接，你只需要记录VPN两端的互联地址、当前VPN隧道的协商存活时长，还有连续10分钟覆盖常规业务场景下的往返时延波动范围，不要只取瞬时值作为参考依据。
同时还要记录低负载状态下VPN隧道本身的丢包统计，还有穿过VPN的TCP连接的三次握手耗时，这些数据是后续判断重传调整有没有正向效果的核心对照基准，没有这些基线就没法确认调整到底是优化还是劣化了链路。
这套记录逻辑适用于所有你拥有两端配置查看权限的自建IPsec、SSL VPN场景，红梅APP不适用于你完全没有底层网络管理权限的第三方商用VPN服务。
调整VPN关联的TCP重传参数前，需先完整记录当前链路的全量基线状态，保障后续出现异常可回溯还原
现有TCP栈的默认参数状态
这个部分的记录要限定在你当前使用的操作系统范围内，不同发行版的Linux、不同版本的Windows的TCP重传相关默认参数差异很大，不要直接照搬其他环境的配置套用到当前系统上。
你只需要用系统自带的只读查询工具，把当前系统预设的初始重传超时基数、最大重传次数、快速重传触发阈值这类参数全部导出留存，不需要做任何修改，后续调整完如果出现异常可以随时对比还原到初始状态。
如果你的VPN客户端自带了专属的TCP优化模块，还要单独记录这个模块当前的开关状态和内置参数，避免后续系统层面的调整和VPN客户端的内置逻辑冲突，出现难以排查的诡异连接问题。
当前业务流量的典型特征
你要记录VPN承载的核心业务的流量类型，比如是定时大文件备份、实时视频会议还是普通的办公网页访问，不同业务对重传延迟的容忍度完全不一样，盲目调低重传等待时间反而会在轻微丢包的时候触发大量无效重传，挤占隧道带宽。
还要记录典型业务场景下的单TCP连接的平均报文大小、每秒并发连接数，还有业务侧能接受的最长中断容忍时间，这些信息能帮你判断调整后的参数会不会影响上层业务的正常运行，避免调整后触发业务侧的不必要告警。
调整前的已知异常现象快照
如果是因为已经出现了连接卡顿、梯子软件意外断连才要调整重传参数，你要把复现异常的完整操作路径记录下来，比如是跑满隧道带宽的时候出问题，还是空闲超过半小时之后出问题，同时留存对应时段的系统日志和VPN隧道日志。
不要把所有TCP层面的问题都归为重传参数不合理，调整前还要确认你记录的异常现象，没有被中间网络的QoS策略、VPN隧道的分片规则影响，避免调整完重传参数之后完全没有效果，浪费排查时间。
