问题标签 [congestion-control]

我正在修改网络考试，但我不确定以下问题的答案：

在每个 ACK​​ 之后，最大段大小是增加 1 还是增加一倍？如果它翻倍，答案会是 50ms，因为 2KB^5 = 32KB 所以在 5 次行程后 MSS 将等于 32KB，并且由于 10ms 的往返时间，它将是 10x5 = 50ms？

TCP 慢启动出现在 Internet 开始经历“拥塞崩溃”的时期。Van Jacobson 和 Michael Karels 论文中的轶事示例如下：

拥塞问题通常被描述为由从高速链路到低速链路的过渡以及在此瓶颈处的缓冲区建立/丢弃数据包引起的。
我想了解的是，这样的构建将如何导致端到端吞吐量下降，而不是简单地在通向完整缓冲区的链接的高速部分上导致多余的活动/重新传输。例如，考虑以下网络：

A 和 D 是端点，B 和 C 是从高速网络过渡到低速网络时的数据包缓冲区。例如，A/B 和 C/D 之间的链路为 10Mbps，B/C 之间的链路为 56Kbps。现在如果 A 发送一个大（假设理论上是无限的）向 D 发送消息，我试图理解的是为什么如果它只是用数据敲击 TCP 连接而不是在连接中间适应较慢的链接速度，它会花更长的时间才能通过. 我设想 B 只是其缓冲区以 56Kbps 的固定速率耗尽的东西，不管它的缓冲区被 A 敲打的程度如何，也不管它必须丢弃多少数据包，因为缓冲区已满。因此，如果 A 始终保持 B 的缓冲区已满（或可能是过满），并且 B 始终以 56Kbps 的最大速率传输，那么通过使用慢启动来提高吞吐量如何？

我唯一能想到的是，如果D 已经收到的相同数据包必须在拥塞下通过慢速 B/C 链路重新传输，这会阻塞新数据包。但是 D 通常不会确认它收到的任何数据包，所以重传的数据包应该主要是那些合法地没有被 D 接收到的数据包，因为它们被丢弃在 B 的缓冲区中？

是否有任何命令或脚本来检索 tcp 连接的当前 TCP 拥塞窗口。所以假设一些通信正在通过网络接口（例如 eth0）通过 tcp 进行，现在有没有办法动态（定期）检索 tcp 拥塞窗口？（在 Linux 平台中）

我有一个运行 Linux 的嵌入式设备，它通过 LAN 提供传感器数据，但从不提供 WAN。有时它可能驻留在http://en.wikipedia.org/wiki/Long_fat_network的一端。

我继承的架构使用 TCP，但我想添加相当于 UDP 实时视频的内容。我不在乎丢包或订购。我只想知道当我掉线时在客户端，如果我发送太快，在服务器端。我永远不想重传。

还有其他地方我应该看吗？鉴于我最初的基准测试，UDT 目前太慢了。带有序列号的简单 UDP 客户端/服务器可以在这个嵌入式系统上维持约 80 Mbit/s，而未调整的 UDT 运行大约 30 Mbit/s。如果我使用它的 SOCK_DGRAM 接口，UDT 似乎过于激进地回退到它通常以 16 Mbit/s 运行的点。有没有人为这种应用程序成功调整过 UDT 的 CCC？我见过的最高吞吐量是 35 Mbit/s 与 UDT 的示例应用程序。

我应该直接跳到 RTP 吗？ http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

我试图了解 TCP 拥塞避免机制，但我不明白一件事：TCP 拥塞避免是每个流还是每个链接？

换句话说：有 2 个路由器 A 和 B A 正在向 B 发送两个 TCP 流 - 当一个 TCP 流检测到拥塞时，它是否也会减小另一个流中的窗口大小？

当然，如果发生这种情况，另一个流会在一段时间内检测到拥塞，但是第二个流是否会“等待”直到它自己检测到拥塞？那将是非常无效的...

多谢

