标签: congestion-control

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

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

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

根据Wikipedia,TCP流量控制依赖于ACK消息中报告的窗口大小.拥塞控制还依赖于确认消息.我想知道两个目标之间的区别,以及它们如何运作.

我一直在阅读"计算机网络:自上而下的方法"一书,并遇到了一个我似乎不理解的问题.

正如我所读到的,TCP拥塞控制有三种状态:慢启动,拥塞避免和快速恢复.我很了解慢启动和拥塞避免,但快速恢复非常模糊.该书声称TCP的行为方式如下:(cwnd =拥塞窗口)
我们来看下面的图表:

我们可以看到,在第16轮,发送方发送了42个段,并且因为拥塞窗口大小减半(+3),我们可以推断出有3个重复ACK.这个问题的答案声称 16到22之间的轮次处于拥塞避免状态.但为什么不快速恢复？我的意思是,在三次重复的ACK之后,TCP进入快速恢复并且每隔一次重复的ACK都应该增加拥塞窗口.为什么图表没有表示？我能想到的唯一合理的解释是,在这个图中,只有三个重复的ACK,并且之后收到的ACK不是重复的.

即使是这种情况,如果有超过3个重复的ACK,图表将如何显示？**

上图中是否有快速恢复的表示？为什么不/是的？

**我一直在努力回答这个问题很长一段时间.我会很高兴回复,谢谢!

更新这里是图像.我认为轮次定义为窗口中的所有段都被确认.在照片中,圆圈显示为圆圈. 为什么cwnd在快速恢复状态下呈指数级增长？(在图像中我偶然写了而不是指数地写)

拥塞控制中流量控制中的滑动窗口和拥塞窗口之间有什么区别和联系？

我认为两者都是传输的控件大小,但有什么区别？我也不太了解流量控制和拥塞控制之间的区别.

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

我继承的架构使用TCP,但我想通过UDP添加相当于实时视频的内容.我不关心丢包或订购.我只想在客户端知道我什么时候丢弃,而在服务器端我是否发送得太快了.我从不想转发.

还有其他我应该看的吗？鉴于我的初步基准,UDT目前太慢了.一个天真的UDP with-sequence-number客户端/服务器可以在这个嵌入式系统上维持~80 Mbit/s,而未调整的UDT运行大约30 Mbit/s.如果我使用它的SOCK_DGRAM接口,UDT似乎会过于激进地回落到它通常以16 Mbit/s运行的程度.有没有人为这种应用成功调整UDT的CCC？我见过的最高吞吐量是使用UDT示例应用程序的35 Mbit/s.

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

我iperf在两台服务器之间运行测量,通过10Gbit链路连接.我试图将我观察到的最大窗口大小与系统配置参数相关联.

特别是,我观察到最大窗口大小为3 MiB.但是,我在系统文件中找不到相应的值.

通过运行sysctl -a我得到以下值:

net.ipv4.tcp_rmem = 4096        87380   6291456
net.core.rmem_max = 212992

第一个值告诉我们最大接收器窗口大小为6 MiB.但是,TCP倾向于分配两倍的请求大小,因此最大接收器窗口大小应为3 MiB,正如我测量的那样.来自man tcp:

请注意,TCP实际上分配的次数是setsockopt(2)调用中请求的缓冲区大小的两倍,因此后续的getsockopt(2)调用将不会返回与setsockopt(2)调用中请求的缓冲区大小相同的缓冲区.TCP使用额外空间用于管理目的和内部内核结构,并且/ proc文件值反映了与实际TCP窗口相比更大的大小.

但是,第二个值net.core.rmem_max表示最大接收器窗口大小不能超过208 KiB.根据以下情况,这应该是硬限制man tcp:

tcp_rmem max:每个TCP套接字使用的接收缓冲区的最大大小.该值不会覆盖全局值net.core.rmem_max.这不用于限制在套接字上使用SO_RCVBUF声明的接收缓冲区的大小.

那么,为什么我会观察到最大窗口大小大于指定的窗口大小net.core.rmem_max？

注意:我还计算了带宽 - 延迟产品:window_size = Bandwidth x RTT大约3 MiB(10 Gbps @ 2毫秒RTT),从而验证我的流量捕获.

我在Mint/Debian盒子上设置了非常简单的CouchDB.我的Java webapp在查询CouchDB时遇到了相当长的延迟,所以我开始寻找原因.

