企业🤖AI智能体构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
# 网络基本功(二十五):Wireshark抓包实例分析TCP重复ACK与乱序 **转载请在文首保留原文出处:EMC中文支持论坛**[https://community.emc.com/go/chinese](https://community.emc.com/go/chinese) [![image001.gif](https://community.emc.com/servlet/JiveServlet/downloadImage/2-863284-106692/image001.gif)](https://community.emc.com/servlet/JiveServlet/showImage/2-863284-106692/image001.gif) ## 介绍 TCP的一大常见问题在于重复ACK与快速重传。这一现象的发生也是由于性能问题,本章讨论如何发现这一问题以及他们意味着什么。 另一个常见问题是前一片段丢失以及乱序片段。某些情况下,这一现象喻示着故障发生,可能是由于网络问题或是抓包中断。 ## 更多信息 **重复ACK与快速重传:** 当网速变慢时,重复ACK是可能的原因之一。大多数情况下,重复ACK的发生是由于高延时,延迟的变化,或无法响应ACK请求的慢速终端。 1. 当重复ACK的数量保持在合理范围时,即1或2个百分比,则可能不是本机问题。 2. 当有大量的重复ACK时(假设有10个),则可能: * 通信链路繁忙引起延迟改变 * 服务器或客户端无响应 3. 快速重传是对重复ACK的响应报文。 4. 下图是该问题的示例。本例中51个重复ACK之后发生了快速重传: [![image002.jpg](https://community.emc.com/servlet/JiveServlet/downloadImage/2-863284-106693/670-300/image002.jpg)](https://community.emc.com/servlet/JiveServlet/showImage/2-863284-106693/image002.jpg) 5. 以下是如何解决该问题: * 如果重复ACK和重传数量较少(少于1个百分比),是可以接受的。 * 如果重复ACK发生在无线网络环境,或是Internet之上的连接,延时或是延时的改变对于这类网络来说很常见,所以也没有什么可做的。 * 如果发生在组织内的网络,则可能有问题。如果发生在LAN之上,检查严重的问题,例如缓存和CPU负载,慢速服务器,等等。如果发生在WAN之上,查看延时,负载以及线路不稳定。 工作原理 当发现有丢失报文时(期望的序列号没有收到),或者收到了预期之外的序列号。这种情况下,接收端生成一个ACK,声明自己希望收到的下一个序列号。接收方持续生成丢失片段的ACK请求,直到实际收到。 在发送方,当它收到三个相同的ACK(初始ACK和两个重复ACK),就会假设有报文丢失并重传该报文,无论重传计时器是否过期。再次发送的报文称为快速重传。 重复ACK也减少了发往网络的吞吐量。减少了多少吞吐量取决于TCP版本。比较早期的TCP版本中出现了重复ACK,发送方将吞吐量减少为之前的一半。在多个DupACK的情况下,吞吐量减到最小。 下图显示了重复ACK和重传的典型例子,本图中第一次重复ACK将吞吐量降低至大约40%,之后重传将吞吐量减至最小。 [![image003.jpg](https://community.emc.com/servlet/JiveServlet/downloadImage/2-863284-106694/670-434/image003.jpg)](https://community.emc.com/servlet/JiveServlet/showImage/2-863284-106694/image003.jpg) **乱序报文:** 在两端抓包,乱序情况下需要关注三种现象: * **先前片段丢失**:当前收到报文的序列号高于该连接的下一个期望序列号时,表明之前的一个或多个报文未能到达 * **乱序报文**:当前报文的序列号低于该连接先前收到的报文 * **先前片段未能捕捉**:(Wireshark 1.8.x及以上版本):同先前报文丢失。 何时发生? 用户可能在以下情况看到乱序报文: * **连接开始时抓包**:当建立连接时抓包,这时,看到连接上的报文没有SYN/SYN-ACK/ACK,因此,Wireshark认为连接有问题。 * **确实有报文丢失**:这时会看到丢失报文重传和/或重复ACK告知发送方重传丢失报文。 [![image004.jpg](https://community.emc.com/servlet/JiveServlet/downloadImage/2-863284-106695/670-155/image004.jpg)](https://community.emc.com/servlet/JiveServlet/showImage/2-863284-106695/image004.jpg) 上图是报文丢失的典型示例。从图中可见,10.0.0.6尝试浏览站点62.90.90.210。这一过程中, TCP片段每个1420字节发送到web服务器,334到336之间3个报文丢失,338到340之间2个报文丢失。两者Wireshark都有提示:TCP’s previous segment is not captured. * **延时变化**:这可能是由于报文从源地址到目的地址经由不同的路由。检查这一点可以使用Tracert,在源和目的地址之间查找路由改变。如果在公司内部网络上是可以做到的,例如,在路由器上配置trap。 * **数据捕捉问题**:可能报文正常收发,但Wireshark没有捕捉到。可能有以下几种原因: * 数据量比较大时,Wireshark在高比特率的情况下可能会丢失报文(高于150-180 Mbps)。要避免这一问题,使用其他工具(大多数需要付费)。 * 台式机不够强大,内存或CPU无法让Wireshark工作的足够快。这一点很好发现。 * 当LAN交换机的端口缓存太小,报文可能被丢弃。连接到交换机(用控制台或telnet连接)使用交换机命令行来检查该问题。 * 无线网络抓包,由于某种原因没有看到所有发送报文。 总结 乱序报文的原理很简单。TCP发送以其字节数为编号的报文到接收方。当一个报文没有按照顺序到达时,Wireshark就会注意到。原因有两点: * **确实有问题**:这时会看到重传和重复ACK,这是TCP对于收到乱序报文的响应。 * **抓包问题**:这时仅看到乱序报文,但没有看到对可能丢失及乱序报文的响应,可能实际上并没有问题。 ## 参考 Network Analysis Using Wireshark Cookbook