ConventionalProgrammer's questions

根据维基百科，传输时间可以定义为（对于数字信号）：

“从消息的第一位到最后一位离开发送节点的时间。”

对于数字信号，传输时间对应于整个数据包的总持续时间。数据从发送缓冲区推送到线路上。数据包的各个位应在发送队列（缓冲区）中等待的时间量是另一种延迟，称为排队延迟，因此我现在将其排除在外。

我的问题是：传输时间到底是一个什么函数？例如，我们可以说传播延迟是光速和连接节点之间距离的函数，处理延迟是 CPU、FPGA 等处理速度的函数。但是，传输延迟时间似乎是根据这些函数关系来松散定义的。

由于排队时间是一种单独的延迟，因此我们应该认为将被推送到线路上的数据已经超过了排队时间，因此，唯一要做的工作就是将数据推送到线路上。我提出的问题也采用以下形式：“什么物理原因阻止数据立即推送到线路上？”。

当然，看起来并不能立即推到电线上，而且一点也不直观，但为什么呢？是从发送缓冲区的物理位置到线路起始端的距离吗？PHY 协议是否能够通过不同的限制机制强制执行某种限制（例如，请参阅：“...许多以太网适配器和交换机端口通过使用自动协商来设置最佳值的速度和双工来支持多种速度两个连接的设备都支持。") ? 如果是，那么硬件层面的这些机制是什么？是节点时钟的采样率吗？其中哪一个可能对传输时间产生最大的影响？

我知道并非每个 PHY 协议都能够处理高传输速度（例如 Comer, DE (2008)。计算机网络和互联网第 5 版：“异步串行接口通常支持高达 230.4 kbit/s 的位传输速度。”） 。据我了解，布线和物理层本身存在限制，但是，我认为答案在于发送节点的属性和 NIC 上的物理连接接口的组合。

顺便说一句，请不要告诉我它是数据包大小和比特率的函数，因为它最终归结为“周期高，但为什么？因为频率低！”，这是没有意义的。

我可能跳过了一些可能提供这方面信息的来源，但是找不到任何来源。

引用维基百科：

“当两个端点都支持 ECN 时，它们会使用 ECT(0) 或 ECT(1) 标记其数据包。路由器将 ECT(0) 和 ECT(1) 代码点视为等效。如果数据包遍历活动队列管理 (AQM) 队列（例如，使用随机早期检测（RED）的队列遇到拥塞并且相应的路由器支持ECN，它可能会将代码点更改为CE而不是丢弃数据包。此行为称为“标记”及其目的是通知接收端点即将发生拥塞。在接收端点，该拥塞指示由上层协议（传输层协议）处理，并且需要回显给发送节点，以便向其发出信号以降低其传输速率. ”

因此，拥塞反馈机制是在传输层（TCP）中通过接收端发送ECE标志设置为1的报文来实现的。我的问题是，为什么首先遇到拥塞的路由器不直接发送例如ICMP消息立即返回给发送者（我知道ICMP没有拥塞选项，但是，不能简单地实现吗？）以便发送者可以更早地减少其拥塞窗口？为什么要等到数据报到达接收端？如果这些数据段到达接收端的时间足够长，导致发送方突发传输，从而导致缓冲区膨胀（这可能已通过早期通知来阻止），从而导致路由器上的其他连接甚至经历高延迟和抖动，会发生什么情况如果可能是很短的一段时间？

可能的情况是，这对网络的有益影响并不值得付出努力，而接收端之所以是回显拥塞的一方，可能是因为路由器无法费心在网络中准备控制消息。许多连接都受到监管的环境。但是，我找不到有关此主题的任何来源。

此外，我首先想到也许数据包需要经过所有路由节点以明确正在经历拥塞的节点，但是，没有一个信息选项可以跟踪帧、数据报、和段头字段。我认为这些段到达接收端发送拥塞反馈而不是直接由路由器发送的另一个原因是在传输层（特别是 TCP）上保持拥塞控制，但互联网层（例如 IPv4）也通过以下方式支持拥塞信息： 2位ECN字段，这让我质疑这个原因。不过，我不确定我的推理是否有实际意义。