1.23里qos新加入的TCP Vegas什么用途？

janylong

开了，默认参数。

上传速度快了 ，到了230KB/S，不开的话210KB/S左右。

下载速度慢了 ，只有110KB/S，不开的话220KB/S左右。

上网不卡，网游也不卡，但也没不开BT时快。

谁能帮我讲解一下啊……

yuxye

转帖，应该对配置有帮助！

Vegas：是TCP变体 英文：维加斯
Vegas对传统TCP做了相当大的改进，更快速的重传
为了避免对操作系统粗粒度时钟的依赖，Vegas在每次重复的ACK到来时，都检查对应的segment是否已经可以超时重传。
另外，发生重传时，如果重传的segment是在上一个大小的拥塞窗口下发送的，则不对拥塞窗口做减半操作。这么做可以避免拥塞窗口被过分减小导致传输性能下降。

拥塞预测
利用吞吐率的变化调整拥塞窗口，而不是利用丢包来检测拥塞。每收到一个有效的ACK，计算如下三个值：

Expected= WindowSize/BaseRTT

Actual = SentData/ActualRTT

Diff ＝ Expected－ Actual

其中，BaseRTT是该连接上观测到的最小的RTT值；ActualRTT是被确认segment被 发送到收到ACK的时间间隔；SentData是ActualRTT内发送的数据量。

Vegas定义两个常量a，b（a<b)，当Diff< a时，则线性增加拥塞窗口；当Diff> b时，线性减少拥塞窗口。

这种拥塞控制方式是在拥塞将要发生时控制，而不是在拥塞发生后控制。正因为如此，Vegas的吞吐率不会象上面几种TCP，会有较大的波动。这种控制方式在高速高延迟的网络中，对性能的提升非常明显。


慢启动的改进

与拥塞预测的改进机制类似，通过监视吞吐率的变化来决定是否离开慢启动模式。


通过以上三方面的改进，Vegas可以提高带宽的利用率，减少重传次数，减少超时次数。这些改进主要针对大带宽高延迟的链路。

happyle0802

那TCP Vegas下面的三个选项都是什么啊？该怎么设置？

ssiaqgpv

综于找到点资料，关于tcp vegas参数的。
http://neal.nu/uw/linux-vegas/
Tuning Vegas
There are three entries in the /proc file system that control Vegas parameters:
The /proc/sys/net/ipv4/tcp_vegas_alpha and /proc/sys/net/ipv4/tcp_vegas_beta entries control the number of packets that Vegas attempts to keep queued in the network in steady state. They are expressed in half-packet units. The default configuration is that recommended by the original Vegas papers: alpha=1 packet and beta=3 packets. In this configuration Vegas tries to keep between 1 and 3 packets queued in the network and usually succeeds in stabilizing cwnd at a value that satisfies this constraint. This is the initial configuration; if you change these parameters, you can restore the default configuration later with:
    echo 2 > /proc/sys/net/ipv4/tcp_vegas_alpha
    echo 6 > /proc/sys/net/ipv4/tcp_vegas_beta

Another configuration that seems to work well is alpha=beta=1.5 packets:

    echo 3 > /proc/sys/net/ipv4/tcp_vegas_alpha
    echo 3 > /proc/sys/net/ipv4/tcp_vegas_beta

In this configuration Vegas oscillates, keeping around 0-2 packets in the network. This is nice because there will often be zero queuing delay, so that new Vegas flows will get an accurate notion of baseRTT; this will improve fairness between Vegas flows. For more details on this, see "Fairness and Stability of Congestion Control Mechanism of TCP," by Go Hasegawa, Masayuki Murata, and Hideo Miyahara, INFOCOM '99.

The /proc/sys/net/ipv4/tcp_vegas_gamma entry controls the number of packets that Vegas will allow to be queued in the network during slow start before it exits slow start. Again, this is expressed in units of half-packets. The default is gamma=1 packet, which you can also get with:
    echo 2 > /proc/sys/net/ipv4/tcp_vegas_gamma


I haven't had much luck with anything but gamma=1 packet.

See the Vegas JSAC paper more details on these three parameters.

大致意思是说，tcp vegas 使用 alpha beta gamma这三个参数来工作，alpha 和beta 用于控制TCP队列长度，官方推荐的参数是alpha=1 beta=3，意思是TCP队列在1-3个数据包之间调整，最后找到一个合适的cwnd（估计是窗口的意思）值。gamma这个参数决定了tcp vegas什么时候离开slow star模式进入拥塞控制模式，官方推荐的参数是1 。
另外，这三个参数的单位是半数据包  units of half-packets
所以我们看到TOMATO的默认参数是 2-6-2.

[ 本帖最后由 ssiaqgpv 于 2009-4-24 14:55 编辑 ]

ssiaqgpv

另外还有一篇文章，结合着看，应该能理解些，唉，英文太差了，得赶紧思考去了
http://www.ahcit.com/lanmuyd.asp?id=2764