在股市技术分析领域，有矩形价格拥堵水平的概念，即：价格在一段时间内基本上没有突破之前的高低水平，形成一个矩形图形。例如：http ://cf.ydcdn.net/1.0.0.25/images/invest/congestion%20area.jpg 。

编辑：对我来说更清楚：股票和外汇市场是由称为“脉冲”和“修正”的一组运动组成的，第一个是当前股票趋势的方向，另一个是相反的方向。当股票朝着趋势方向移动时，冲动运动总是大于随后的修正，但有时会发生这种情况，修正最终与冲动的大小相同。因此，例如，在具有积极趋势的股票中，冲动运动从价格 10.00 美元移动到 15.00 美元，然后出现修正，将价格降至 12.00 美元。当新的推动力出现时，我想，它并没有超过之前的高点（15.00 美元），而是完全屈服于它，随后又出现了新的修正，将价格准确地降至之前的低点（12.00 美元）。所以现在我们可以在股票图中画两条平行的水平线：一条在 15.00 美元的价格处，另一条在 12.00 美元的价格处，形成一个价格在内部“拥挤”的通道。如果我们在最边上画两条垂直条，我们就得到了一个矩形：一个的顶部条在高水平，另一个在低水平。

我正在尝试在 C++/Qt 中创建一种算法，该算法能够使用列表容器内的烛台数据检测此类模式（使用 Qt -> QList），但目前我正在研究是否有人知道已经这样做的人代码，所以我在开发这种算法时节省了大量的精力和时间。

所以我的第一个问题是：有没有人知道并且开源代码可以检测到这样的数字？- 显然不必完全在这种情况下，但是如果有一个代码可以执行类似的任务，只需要我进行调整就可以了。

另一方面，我怎么能创建这样的算法呢？很明显，高点是检测高低电平，而不仅仅是控制这些电平何时“中断”以检测图形的结尾，但我怎样才能以有效的方式做到这一点？今天我能做的最好的事情是使用时间作为参数来检测高低水平（例如“四根蜡烛中的最高价格”，并且使用非常昂贵的代码。

对于我的研究，我想手动控制 TCP 的拥塞控制窗口大小。

当测试网络上发生分段/确认丢失时，我想明确阻止窗口减少。

这可能吗？

我一直在寻找使用 Python、Netem 和 Scapy 的方法。我可以访问 windows 和 linux (ubuntu 12)。

我发现，在 Linux 中，有许多用于 TCP 拥塞控制算法的可加载模块（cubic、new-reno、veno、vegas...）。但是有两个模块让我感到困惑，一个是“HTCP”，另一个是“高速”。HTCP不代表高速TCP吗？那么这里的“HTCP”和“highspeed”模块有什么区别呢？提前感谢您指出差异。

我有一个关于 TCP 发送方在慢启动阶段的拥塞窗口增加率的问题。传统上，每个 RTT 的 cwnd 大小都会呈指数增长。例如，如果初始 cwnd 值为 1，则增加 2->4->8->16->....。

就我而言，由于发送方使用 linux 内核 3.5，初始 cwnd 为 10。我预计 cwnd 会随着 10->20->40->... 而增加而没有延迟 ACK（我在接收方将其关闭）。但是，当接收方通过 HTTP 从发送方下载大尺寸（超过 1MB）的对象时，cwnd 增加为 10->12->19->29->...。我无法理解这个顺序。

我将 RTT 设置为 100ms 并且链路带宽足够高。会话期间没有损失。我通过计算接收方在一个 RTT 内收到的数据包数量来估计发送方的 cwnd。

有人知道这种行为吗？谢谢。

TCP中的流量控制和拥塞控制有什么区别？

这个问题可以分为两部分：

1. 流量和拥塞控制的总体目的是什么？
2. 任务是如何完成的？

根据Wikipedia，TCP 流量控制依赖于 ACK 消息中报告的窗口大小。拥塞控制也依赖于确认消息。我想知道这两个目标之间有什么区别，以及它们是如何工作的。