TCP 中，没有 SACK 能力的接收方，也会缓存 LastRcvd 之后的数据包吗？

2021-11-04 21:46:55 +08:00
 amiwrong123

我现在知道了，tcp 在三次握手的时候会确认双方有没有 SACK 的能力（通过选项）。

如果有的话，那么接收方可能下面这种情况： 即已经收到了 14-20 的包，但由于网络原因，又收到了 22-23 的包。这时候，可能接收方会回复信息 ACK = 21 、SACK = [22-23]、window = 5 。所以，接收方有缓存 LastRcvd 之后的数据包的能力（ 22-23 ），即使 21 没有收到。

但我现在想问，如果接收方没有 SACK 的能力，

1275 次点击
所在节点    程序员
5 条回复
ManjusakaL
2021-11-04 22:19:08 +08:00
SACK 只是为了加快 Retransmit 的速率而已

没有 SACK 该缓存的缓存，对端接到 duplicate ACK 或者定时器触发重传 21 后，接收端做 reorder 就行了。
amiwrong123
2021-11-04 22:23:44 +08:00
@ManjusakaL #1
好吧，我也觉得应该是这样。是我想太多了
amiwrong123
2021-11-04 22:25:04 +08:00
@ManjusakaL #1
也就是说，不管有没有 SACK ，接收方都会缓存 LastRcvd 之后的数据包
choury
2021-11-04 23:08:21 +08:00
并不强制，tcp 中甚至可以接受丢弃 sack 中确认的包，发送端不能把 sack 的内容当 ack 处理
ManjusakaL
2021-11-04 23:58:47 +08:00
@amiwrong123 RFC 2018 中有很明确的描述了

SACK 要解决的是 “With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time.” 这个问题。它和你 LastRcvd 行为无关

更进一层说，你想一下，仅仅是一个包有延迟，就 drop 到后面 seq 更大的包。那么你带来的问题是你还需要让对端重传 N 个包。那么在网络一般会有偶发丢包的情况下，这种行为毫无疑问会导致网络负荷的进一步增加

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/813146

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX