plantegg / programmer_case Goto Github PK

很好的学习材料，感谢。

求修复，例如下图：

https://github.com/plantegg/programmer_case/blob/main/network/%E5%B0%B1%E6%98%AF%E8%A6%81%E4%BD%A0%E6%87%82TCP--%E6%80%A7%E8%83%BD%E5%92%8C%E5%8F%91%E9%80%81%E6%8E%A5%E6%94%B6Buffer%E7%9A%84%E5%85%B3%E7%B3%BB.md

这篇文章，它提到了
“
如果tcp发送buffer也就是SO_SNDBUF只有16K的话，这些包很快都发出去了，但是这16K的buffer不能立即释放出来填新的内容进去，因为tcp要保证可靠，万一中间丢包了呢。只有等到这16K中的某些包ack了，才会填充一些新包进来然后继续发出去。由于这里rt基本是20ms，也就是16K发送完毕后，等了20ms才收到一些ack，这20ms应用、内核什么都不能做，所以就是如前面第二个图中的大概20ms的等待平台。这块请参考[这篇文章][7]
”
如果 这里的"buffer" 是指 socket.SO_SNDBUF，那么这意味着 “bytes in flight” 必须永远 <= socket.SO_SNDBUF，但，实际上，从wireshark抓包看，并非如此。通过设置不同的socket.SO_SNDBUF来进行抓包验证，可以发现 “bytes in flight” 会远远 > socket.SO_SNDBUF。所以，这可以证明该"buffer" 并不应该是指 socket.SO_SNDBUF。

那么，问题来了：这里的" buffer"（或者说 BDP所算出的 “发送窗口”），对应到 linux kernel 之后的哪一个数据结构？

https://plantegg.github.io/2022/01/01/%E4%B8%89%E4%B8%AA%E6%95%85%E4%BA%8B/

https://plantegg.github.io/2023/04/02/为什么你有知识但没有能力/