再说TCP神奇的40ms

TCP是一个复杂的协议,每个机制在带来优势的同时也会引入其他的问题。 Nagel算法和delay ack机制是减少发送端和接收端包量的两个机制, 可以有效减少网络包量,避免拥塞。但是,在特定场景下, Nagel算法要求网络中只有一个未确认的包, 而delay ack机制需要等待更多的数据包, 再发送ACK回包, 导致发送和接收端等待对方发送数据, 造成死锁, 只有当delay ack超时后才能解开死锁,进而导致应用侧对外的延时高。 其他文字已经介绍了相关的机制, 已经有一些文章介绍这种时延的场景。本文结合具体的tcpdump包,分析触发delay ack的场景,相关的内核参数, 以及规避的方案。

背景

给redis加了一个proxy层, 压测的时候发现, 对写入命令,数据长度大于2k后, 性能下降非常明显, 只有直连redis-server的1/10. 而get请求影响并不是那么明显。

分析

观察系统的负载和网络包量情况, 都比较低, 网络包量也比较小, proxy内部的耗时也比较短。 无赖只能祭出tcpdump神奇, 果然有妖邪。

22号tcp请求包, 42ms后服务端才返回了ack。 初步怀疑是网络层的延时导致了耗时增加。Google和km上找资料, 大概的解释是这样: 由于客户端打开了Nagel算法, 服务端未关闭延迟ack, 会导致延迟ack超时后,再发送ack,引起超时。

原理

Nagel算法,转自维基百科

if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now  else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

简单讲, Nagel算法的规则是:

  1. 如果发送内容大于1个MSS, 立即发送;
  2. 如果之前没有包未被确认, 立即发送;
  3. 如果之前有包未被确认, 缓存发送内容;
  4. 如果收到ack, 立即发送缓存的内容。

延迟ACK的源码如下:net/ipv4/tcp_input.c

基本原理是:

  1. 如果收到的数据内容大于一个MSS, 发送ACK;
  2. 如果收到了接收窗口以为的数据, 发送ACK;
  3. 如果处于quick mode, 发送ACK;
  4. 如果收到乱序的数据, 发送ACK;
  5. 其他, 延迟发送ACK

其他都比较明确, quick mode是怎么判断的呢? 继续往下看代码:

影响quick mode的一个因素是 ping pong的状态。 Pingpong是一个状态值, 用来标识当前tcp交互的状态, 以预测是否是W-R-W-R-W-R这种交互式的通讯模式, 如果处于, 可以用延迟ack, 利用Read的回包, 将Write的回包, 捎带给发送方。

如上图所示, 默认pingpong = 0, 表示非交互式的, 服务端收到数据后, 立即返回ACK, 当服务端有数据响应时,服务端将pingpong = 1, 以后的交互中, 服务端不会立即返回ack,而是等待有数据或者ACK超时后响应。

问题

按照前面的的原理分析,应该每次都有ACK延迟的,为什么我们测试小于2K的数据时, 性能并没有受到影响呢?

继续分析tcpdump包:

按照Nagel算法和延迟ACK机制, 上面的交互如下图所示, 由于每次发生的数据都包含了完整的请求, 服务端处理完成后, 向客户端返回命令响应时, 将请求的ACK捎带给客户端,节约一次网络包。

再分析2K的场景:

如下表所示, 第22个包发送的数据小于MSS, 同时,pingpong = 1, 被认为是交互模式, 期待通过捎带ACK的方式来减少网络的包量。 但是, 服务端收到的数据,并不是一个完整的包,不能产生一次应答。服务端只能在等待40ms超时后,发送ACK响应包。

同时,从客户端来看,如果在发送一个包, 也可以打破已收数据 > MSS的限制。 但是,客户端受Nagel算法的限制, 一次只能有一个包未被确认,其他的数据只能被缓存起来, 等待发送。

触发场景

一次tcp请求的数据, 不能在服务端产生一次响应,或者小于一个MSS

规避方案

