tcp westwood源代码分析

/*
 * TCP Westwood+: end-to-end bandwidth estimation for TCP
 *
 *      Angelo Dell‘Aera: author of the first version of TCP Westwood+ in Linux 2.4
 *
 * Support at http://c3lab.poliba.it/index.php/Westwood
 * Main references in literature:
 *
 * - Mascolo S, Casetti, M. Gerla et al.
 *   "TCP Westwood: bandwidth estimation for TCP" Proc. ACM Mobicom 2001
 *
 * - A. Grieco, s. Mascolo
 *   "Performance evaluation of New Reno, Vegas, Westwood+ TCP" ACM Computer
 *     Comm. Review, 2004
 *
 * - A. Dell‘Aera, L. Grieco, S. Mascolo.
 *   "Linux 2.4 Implementation of Westwood+ TCP with Rate-Halving :
 *    A Performance Evaluation Over the Internet" (ICC 2004), Paris, June 2004
 *
 * Westwood+ employs end-to-end bandwidth measurement to set cwnd and
 * ssthresh after packet loss. The probing phase is as the original Reno.
 */

#include <linux/mm.h>
#include <linux/module.h>
#include <linux/skbuff.h>
#include <linux/inet_diag.h>
#include <net/tcp.h>

/* TCP Westwood structure */
struct westwood {
    u32    bw_ns_est;        /*中间变量,经过一次平滑后的带宽值  first bandwidth estimation..not too smoothed 8) */
    u32    bw_est;           /*最终估计的带宽值  bandwidth estimate */
    u32    rtt_win_sx;       /*采样周期的起始点,一个RTT后结束 here starts a new evaluation... */
    u32    bk;               //在某个时间段delta内确认的字节数
    u32    snd_una;          /*snd_una历史记录,用于计算bk    used for evaluating the number of acked bytes */
    u32    cumul_ack;        //在慢速路径下,一个ACK确认的数据量  cumulative ack
    u32    accounted;        //在慢速路径下,收到的重复数据包个数
    u32    rtt;              //当前RTT值,以毫秒为单位,每收到一个ACK都更新
    u32    rtt_min;          /*最小RTT值,以毫秒为单位,inimum observed RTT */
    u8     first_ack;        /*是否第一个ack包   flag which infers that this is the first ack */
    u8     reset_rtt_min;    /*是否重置采样周期  Reset RTT min to next RTT sample*/
};

/* TCP Westwood functions and constants */
#define TCP_WESTWOOD_RTT_MIN   (HZ/20)    /* 50ms */
#define TCP_WESTWOOD_INIT_RTT  (20*HZ)    /* 20000ms 太保守???  maybe too conservative?! */

/*
westwood在丢包率较高的无线网络中表现较好。
Reno对随机丢包和拥塞丢包都较为敏感,随机丢包会导致Reno不必要的降低拥塞窗口和慢启动阈值。
在westwood算法中,需要强调的一点是:丢包对带宽的影响不大。
每个RTT采样一次带宽值,而这次样本只占bw_est的1/64。丢包后进入快速恢复阶段,尽管在快速恢复阶段
中得到的几个采样值较小,但是整体的bw_est却没有太大的减小。
来看一下为什么westwood对随机丢包不敏感。
(1)随机丢包
丢包前:cwnd = bw_est * RTT
丢包后:cwnd = bw_est * RTTmin
因为是随机丢包,所以丢包前的RTT只是比RTTmin略大。丢包后的bw_est也只是微略减小。
所以丢包后的cwnd只是微略的减小。
(2)拥塞丢包
丢包前:cwnd = bw_est * RTTmax => BDP + Queue
丢包后:cwnd = bw_est * RTTmin => BDP
因为是拥塞丢包,所以丢包前的bw_est已经是连接的最大带宽,并且时延也达到了最大值。
这是丢包后就达到了完全利用BDP,同时使Queue为空的效果。
可以看到,westwood对随机丢包和拥塞丢包采取同样的算法来处理,却能达到不同的效果。
但是,westwood不能主动的区分随机丢包和拥塞丢包。
*/

