☰

TCP 重传延迟 - 丢失确认

tag-icon • tag-icon linux-networking tcp performance-tuning latency
TCP 重传延迟 - 丢失确认

也许有人能帮我解决这个问题。我正在尝试找出是否可以优化服务器端以减少数据包丢失时的延迟。

环境：Windows 2012 客户端，CentOS 6.x 服务器 [Couchbase]，同一数据中心，繁忙的 LAN，需要穿越防火墙。两者都是大型物理服务器，具有充足的备用容量。

问题：从客户端测量，响应时间分布在约 1 毫秒左右，但我们看到约 200 毫秒处出现峰值。

网络跟踪显示：

  1. 客户端->发送请求
  2. 服务器 -> 使用包含{应用程序响应 + TCP 确认请求数据包} 的数据包进行回复（1 毫秒）（在本例中为 78 字节）
  3. 客户端未收到数据包
  4. 约 30 毫秒后，客户端 TCP 堆栈重新传输原始请求
  5. 服务器立即回复DUP ACK（66字节，不包含应用程序响应）
  6. 从初始请求发出后约 200 毫秒，服务器重新传输原始响应（78 字节数据包）。

知道这 200ms 的延迟是从哪里来的吗？如何减少它？我猜是 tcp 延迟确认、nagle 和拥塞/RTO 算法的某种组合，但 Linux 内核调优对我来说有点神秘。

有什么建议吗？

答案1

是的，双方都使用 wireshark、tcpdump、在交换机级别（相当高端的 Arista 10G 交换机）获取的网络跟踪、在防火墙（Fortinet）上获取的跟踪等等。

问题不在于客户端为什么没有收到回复。这是一个繁忙的网络，流量突发，因此丢失 10,000 个数据包中的一个并不意外。但即使我丢失了一个数据包，我也需要提供 SLA，而这 200 毫秒的延迟正在影响它。

我的意思是，在 DEV 上进行实验时，我可以通过路由命令 [服务器端] 将客户端子网的 TCP RTO 设置为 5ms 来“修复”问题。这样，99.999% 的请求都会在 10ms 内得到答复，并且我会满足我的 SLA。很好，但在生产中这样做有什么缺点？RTO 是真正的问题吗，还是我无意中修复了它？这是解决问题的最佳方法吗，还是有更聪明/更好的方法（调整配置文件？sysctl 参数？向 minix 神祈祷？）？

谢谢

相关内容