2.1  加法增加乘法减少(AIMD)窗口算法
    TCP是Internet中最流行的端到端传输协议，为主机之间提供可靠按序的传输服务。在现有的TCP/IP协议体系下，TCP拥塞控制机制主要基于加法增加乘法减少(AIMD)算法。在该算法中主要用到三个窗口变量：
    (1)拥塞窗口(cwnd)：限定源端在拥塞控制中在一定时间内允许传送的最大数据量，是来自源端的流量控制。
    (2)通告窗口(awnd)：连接建立及传输过程中，接收端向源端通告的最大可接收速率，是来自接收端的流量控制。
    (3)有效窗口(win)：源端数据发送的实际窗口大小，限定为win＝min(cwnd，awnd)。
由于计算机计算能力和存储能力的提高，通告窗口一般都比较大，因此当前发送窗口的大小大多数情况下等于拥塞窗口的大小。
    AIMD的具体工作过程为：
    (1)源端每收到一个ACK，拥塞窗口按下式增加：
    Incr＝MSS×(MSS/cwnd)   (MSS为分组大小)
    cwnd＝cwnd＋Incr
    也就是，如果每个发出的分组都在最近的RTT(往返时延)时间内获得确认，源端就将cwnd增加1，即加法增加。
    (2)当发生超时，TCP将超时看作拥塞的标志，并减小发送速率。每发生一次超时，源端重新计算拥塞窗口值：
    cwnd＝cwnd/2
    也就是，一次超时，拥塞窗口值减为当前值的一半，即乘法减少。
2.2  TCP拥塞控制的四个阶段
2.2.1  启动阶段
    当连接刚建立或超时时，进入慢启动阶段。
    当新建TCP连接时，拥塞窗口(cwnd)被初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，就增加一个数据包发送量，这样慢启动阶段cwnd随RTT呈指数级增长。
    慢启动采用逐渐增大cwnd的方法，可以防止TCP在启动一个连接时向网络发送过多的数据包而造成不必要的数据丢失和网络拥塞，并且它还能够避免采用单纯的AIMD算法造成的吞吐量增加过慢的问题。
    为了防止cwnd的无限制增长引起网络拥塞，引入一个状态变量：慢启动阈值ssthresh。
    当cwnd<ssthresh时，使用上述的慢启动算法，cwnd随RTT呈指数增长。
    当cwnd>ssthresh时，使用拥塞避免算法，减缓cwnd的增长速度。
2.2.2  拥塞避免阶段
    当TCP源端发现超时或收到3个相同的ACK确认帧时，即认为网络将发生拥塞，此时进入拥塞避免阶段。
    在拥塞避免阶段，慢启动域值ssthresh将被设置为当前cwnd的一半，当发生超时时，cwnd被置为初始值1。此时，如果cwnd<ssthresh，TCP重新进入慢启动过程；如果cwnd> =ssthresh，则执行拥塞避免算法，即cwnd在每次收到一个ACK确认时只增加1/cwnd个数据包。拥塞避免阶段cwnd随RTT呈线性增长。
2.2.3  快速重传和快速恢复阶段
    在拥塞避免阶段，当数据包超时时，cwnd被置为1，重新进入慢启动阶段，这会导致过大地减小发送窗口尺寸，降低TCP连接的吞吐量。因此，引入了快速重传和快速恢复机制。
    在快速重传阶段，当源端收到3个或3个以上重复的ACK时，就判定数据包丢失，同时将ssthresh设置为当前cwnd的一半，并重传丢失的包，进入快速恢复阶段。
    在快速恢复阶段，每收到重复的ACK，则cwnd加1；收到非重复ACK时，置cwnd＝ssthresh，转入拥塞避免阶段；如果发生超时重传，则置ssthresh为当前cwnd的一半，cwnd＝1，重新进入慢启动阶段。
    这种方法避免了数据包超时后就重新进入慢启动阶段，提高了TCP连接的吞吐量。
3  典型TCP拥塞控制算法分析
3.1  TCP Tahoe算法
    Tahoe算法是TCP的早期版本。它的核心思想是：让cwnd以指数增长方式迅速逼进可用信道容量，然后慢慢接近均衡。Tahoe包括3个基本的拥塞控制算法：“慢启动”、“拥塞避免”和“快速重传”。
    (1)慢启动：避免了连接建立时突发数据流对网络的冲击。
    初始设置cwnd为1，并按指数型方式增长，直至cwnd超过ssthresh。
    当cwnd>=ssthresh时，Tahoe进入拥塞避免阶段。
    (2)拥塞避免：限制传输过程中无限制的速率增长，避免由此可能导致的拥塞。
    cwnd以线性方式增长。
    如果发生超时或者连续收到3个重复ACK，Tahoe认为发生了拥塞。
    对于超时，置ssthresh为当前拥塞窗口的一半，cwnd=1，转入慢启动。
    如果收到3个连续ACK，则Tahoe进入快速重传阶段。
    (3)快速重传：根据3个重复的应答报文来判断丢包，减少了超时重传的发生，加快了源端对拥塞的响应，使得拥塞能快速消除。立即重传丢失的分组，同时置ssthresh为当前拥塞窗口的一半，cwnd=1，转入慢启动。
    Tahoe算法存在着不足之处：在收到3个重复ACK或在超时的情况下，Tahoe置cwnd为1，然后进入慢启动阶段。这一方面会引起网络的激烈振荡，另一方面大大降低了网络的利用率。