/*
 * @tcp_westwood_create
 * This function initializes fields used in TCP Westwood+,
 * it is called after the initial SYN, so the sequence numbers
 * are correct but new passive connections we have no
 * information about RTTmin at this time so we simply set it to
 * TCP_WESTWOOD_INIT_RTT. This value was chosen to be too conservative
 * since in this way we‘re sure it will be updated in a consistent
 * way as soon as possible. It will reasonably happen within the first
 * RTT period of the connection lifetime.
 */
static void tcp_westwood_init(struct sock *sk)
{ //初始化westwood拥塞算法的参数
    struct westwood *w = inet_csk_ca(sk);

    w->bk = 0;
    w->bw_ns_est = 0;
    w->bw_est = 0;
    w->accounted = 0;
    w->cumul_ack = 0;
    w->reset_rtt_min = 1;
    w->rtt_min = w->rtt = TCP_WESTWOOD_INIT_RTT;
    w->rtt_win_sx = tcp_time_stamp;//jiffies毫秒
    w->snd_una = tcp_sk(sk)->snd_una;
    w->first_ack = 1;
}

/*
 * @westwood_do_filter
 * Low-pass filter. Implemented using constant coefficients.
 */
static inline u32 westwood_do_filter(u32 a, u32 b)
{
    return (((7 * a) + b) >> 3); //返回7a/8与1b/8之和
}

static void westwood_filter(struct westwood *w, u32 delta)
{ //带宽过滤器
    /* If the filter is empty fill it with the first sample of bandwidth  */
    if (w->bw_ns_est == 0 && w->bw_est == 0) {
        //如果是第一次得到带宽测量样本
        w->bw_ns_est = w->bk / delta;
        w->bw_est = w->bw_ns_est;
    } else {//如果已经有收到过测量样本了
        w->bw_ns_est = westwood_do_filter(w->bw_ns_est, w->bk / delta);
        w->bw_est = westwood_do_filter(w->bw_est, w->bw_ns_est);
    }
}

/*
 * @westwood_pkts_acked
 * Called after processing group of packets.
 * but all westwood needs is the last sample of srtt.
 */
static void tcp_westwood_pkts_acked(struct sock *sk, u32 cnt, s32 rtt)
{ //每收到一个ACK时,会更新当前的RTT(w->rtt)
    struct westwood *w = inet_csk_ca(sk);

    if (rtt > 0) //这个参数rtt是以微秒为单位的,rtt为-1则不会执行转换
        w->rtt = usecs_to_jiffies(rtt); //w->rtt是以毫秒为单位的
}

/*
 * @westwood_update_window
 * It updates RTT evaluation window if it is the right moment to do
 * it. If so it calls filter for evaluating bandwidth.
 */
static void westwood_update_window(struct sock *sk)
{ //每经过一个RTT后,采集一个新的测量样本,更新带宽估计值。
    struct westwood *w = inet_csk_ca(sk);
    s32 delta = tcp_time_stamp - w->rtt_win_sx; //计算时间差

    /* Initialize w->snd_una with the first acked sequence number in order
     * to fix mismatch between tp->snd_una and w->snd_una for the first
     * bandwidth sample
     */
    if (w->first_ack) {//如果是第一个ack包
        w->snd_una = tcp_sk(sk)->snd_una;
        w->first_ack = 0;
    }

    /*
     * See if a RTT-window has passed.
     * Be careful since if RTT is less than
     * 50ms we don‘t filter but we continue ‘building the sample‘.
     * This minimum limit was chosen since an estimation on small
     * time intervals is better to avoid...
     * Obviously on a LAN we reasonably will always have
     * right_bound = left_bound + WESTWOOD_RTT_MIN
     */
     //如果当前的rtt大于TCP_WESTWOOD_RTT_MIN,也就是超时了
    if (w->rtt && delta > max_t(u32, w->rtt, TCP_WESTWOOD_RTT_MIN)) {
        westwood_filter(w, delta);// 更新带宽估计值

        w->bk = 0;//清零确认字节数
        w->rtt_win_sx = tcp_time_stamp;//重设取样周期开始时间
    }
}

