混沌工程之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- 在界面上配置完成提交后即开始执行。
验证
- 进入被模拟的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 = 15tcp_retries1 = 3 是指重传了3次后，如果还没收到ACK，则后续重传中会先更新路由。
tcp_retries2 = 15 是指最多重传15次，15次都传不成功，那就放弃了。
正常情况下，你看到这里就可以结束了。但也不排除有些人想看明白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的函数？
腾讯云开发者
