我很难推导出数学模型/方程来估计使用 TCP/IP 通信的两个节点之间的往返延迟。节点基于 HTTP 协议交换数据。在这个模型中,要研究的最重要的因素是网络中两个节点之间的物理距离、中间跳数、带宽、每跳的处理延迟。我在网上搜索,但在这个意义上找不到任何东西,而是找到了一些关于电路交换网络和 UDP 协议的东西。我可以自定义它们以适应 TCP 吗?
如何制定 TCP/IP 中的通信延迟?
这是一个非常复杂的过程,因此制定一个可用于准确预测 RTT 的方程式极其困难。充其量,我会说您可以创建一个模型,该模型对每个阶段使用一堆平均值,如果您碰巧对特定情况“了解得更好”,则可以调整该模型尽可能接近。这是我目前正在研究的东西,所以我可以告诉你我目前所知道的(从头开始,从物理层开始):
查看我关于 Electronics SE 的问题;以太网的编码延迟以及与电缆频率额定值和通过铜线传输的电力(信号传播?)速度的关系,以实现通信延迟。由于您将使用标准化速度(100Mbps、1Gbps、10Gbps 等),因此不要区别对待光纤或铜线。两者的“延迟”几乎一样,但铜显然不能传输信号。我在 Physics SE 网站上有这个问题,我现在知道答案了。我只需要找到时间来解决它,所以如果你有兴趣,请密切关注(我将发布更多与电信使用光纤相关的问题,当我有机会时,我现在知道答案了)。
链接末端的设备将添加更多延迟。没有标准的说法“哦,一条路径上的 2 个交换机是 Xms 延迟,4 个交换机是 2*Xms,2 个路由器是 Yms……等等”。假设您使用例如 1Gpbs 并且路径中的设备以线速前进,我们知道这是 1000000000bps,因此物理接口以固定编码速率运行(范围从每比特 1 纳秒到最大使用的符号编码方案是,例如10b )
您需要注意并考虑三种主要类型的延迟(在物理层);序列化延迟、编码延迟、传播延迟(还有处理延迟、排队延迟、编解码延迟,但这些都在物理层之上但需要提及!)。这些在 Internet、VoIP:深入分析、此处的幻灯片 13 、Google Scholar上的加载等等上都有相当详细的记录。
当我们向上移动协议栈时,我会假设目标 MAC 位于每个交换机的凸轮表中,而在 IP 层,目标 MAC 位于 ARP 表中。这些发现过程引起的额外延迟仅发生在流中的第一个数据包中,因此可以通过增加超时和发送免费 ARP 等来规避它们。
当您到达应用程序层时,这将变得非常困难,因为这取决于服务器(例如)处理请求,这将受到中断延迟的影响。由于负载,处理请求和上下文切换所需的中断数量是不可预测的。
我很想帮助你解决你的问题,很遗憾,这就是我现在唯一的时间。我可能会在今晚晚些时候或明天更新这个答案,我想发布到目前为止我所拥有的。
同时,大多数人倾向于使用大约 0.6*c(C = 光速)的物理铜/光纤层的延迟数字。此外,您需要考虑 TCP 对每个 X 数据包的 ACK 交换,例如,如果您使用的是 SACK,并且您使用的是巨型帧和/或更大的 MSS(现在 MTU 也需要考虑在内!) , 如果您要发送更多中间 ACK(如果您对传输的数据量感兴趣)。您还需要考虑臭名昭著的带宽延迟产品,不要像我对那个页面那样做出愚蠢的误解。我开始在这里制作各种简单(而且非常丑陋)的数据计算器. 又是一项正在进行的工作,我会尽快尝试更新它们。我计划添加一个类似于您正在尝试做的计算器。如果您有兴趣,我还制作了一些光和纤维计算器,但同样,没时间了!我还没来得及上传它们。在接下来的几天里,我会尽快尝试更新这个答案。
PS我忘了提到QoS!如果 QoS 在路径中的任何地方都起作用,那么计算 RTT 将变得非常困难!
(我想指出其他人已经发布了关于延迟等如何工作以及导致延迟的原因的出色答案。但是 OP 询问了建模;基本模型很简单,您只需插入示例数字。如果您想知道为什么延迟就是这样,然后看看其他人的答案:^)
网络延迟只是从一个端点到另一个端点的传输时间,在 之间跨越 N 跳。
所以你有 N 个段(跃点)和 N-1 个中间节点。每个节点都有一个延迟(多个事物对该节点的累积影响,例如队列延迟、处理延迟等),并且每个段都有一个传输延迟。总的来说,这是2N - 1 个自变量。所以它是 seg1 +node1 +seg2 ... +node(N-1) +segN 一跳,就是 =seg1 ,两个希望是 seg1 +node1 +seg2 等等。
接下来,您必须定义所有这些部分是什么。因此,您可以使用 CATV 网络、卫星链路、光纤链路、以太网等构建模型网络。对于这些技术中的每一种,您都必须查找示例信息。
传输延迟大约是数据大小除以段的传输速度。如果您需要更精确的模型,您可以添加飞行时间延迟——大约是段的长度除以数据流的速度(近似光速)。如果您有卫星链接,这很重要;对地球同步卫星的升降意义重大。
您必须根据您在模型中放置的设备来估计每个节点上的延迟。
如果您想要应用程序延迟(例如,直到 FTP 传输数据流开始的延迟),那么您可以通过计算网络延迟发挥作用的次数来建立。例如,3 次 TCP 握手会增加三倍的网络延迟,依此类推,构建应用程序所看到的内容。
您可以通过在任一侧捕获数据包来估计往返延迟,然后测量从受监控机器发出的请求和返回响应之间的延迟。例如,如果您标记 SYN 发出到远程机器的时间,然后标记 SYN+ACK 响应进入的时间,则差异将为您提供往返 TCP 延迟的相当不错的大致情况。
请记住,这将大于真实的网络延迟,而延迟的大小取决于任一机器的负载情况。
两台主机之间的延迟取决于几个因素:
- 传播延迟
- 序列化延迟
- 排队/缓冲延迟
传播延迟是数据包在两个位置之间传输所需的物理时间。光纤中的光速约为 200000 公里/秒。我住的瑞典大约是 1570 公里,所以这将是 7.85 毫秒,但实际上它更多,因为这是通过鸟瞰图的距离。
序列化延迟是通过物理介质(即网络设备上的接口)序列化数据包所需的时间。如果您有一个 2 Mbit 的连接并且您正在发送一个 1500 字节的数据包,该数据包将需要 6 毫秒来序列化数据包(12000/2000000)。
排队/缓冲延迟是数据包在被发送到接口之前必须在队列/缓冲区中停留的时间。根据接口上的速度和使用的缓冲区大小,这可能是接下来的一无所获或显着延迟。
然后主机上会出现一些延迟来生成数据包并让应用程序处理它们。有一些应用程序可以测量 HTTP 延迟。人们在放弃网站之前不会接受网站上的太多延迟,因此这是一个重要因素。