收藏文章 楼主

tcp retransmission 出现的原因_TCP重传问题排查思路与实践

版块:疑难   类型:普通   作者:小绿叶技术博客   查看:2703   回复:0   获赞:0   时间:2021-11-07 15:03:15

 图 under the strange horizon  by joeyjazz


一 关于TCP重传


TCP有重传是正常的机制,为了保障数据传输可靠性。只是局域网环境,网络质量有保障,因为网络问题出现重传应该极低;互联网或城域网环境,线路复杂(可以想象下城市地下管网,错综复杂的电线杆等),网络质量不好保障,重传出现概率较高。


TCP有重传,也不一定是网络层面的问题。也可能是接收端不存在,接收端receive buffer满了,应用程序有异常链接未正常关闭等等等。


二 TCP/IP相关

排查网络问题,要掌握TCP/IP原理,真相都在一个一个的数据包里。以下是和TCP重传比较关键的几个参数。


2.1 建立TCP链接时的参数

其他参考:


/proc/sys/net/ipv4/* Variables: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt


2.2 TCP重传类型

超时重传


在请求包发出去的时候,开启一个计时器,当计时器达到时间之后,没有收到ACK,则就进行重发请求的操作,一直重发直到达到重发上限次数或者收到ACK。


快速重传


当接收方收到的数据包是不正常的序列号,那么接收方会重复把应该收到的那一条ACK重复发送,这个时候,如果发送方收到连续3条的同一个序列号的ACK,那么就会启动快速重传机制,把这个ACK对应的发送包重新发送一次。具体可以参考: 


3180a50229fb5216d613193043b9569d.png


三 常见问题与措施

3.1单台机器或单个应用机器tcp重传,可能是链接的服务器或端口无法访问

排查思路

3.2 多台机器或多个应用同时tcp重传,可能是网络抖动

排查思路

3.3 带宽跑满

排查思路

3.4 不常见问题

1 网络设备端口或光模块异常等导致包checksum失败


2 网络路由收敛抖动


3 主机网络驱动有bug,网络设备有bug等


四 如何监控

使用tsar -tcp -C 可以监控到tcp的retran属性也即是重传次数。


tsar --tcp -C | sed 's/:/_/g;s/=/ /g' | xargs -n 2


e05b1085ac9b15dad6cfc06a62c138fc.png


感兴趣的朋友可以直接执行以下监控脚本获取tcp相关的状态监控数据,适用于open-falcon。


metric_item="{\"endpoint\":\"${HOSTNAME}\",\"tags\":\"${tags}\",


\"timestamp\":${timestamp},\"metric\":\"$metric\",


\"value\":${getvalue},\"counterType\":\"GAUGE\",


\"step\":60}"


if [ "${data_item}x" = "x" ];then

data_item="$metric_item" else data_item="${data_item},${metric_item}" fi

done

echo "[$data_item]"

五 案例实践

1 在遇到丢包重传的机器上抓包并使用wireshark 分析该包,注意因为重传不是时刻都有的,所以抓包命令是要持续执行以便捕捉到重传的包。使用wireshark打开tcpdump的结果,在搜索框里入手tcp.analysis.retransmission 得到如下结果:


c4531b352ec02e6366f2f21e5e17a602.png


图1 表明服务端发生了三次重传动作。


2 由于包比较多,我们可以使用wireshark的追踪流功能获取重传相关的tcp流 


ddbb2a78a1c9ae27b8fe970606a165dd.png


图二 追踪流-->TCP流 可以得到重传相关的数据包


2273264b4a3945fe0fe60b96a904c14f.png


图三 可以看出客户端和服务端的请求与应答。


3 解析重传


7e191971b5486d7b9d2ca9cfd6cf166e.png


特别需要说明的是


NO 67,68 client端由于某些原因没有收到正确的包数据,向server端发送dup ack,参考基础知识提到的快速重传


NO.68和NO.69之间的时间差200ms(关注time那一列,其他都是相差小于1ms),server等待超时,于是重传。


NO 73-74是client端发送了一个fin包并主动关闭连接。


这个案例仅仅发生一次,没有复现,通过抓包解析出来分析没有得到明确的结论。


六 小结

本文总结自己工作过程中遇到的TCP重传问题的解决过程 ,侧重于大致的解决问题的思路与具体的实践,理论知识偏少,大家有兴趣的可以阅读推荐文章以便深入了解tcp的工作机制。


推荐文章

tcp 重传系列文章


https://www.cnblogs.com/lshs/p/6038516.html https://www.cnblogs.com/lshs/p/6038527.html https://www.cnblogs.com/lshs/p/6038536.html


网络性能排查之TCP重传与重复ACK https://www.kancloud.cn/digest/wireshark/62473


一站式学习wireshark https://www.kancloud.cn/digest/wireshark 


TCP重传  http://www.vants.org/?post=36 本文有图文介绍。


https://blog.csdn.net/weixin_39583623/article/details/111107829


提供企业建站服务,免费网防系统,提交信息登录 http://yundun.ddoss.cn 邮箱: proposal@ddoss.cn 
回复列表
默认   热门   正序   倒序

回复:tcp retransmission 出现的原因_TCP重传问题排查思路与实践

头像

用户名:

粉丝数:

签名:

资料 关注 好友 消息