Windows
macOS
Android
iOS
TCP传输优化的目标，不是把某个参数调到最大，而是在当前网络、操作系统和业务负载下，找到速度与稳定性的平衡点。文件传输、接口调用、数据库同步和远程办公对网络的要求并不相同：大文件更关注持续吞吐，交互式请求更在意往返时延和抖动，短连接业务则容易受到连接建立成本影响。
一、先确认瓶颈，别急着修改参数
带宽不足、链路丢包、服务器 CPU 过高、磁盘读写缓慢，都可能表现为“TCP速度不够”。如果源站读取文件只能达到较低速率，即使把发送缓冲区调大，网络吞吐也不会同步提升。
- 固定测试时间、客户端、服务端和目标文件，避免把不同条件下的结果进行比较。
- 分别记录实际吞吐、往返时延、丢包率、重传情况以及服务器 CPU、内存和磁盘使用率。
- 先做基线测试，再一次只调整一类参数，观察持续时间至少覆盖业务高峰和低峰。
在同一局域网内测试得到的结果，不能直接代表跨运营商或跨地区连接质量。TCP传输优化应以真实业务路径为依据，而不是只看本机测速结果。
二、选择拥塞控制算法时兼顾链路特征
拥塞控制决定发送端如何根据网络反馈调整速率。Linux系统常见的拥塞控制实现包括 CUBIC 和 BBR，但可用算法、默认配置及内核支持情况会因发行版和版本而不同。
- CUBIC：在传统宽带和数据中心网络中应用广泛，行为相对成熟，适合先作为基准。
- BBR：更关注带宽和往返时延的估计，在高延迟或带宽较大的链路上可能改善吞吐，但不应假定所有网络都能受益。
切换前应确认系统支持情况，并在相同目标地址、相同文件和相同并发数下比较。若出现队列延迟上升、其他连接变慢或丢包增加，应回退设置。拥塞控制优化必须服务于整体连接质量，而不是只追求单个下载任务的峰值。
三、窗口大小要匹配带宽与时延
TCP发送窗口和接收窗口决定了未确认数据能够积累多少。高带宽、长距离链路需要更大的窗口，否则发送端可能频繁等待确认；但在低速或高丢包网络中，盲目放大窗口会增加排队数据和重传成本。
用带宽时延积判断方向
可用“带宽 × 往返时延”估算带宽时延积。例如，500 Mbps 链路的往返时延约为 80 毫秒时，理论在途数据量约为 5 MB。这个数值只是估算，实际还会受到协议开销、接收端处理能力和链路拥塞影响。
- 确认客户端和服务端都支持窗口缩放。
- 观察接收窗口是否持续成为限制因素，以及是否存在大量重传。
- 逐步调整系统允许的缓冲区上限，而不是直接设为极大值。
- 用大文件传输和小请求各测一次，避免只针对单一业务优化。
四、MTU和MSS必须通过实际路径验证
MTU过大可能造成分片、丢包或连接异常，MTU过小则会增加协议头开销。家庭宽带、企业专线、虚拟专用网络和隧道连接的可用MTU可能不同，不能照搬其他环境的数值。
执行TCP传输优化时，应先确认出口设备、隧道设备和服务器网卡的配置，再通过禁止分片的连通性测试逐步探测路径允许的最大报文。若使用隧道，通常需要为封装头预留空间，并相应降低接口MTU或MSS。修改后要同时验证网页、API和大文件传输，因为部分业务可能只在较大报文下暴露问题。
五、连接复用比单纯提高并发更重要
每次建立TCP连接都要经历握手，启用加密时还会增加TLS协商成本。对频繁访问同一服务的客户端，HTTP持久连接和连接池通常比不断创建短连接更有效。
- 连接池过小：请求可能排队，吞吐不足。
- 连接池过大：会消耗文件描述符、内存和服务端连接资源，还可能加剧拥塞。
- 空闲时间过长：中间防火墙或负载均衡设备可能回收连接，导致复用时出现失败。
应结合请求耗时、并发量和服务端连接上限设置连接池，并为失效连接设计重试和退避机制。重试次数不能无限增加，否则会在故障期间形成请求风暴。
六、用指标验证效果，防止“速度提升”掩盖稳定性下降
完整的TCP传输优化至少要观察吞吐、P95或P99延迟、重传率、连接失败率、超时数和服务器资源。单次峰值速度没有代表性，持续传输、突发请求和网络波动下的表现更有参考价值。
| 现象 | 可能原因 | 优先检查项 |
|---|---|---|
| 大文件速度忽高忽低 | 丢包、拥塞或磁盘读取不稳定 | 重传、时延变化、磁盘吞吐 |
| 小请求延迟明显增加 | 队列过长或连接池拥塞 | 排队时间、并发数、缓冲区 |
| 部分网络无法访问 | MTU、MSS或中间设备策略异常 | 不同出口、不同报文大小 |
建议保留调整前后的配置和监控截图，设置回滚方案，并在低风险时段逐步发布。稳定性指标恶化时，即使平均吞吐有所提高，也不应视为成功。真正可靠的TCP传输优化，是让多数请求在可接受时延内稳定完成。
常见问题
1. TCP窗口越大越好吗？
不是。窗口应与带宽、往返时延、接收能力和丢包状况匹配，过大可能带来排队和重传。
2. 只修改服务器端能完成TCP传输优化吗？
不一定。客户端、服务端、中间防火墙、负载均衡器和隧道设备都可能成为限制因素，端到端协同更可靠。
3. 如何判断拥塞控制是否值得切换？
在相同链路和业务负载下，对比吞吐、尾延迟、重传和其他连接的影响；不要只看一次下载峰值。
4. MTU调整后为什么还要测试应用？
不同应用的报文大小和连接方式不同，基础连通性正常，并不代表API、文件上传和长连接业务都没有问题。