只有同时客户端打开Nagel算法, 服务端打开tcp_delay_ack才会导致前面的死锁状态。 解决方案可以从TCP的两端来入手。

服务端:

  1. 关闭tcp_delay_ack, 这样, 每个tcp请求包都会有一个ack及时响应, 不会出现延迟的情况。 操作方式: echo 1 > /proc/sys/net/ipv4/tcp_no_delay_ack 但是, 每个tcp请求都返回一个ack包, 导致网络包量的增加,关闭tcp延迟确认后, 网络包量大概增加了80%,在高峰期影响还是比较明显。

2.设置TCP_QUICKACK属性。 但是需要每次recv后再设置一次。 对应我们的场景不太适合,需要修改服务端redis源码。

客户端:

  1. 关闭nagel算法,即设置socket tcp_no_delay属性。static void _set_tcp_nodelay(int fd) { int enable = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (void*)&enable, sizeof(enable)); }
  2. 避免多次写, 再读取的场景, 合并成一个大包的写;避免一次请求分成多个包发送, 最开始发送的包小于一个MSS,对我们的场景, 把第22号包的1424个字节缓存起来, 大于一个MSS的时候,再发送出去, 服务端立即返回响应, 客户端继续发送后续的数据, 完成交互,避免时延。

原文发布于微信公众号 - nginx(nginx-study)

原文发表时间:2018-05-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

Java 程序员必备的 IntelliJ IDEA 插件

IntelliJ 在业界被公认为最好的 java 开发工具之一,尤其在智能代码助手、代码自动提示、重构、CVS 整合、代码审查、 创新的 GUI 设计等方面的功...

25850
来自专栏Java进阶架构师

「架构技术专题」构建网站高可用架构(详细分析篇)(6)

可用性指标时网站架构设计的重要指标,对外是服务承诺,对内是考核指标,具体到每个工程师,更多的是使用故障分。

8630
来自专栏漏斗社区

安全运维中基线检查的自动化之ansible工具巧用

前几周斗哥分享了基线检查获取数据的脚本,但是在面对上百台的服务器,每台服务器上都跑一遍脚本那工作量可想而知,而且都是重复性的操作,于是斗哥思考能不能找到一种方法...

31530
来自专栏北京马哥教育

corosync+pacemaker高可用集群

简介 高可用集群,是指以减少服务中断(如因服务器宕机等引起的服务中断)时间为目的的服务器集群技术。简单的说,集群就是一组计算机,它们作为一个整体向用户提供一组网...

353120
来自专栏java达人

Kafka最佳实践

作者:Sriharsha Chintalapani, Jay Kumar SenSharma 译者:java达人 来源:https://community.ho...

26700
来自专栏北京马哥教育

corosync+pacemaker高可用集群

一、简介 高可用集群,是指以减少服务中断(如因服务器宕机等引起的服务中断)时间为目的的服务器集群技术。简单的说,集群就是一组计算机,它们作为一个整体向用户提供一...

688150
来自专栏大前端开发

微信小程序之生成自定义参数小程序二维码

扫码已经成为一种常见又方便的进入移动应用的途径,可以把线上线下的用户流量带入你的移动应用中来。微信小程序也提供了扫码进入的功能,可以通过扫描二维码或者微信小程序...

71440
来自专栏大史住在大前端

webpack4.0各个击破(4)—— Javascript & splitChunk

javascript之所以需要打包合并,是因为模块化开发的存在。开发阶段我们需要将js文件分开写在很多零碎的文件中,方便调试和修改,但如果就这样上线,那首页的h...

17630
来自专栏眯眯眼猫头鹰的小树杈

记录分布式一致性中的几个概念

事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元,狭义上的事务特指数据库事务。事务具有ACID属性。

21520
来自专栏杨建荣的学习笔记

通过celery提高crontab配置效率

今天在接入备份任务配置的时候也是一波三折,解决了业务元数据的问题,也逐步熟悉了业务,对于现有的备份情况会越来越有把握。

20820

扫码关注云+社区

领取腾讯云代金券