Linux性能优化实战 40 ：网络延迟问题

一、查看延迟情况

1. 确定网络延迟，更常用的是双向的往返通信延迟RTT（Round-Trip Time）。

2. 很多网络服务会把 ICMP 禁止掉，所以需要使用traceroute 或 hping3 的 TCP 和 UDP 模式，来获取网络延迟。

从 hping3 的结果中，你可以看到，往返延迟 RTT 为 20.9ms。

traceroute 会在路由的每一跳发送三个包，并在收到响应后，输出往返延时。

如果无响应或者响应超时（默认 5s），就会输出一个星号。

 

二、高并发时的延迟情况查看及优化策略

1. 使用 wrk 来模拟并发100的网络情况

延迟大了很多。

2. 客户端的TCP 延迟确认

    不用每次请求都发送一个 ACK，而是先等一会儿（比如 40ms），如果这段时间内，正好有其他包需要发送，那就捎带着 ACK 一起发送过去。如果一直等不到其他包，那就超时后单独发送 ACK。

3. 服务端的Nagle 算法，是用于减少小包发送数量的一种优化算法，目的是为了提高实际带宽的利用率。

    它通过合并 TCP 小包，提高网络带宽的利用率。规定：

(1) 多个小分组合并成一个分组，一起发送

(2) 一个 TCP 连接上，最多只能有一个未被确认的分组；

(3)在收到这个分组的 ACK 前，不发送其他分组;

    它提高了带宽利用率，但是导致网络延迟加大(第二个分组必须在第一个分组完成后才能发出去)

4. 客户端的TCP 延迟确认,和 服务端的Nagle 算法 一起使用时带来的问题。

(1) 当 Sever 发送了第一个分组后，Client 需要等待 40ms 后才会回复 ACK。

(2) 没收到第一个分组的 ACK，会一直等着

(3) Client 回复 ACK后，Server 才会继续发送第二个分组。

5.  解决办法：

    服务端启用tcp_nodelay(即禁用nagle算法)