用户带宽和下载间隔之间的权衡
Trading off between User Bandwidth and Download Interval
我正在设计一个非商业开源客户端应用程序，它需要定期从服务器下载恰好 100 KB 的数据，并根据数据变化在客户端应用程序中显示警报。现在我需要在 user bandwidth 和 download interval 之间进行权衡。
分析，
- 如果我设置
interval = 1 hour。这意味着应用程序将在 1 个月内下载 30*24*100KB = 72MB.
- 如果我设置
interval = 30 mins。这意味着应用程序将在 1 个月内下载 30*48*100KB = 144MB.
- 以此类推
现在，我只考虑文件大小，在实践中，除了数据流之外，还有一部分带宽用于控制流。要从服务器下载恰好 100 KB 的文件，在我对 TCP 通信的分析中，我应该考虑 多少控制流开销带宽？ 是否有关于该主题的guideline/reference或研究？
假设，如果 10KB 用于控制流，则每月总使用量将包括 14.4MB 的额外数据，需要在我的分析中确定这些数据。
注意： (1) 我仅限于分析客户端部分。 (2) 此时无法在服务器端进行任何更改（即基于拉式到基于推式，部分数据更改 api 等无法应用 ）。 (3) 我仅限于使用 TCP 下载文件。 (4) 虽然在实践中不经常考虑那么多的粒度，但让我们假设，对于我的情况，分析需要的粒度如此之大，以至于我需要知道数据与控制带宽的比率。
如果您只询问 TCP/IP 部分，payload/PDU 比率对于 IPv4 是 1460/1500，对于 IPv6 是 1440/1500，假设 MTU 为 1500 字节（来源：this already mentioned discussion, this other discussion, this other article).
我还找到了this really nice page that allows you to see all the header sizes for an arbitrary protocol stack and this academic paper。
然而除了协议头之外，还有更多降低带宽的效果：
- TCP 将发送额外的消息，例如用于在建立连接时执行握手，
- 可能会发生数据重传，
- 实际帧大小是在较低的通信层上协商的，因此 TCP 段可能比假设的要小。
综上所述，这个问题不好准确回答，因为在传输过程中有一些影响是你无法控制的。
您是否考虑过测量传输一个（或多个）100KB 有效载荷块所需的实际数据量而不是进行理论分析？
我正在设计一个非商业开源客户端应用程序，它需要定期从服务器下载恰好 100 KB 的数据，并根据数据变化在客户端应用程序中显示警报。现在我需要在 user bandwidth 和 download interval 之间进行权衡。
分析，
- 如果我设置
interval = 1 hour。这意味着应用程序将在 1 个月内下载30*24*100KB = 72MB. - 如果我设置
interval = 30 mins。这意味着应用程序将在 1 个月内下载30*48*100KB = 144MB. - 以此类推
现在，我只考虑文件大小，在实践中，除了数据流之外，还有一部分带宽用于控制流。要从服务器下载恰好 100 KB 的文件，在我对 TCP 通信的分析中，我应该考虑 多少控制流开销带宽？ 是否有关于该主题的guideline/reference或研究？
假设，如果 10KB 用于控制流，则每月总使用量将包括 14.4MB 的额外数据，需要在我的分析中确定这些数据。
注意： (1) 我仅限于分析客户端部分。 (2) 此时无法在服务器端进行任何更改（即基于拉式到基于推式，部分数据更改 api 等无法应用 ）。 (3) 我仅限于使用 TCP 下载文件。 (4) 虽然在实践中不经常考虑那么多的粒度，但让我们假设，对于我的情况，分析需要的粒度如此之大，以至于我需要知道数据与控制带宽的比率。
如果您只询问 TCP/IP 部分，payload/PDU 比率对于 IPv4 是 1460/1500，对于 IPv6 是 1440/1500，假设 MTU 为 1500 字节（来源：this already mentioned discussion, this other discussion, this other article).
我还找到了this really nice page that allows you to see all the header sizes for an arbitrary protocol stack and this academic paper。
然而除了协议头之外，还有更多降低带宽的效果：
- TCP 将发送额外的消息，例如用于在建立连接时执行握手，
- 可能会发生数据重传，
- 实际帧大小是在较低的通信层上协商的，因此 TCP 段可能比假设的要小。
综上所述，这个问题不好准确回答，因为在传输过程中有一些影响是你无法控制的。
您是否考虑过测量传输一个（或多个）100KB 有效载荷块所需的实际数据量而不是进行理论分析？