考虑到这两个捕获（都说明了问题），当我们有一些特定的数据包丢失时，我们会遇到 TCP 流问题。

https://www.cloudshark.org/captures/a1a050d95269（从 linux 3.2 初始捕获） https://www.cloudshark.org/captures/7e5b91e67a64（升级到 linux 3.8 后）

基本上，TCP 连接挂了。

在数据包 4 和 6 之间 GH (.128) 实际上向我们发回了对 SSL hello 的回复 - 3 个没有发送给我们的数据包。在这 3 个数据包中，他们将确认我们最初的 136 个字节并发送他们自己的 3741 个（可以从数据包 6 中的 ACK=137 和 Seq=3742 推断出）

数据包 6 最终发送给我们，表明他们确认了 137 个字节，并且已经在这个流中向我们发送了 3741 个字节。这意味着他们已经发送了至少 3 个没有成功的数据包。奇怪的是连续丢了 3 个数据包。

我的解释是我们对数据包 6 的反应应该是向 0.128 发送一个 LEN=0 ACK=1 数据包，说明我们没有看到来自它们的任何流量，从而触发了它们初始 3741 字节响应的重传。

这就是导致连接挂起的原因，尽管初始数据包丢失。

我64.71.148.3在复制问题时从我们的一端 ( )捕获了一些信息（尝试从 github 执行 git pull 时挂起）。

这里的主要问题是：

• 我对 TCP 流的分析是否正确？
• 这里的最终责任是否在于我们端的 Linux 请求重传？

还：

• 这是 Linux TCP/IP 堆栈中的错误吗？
• 有什么我可以改变的，让它表现得更好吗？

笔记

• 这不是特定于 HTTPS 的问题；我可以通过 SSH 克隆来复制它
• 是的，有数据包丢失，但这就是 TCP 应该处理的
• 问题最初是在内核 3.2 的网关上发现的。已升级到 3.8.0-37-generic (ubuntu 12.04)
• 在 (PAT) 网关后面以及在网关本身上进行测试
• 在具有“相同”配置的另一个网关上进行测试- 没有变化
• 可以通过运行git clone -v https://github.com/SamSaffron/pups.git; rm -rf pups几次迭代快速重现通常会触发它。