内容简介:图 under the strange horizon by joeyjazz一 关于TCP重传
图 under the strange horizon by joeyjazz
一 关于TCP重传
-
TCP 有重传是正常的机制,为了保障数据传输可靠性。只是局域网环境,网络质量有保障,因为网络问题出现重传应该极低;互联网或城域网环境,线路复杂(可以想象下城市地下管网,错综复杂的电线杆等),网络质量不好保障,重传出现概率较高。
-
TCP 有重传,也不一定是网络层面的问题。也可能是接收端不存在,接收端receive buffer满了,应用程序有异常链接未正常关闭等等等。
二 TCP/IP相关
排查网络问题,要掌握TCP/IP原理,真相都在一个一个的数据包里。以下是和 TCP 重传比较关键的几个参数。
2.1 建立 TCP 链接时的参数
net.ipv4.tcp_syn_retries#syn包重传多少次后放弃,重传间隔是2的n次方(1s,2s,4s..) net.ipv4.tcp_synack_retries#syn ack包重传多少次后放弃 net.ipv4.tcp_max_syn_backlog#syn包队列
其他参考:
/proc/sys/net/ipv4/* Variables: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
2.2 TCP重传类型
超时重传
在请求包发出去的时候,开启一个计时器,当计时器达到时间之后,没有收到ACK,则就进行重发请求的操作,一直重发直到达到重发上限次数或者收到ACK。
快速重传
当接收方收到的数据包是不正常的序列号,那么接收方会重复把应该收到的那一条ACK重复发送,这个时候,如果发送方收到连续3条的同一个序列号的ACK,那么就会启动快速重传机制,把这个ACK对应的发送包重新发送一次。具体可以参考:
三 常见问题与措施
3.1单台机器或单个应用机器tcp重传,可能是链接的服务器或端口无法访问
排查思路
# 1、抓1000或者更多个tcp包 # 出现2次以上seq一样的包就是发生了重传 # syn包重传间隔是指数增加 # 已经建立了链接的tcp重传间隔,参考RTO # 收到比较多ack重传,一般说明数据包出现乱序,seq较大的先到达了目的端,发送端收到3次sack会触发立即快速重传缺失的tcp分片。快速重传不太影响rt,但是发送窗口立即减半,会对吞吐带宽有一定影响 # 云环境虚拟机,还要考虑分析宿主机的问题 sudo ss -anti |grep -B 1 retrans #重传统计 if=bond0 sudo tcpdump -w /tmp/tcp.pcap -i $if -c 1000 -nn tcp 2>/dev/null sudo tcpdump -nn -r /tmp/tcp.pcap | awk '{print $3,$5,$8,$9}' | sort | uniq -c | sort -rn |sed 's/^ \{1,\}//g'|egrep -v "^1 |Request" 2、联通性检查 ping $ip nc -nvz $ip $port 3、接收端应用程序问题排查;来源和目的抓包,wireshark分析具体是什么包丢失导致了重传
3.2 多台机器或多个应用同时tcp重传,可能是网络抖动
排查思路
1、查看网络区域埋点,查看网络设备报警,看是否有区域网络抖动 2、区域网络没问题的话。可以用常见问题:1 的方法缩小排查范围
3.3 带宽跑满
排查思路
1、查看主机监控,检查是否带宽跑满 2、检查重传联路上相关的网络设备是否有带宽跑满
3.4 不常见问题
1 网络设备端口或光模块异常等导致包checksum失败
2 网络路由收敛抖动
3 主机网络驱动有bug,网络设备有bug等
四 如何监控
使用tsar -tcp -C 可以监控到tcp的retran属性也即是重传次数。
tsar --tcp -C | sed 's/:/_/g;s/=/ /g' | xargs -n 2
感兴趣的朋友可以直接执行以下监控脚本获取tcp相关的状态监控数据,适用于open-falcon。
#!/usr/bin/env bash HOSTNAME=`hostname` timestamp=`date +%s` tagapp="app=tsar.collect" data_item="" tsarcollectstring=`/opt/tsar/bin/tsar --tcp -C | sed 's/:/_/g;s/=/ /g' | xargs -n 2 | tail -n +2|sed 's/ /|/'` for i in $tsarcollectstring do getkey=`echo $i|awk -F "|" '{print $1}'` getvalue=`echo $i|awk -F "|" '{print $2}'` tags="$tagapp" metric="tsar.collect.$getkey"
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 得到如下结果:
图1 表明服务端发生了三次重传动作。
2 由于包比较多,我们可以使用wireshark的 追踪流功能 获取重传相关的tcp流
图二 追踪流-->TCP流 可以得到重传相关的数据包
图三 可以看出客户端和服务端的请求与应答。
3 解析重传
特别需要说明的是
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 本文有图文介绍。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- SSH 登陆问题及排查思路
- 提供一个排查性能问题的思路
- Flink Checkpoint超时问题常见排查思路
- 从排查端口弱口令研究打造完美防御的思路
- Flink on YARN(下):常见问题与排查思路
- MySQL CPU 彪高到百分之 1000 的排查思路
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Coding the Matrix
Philip N. Klein / Newtonian Press / 2013-7-26 / $35.00
An engaging introduction to vectors and matrices and the algorithms that operate on them, intended for the student who knows how to program. Mathematical concepts and computational problems are motiva......一起来看看 《Coding the Matrix》 这本书的介绍吧!