3.2  TCP Reno
    针对Tahoe算法的不足之处，1990年Jacobson在Tahoe的基础上提出了改进算法Reno。改进主要有两个方面：一是对于收到连续3个重复ACK，算法不经过慢启动，而直接进入拥塞避免阶段；二是增加了快速重传/快速恢复机制。具体实现过程为：
    (1)收到三个重复的ACK，进入快速重传/快速恢复，此时ssthresh设置为当前拥塞窗口的一半。
    (2)重传丢失的数据包，并置cwnd＝cwnd＋ndup(ndup为收到的重复ACK数)。
    (3)发送新的数据包。
    (4)当收到非重复的ACK时，cwnd＝ssthresh。
    (5)进入拥塞避免阶段。
    从上面的过程可以看出，Reno在收到3个重复ACK后，就转入快速重传/快速恢复阶段；而遇到超时时，Reno和Tahoe一样进入慢启动阶段。
    Reno目前被广泛采用，以其算法的简单、有效和鲁棒性成为TCP源算法的主流。但是如果在一个发送窗口内有多个包丢失时，该算法不能有效恢复出来，为此提出了一些改进，如NewReno、Sack等。
3.3  TCP NewReno
    NewReno对Reno中“快速恢复”算法进行了补充，它考虑了一个发送窗口内多个报文同时丢失的情况。在Reno算法中，发送方收到一个不重复的应答后就退出“快速恢复”状态。而在NewReno中，只有当所有报文都被应答后才退出“快速恢复”状态。
    具体执行过程是：在快速恢复期间，TCP发送端收到一个ACK后，发送端通过此ACK应答推断出下一个丢失的数据包序列号，并且立即重传那个数据包。这样，NewReno在每个RTT内重传一个丢失的数据包，直到发生多个数据包丢失的窗口中所有丢失数据包被重传，而不是等到超时。在这个期间如果还有其它重复的ACK到来，则继续快速恢复算法，直到在快速恢复初始时所有未确认数据包都被确认。
    NewReno的实现只要修改TCP发送端的实现代码，实现简单。
3.4  SACK(selective acknowledgement，选择性应答)
    SACK也关注一个窗口内有多个报文的丢失，它使用“选择性重传”策略，提高TCP在拥塞较严重且一个窗口中有多个分组丢失时的性能。SACK的基本思想是：接收方TCP发送SACK分组来通知发送方接收数据的情况，这样源端就能准确的知道哪些数据包被正确的传到接收端，从而避免不必要的重传，减少时延，提高网络吞吐量。
    SACK算法是对Reno算法的改进。它的改进之处在于：在快速恢复阶段，SACK保持一个变量pipe来表示出现在路由器上报文的估计数量。当pipe小于拥塞窗口大小时，源端只发送一个新报文分组或重发一个老报文，pipe加1；当发送端接收到一个带SACK选项的重复ACK时，表明新数据已被接收端接收，pipe减1；此外，对收到的“恢复ACK”使用特殊的处理方法，对pipe变量值减2。
SACK算法降低了不必要的重传，能有效的从多个数据包丢失中恢复。但是它的实现需要修改TCP发送端和接收端的实现代码，增加了TCP的复杂性，不易大规模的应用。
3.5  Vegas算法
    Vegas算法是一个得到普遍认可，但是未能获得广泛应用的算法。Vegas与上述介绍的算法不同，它以RTT的变化作为拥塞信号，调节源端的发送速率。如果发现RTT变大，Vegas就认为网络发生拥塞，开始减小cwnd；如果RTT变小，Vegas则解除拥塞，再次增加cwnd。这样，在理想情况下，cwnd值会稳定在一个合适的范围内。Vegas的重传策略与上述算法也不同，它是在收到一个重复ACK后，比较数据包发出的时间和当前时间，然后决定是否重发。这样能更及时地重传丢失的数据包，提高响应速度。
    该算法采用RTT的改变来判断网络的可用带宽，能较好的预测网络带宽的使用情况，其公平性、效率都较好。但是，由于Vegas与其它算法在竞争带宽方面存在不公平现象，因此未能在Internet上普遍采用，还需不断改进。

qianxiaotong

很好，思考了！试试看！

panyuxiang

我也试了，用的是默认的2-6-2，效果不错

martin_wk

思考中。。。。。

topjim

哦哦哦哦

tommy007

不错...做记号留用

binli

思考了！！！

20314554

思考了！留个记号

周生生

TCP Vegas ：
2-6-2  默认
3-3-2
6-6-2
用哪个好？ 和有什么特点（适合用途）？

我两台机，要保证老婆机打网络纸牌游戏，我下载又不想损失太多速度（最好打开网页也流畅）。
联通PPOE拨号4M光纤！

lion2002

刘明