这篇文章主要介绍了Wireshark TS FTP传输失败问题如何解决的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇Wireshark TS FTP传输失败问题如何解决文章都会有所收获，下面我们一起来看看吧。
用户反馈说当与外部客户端进行 FTP 传输时，可以成功登录，但无法传输任何数据。总之 FTP 传输失败，需要来弄清楚到底发生了什么。
跟踪文件基本信息如下：
λ capinfos FTPFinal.pcap File name: FTPFinal.pcap File type: Wireshark/tcpdump/... - pcap File encapsulation: Ethernet File timestamp precision: microseconds (6) Packet size limit: file hdr: 65535 bytes Packet size limit: inferred: 69 bytes Number of packets: 44 File size: 3710 bytes Data size: 3555 bytes Capture duration: 34.493422 seconds First packet time: 2007-03-22 04:37:11.513913 Last packet time: 2007-03-22 04:37:46.007335 Data byte rate: 103 bytes/s Data bit rate: 824 bits/s Average packet size: 80.80 bytes Average packet rate: 1 packets/s SHA256: 36512b444dacb061e0d8a661923f1323d0c778131bedaa7bbd5b2ab810e9a09f RIPEMD160: 3e14f2dd481632867eba14503a24e92b316b5caf SHA1: 771e45893504af381de89ba6b047b5cd3fa554fd Strict time order: True Number of interfaces in file: 1 Interface #0 info: Encapsulation = Ethernet (1 - ether) Capture length = 65535 Time precision = microseconds (6) Time ticks per second = 1000000 Number of stat entries = 0 Number of packets = 44 λ
跟踪文件在 linux 上通过 tcpdump 所捕获，数据包数量并不多，只有 44 个，长度截断为 69 字节，文件数据大小 3555 字节，捕获时长 34.49 秒，平均速率 824 bps。
专家信息如下，可以看到 Warning 信息包括很多数据分段未被捕获，同时也有很多的(疑似)重传、(疑似)快速重传以及(疑似)虚假重传等问题，需要进一步实际分析。
众所周知，FTP 有主动和被动两种工作模式，而在有防火墙的网络环境中，经常会因为安全策略出现访问失败问题。如果排除了 FTP 主动和被动、防火墙安全策略等常见的可能性问题之外，那么剩下的就要专项分析了，就像这个特殊的案例。
数据包初步信息如下，为一条 FTP 控制连接，在 No.15 之后出现了大量的告警信息。既然与 TCP Seq Num 相关，那么转到专用视图上。
首先是 TCP 三次握手，此处有个明显问题的是SYN 数据包的 ACK 有数值，非 0，Wireshark 也会有明显提示 [The acknowledgment number field is nonzero while the ACK flag is not set] 。虽然有些小问题，但此处未影响 TCP 三次握手的建立。
No.4 - No.15 正常的控制交互，Request - Response 。
主要分析如下：
No.15 客户端 Request 数据包，Seq Num 为 70，Next Seq Num 为 94，同时 ACK Num 213 期望收到服务器 Seq 213 的数据包；
No.16 服务器 Response 数据包，Seq Num 为 213，但 Ack Num 为 97，不同于 No.15 的 94意思是服务器可能收到了客户端发送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的两个 TCP 分段，因此 No.16 ACK Num 为 97；此处只是疑似捕获时丢失了客户端发送的后一个 3 字节的分段（Seq 94，Next Seq 97 ），所以提示 TCP ACKed unseen segment ；
No.17 客户端发出的 ACK 数据包 Seq Num 为 94，此处和 No.16 的期望 97 无法对应上，同时客户端 No.15 ACK 期望收到 Seq 213，No.16 Seq Num 也为 213，但是客户端并不认可 No.16 数据包，因此 No.17 ACK Num 仍为 213；
问题貌似出现在服务器发送的 No.16 数据包上，需要继续展开部分字段辅助判断，譬如 IP ID。
可以看到客户端 No.15、No.17、No.19 ...... IP ID 是逐步递增的，意味着客户端并没有发送过 Seq 94，Next Seq 97 的 TCP 分段，因此对于服务器，上述分析 2 中的结论并不正确（可能收到了客户端发送的 Seq 70，Next Seq 94 和 Seq 94，Next Seq 97 的两个 TCP 分段）。
那么具体问题是什么呢？让我们做一个假设，客户端数据包在传输过程中发生了变化，额外多出来了 3 个字节，是否符合问题现象。
服务器侧，收到了 No.15 Seq Num 70，Next Seq Num 97，ACK Num 213的数据包，所以回复了 No.16 Seq Num 213，ACK Num 97的数据包；
客户端侧，收到了 No.16 Seq Num 213，ACK Num 97，由于 ACK Num 的异常（不同于 94），客户端实际忽略了该数据包，产生一个 No.17 ACK 数据包，ACK Num 仍然为 213；
服务器侧，收到了 No.17 Seq Num 94，Next Seq Num 97，ACK Num 213的数据包，之后由于 No.16 发生超时重传，重新发送了 No.18 Seq Num 213，ACK Num 97的数据包；
客户端侧，由于 No.15 超时，产生了重传，所以重新发送了 No.19 Seq Num 70，Next Seq Num 94，ACK Num 213的数据包；
服务器侧，收到了 No.19 Seq Num 70，Next Seq Num 97，ACK Num 213的数据包，回复了 No.20 Seq Num 243，ACK Num 97的数据包；
之后由于客户端 -> 服务器传输方向上，持续的 94 -> 97 多出 3 个字节，问题持续。
总之，问题可能出现在中间传输路径上的设备，可能是 NAT 或是防火墙等设备，增加了客户端从未发送的 3 个额外字节，所以服务器回复的 ACK 也增加了 3 个字节，造成一系列连续问题。
关于“Wireshark TS FTP传输失败问题如何解决”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“Wireshark TS FTP传输失败问题如何解决”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