static inline void update_rtt_min(struct westwood *w)
{//更新最小RTT
    if (w->reset_rtt_min) { //如果非0
        //当发生超时后,最小RTT可能不再准确,需要更新
        w->rtt_min = w->rtt;
        w->reset_rtt_min = 0;
    } else  //如果为0
        w->rtt_min = min(w->rtt, w->rtt_min);//更新最小RTT
}

/*
 * @westwood_fast_bw
 * It is called when we are in fast path. In particular it is called when
 * header prediction is successful. In such case in fact update is
 * straight forward and doesn‘t need any particular care.
 */
//快速路径时的带宽估计值更新
//处于快速路径时调用,说明此时收到的数据包是顺序的,此时应该处于Open状态。
//这种状态下,收到新的ACK会使tp->snd_una前进。
//所以,tp->snd_una - w->snd_una能代表此ACK确认的数据量。
static inline void westwood_fast_bw(struct sock *sk)
{
    const struct tcp_sock *tp = tcp_sk(sk);
    struct westwood *w = inet_csk_ca(sk);

    westwood_update_window(sk); //更新带宽估计值

    w->bk += tp->snd_una - w->snd_una; //累计确认的字节数
    w->snd_una = tp->snd_una;//记录当前snd_una
    update_rtt_min(w); //更新最小RTT
}

/*
 * @westwood_acked_count
 * This function evaluates cumul_ack for evaluating bk in case of
 * delayed or partial acks.
 */
//慢速路径时,计算所收到ACK确认的数据量。
//这时候的ACK可能是delayed ACK、partial ACK、duplicate ACK、
//cumulative ACK following a retransmission event.

static inline u32 westwood_acked_count(struct sock *sk)
{
    const struct tcp_sock *tp = tcp_sk(sk);
    struct westwood *w = inet_csk_ca(sk);

    //计算此ACK确认的字节数
    w->cumul_ack = tp->snd_una - w->snd_una;

    /* If cumul_ack is 0 this is a dupack since it‘s not moving
     * tp->snd_una.
     */
    //如果cumul_ack=0,那么此ACK是dupack,
    //代表接收端收到一个数据包。
    if (!w->cumul_ack) {
        w->accounted += tp->mss_cache;//接收端保存的乱序数据包加一
        w->cumul_ack = tp->mss_cache;//代表传输了一个数据包
    }

    //如果cumul_ack > 1,则有可能是多种情况。
    if (w->cumul_ack > tp->mss_cache) {
        /* Partial or delayed ack   表示此ACK为partial ACK */
        if (w->accounted >= w->cumul_ack) {
            w->accounted -= w->cumul_ack;
            //表示只确认了一个包,其它包已经被dupack确认过了
            w->cumul_ack = tp->mss_cache;
        } else {
        /* delayed ack or cumulative ack,
         * 表示被延迟的确认,或者结束Recovery的累积确认
         */
            w->cumul_ack -= w->accounted;
            w->accounted = 0;
        }
    }

    w->snd_una = tp->snd_una; //记录当前的snd_una

    return w->cumul_ack;//返回此ACK确认的字节数
}

/*
 * TCP Westwood
 * Here limit is evaluated as Bw estimation*RTTmin (for obtaining it
 * in packets we use mss_cache). Rttmin is guaranteed to be >= 2
 * so avoids ever returning 0.
 */
static u32 tcp_westwood_bw_rttmin(const struct sock *sk)
{//此函数在丢包后调用,根据带宽来设置拥塞窗口和慢启动阈值。
    const struct tcp_sock *tp = tcp_sk(sk);
    const struct westwood *w = inet_csk_ca(sk);
    return max_t(u32, (w->bw_est * w->rtt_min) / tp->mss_cache, 2);
}

