-1

我的理解是，通过“度量”或“度量”我们描述了通过网络传输的包的长度（以字节为单位？），问题是据我所知这个值与 ISP 相关，几乎不可能找到甚至 2 个具有相同指标的 ISP。

如果我正在编写 P2P 软件以保持 2 个软件同步，并且我想估计我的数据包的最佳大小是多少，那么将指标保留在计数中是否有意义，尤其是因为这是一个与 ISP 相关的值全世界有很多 ISP 吗？我应该应用一些“启发式算法”，比如假设最好的指标是最低的，我只是继续为最长的填充添加空值？

谢谢。

PS，如果您需要一个示例的起点，我更喜欢 C++ 中的东西，因为我目前对这种语言感兴趣。

编辑：回顾一下您可以在下面找到的评论：看起来我的问题太笼统了，现在我专注于 MTU 和延迟（滞后），以使事情更直截了当。

4

3 回答 3

2

我认为您可能正在谈论路由表中的指标。如果是这样，它只是一个反映下一跳的“成本”的数字，很可能是在延迟方面，但它不是以毫秒为单位的直接测量。这不是程序员需要关心的。

于 2013-05-25T07:04:28.583 回答
1

好的，考虑到关于最大传输单元大小 (MTU) 的优化更新，您将希望将尽可能多的位填充到数据包中，以最大限度地减少通过线路发送的数据包数量。应该注意的是，如果您的主机（首先获得更新的机器）更新缓慢，您可能决定不等待足够的数据完全达到 MTU，而是更新从机（机器备份数据）。因此，作为示例，您的逻辑可能看起来像这样（在伪代码中）

while(keep_updating){

    if(new_data_size == (MTU - x)){  //really approximately equal to but smaller then the MTU 
      send_update_packet();

     }else if(count_time > max_wait_time){ // this will have to deal with min latency 
                                           // discussed below
         send_update_packet();
     }
   count_time++;  
}

现在，如果这是您实际编写的内容，那么上面的示例非常愚蠢在每个线程中。

现在，就延迟或延迟时间而言，这更具体地解决为网络延迟，在 p2p 情况下您很可能无法控制，因为它需要与 ISP 签订特定的服务协议。然而，这些部分的总和将给出一般意义上的延迟近似值。IE。send_update_packet();从机器收到数据包和您在内核/操作系统中实际记录新更新的钩子所花费的时间。无论如何，这些将是您感兴趣的延迟

 Processing delay - time routers take to process the packet header
 Queuing delay - time the packet spends in routing queues
 Transmission delay - time it takes to push the packet's bits onto the link
 Propagation delay - time for a signal to reach its destination

...现在至于您应该再次选择哪种协议，这取决于您是否计划让两台机器一直在通话 tcp 可能是您最好的选择，它会阻止您至少确保数据包不会丢失（豪华的 UDP 处理协议在堆栈中的更高层）。如果您希望更新更加分散，您将希望避免 TCP，因为打开连接的 TCP 握手过程需要 3 倍（上面提到的延迟总和），其中 udp 将允许您发送数据包的写入然后在同一个套接字上等待响应，如果您在x重试时间内没有得到响应，请确保正确接收到数据包。

根据@EJP的答案，大多数时候程序员不需要担心这一点，但在某种程度上，有人担心这一点，特别是在数据库服务器的灾难管理和这样的区域中，数据库的关键是在任何时候都接近不同步......但这是我去年编写一些处理该特定问题的内核代码后的两种感觉希望它有所帮助！

于 2013-05-25T07:15:48.667 回答
1

网络（尤其是互联网络）是一门相对年轻的科学，尚未完全形成。因此，并非所有“正确的行为”都被任何人“分享”，仅仅是因为并非所有人都相信（或被迫）控制它“正确”。结果是任何人都必须——在某种程度上——“关心”任何事情，因为永远不可能完全信任。

也就是说，为了解决您的问题，让我首先告诉您，您自己“不受信任”，因为您使用了不正确的术语。

您谈论网络“度量”（在网络科学中与路由有关的东西），但您谈论的是其他东西，即 MTU（最大传输单元）。如果您以这种方式与网络工程师交谈，您几乎可以肯定您永远找不到问题的答案，因为他很可能会理解另一个完全不相关的事情。

现在一切都清楚了（我希望如此），让我们了解一点理论：

  • 每种传输媒体，由于其物理特性，都会引入一些错误。
    • 在链路级别，这主要是由于“电噪声”或群分散，这使得“信号”越来越难以理解。
    • 在电路（或路径，对于无连接网络协议，如 IP）级别，这可能是由于拥塞导致的数据包丢失。
  • 以上几点的直接后果是“无限的端到端正确传输”在物理上是不可能的。
  • 为了解决这个问题，链路协议和传输协议都必须引入一些“冗余校验”（CRC）和一些机制——以防校验和失败——来恢复错误。从这个意义上说，MTU 只是在不违反有关如何计算 CRC 和管理物理媒体的基本规则的情况下，您可以推入数据包的最大字节数。
  • 根据应用需求，IP 提供不同的“传输协议”：
    • UDP 是“无关紧要”：如果数据包丢失，传输协议将不采取任何措施来恢复
    • TCP 是“全心全意，直到给定的时间限制”：如果某些东西丢失，将要求重新传输。所有这一切都在 TCP/IP 驱动程序级别进行管理，因此不需要应用程序注意，除非“问题”持续时间超过会话的超时限制。
  • 独立于 TCP 和 UDP 行为，IP 还提供“分段”：如果传输单元太长而无法容纳链接协议帧，则打包的内容将被拆分为更小的部分。这个过程发生在（至少在理论上）每一跳（每次你遍历一个路由器从一个链接到另一个链接，然后另一个链接到最终目的地），并且需要对数据包结构和 CRC 进行完全重建，因此它需要更多的计算时间和 CPU 功率或路由器，通常只需要将数据包从端口移动到另一个端口。

这就是您必须小心的原因：无论数据包长度如何，网络性能都不相同：进入 TCP 的数据包越长，“等待确认”的时间就越少（因此数据传输可以更快地流动），但更长的数据包需要更长的延迟，以防万一中间碎片，以及路由器上更多的处理能力。（在这一点上，许多 ISP 不分段：如果它不能通过，他们只是丢弃，让 TCP 重新调整到更小的 MTU，或让应用程序缩短其 UDP 数据包）。

换句话说，如果你不关心性能，只要让 TCP 完成它的工作，数据就会以某种方式找到流动的方式（通过中间分段或通过和到终端的 MTU 协商）。但是如果你想最大化性能，你“刺激”的错误控制和恢复机制越少，你得到的延迟就越少，因此你得到的“段”越宽，因此你得到的数据速率就越高。

如果您想要更好的性能，您必须发现和尊重两个端点之间的每条路径都有一个“最佳长度”。

如果你使用 UDP，情况会有点糟糕：因为没有 MTU 协商和恢复，如果一个太长的数据包在途中被丢弃（因为在某个点它不再适合物理媒体，而 ISP去碎片化，以保护自己和其他客户）你必须小心，并减少它的大小，否则你将永远无法转移它。

随意保留 ISP 对您来说是“不公平的”，但考虑到过多的碎片活动可能会使路由器处于无法从无处到无处进行其他传输的位置。而且这伤害比单纯的让你流的伤害更高。

于 2013-05-25T07:29:29.280 回答