TCP_CORK 的影响
我有一个用例，我通过 TCP/IP 向一个方向发送数据。我通过多个 send() 调用来完成此操作，负载非常小（相对于以太网帧的大小）（没有任何 send() 标志） -称呼）。为了防止我的小有效负载数据包膨胀到完整以太网帧的大小，我认为使用 TCP_CORK 套接字选项会很好。这是可行的，但是当实际比较使用 TCP_CORK 之前和之后的情况时，我注意到这种聚合已经完成了。为什么会这样呢？正如我所说，我没有对 send() 使用任何标志（如 MSG_MORE）或其他套接字选项，因此我预计我最初的解决方案是浪费的。
I'm having a use case where I'm sending data via TCP/IP in one direction. I'm doing this via multiple send()-calls with very small (in relation to the size of an ethernet frame) payloads (without any flags for the send()-call). To prevent bloating up my small payload packets to the size of a full ethernet frame, I thought it would be nice to use the TCP_CORK socket option. This works, but when actually comparing the situation before and after using TCP_CORK, I noticed that this kind of aggregation was already done. Why is this so? As I said, I do not use any flags for send() (like MSG_MORE) or other socket options, so I would have expected my original solution to be wasteful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您发送消息的速度非常快，您可能会看到 Nagle 算法正在发挥作用。您必须明确禁用它。在linux中的iirc你必须设置TCP_NODELAY，但是在其他操作系统中有不同的选项。
If you are sending messages very quickly you may be seeing the Nagle algorithm at work. You have to disable it explicitly. Iirc in linux you have to set TCP_NODELAY, but there are different options in other operating systems.