static void tcp_westwood_event(struct sock *sk, enum tcp_ca_event event)
{//westwood的"入口函数",其他函数都是通过这个函数调用的,
 //不同与其他的TCP拥塞控制算法。
    struct tcp_sock *tp = tcp_sk(sk);
    struct westwood *w = inet_csk_ca(sk);

    switch (event) {
        /* 处于快速路径时,用此函数更新w->bw_est和w->rtt_min */
    case CA_EVENT_FAST_ACK:
        westwood_fast_bw(sk);
        break;

        /* 退出Recovery或CWR状态时,进行拥塞窗口和慢启动阈值设置*/
    case CA_EVENT_COMPLETE_CWR:
        tp->snd_cwnd = tp->snd_ssthresh = tcp_westwood_bw_rttmin(sk);
        break;

        //当RTO超时时,会先进行FRTO检测,这时可设置慢启动阈值,
        //而拥塞窗口则设置为1.
    case CA_EVENT_FRTO:
        tp->snd_ssthresh = tcp_westwood_bw_rttmin(sk);
        /* Update RTT_min when next ack arrives */
        //如果超时了,那么最小RTT可能不准确,需要重新设置
        w->reset_rtt_min = 1;
        break;

        //处于慢速路径时,这时候的拥塞状态可能是CWR、Recovery、Loss等。
        //必须采用westwood_acked_count()来统计此ACK确认的数据量。
        //同时也进行w->bw_est和w->rtt_min的更新。
    case CA_EVENT_SLOW_ACK:
        westwood_update_window(sk);//更新带宽估计值
        w->bk += westwood_acked_count(sk);//计算所收到ACK确认的数据量
        update_rtt_min(w);//更新最小rtt
        break;

    default:
        /* don‘t care 对其它的事件则不做响应 */
        break;
    }
}

/* Extract info for Tcp socket info provided via netlink. */
//通过netlink提供信息给tcp_socket
static void tcp_westwood_info(struct sock *sk, u32 ext,
                  struct sk_buff *skb)
{
    const struct westwood *ca = inet_csk_ca(sk);
    if (ext & (1 << (INET_DIAG_VEGASINFO - 1))) {
        struct tcpvegas_info info = {
            .tcpv_enabled = 1,
            .tcpv_rtt = jiffies_to_usecs(ca->rtt),
            .tcpv_minrtt = jiffies_to_usecs(ca->rtt_min),
        };

        nla_put(skb, INET_DIAG_VEGASINFO, sizeof(info), &info);
    }
}

static struct tcp_congestion_ops tcp_westwood = {
    .init        = tcp_westwood_init,
    .ssthresh    = tcp_reno_ssthresh,
    .cong_avoid    = tcp_reno_cong_avoid,
    .min_cwnd    = tcp_westwood_bw_rttmin,
    .cwnd_event    = tcp_westwood_event,
    .get_info    = tcp_westwood_info,
    .pkts_acked    = tcp_westwood_pkts_acked,

    .owner        = THIS_MODULE,
    .name        = "westwood"
};

static int __init tcp_westwood_register(void)
{ //注册westwood算法
    BUILD_BUG_ON(sizeof(struct westwood) > ICSK_CA_PRIV_SIZE);
    return tcp_register_congestion_control(&tcp_westwood);
}

static void __exit tcp_westwood_unregister(void)
{ //注销westwood算法
    tcp_unregister_congestion_control(&tcp_westwood);
}

module_init(tcp_westwood_register);//westwood模块的入口函数
module_exit(tcp_westwood_unregister);//westwood模块的出口函数

MODULE_AUTHOR("Stephen Hemminger, Angelo Dell‘Aera");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("TCP Westwood+");
时间: 2024-12-23 14:44:56

tcp westwood源代码分析的相关文章

转:RTMPDump源代码分析

0: 主要函数调用分析 rtmpdump 是一个用来处理 RTMP 流媒体的开源工具包,支持 rtmp://, rtmpt://, rtmpe://, rtmpte://, and rtmps://.也提供 Android 版本. 最近研究了一下它内部函数调用的关系. 下面列出几个主要的函数的调用关系. RTMPDump用于下载RTMP流媒体的函数Download: 用于建立网络连接(NetConnect)的函数Connect: 用于建立网络流(NetStream)的函数 rtmpdump源代码

【转载】linux环境下tcpdump源代码分析

