记一次 tcpdump 抓包分析，Dup Ack

起因是 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 的包，网络肯定有问题，不太好。但具体是啥问题，我已经无能为力了。。。。