由nginx响应时间变大引出的tcp重传和带宽限速问题

    最近接到项目组的一个问题，nginx反向代理到应用的响应respone_time变大，虽然因为一些奇葩原因，nginx反向代理是走公网访问到的app应用，但平时一般都是十几ms就能完成一次请求，但最近部分请求可能会延迟到几百ms才能完成一次，对访问造成了严重的卡顿。项目组反馈把部分流量切换到另一台nginx，延迟现象有所缓解。并且切换到的那台nginx，请求一切正常。

猜测了下问题可能的原因：

1.app本身访问延迟，但无法解释为啥部分流量切换到另一台nginx，延迟就有所缓解了，因为访问app的总流量是不会变的

2.因为走的是公网，可能公网延迟不稳定引起的，但问了下同事，两台nginx都是同一公网出口。

3.自身网络原因（可能是机器原因，也可能是别的原因）

   去服务器上追踪下路由：

发现到172.31.160.69有严重丢包。然后抓包发现，有大量的tcp重传：

询问了下同事，原来在出口针对每ip做了限速，观察出口带宽，发现限速ip带宽都打满了。于是调整了带宽限速，不再发生丢包，观察respone_time，也发现回到了正常水平。

  但为啥带宽满了会引起丢包和tcp重传，网上找了两张图来说明问题：

由于在出口做了带宽限速，因此出口路由能接收的tcp队列就受到了限速带宽的影响

当队列满时，tcp包就会被丢弃，因此追踪路由发现有大量的丢包，又由于tcp有重传机制，当nginx主机发现发送的tcp包没有响应时，会发生重传，因此抓包显示了大量的tcp重传包。队列过长和tcp包丢弃重传都会导致tcp发送到对端的延迟，也就是看到的response_time变大。因此该现象得到了解释。

参考：

http://www.taohui.pub/2019/08/07/%e4%b8%80%e6%96%87%e8%a7%a3%e9%87%8a%e6%b8%85%e6%a5%9agoogle-bbr%e6%8b%a5%e5%a1%9e%e6%8e%a7%e5%88%b6%e7%ae%97%e6%b3%95%e5%8e%9f%e7%90%86/