tcp retransmission dup ack 偶尔_TCP重传问题的排查思路与实践，有点干货

1、关于TCP重传

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

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

2、TCP/IP相关

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

2.1 建立TCP链接时的参数

2.2 TCP重传类型

超时重传

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

快速重传

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

3、常见问题与措施

3.1单台机器或单个应用机器tcp重传

可能是链接的服务器或端口无法访问

排查思路

3.2 多台机器或多个应用同时tcp重传

可能是网络抖动

排查思路

1查看网络区域埋点，查看网络设备报警，看是否有区域网络抖动2区域网络没问题的话。可以用常见问题：的方法缩小排查范围

3.3 带宽跑满

排查思路

1、查看主机监控，

3.4 不常见问题

1 网络设备端口或光模块异常等导致包checksum失败 2 网络路由收敛抖动 3 主机网络驱动有bug，网络设备有bug等

4、如何监控

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

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

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

5、案例实践

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包并主动关闭连接。

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

6、小结

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

我目前是在职Java开发，如果你现在正在了解Java技术，想要学好Java，渴望成为一名Java开发工程师，在入门学习Java的过程当中缺乏基础的入门视频教程，你可以关注并私信我：01。我这里有一套最新的Java基础JavaSE的精讲视频教程，这套视频教程是我在年初的时候，根据市场技术栈需求录制的，非常的系统完整。