编辑:查询模式是许多小查询和小JSON对象(如300字节向上/ 1Kbyte向下).

Wireshark转储非常好,主要显示3-5毫秒的请求 - 响应周转.JVM帧采样向我展示了套接字代码(客户端查询到Couch)有点繁忙,但没什么了不起的.然后我尝试用ApacheBench和oops来描述它:我目前看到keep-alive在非持久性设置上引入了稳定的额外39ms延迟.

有谁知道如何解释这个？也许持久连接会增加TCP层的拥塞窗口,然后由于TCP_WAIT和小的请求/响应大小而空闲,或类似的东西？是否应该为环回tcp连接打开此选项(TCP_WAIT)？

w@mint ~ $ uname -a
Linux mint 2.6.39-2-486 #1 Tue Jul 5 02:52:23 UTC 2011 i686 GNU/Linux
w@mint ~ $ curl http://127.0.0.1:5984/
{"couchdb":"Welcome","version":"1.1.1"}

保持活着,每次请求平均40毫升

w@mint ~ $ ab -n 1024 -c 1 -k http://127.0.0.1:5984/
>>>snip
Server Software:        CouchDB/1.1.1
Server Hostname:        127.0.0.1
Server Port:            5984

Document Path:          /
Document Length:        40 bytes

Concurrency Level:      1
Time taken for tests:   41.001 seconds
Complete requests:      1024
Failed requests:        0
Write errors:           0
Keep-Alive requests: …

sshuttle 声称它解决了很多讨论过的TCP-over-TCP 崩溃问题。

sshuttle 在本地组装 TCP 流，通过 ssh 会话有状态地多路复用它，然后在另一端将其分解回数据包。所以它永远不会做 TCP-over-TCP。它只是通过 TCP 传输的数据，这是安全的。

但是从程序的角度来看，它维护与目标服务器的 TCP 连接及其附带的所有内容（读取指数超时），这是与其他 TCP 会话分层的，因为 SSH 还不能仅在udp. 这很像 TCP-over-TCP。

这里的诀窍是什么？问题真的通过sshuttle解决了吗？

我尝试阅读源代码，但到目前为止还没有找到答案。

更重要的是，他们究竟是如何做到的？如果想在准系统中重新实现它，应该从哪里寻找灵感？

我想要一个程序来确定捕获的TCP会话中使用的TCP拥塞控制算法.

引用的维基百科文章指出:

TCP New Reno是最常用的算法,SACK支持很常见,是Reno/New Reno的扩展.大多数其他竞争提案仍需要评估.从2.6.8开始,Linux内核将默认实现从reno切换到BIC.在2.6.19版本中,默认实现再次更改为CUBIC.

也:

复合TCP是TCP的Microsoft实现,它同时维护两个不同的拥塞窗口,目的是在不损害公平性的同时在LFN上实现良好性能.它已经与Microsoft Windows Vista和Windows Server 2008一起广泛部署,并已移植到较旧的Microsoft Windows版本以及Linux.

确定使用哪种CC算法(来自第三方捕获会话)的策略是什么？

更新

这个项目构建了一个工具来完成这个:

互联网最近已从均匀拥塞控制演变为异构拥塞控制.几年前,互联网流量主要由标准TCP AIMD算法控制,而互联网流量现在由许多不同的TCP拥塞控制算法控制,如AIMD,BIC,CUBIC,CTCP,HSTCP,HTCP,HYBLA,ILLINOIS,LP, STCP,VEGAS,VENO,WESTWOOD +和YEAH.然而,对于具有异构拥塞控制的因特网的性能和稳定性研究的工作很少.一个根本原因是缺乏不同TCP算法的部署信息.该项目的目标是:

1) develop tools for identifying the TCP algorithms in the Internet,
2) conduct large-scale TCP-algorithm measurements in the Internet.

Run Code Online (Sandbox Code Playgroud)

TCP TAHOE 和 TCP RENO 之间有什么区别？

我想知道的是关于 3-dup-ack 和超时的行为？

cwind 发生了什么 SST 发生了什么？

谢谢！

linux 中的“sysctl”命令现在全局更改了整个系统的拥塞控制算法。但是拥塞控制，其中 TCP 窗口大小和其他类似参数是变化的，通常是每个 TCP 连接完成的。所以我的问题是：

• 是否存在一种方法可以更改每个 TCP 连接使用的拥塞控制算法？

还是我在这里遗漏了一些微不足道的东西？如果是，那是什么？