TCP 窗口大小 libnids
我的目的是写一个应用程序。 libnids 之上的层进程。使用libnids API的原因是它可以模拟Linux内核的TCP功能。 Libnids 将返回 hlf->count_new，即上次调用 TCP 回调函数的字节数。然而，每次新数据包进入时都会调用 tcp_callback，因此 hlf->count_new 包含单个 TCP 段。
然而，该应用程序。层应该接收 TCP 窗口缓冲区，而不是单独的 TCP 段。
有没有办法获取TCP窗口的数据（而不是TCP段）？换句话说，让 libnids 传递 TCP 窗口缓冲区数据。
提前致谢！
My intent is to write a app. layer process on top of libnids. The reason for using libnids API is because it can emulate Linux kernel TCP functionality. Libnids would return hlf->count_new which the number of bytes from the last invocation of TCP callback function. However the tcp_callback is called every time a new packet comes in, therefore hlf->count_new contains a single TCP segment.
However, the app. layer is supposed to receive the TCP window buffer, not separate TCP segments.
Is there any way to get the data of the TCP window (and not the TCP segment)? In other words, to make libnids deliver the TCP window buffer data.
thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你有误会。 TCP 窗口旨在控制传输中的数据量。应用程序读取并不总是触发 TCP 窗口更改。因此，您所寻找的信息在您正在寻找的地方不可用。
例如，假设窗口为 128KB 并且已发送 8 个字节。接收 TCP 堆栈必须确认这八个字节，无论应用程序是否读取它们，否则 TCP 连接将超时。现在想象应用程序读取一个字节。 TCP 堆栈将窗口放大一个字节是没有意义的——并且如果正在使用窗口缩放，即使它愿意也无法做到这一点。
然后呢？如果四秒后应用程序读取另一个字节，是否再次调整窗口？有什么意义呢？
窗口的目的是控制两个 TCP 堆栈之间的数据流，防止缓冲区无限增长，并控制“传输中”的数据量。它仅间接反映应用程序从 TCP 堆栈中读取的内容。
奇怪的是你竟然想要这个。即使您可以知道应用程序读取了哪些内容，这对您有什么用处呢？
You have a misunderstanding. The TCP window is designed to control the amount of data in flight. Application reads do not always trigger TCP window changes. So the information you seek is not available in the place you are looking.
Consider, for example, if the window is 128KB and eight bytes have been sent. The receiving TCP stack must acknowledge those eight bytes regardless of whether the application reads them or not, otherwise the TCP connection will time out. Now imagine the application reads a single byte. It would be pointless for the TCP stack to enlarge the window by one byte -- and if window scaling is in use, it can't do that even if it wants to.
And then what? If four seconds later the application reads another single byte, adjust the window again? What would be the point?
The purpose of the window is to control data flow between the two TCP stacks, prevent the buffers from growing infinitely, and control the amount of data 'in flight'. It only indirectly reflects what the application has read from the TCP stack.
It is also strange that you would even want this. Even if you could tell what had been read by the application, of what possible use would that be to you?