起因是 docker pull 镜像时有时卡住,然而 registry 一切正常,无奈只好一试抓包。
抓包命令
tcpdump -n -i en0 host 10.116.58.41 -w pull.pcap
参数说明:
-n 不转换 ip 地址为 hostname
-i 网卡
host 过滤条件,抓符合 host 地址的包
-w 将抓包结果保留到文件
分析
先将抓包文件下载到本机,然后用 wireshark 打开。
发现一大片的 Dup Ack,这是咋回事???
经过几番查找,终于知道是为啥。不过这得从 tcp 协议得传输过程讲起:
下文的 sender、receiver 分别代表数据的发送方和接收方。在此处 registry 即为 sender,docker client 为 receiver。
在建立 tcp 链接协议后,sender 开始发送数据,receiver 接收到数据后会给 sender 发送确认的包。通常传输的数据较大,tcp 会将其分片传输,并且数据包是顺序发送的,每一个数据包都会有相应的序号 Seq。如果 recevier 发现收到的数据包的 Seq 不对,则会抛弃该包,并且给 sender 发送前一个确认包,此时确认包的 Ack 跟上一个相同,故为 Dup Ack。
receiver 的确认包的 Ack 计算公式如下,而该 Ack 也是 sender 下一个数据包的 Seq
Ack = Seq + Bytes of date received
# Seq 为 sender 发送的数据包的报文 Seq
这个值在 wireshark 查看这个很方便,会自动帮我们计算出来,如图:
进一步分析发现,Dup Ack 通常以一个 Fast Retransmission 结束,然后恢复正常。这是什么原理呢?
这是因为 sender 在收到超过 3 个相同的 Ack 时,此时 sender 认为 receiver 没有收到相应的包,快速再次发送此丢失包则为 Fast Retransmission。
那为何是有个 Fast 呢?
在 sender 发送一个包后,如果超出一定时间没有收到返回的确认包 Ack,sender 则认为 receiver 没有收到,再次发送此包即为 Retransmission。而 Fast Retransmission 是 sender 收到超过3个相同的 Ack 包时立即发出,可能还没有到超时时间,故 Fast 。
嘛。。。知道来 Dup Ack 和 Fast Retransmission ,那我们的网络是啥问题呢?
首先,有太多的 Dup Ack,说明丢失很多的 sender 的包,网络肯定有问题,不太好。但具体是啥问题,我已经无能为力了。。。。