混沌工程之ChaosMesh使用之四模拟网络Duplicate包

今天我们来玩一下ChaosMesh模拟网络duplicate包的情况。同时也要看一下对应用产生的直接影响。

目标

模拟网络重复包。

配置

• yaml文件配置

[root@s5 ChaosMesh]# cat network-duplicate.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-duplicate
  namespace: chaos
spec:
  action: duplicate
  mode: one
  selector:
    labelSelectors:
"k8s.kuboard.cn/name": "svc-7dmall"
  duplicate:
    duplicate: "40"
    correlation: "25"
  duration: "10s"
  scheduler:
    cron: '@every 15s'

• 界面配置

执行

• 在命令行执行：

[root@s5 ChaosMesh]# kubectl apply -f network-duplicate.yaml
networkchaos.chaos-mesh.org/network-duplicate created

• 在界面上配置完成提交后即开始执行。

验证

1. 进入被模拟的POD，先查看qdisc上增加的规则，再执行tcpdump抓包。

- 查看qdisc上的规则
[root@svc-7dmall-664d59f75b-whtvc /]# tc qdisc ls dev eth0
qdisc netem 1: root refcnt 2 limit 1000 duplicate 40%
[root@svc-7dmall-664d59f75b-whtvc /]#

- 执行tcpdump抓包
[root@svc-7dmall-664d59f75b-whtvc /]# tcpdump -i eth0 -w networkduplicate.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes


^C195 packets captured
195 packets received by filter
0 packets dropped by kernel
[root@svc-7dmall-664d59f75b-whtvc /]#

从上面的结果看抓到了195个包。

2. 进入pod所在机器或用其他工具把抓到的文件复制到本地。

[root@s7 ~]# docker cp 3d4ab3241d8a:/networkduplicate.cap ./

3. 用wireshark打开查看。

确实出现了大量的重复包。

正常抓包结果是这样的：

4. 用jmeter开始一个线程访问应用，持续60s，看下有什么区别。

• 有重复包的结果：

• 无重复包的结果：

从上面的结果来看，产生重复包的时候，对性能的影响还是不小的。

应用直接的感受就是：响应时间长、TPS下降。

用户直接的感受就是：慢但有响应或慢直到报错。

5. 进入被模拟的POD，再次查看qdisc上的规则

[root@svc-7dmall-664d59f75b-whtvc /]# tc qdisc ls dev eth0
qdisc noqueue 0: root refcnt 2
[root@svc-7dmall-664d59f75b-whtvc /]#

恢复

• 在界面上停止案例

• 用命令行停止案例

[root@s5 ChaosMesh]# kubectl delete -f network-duplicate.yaml
networkchaos.chaos-mesh.org "network-duplicate" deleted
[root@s5 ChaosMesh]#

重传原理逻辑说明和RTO计算过程

重复包产生的原因有很多，像应用故障、网络设备故障、服务宕机等等。

我们这里主要来说明一下重传的逻辑。

决定报文重传机制的是重传计时器（retransmission timer），它的功能是维护重传超时值（retransmission timeout）。

发出报文后，重传计时器启动，收到ACK后计时器停止。如果未收到ACK，发送方认为报文丢失并重传，同时RTO加倍；如果2倍RTO之后还没收到ACK，则再次重传。

在linux中重传次数默认最大为15次，由两个参数控制：

net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15

tcp_retries1

tcp_retries2

正常情况下，你看到这里就可以结束了。但也不排除有些人想看明白RTO的计算逻辑。那就接着看。

也许你会问RTO是多长时间？在Linux源码中，有这样的定义（源码路径include/net/tcp.h，在我这个3.10版本的内核代码中是134、135行）：

#define TCP_RTO_MAX  ((unsigned)(120*HZ))
#define TCP_RTO_MIN  ((unsigned)(HZ/5))

看到这里，知道RTO有最大最小值，分别是 HZ/5 和 120*HZ 。但是又有疑问，那HZ是什么值？你可以在系统中执行如下命令获得。

[root@s5 ~]# cat /boot/config-`uname -r` | grep '^CONFIG_HZ='
CONFIG_HZ=1000

在我的系统中值是1000，也就是说RTO的最小值是200、最大值是120000（单位是毫秒）。

但是这个RTO又是怎么算来的呢？这个值由__tcp_set_rto（3.10源码路径include/net/tcp.h中606-609行）函数算出（其中srtt的计算逻辑，我就不展开了，越说越多越容易乱，有兴趣的可以自己去查查资料）。

static inline u32 __tcp_set_rto(const struct tcp_sock *tp)
{
  return (tp->srtt >> 3) + tp->rttvar;
}

这个函数算出来的值不可以小于TCP_RTO_MIN的值。

而RTO的最大值又由谁来确定呢？那就是tcp_bound_rto（3.10源码路径include/net/tcp.h中600-604行）了。

static inline void tcp_bound_rto(const struct sock *sk)
{
  if (inet_csk(sk)->icsk_rto > TCP_RTO_MAX)
    inet_csk(sk)->icsk_rto = TCP_RTO_MAX;
}

以上就是RTO的计算逻辑。

留下思考的空间：

1. 怎么分析网络包重传的原因？

2. 有没有设置最小RTO的函数？