嗨，我读了一本教科书（计算机网络：自上而下的方法/James F. Kurose，Keith W. Ross。）描述了 TCP 快速重传的过程，基本上 TCP 在收到该数据包之前收到三个重复的确认时重新传输丢失的数据包超时如下图所示： 
但是我不明白的一点是，TCP也可以缓存乱序的数据包，所以发送方只重发丢失的数据包，所以对于图中的情况，因为接收方只确认了序列为100的丢失数据包，但是发送方已经发送了数据包 120、135 ...等，由于接收方没有确认它们，发送方如何知道这些数据包已经到达接收方？那么发送方是否需要再次重新发送所有这些数据包？在我看来，快速重传只能适用于 Go-Back N 型 TCP，不适用于选择性重复型 TCP？
了解 TCP 的最佳方法是打开 Wireshark，使用 HTTP 或任何 TCP 协议下载一个大文件，然后查找表示 DUP ACK、Fast Retransmit 或 Retransmit 的黑色行以在屏幕上滚动。
通常，您会在 Internet 连接上看到一些数据包丢失，您可以自己进一步深入研究，以查看您自己的客户端为丢失的数据包发送 DUP ACK。
或者更好的是，进行上传，您可以看到您的客户端在看到 3 个相同的 ACK 后进行快速重传。
您还可以仔细查看 TCP 选项并查看 manbearpig 所指的 SACK。
关于快速重传的另一个很好的信息来源是 RFC。第二段回答了您关于为什么 3 ACK 与 1、2、4、5 的评论。
https://www.rfc-editor.org/rfc/rfc2001
3. 快速重传
1990 年提出了对拥塞避免算法的修改[3]。在描述更改之前，请意识到 TCP 可能会
在
收到乱序段时生成立即确认（重复 ACK）（[1] 的第 4.2.2.21 节，并注意
这样做的一个原因是实验性快速
重传算法）。这个重复的 ACK 不应该被延迟。
这个重复的 ACK 的目的是让另一端知道一个段被乱序接收，并告诉它
期望的序列号。由于 TCP 不知道重复 ACK 是由丢失的段引起的还是只是段的重新排序引起的，因此它等待接收少量重复的 ACK。假设如果
只是对段进行重新排序，则
在处理重新排序的段之前将只有一个或两个重复的 ACK，然后将
生成新的 ACK。 如果连续
收到三个或更多重复的 ACK ，则强烈表明段已
丢失。 然后，TCP 会重新传输看似
丢失的数据段，而无需等待重新传输计时器
到期。
您正在更原始的领域中阅读有关 TCP 的信息，其中不存在选择性确认。如果没有更高级的 TCP 行为，这里演示的问题是正确的。
这篇很棒的文章来自Packet Life
选择性确认让我们更有效地做到这一点。ACK 还包含有关它确实接收到的序列以及它没有接收到的序列的信息。没有这个 TCP 是愚蠢的，它将请求重新传输它已经收到的数据包。
编辑：
我没有在这里绑定快速重传。快速重传只是对数据包必须已被丢弃的假设做出反应的一种更快方式（否则为什么您会得到 3 个具有相同 SEQ# 的 ACK。）它是优化 TCP 性能的其他功能之一，例如 Selective ACK。