`
simohayha
  • 浏览: 1400088 次
  • 性别: Icon_minigender_1
  • 来自: 火星
社区版块
存档分类
最新评论

linux 内核tcp拥塞处理(一)

阅读更多
这次我们来分析tcp的拥塞控制,我们要知道协议栈都是很保守的,也就是说只要有一个段被判断丢失,它就会认为发生了拥塞.而现在还有另一种,也就是路由器来通知我们发生了拥塞,这里ip头还会有一个ECN的位(准确的说是两位),来表示已经发送拥塞,不过这里要注意首先收到ECN的是接受方,可是真正需要被通知的却是发送方,因此当接受方收到ECN之后,用下一个ack来通知发送方有拥塞发生了,然后发送方才会做出响应.

可以看到这里会有个问题的,那就是我们如何来之到对端是否支持ECN,在内核中一般都是在握手的时候就会确定对端是否支持ECN.这里可以看到我们ip头里面必须用到2位,因为这里我们会有3个状态:

第一个发送端不支持ECN,第二个状态发送端支持ECN,第三个状态,发生了拥塞.

可以看到我们在握手的时候双方通过交换ECN的信息,从而能得到这条连接是否支持ECN.

下面这段在tcp_transmit_skb中的代码片断就是如何通知对端本地支持ecn的代码。可以看到代码很简单,就是判断是否是一个syn包,如果是的话就进入ecn的握手处理。


if (likely((tcb->flags & TCPCB_FLAG_SYN) == 0))
		TCP_ECN_send(sk, skb, tcp_header_size);


而在TCP_ECN_send中最终会通过下面这两个宏来设置是否支持ecn。可以看到都是通过设置tos。


//支持
#define	INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; } while (0)

//不支持
#define	INET_ECN_dontxmit(sk) \
	do { inet_sk(sk)->tos &= ~INET_ECN_MASK; } while (0)



内核中是使用ip头的TOS域的剩余2两位来表示ECN的.下面就是ECN的三种状态:

enum {

//发送端不支持ecn
	INET_ECN_NOT_ECT = 0,
//下面这个貌似没有用到,不知道有什么意义。
	INET_ECN_ECT_1 = 1,
//发送端支持ecn
	INET_ECN_ECT_0 = 2,
//发生了拥塞
	INET_ECN_CE = 3,

//掩码
	INET_ECN_MASK = 3,
};



而这里通过ecn来设置拥塞是通过IP_ECN_set_ce方法来做的,这个设置是在ip层(是在qos的enqueue也就是出队列方法)来做的,我们先来看这个方法。这个方法就是通过ip头的tos域来判断是否为INET_ECN_CE,如果是这个则说明发生了拥塞(路由器通知我们),此时我们需要设置这个ip头的tos域,然后发送给对端,从而通知对端。


static inline int IP_ECN_set_ce(struct iphdr *iph)
{
	u32 check = (__force u32)iph->check;
	u32 ecn = (iph->tos + 1) & INET_ECN_MASK;

	/*
	 * After the last operation we have (in binary):
	 * INET_ECN_NOT_ECT => 01
	 * INET_ECN_ECT_1   => 10
	 * INET_ECN_ECT_0   => 11
	 * INET_ECN_CE      => 00
	 */
//可以看到如果没有发生拥塞或者说不支持ecn的话直接返回。
	if (!(ecn & 2))
		return !ecn;

	/*
	 * The following gives us:
	 * INET_ECN_ECT_1 => check += htons(0xFFFD)
	 * INET_ECN_ECT_0 => check += htons(0xFFFE)
	 */
///然后开始计算对应的域。
	check += (__force u16)htons(0xFFFB) + (__force u16)htons(ecn);

	iph->check = (__force __sum16)(check + (check>=0xFFFF));

//设置tos为 INET_ECN_CE从而通知对端。
	iph->tos |= INET_ECN_CE;
	return 1;
}


然后我们来看接受端如何来处理ECN通知的拥塞,这里检测拥塞(ECN通知的)是通过TCP_ECN_check_ce这个方法来做的。

static inline void TCP_ECN_check_ce(struct tcp_sock *tp, struct sk_buff *skb)
{
	if (tp->ecn_flags & TCP_ECN_OK) {
//如果发生了拥塞,则设置flags。
		if (INET_ECN_is_ce(TCP_SKB_CB(skb)->flags))
			tp->ecn_flags |= TCP_ECN_DEMAND_CWR;
		/* Funny extension: if ECT is not set on a segment,
		 * it is surely retransmit. It is not in ECN RFC,
		 * but Linux follows this rule. */
		else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags)))
			tcp_enter_quickack_mode((struct sock *)tp);
	}
}



接下来来看拥塞状态机,也就是发送的状态机,在linux内核中,发送端的状态分为下面5种,而这个状态是保存在inet_connection_sock的icsk_ca_state域中的。

enum tcp_ca_state
{
	TCP_CA_Open = 0,
#define TCPF_CA_Open	(1<<TCP_CA_Open)
	TCP_CA_Disorder = 1,
#define TCPF_CA_Disorder (1<<TCP_CA_Disorder)
	TCP_CA_CWR = 2,
#define TCPF_CA_CWR	(1<<TCP_CA_CWR)
	TCP_CA_Recovery = 3,
#define TCPF_CA_Recovery (1<<TCP_CA_Recovery)
	TCP_CA_Loss = 4
#define TCPF_CA_Loss	(1<<TCP_CA_Loss)
};


然后就简要的描述下这4个状态。

1 TCP_CA_Open

这个状态是也就是初始状态,我们可以看到在tcp_create_openreq_child(这个函数的意思可以看我前面的blog)中,当我们new一个新的socket之后就会设置这个socket的状态为TCP_CA_Open。这个也可以说是fast path。

2 TCP_CA_Disorder

当发送者检测到重复的ack或者sack就进入这个状态。在这个状态,拥塞窗口不会被调整,但是这个状态下的话,每一次新的输入数据包都会触发一个新的端的传输。

3 TCP_CA_CWR

这个状态叫做 (Congestion Window Reduced),顾名思义,也就是当拥塞窗口减小的时候会进入这个状态。比如当发送者收到一个ECN,此时就需要减小窗口。这个状态能够被Recovery or Loss 所打断。当接收到一个拥塞提醒的时候,发送者是每接收到一个ack,就减小拥塞窗口一个段,直到窗口大小减半。因此可以这么说当发送者正在减小窗口并且没有任何重传段的时候,就会处于CWR状态。

4 TCP_CA_Recovery

当足够数量的(一般是3个)的连续的重复ack到达发送端,则发送端立即重传第一个没有被ack的数据段,然后进入这个状态。处于这个状态的时候,发送者也是和CWR状态类似,每次接收到ack后减小窗口。在这个状态,拥塞窗口不会增长,发送者要么重传标记lost的段,要么传输新的段。当发送者进入这个状态时的没有被ack的段全部ack之后就离开这个状态。

5 TCP_CA_Loss

当RTO超时后,发送者就进入这个状态。此时所有的没有被ack的段都标记为loss,然后降低窗口大小为1,然后进入慢开始阶段。loss状态不能被其他状态所中断。而这个状态的退出只有当进入loss时,所有的被标记为loss的段都得到ack后,才会再次返回open状态。


然后我们再来看一下,linux中拥塞控制的用到的一些变量,这些变量前面的blog或多或少都有提过了,这次再统一描述一下。

在linux的协议栈实现中,用于拥塞控制的变量的关系满足下面的表达式:

left_out = sacked_out + lost_out
packets_out = SND.NXT - SND.UNA
in_flight = packets_out - left_out + retrans_out


sacked_out指的是被sack的段的个数。
lost_out指的是在网络中丢失的段的数目。这里要注意loss_out所包括的段依赖于所选择的recovery 方法的不同而不同(也就是依赖于不同的算法)。而且我们知道tcp并不能准确的得到数据包是否被丢弃,因此这个值只能是个猜测值。

因此我们可以看到left_out表示的就是已经离开网络可是还没有被ack的数据包。

packets_out指的是发送了还没有被确认的数据包。

retrans_out指的是重传的段的数目。

在linux协议栈的实现中,有两种算法来计算lost packets

1 FACK

这个算法是最简单的一个启发式算法,在这种算法中

lost_out = fackets_out - sacked_out并且left_out = fackets_out.

可以看到这里丢失的包不包括sacked的数据包。而fackets_out也就是sack和丢失的数据包的总和。

2 NewReno

这里还有一个classic Reno算法,是比较老的一个算法,这个算法中发送端收到一个新的ACK后旧退出TCP_CA_Recovery状态,而在NewReno中,只有当所有的数据包都被确认后才退出
TCP_CA_Recovery状态。

这里还有两个很重要的方法,分别是tcp_time_to_recover和tcp_xmit_retransmit_queue,这两个函数内核注释的也很详细:


引用


tcp_time_to_recover determines the moment _when_ we should reduce CWND and,
* hence, slow down forward transmission. In fact, it determines the moment
* when we decide that hole is caused by loss, rather than by a reorder.
*
* tcp_xmit_retransmit_queue() decides, _what_ we should retransmit to fill
* holes, caused by lost packets.


这两个方法后面会详细分析。

然后我们主要来看tcp_fastretrans_alert这个函数,所有的拥塞处理可以说都是在这个函数中进行的。这个函数被调用的条件是:

引用
* - each incoming ACK, if state is not "Open"
* - when arrived ACK is unusual, namely:
* * SACK
* * Duplicate ACK.
* * ECN ECE.


通过前面的blog我们知道,我们是在tcp_ack()中调用的,进入这个函数就意味着我们碰到了拥塞状态或者在拥塞状态处理tcp。在这个函数中,实现了下面的这些算法:

1 失败重传。
2 从不同的拥塞状态恢复。
3 检测到一个失败的拥塞状态从而使数据包的传输的延迟。
4 从所有的拥塞状态恢复到Open状态。



我们来一段段的看代码:

下面这一段主要是进行一些初始化,以及校验工作。

这里的这些flag标记就不详细介绍了,我前面的blog都有介绍,并且内核源码注释的也比较详细。

struct inet_connection_sock *icsk = inet_csk(sk);
	struct tcp_sock *tp = tcp_sk(sk);
///FLAG_SND_UNA_ADVANCED表示Snd_una被改变,也就是当前的ack不是一个重复ack。而FLAG_NOT_DUP表示也表示不是重复ack。
	int is_dupack = !(flag & (FLAG_SND_UNA_ADVANCED | FLAG_NOT_DUP));
//判断是否有丢失的段。
	int do_lost = is_dupack || ((flag & FLAG_DATA_SACKED) &&
				    (tcp_fackets_out(tp) > tp->reordering));
	int fast_rexmit = 0, mib_idx;

//如果发送未确认的数据包为0,则我们必须要重置sacked_out.
	if (WARN_ON(!tp->packets_out && tp->sacked_out))
		tp->sacked_out = 0;
//如果sacked_out为0,则fackets_out也必须设置为0.这是因为fack的计数依赖于最少一个sack的段。
	if (WARN_ON(!tp->sacked_out && tp->fackets_out))
		tp->fackets_out = 0;

	/* Now state machine starts.
	 * A. ECE, hence prohibit cwnd undoing, the reduction is required. */
///如果接收到ece则reset慢开始的界限。这是因为我们就要开始减小窗口了,所以这样就能停止慢开始。
	if (flag & FLAG_ECE)
		tp->prior_ssthresh = 0;

	/* B. In all the states check for reneging SACKs. */
//这个主要用来判断当前的ack是不是确认的是已经被sack的数据段,如果是的话,说明对端有bug或者不能正确的处理OFO的数据段。此时我们需要destroy掉所有的sack信息,然后返回。
	if (tcp_check_sack_reneging(sk, flag))
		return;

	/* C. Process data loss notification, provided it is valid. */

//这段主要是为了判断数据是否丢失。前两个判断主要是flag和fack的判定。
	if (tcp_is_fack(tp) && (flag & FLAG_DATA_LOST) &&
//这个为真说明一些段可能已经被接受端sack掉了。
	    before(tp->snd_una, tp->high_seq) &&
//这个说明当前已经进入了拥塞处理的状态。
	    icsk->icsk_ca_state != TCP_CA_Open &&
//这个为真说明在重传队列开始的一些段已经丢失。
	    tp->fackets_out > tp->reordering) {
///到达这里,我们将会依次标记所有的重传段都为丢失,直到我们发现第一个被sacked的段。
		tcp_mark_head_lost(sk, tp->fackets_out - tp->reordering);
		NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPLOSS);
	}

	/* D. Check consistency of the current state. */
	tcp_verify_left_out(tp);



下一篇我将会通过配合tcp_fastretrans_alert的剩余代码详细描述拥塞状态的变迁,以及各个状态的进入,退出条件.

这里可以看到慢开始这些没有介绍,这是因为我前面的blog对这些已经介绍过了,相关的可以看我前面的blog.
分享到:
评论

相关推荐

    Linux内核源码剖析:TCP IP实现(上册).pdf

    在Linux内核中,TCP/IP协议栈实现了这一系列协议的功能,使得Linux系统能够作为服务器或者客户端进行网络通信。 ### 二、TCP/IP协议栈基础知识 #### 1. 协议层次结构 TCP/IP模型分为四层:应用层、传输层、网络层...

    Linux内核中拥塞控制算法的比较分析.pdf

    本文对Linux内核中拥塞控制算法进行了比较分析,旨在评估不同拥塞控制协议的性能和局限性,并设计了一种新的环境自适应拥塞控制协议CVTCP。 拥塞控制算法的重要性 ------------------------ 在计算机网络中,拥塞...

    Linux 4.4.0 内核源码分析 TCP实现

    至于TCP的输入部分,Linux内核网络数据接收流程是一个复杂的多层处理过程。从接收到网络数据包开始,内核会逐层向上处理,从数据链路层、网络层、传输层,最终到达应用层。在处理过程中,既有可能是从下而上的处理,...

    Linux内核 tcp ip协议栈源码分析

    总之,《Linux内核TCP/IP协议栈源码分析》是一个深入理解网络通信、优化系统性能的重要课题。通过对源码的研读,我们可以更有效地排查网络问题,理解和设计高效的网络应用程序,并为未来的网络技术发展打下坚实基础...

    Linux内核TCP-IP协议栈分析.rar

    在本资料"Linux内核TCP/IP协议栈分析"中,我们将深入探讨这个核心组件的工作原理。 TCP/IP协议栈分为四个主要层次:应用层、传输层、网络层和数据链路层。在Linux内核中,每一层都有相应的模块负责处理相关的协议和...

    linux tcp(linux tcp下拥塞控制的经典文章)

    - **高级队列管理**:Linux内核实现了多种先进的队列管理算法,如FQ_CODEL等,能够有效地管理和减少网络队列长度,防止拥塞的发生。 #### 五、结论 本文详细介绍了Linux TCP中的拥塞控制机制及其关键特性。通过...

    《Linux内核源码剖析 TCP IP实现(上册) 樊东东 莫澜 pdf扫描版.

    《Linux内核源码剖析 TCP/IP实现》是樊东东和莫澜合著的一本深入解析Linux内核网络协议栈的书籍,主要关注TCP/IP协议的实现细节。这本书上册的内容,将引领读者深入理解Linux操作系统如何处理网络通信,特别是TCP/IP...

    linux内核TCP协议栈部分,下册

    《Linux内核TCP协议栈部分,下册》深入解析了Linux操作系统中TCP协议栈的实现细节,涵盖了TCP协议从启动到控制发送的全过程,以及不启用DSACK(duplicate SACK,重复确认选择)等相关主题。这本书是理解网络通信底层...

    Linux 内核源码剖析-TCP/IP实现(上册)

    《Linux内核源码剖析-TCP/IP实现(上册)》是一本专为初学者设计的书籍,旨在帮助读者深入理解Linux操作系统内核中的TCP/IP协议栈实现。这本书以清晰易懂的方式阐述了TCP/IP协议在Linux内核中的工作原理,涵盖了从...

    深入理解linux内核 中文第三版 高清PDF

    《深入理解Linux内核》是Linux系统开发领域的一本经典著作,中文第三版更是结合了最新的Linux内核版本,提供了全面且深入的内核解析。这本书涵盖了从内核设计哲学到具体实现细节的广泛主题,旨在帮助读者深入理解这...

    Linux网络体系结构 Linux内核中网络协议的设计与实现

    在Linux内核中,TCP和UDP模块处理连接建立、数据传输、流量控制和拥塞控制等问题。 5. **应用层**:这一层包含各种应用协议,如HTTP、FTP、SMTP等,它们直接与用户交互。Linux内核通过socket API为上层应用提供了与...

    通用拥塞控制及其在Linux内核中的实现.pdf

    在Linux内核中实现这一架构,需要修改或扩展现有的TCP拥塞控制模块,例如引入新的拥塞避免算法、更新拥塞窗口更新策略等。此外,还需要进行详细的性能测试和调优,确保新机制在实际网络环境中的稳定性和效率。 总的...

    深入分析Linux内核源码

    《深入分析Linux内核源码》是一本专为IT专业人士准备的深度学习资源,它旨在帮助读者理解并掌握Linux操作系统的内核工作原理。Linux内核是开源软件领域的瑰宝,是众多服务器、嵌入式设备以及云计算平台的核心。通过...

    Linux 内核设计与实现

    通过阅读这本书,你可以了解到Linux内核是如何处理系统调用、管理内存、调度进程、实现文件系统以及网络协议栈等一系列核心功能的。以下是对这些关键知识点的详细阐述: 1. **系统调用**:Linux内核通过系统调用...

    linux内核图解-内核图解

    Linux内核是一个开源的操作系统内核,由林纳斯·托瓦兹于1991年创建。它遵循GNU General Public License(GPL),鼓励全球开发者参与改进和扩展。Linux内核的模块化设计使得它可以根据不同的硬件平台进行定制,适用...

    linux内核注释全解

    《Linux内核注释全解》是一本深入探讨Linux内核的权威指南,它通过详尽的注释和解析,帮助读者理解这个开源操作系统的核心机制。Linux内核是全球开发者共同智慧的结晶,其设计与实现充满了巧妙和深思熟虑的细节。这...

    Linux内核情景分析(上下全集高清版)

    《Linux内核情景分析》是一本深度探讨Linux操作系统内核的权威著作,旨在帮助读者深入理解Linux内核的工作原理和实现机制。这本书分为上下两部分,全面覆盖了Linux内核的各个方面,包括进程管理、内存管理、文件系统...

    Linux内核源代码分析.

    6. **网络协议栈**:Linux内核的网络部分实现了TCP/IP协议族,包括IP、TCP、UDP等协议。它处理网络数据包的接收和发送,网络连接的建立和关闭,以及拥塞控制和错误恢复。 在分析Linux内核源代码时,通常会从以下几...

Global site tag (gtag.js) - Google Analytics