混沌工程之ChaosMesh使用之四模拟网络Duplicate包
标签: 混沌工程之ChaosMesh使用之四模拟网络Duplicate包 JavaScript博客 51CTO博客
2023-04-04 18:23:37 132浏览
今天我们来玩一下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 = 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的函数?
好博客就要一起分享哦!分享海报
此处可发布评论
评论(0)展开评论
展开评论