Question

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

如果我正在编程P2P软件以保持2个软件同步，并且我想估计我的数据包的最佳大小，那么将指标保持在计数中是否有意义，特别是因为这是一个事实ISP相关的价值和整个世界有很多ISP？我应该应用一些“启发式算法”，比如假设最佳度量标准是最低的那个，我只是在最长的那个上添加填充空值？

感谢。

PS 如果你需要一个例子的起点，我更喜欢C ++中的东西，因为我现在对这种语言很感兴趣。

编辑：回顾一下你可以在下面找到的评论：看起来我的问题太过通用了，现在我专注于MTU和延迟（滞后）来保持事情的直线性。

Answer 1

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

Answer 2

好的，为了优化有关最大传输单元大小（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的特定服务协议。然而，这些部分的总和将给出一般延迟的近似值。即。从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握手过程需要3x（上面提到的延迟总和），因为udp将允许你发送数据包的写入然后等待同一套接字上的响应，确保在x次重试后没有得到响应时正确接收到数据包。

根据@EJP提供的答案，大多数情况下程序员不需要担心这一点，但在某种程度上，有人担心数据库服务器的灾难管理和这样的区域，这是至关重要的这个数据库在任何时候都非常接近insync ...在我去年编写一些处理特定问题的内核代码后，我的两个感觉就越少了希望它有所帮助！

Answer 3

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

那就是说，为了接近你的问题，让我首先告诉你，你自己“不信任”，因为你使用了不正确的术语。

您谈论网络“指标”（在网络科学中与路由相关），但您谈论的是其他内容，即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对您来说是“不公平的”，但是考虑到过多的碎片活动可能会让路由器无法在其他任何地方进行其他传输。这是一种伤害，而不仅仅是让你流下来。

什么是指标以及程序员应该关注的原因？ - 联网

3 个答案: