问题背景
用户反馈 FTP 下载慢。业务在遇到应用通讯不正常、连接中断、传输慢等问题时，一般都会第一时间怀疑网络。网络慢、网络卡、网络不通等问题，简直是网络工程师的梦魇，而其中慢的问题和案例尤其多，继续学习分享之。
案例取自 Wireshark 官方问答论坛
问题描述
该问题提出者描述两客户端通过长途专线进行连接，往返时间约 36ms。通过 FTP 从 251 客户端上传到 179 客户端时，速度为 3.5MBps，正常无问题。但是通过 FTP 从 179 客户端下载到 251 客户端时，速度仅为 538KBps，相较正常速度低很多。捕获的数据包反馈出很多的 “Tcp Dup Ack”, “TCP Retransmission” 和 “TCP Out-Of-Order”。
问题分析
基础分析
验证题主所提到的基本情况，数据包中共有两条 tcp.stream ，其中一条为 FTP 21 控制连接，另一条为 FTP 20 数据连接。
数据包可以看出是在客户端 10.240.12.251 上所抓取，IRTT 为 0.036169000 s 。会话速率为 3950bps，即 493.75 KBps ，和题主所说基本一致。
深度分析
通过查看专家分析，发现有比较明显的丢包重传、乱序等现象。
10.224.180.179 -> 10.240.12.251 传输数据方向，重传、乱序。
另通过增量时间观察，有 3 次比较明显的高增量，两次来自于发送端 10.224.180.179 346 ms（数据包111） 和 336 ms（数据包1446） ，一次来自于接收端 10.240.12.251 199ms 的 ack 。
首先查看数据包 111，考虑到 ip.id 的跳变，以及 RTT 36ms。分析 346ms 包含因为丢包而造成的重传超时 300ms，数据包 111 疑似重传数据包。此外数据包 112 ，为 delay ack 所造成的 200 ms 延时。
数据包 1446 类似数据包 111
问题总结
综上分析， FTP 从 179 客户端下载到 251 客户端速度慢的问题，主要是因为数据包丢失、发送端重传超时（2次）以及1次接收端的 Delay ACK 导致。
?
参考
https://osqa-ask.wireshark.org/questions/46428/troubleshooting-slow-ftp-speed/
?