linux环境下tcpdump源代码分析 原文时间 2013-10-11 13:13:02   原文链接   主题 Tcpdump 作者:韩大卫 @ 吉林师范大学 tcpdump.c 是tcpdump 工具的main.c, 本文旨对tcpdump的框架有简单了解,只展示linux平台使用的一部分核心代码. Tcpdump 的使用目的就是打印出指定条件的报文,即使有再多的正则表达式作为过滤条件.所以只要懂得tcpdump -nXXi eth0 的实现原理即可. 进入main之前,先看一些头文件 n

OpenStack_Swift源代码分析——创建Ring及加入?设备源代码算法具体分析

1 创建Ring 代码具体分析 在OpenStack_Swift--Ring组织架构中我们具体分析了Ring的具体工作过程,以下就Ring中添加?设备,删除设备,已经又一次平衡的实现过程作具体的介绍. 首先看RingBuilder类 def __init__(self, part_power, replicas, min_part_hours): #why 最大 2**32 if part_power > 32: raise ValueError("part_power must be a

Memcached源代码分析 - Memcached源代码分析之消息回应(3)

文章列表: <Memcached源代码分析 - Memcached源代码分析之基于Libevent的网络模型(1)> <Memcached源代码分析 - Memcached源代码分析之命令解析(2)> <Memcached源代码分析 - Memcached源代码分析之消息回应(3)  > <Memcached源代码分析 - Memcached源代码分析之HashTable(4) > <Memcached源代码分析 - Memcached源代码分析之增删

wireshark源代码分析

3.如果执行命令,总是nmake报各种错,请反复检查你的Wireshark目录里面config.nmake文件配置的是否正确. 输入这个网址,http://www.wireshark.org/download/src/all-versions/,从上面下载Wireshark源代码,这里,值得一提的是,最好下载页面中给出的svn中的源代码,能保证该代码绝对是最新的. 下载完成之后,在Wireshark目录里面打开config.nmake,需要进行一些设置之后才可以开始编译. (1)WIRESHAR

MonkeyRunner源代码分析之启动

在工作中由于要追求完毕目标的效率,所以很多其它是强调实战.注重招式.关注怎么去用各种框架来实现目的.可是假设一味仅仅是注重招式.缺少对原理这个内功的了解,相信自己非常难对各种框架有更深入的理解. 从几个月前開始接触ios和android的自己主动化測试.原来是本着只为了提高測试团队工作效率的心态先行作浅尝即止式的研究,然后交给測试团队去边实现边自己研究.最后由于各种原因果然是浅尝然后就止步了,而自己终于也离开了上一家公司. 换了工作这段时间抛开全部杂念和曾经的困扰专心去学习研究各个框架的使用,逐

Java中arraylist和linkedlist源代码分析与性能比較

Java中arraylist和linkedlist源代码分析与性能比較 1,简单介绍 在java开发中比較经常使用的数据结构是arraylist和linkedlist,本文主要从源代码角度分析arraylist和linkedlist的性能. 2,arraylist源代码分析 Arraylist底层的数据结构是一个对象数组.有一个size的成员变量标记数组中元素的个数,例如以下图: * The array buffer into which the elements of the ArrayLis

Kafka SocketServer源代码分析

Kafka SocketServer源代码分析 标签: kafka 本文将详细分析Kafka SocketServer的相关源码. 总体设计 Kafka SocketServer是基于Java NIO来开发的,采用了Reactor的模式,其中包含了1个Acceptor负责接受客户端请求,N个Processor负责读写数据,M个Handler来处理业务逻辑.在Acceptor和Processor,Processor和Handler之间都有队列来缓冲请求. kafka.network.Accepto

pomelo源代码分析(一)

千里之行始于足下,一直说想了解pomelo,对pomelo有兴趣,但一直迟迟没有去碰,尽管对pomelo进行源代码分析,在网络上肯定不止我一个,已经有非常优秀的前辈走在前面,如http://golanger.cn/,在阅读Pomelo代码的时候,已经连载到了11篇了,在我的源代码分析參考了该博客,当然,也会添?我对pomelo的理解,借此希望能提高一下自己对node.js的了解和学习一些优秀的设计. 开发环境:win7 调试环境:webstorm5.0 node.js版本号:v0.8.21 源代