kk Blog —— 通用基础

date [-d @int|str] [+%s|"+%F %T"]

select,poll,epoll

样例 socket_select_poll_epoll.tar


https://blog.csdn.net/jyy305/article/details/73012706

select

select函数预备知识

1.struct fd_set可以理解为一个集合,这个集合中存放的是文件描述符(file descriptor),即文件句柄,这可以是我们所说的普通意义的文件,当然Unix下任何设备、管道、FIFO等都是文件形式,全部包括在内,所以毫无疑问一个socket就是一个文件,socket句柄就是一个文件描述符。fd_set集合可以通过一些宏由人为来操作。

(1) FD_CLR(inr fd,fd_set set):用来清除描述词组set中相关fd 的位
(2) FD_ISSET(int fd,fd_set
set):用来测试描述词组set中相关fd 的位是否为真
FD_SET(int fd,fd_set*set):用来设置描述词组set中相关fd的位

2.struct timeval是一个大家常用的结构,用来代表时间值,有两个成员,一个是秒数,另一个是毫秒数。

FD_ZERO(fd_set *set);用来清除描述词组set的全部位

select函数介绍

1
int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout);

maxfdp : 需要监视的最大文件描述符加1。

readfds、writefds、errorfds:分别对应于需要检测的可读文件描述符的集合,可写文件描述符的集 合及异常文件描述符的集合。

timeout:等待时间,这个时间内,需要监视的描述符没有事件
发⽣生则函数返回,返回值为0。设为-1表示阻塞式等待,一直等到有事件就绪,函数才会返回,0表示非阻塞式等待,没有事件就立即返回,大于0表示等待的时间。
返回值:大于0表示就绪时间的个数,等于0表示timeout等待时间到了,小于0表示调用失败。

select函数原理

select系统调用是用来让我们的程序监视多个文件句柄的状态变化的。程序会停在select这⾥里等待,直到被监视的文件句柄有一个或多个发⽣生了状态改变。关于文件句柄,其实就是⼀一个整数,我们最熟悉的句柄是0、1、2三个,0是标准输入,1是标准输出,2是标准错误输出。0、1、2是整数表示的,对应的FILE *结构的表示就是stdin、stdout、stderr。

1.我们通常需要额外定义一个数组来保存需要监视的文件描述符,并将其他没有保存描述符的位置初始化为一个特定值,一般为-1,这样方便我们遍历数组,判断对应的文件描述符是否发生了相应的事件。

2.采用上述的宏操作FD_SET(int fd,fd_set*set)遍历数组将关心的文件描述符设置到对应的事件集合里。并且每次调用之前都需要遍历数组,设置文件描述符。

3.调用select函数等待所关心的文件描述符。有文件描述符上的事件就绪后select函数返回,没有事件就绪的文件描述符在文件描述符集合中对应的位置会被置为0,这就是上述第二步的原因。

4.select 返回值大于0表示就绪的文件描述符的个数,0表示等待时间到了,小于0表示调用失败,因此我们可以遍历数组采用FD_ISSET(int fd,fd_set *set)判断哪个文件描述符上的事件就绪,然后执行相应的操作。


https://www.cnblogs.com/Anker/p/3261006.html

poll

1、基本知识

poll的机制与select类似,与select在本质上没有多大差别,管理多个描述符也是进行轮询,根据描述符的状态进行处理,但是poll没有最大文件描述符数量的限制。poll和select同样存在一个缺点就是,包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间,而不论这些文件描述符是否就绪,它的开销随着文件描述符数量的增加而线性增大。

2、poll函数

函数格式如下所示:

1
2
#include <poll.h>
int poll ( struct pollfd * fds, unsigned int nfds, int timeout);

pollfd 结构体定义如下:

1
2
3
4
5
struct pollfd {
	int fd;         /* 文件描述符 */
	short events;   /* 等待的事件 */
	short revents;  /* 实际发生了的事件 */
} ; 

每一个pollfd结构体指定了一个被监视的文件描述符,可以传递多个结构体,指示poll()监视多个文件描述符。每个结构体的events域是监视该文件描述符的事件掩码,由用户来设置这个域。revents域是文件描述符的操作结果事件掩码,内核在调用返回时设置这个域。events域中请求的任何事件都可能在revents域中返回。合法的事件如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
POLLIN           有数据可读。
POLLRDNORM       有普通数据可读。
POLLRDBAND       有优先数据可读。
POLLPRI          有紧迫数据可读。
POLLOUT          写数据不会导致阻塞。
POLLWRNORM       写普通数据不会导致阻塞。
POLLWRBAND       写优先数据不会导致阻塞。
POLLMSGSIGPOLL   消息可用。

# 此外,revents域中还可能返回下列事件:
# 这些事件在events域中无意义,因为它们在合适的时候总是会从revents中返回。
POLLER           指定的文件描述符发生错误。
POLLHUP          指定的文件描述符挂起事件。
POLLNVAL         指定的文件描述符非法。

使用poll()和select()不一样,你不需要显式地请求异常情况报告。

POLLIN | POLLPRI等价于select()的读事件,POLLOUT |POLLWRBAND等价于select()的写事件。POLLIN等价于POLLRDNORM |POLLRDBAND,而POLLOUT则等价于POLLWRNORM。

例如,要同时监视一个文件描述符是否可读和可写,我们可以设置 events为POLLIN | POLLOUT。在poll返回时,我们可以检查revents中的标志,对应于文件描述符请求的events结构体。如果POLLIN事件被设置,则文件描述符可以被读取而不阻塞。如果POLLOUT被设置,则文件描述符可以写入而不导致阻塞。这些标志并不是互斥的:它们可能被同时设置,表示这个文件描述符的读取和写入操作都会正常返回而不阻塞。

timeout参数指定等待的毫秒数,无论I/O是否准备好,poll都会返回。timeout指定为负数值表示无限超时,使poll()一直挂起直到一个指定事件发生;timeout为0指示poll调用立即返回并列出准备好I/O的文件描述符,但并不等待其它的事件。这种情况下,poll()就像它的名字那样,一旦选举出来,立即返回。

返回值和错误代码

成功时,poll()返回结构体中revents域不为0的文件描述符个数;如果在超时前没有任何事件发生,poll()返回0;失败时,poll()返回-1,并设置errno为下列值之一:

1
2
3
4
5
EBADF       一个或多个结构体中指定的文件描述符无效。
EFAULTfds   指针指向的地址超出进程的地址空间。
EINTR       请求的事件之前产生一个信号,调用可以重新发起。
EINVALnfds  参数超出PLIMIT_NOFILE值。
ENOMEM      可用内存不足,无法完成请求。

https://www.jianshu.com/p/ee381d365a29

https://blog.csdn.net/libaineu2004/article/details/70197825

https://www.cnblogs.com/fnlingnzb-learner/p/5835573.html

epoll

在linux的网络编程中,很长的时间都在使用select来做事件触发。在linux新的内核中,有了一种替换它的机制,就是epoll。 相比于select,epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中,它是采用轮询来处理的,轮询的fd数目越多,自然耗时越多。并且,在linux/posix_types.h头文件有这样的声明:

1
#define __FD_SETSIZE    1024

表示select最多同时监听1024个fd,当然,可以通过修改头文件再重编译内核来扩大这个数目,但这似乎并不治本。

EPOLL 的API用来执行类似poll()的任务。能够用于检测在多个文件描述符中任何IO可用的情况。Epoll API可以用于边缘触发(edge-triggered)和水平触发(level-triggered), 同时epoll可以检测更多的文件描述符。以下的系统调用函数提供了创建和管理epoll实例:

epoll_create() 可以创建一个epoll实例并返回相应的文件描述符(epoll_create1() 扩展了epoll_create() 的功能)。
注册相关的文件描述符使用epoll_ctl()
epoll_wait() 可以用于等待IO事件。如果当前没有可用的事件,这个函数会阻塞调用线程。

关于ET、LT两种工作模式:

ET模式仅当状态发生变化的时候才获得通知,这里所谓的状态的变化并不包括缓冲区中还有未处理的数据,也就是说,如果要采用ET模式,需要一直read/write直到出错为止,很多人反映为什么采用ET模式只接收了一部分数据就再也得不到通知了,大多因为这样;而LT模式是只要有数据没有处理就会一直通知下去的.

下面情况下推荐使用ET模式:

使用非阻塞的IO。
epoll_wait() 只需要在read或者write返回的时候。

相比之下,当我们使用LT的时候(默认),epoll会比poll更简单更快速,而且我们可以使用在任何一个地方。

API介绍

1. 创建epoll

1
2
3
4
#include <sys/epoll.h>

int epoll_create(int size);
int epoll_create1(int flags);

epoll_create() 可以创建一个epoll实例。在linux 内核版本大于2.6.8 后,这个size 参数就被弃用了,但是传入的值必须大于0。

在 epoll_create () 的最初实现版本时, size参数的作用是创建epoll实例时候告诉内核需要使用多少个文件描述符。内核会使用 size 的大小去申请对应的内存(如果在使用的时候超过了给定的size, 内核会申请更多的空间)。现在,这个size参数不再使用了(内核会动态的申请需要的内存)。但要注意的是,这个size必须要大于0,为了兼容旧版的linux 内核的代码。

epoll_create() 会返回新的epoll对象的文件描述符。这个文件描述符用于后续的epoll操作。如果不需要使用这个描述符,请使用close关闭。

epoll_create1() 如果flags的值是0,epoll_create1()等同于epoll_create()除了过时的size被遗弃了。当然flasg可以使用 EPOLL_CLOEXEC,请查看 open() 中的O_CLOEXEC来查看 EPOLL_CLOEXEC有什么用。

返回值: 如果执行成功,返回一个非负数(实际为文件描述符), 如果执行失败,会返回-1,具体原因请查看erro

2. 设置epoll事件

1
2
3
#include <sys/epoll.h>

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件注册函数,它不同与select()是在监听事件时告诉内核要监听什么类型的事件,而是在这里先注册要监听的事件类型。第一个参数是epoll_create()的返回值,第二个参数表示动作,用三个宏来表示:

1
2
3
EPOLL_CTL_ADD    注册新的fd到epfd中;
EPOLL_CTL_MOD 修改已经注册的fd的监听事件;
EPOLL_CTL_DEL 从epfd中删除一个fd;

第三个参数是需要监听的fd,第四个参数是告诉内核需要监听什么事,struct epoll_event结构如下:

1
2
3
4
5
6
7
8
9
10
11
typedef union epoll_data {
	void *ptr;
	int fd;
	__uint32_t u32;
	__uint64_t u64;
} epoll_data_t;

struct epoll_event {
	__uint32_t events; /* Epoll events */
	epoll_data_t data; /* User data variable */
};

events可以是以下几个宏的集合:

1
2
3
4
5
6
7
EPOLLIN      表示对应的文件描述符可以读(包括对端SOCKET正常关闭);
EPOLLOUT  表示对应的文件描述符可以写;
EPOLLPRI  表示对应的文件描述符有紧急的数据可读(这里应该表示有带外数据到来);
EPOLLERR  表示对应的文件描述符发生错误;
EPOLLHUP  表示对应的文件描述符被挂断;
EPOLLET       将EPOLL设为边缘触发(Edge Triggered)模式,这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT  只监听一次事件,当监听完这次事件之后,如果还需要继续监听这个socket的话,需要再次把这个socket加入到EPOLL队列里
返回值:如果成功,返回0。如果失败,会返回-1, errno将会被设置

有以下几种错误:

1
2
3
4
5
6
EBADF  - epfd 或者 fd 是无效的文件描述符。
EEXIST - op是EPOLL_CTL_ADD,同时 fd 在之前,已经被注册到epoll中了。
EINVAL - epfd不是一个epoll描述符。或者fd和epfd相同,或者op参数非法。
ENOENT - op是EPOLL_CTL_MOD或者EPOLL_CTL_DEL,但是fd还没有被注册到epoll上。
ENOMEM - 内存不足。
EPERM  - 目标的fd不支持epoll。

3. 等待epoll事件

1
2
3
#include <sys/epoll.h>

int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epoll_wait 这个系统调用是用来等待epfd中的事件。events指向调用者可以使用的事件的内存区域。maxevents告知内核有多少个events,必须要大于0.

timeout这个参数是用来制定epoll_wait 会阻塞多少毫秒,会一直阻塞到下面几种情况:

一个文件描述符触发了事件。
被一个信号处理函数打断,或者timeout超时。

当timeout等于-1的时候这个函数会无限期的阻塞下去,当timeout等于0的时候,就算没有任何事件,也会立刻返回。

epoll_pwait

还有一个系统调用epoll_pwait ()。epoll_pwait()和epoll_wait ()的关系就像select()和 pselect()的关系。和pselect()一样,epoll_pwait()可以让应用程序安全的等待知道某一个文件描述符就绪或者捕捉到信号。

下面的 epoll_pwait () 调用:

1
ready = epoll_pwait(epfd, &events, maxevents, timeout, &sigmask);

在内部等同于:

1
2
3
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ready = epoll_wait(epfd, &events, maxevents, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);

如果 sigmask为NULL, epoll_pwait()等同于epoll_wait()。

返回值:有多少个IO事件已经准备就绪。如果返回0说明没有IO事件就绪,而是timeout超时。遇到错误的时候,会返回-1,并设置 errno。

有以下几种错误:

1
2
3
4
EBADF  - epfd是无效的文件描述符
EFAULT - 指针events指向的内存没有访问权限
EINTR  - 这个调用被信号打断。
EINVAL - epfd不是一个epoll的文件描述符,或者maxevents小于等于0

mysql conf

/etc/my.cnf

增加:

1
2
3
4
5
6
7
8
9
10
11
12
[client]
default-character-set=utf8

[mysql]
default-character-set=utf8

[mysqld]
init_connect='SET collation_connection = utf8_unicode_ci'
init_connect='SET NAMES utf8'
character-set-server=utf8
collation-server=utf8_unicode_ci
skip-character-set-client-handshake

nulls_hlist原理 和 tcp连接查找

1
2
3
4
5
struct proto tcp_prot = {
	...
	.slab_flags             = SLAB_DESTROY_BY_RCU,
	...
}

sk 的slab初始化的时候带上 SLAB_DESTROY_BY_RCU ,所以free(sk)只会把sk加入到slab的freelist,并不会释放内存。

这也就是为什么__inet_lookup_established里需要两次INET_MATCH。因为第一次INET_MATCH到atomic_inc_not_zero之间有可能在另一个cpu上将sk放到freelist,然后sk又被其他连接alloc拿去用了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
__inet_lookup_established() {
	...
begin:
	sk_nulls_for_each_rcu(sk, node, &head->chain) {
		if (likely(INET_MATCH(sk, net, acookie, saddr, daddr, ports, dif))) {
			if (unlikely(!atomic_inc_not_zero(&sk->sk_refcnt)))
				goto out;
			if (unlikely(!INET_MATCH(sk, net, acookie, saddr, daddr, ports, dif))) {
				sock_gen_put(sk);
				goto begin;
			}
			goto found;
		}
	}
	...
}

https://blog.csdn.net/dog250/article/details/73013732

Linux 4.7之前TCP连接处理问题

我们已经知道,在TCP的接收主函数tcp_v4_rcv中,基于skb的元数据查找socket的过程是无锁的,查找完毕之后,会针对找到的socket结果上锁或者无锁处理,逻辑非常清晰:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
tcp_v4_rcv(skb)
{
	sk = lockless_lookup(skb);
	if (sk.is_listener) {
// Lockless begin
		process_handshake(sk, skb);
		new_sk = build_synack_sk(skb);
		new_sk.listener = sk;
	} else if (sk.is_synrecv) {
		listener = sk.lister;
		child_sk = build_child_sk(skb, sk);
		add_sk_into_acceptq(listener, child_sk);
// Lockless end
		goto data;
	} else {
data:
		lock(sk);
		process(sk, skb);
		unlock(sk);
	}
}

这个逻辑已经臻于完美了,至少在表面上看来确实如此!

当我知道了4.7内核针对syncookie的优化之后,我便内窥了lockless_lookup内部,突破性的改进在于,4.7内核用真正的RCU callback替换了一个仅有的Atomic操作,做到了真正的无锁化查找!

看来我们都被骗了,其实所谓的lockless_lookup并不是真正的lockless,为了应景和应题,本文只讨论Listener socket,我们来看下它的逻辑:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
lockless_lookup(skb)
{
	hash = hashfn(skb);
	hlist = listener_list[hash];
// 第一部分:#1-查找socket
begin:
	sk_nulls_for_each_rcu(sk, node, hlist) {
		if (match(skb, sk)) {
			ret = sk;
		}
	}
// 第二部分:#2-与socket重新hash并插入hlist进行互斥    
	if (get_nulls_value(node) != hash) {
		goto begin;
	}

// 第三部分:#3-与socket被释放进行互斥   
	if (ret) {
		if (!atomic_inc_not_zero(ret))
			ret = NULL;
	}

	return ret;
}

这个逻辑可以分为3个部分,我在注释中已经标明,可以看到,虽然在调用者tcp_v4_rcv看来,查找socket的操作是无锁的,然而内窥其实现逻辑之后便会发现,它其实还是在内部进行了两个轻量级的互斥操作。下面我来一个一个说。

nulls hlist互斥

由于在lockless_lookup被调用时是无锁的,所以在sk_nulls_for_each_rcu遍历过程中会出现以下情况造成遍历混乱:

这种情况下,常规的hlist是无法发现的,因为这种hlist以next为NULL视为链表的结束。不管一个node被重新hash到哪个链表,在结束的时候都会碰到NULL,此时你根本区别不出来这个NULL是不是一开始遍历开始时那个hlist冲突链表的NULL。怎么解决这个问题呢?上锁肯定是不妥的,幸亏Linux内核有一个精妙的数据结构,即nulls hlist!下面我先来简单地介绍一下这个精妙的hlist数据结构和标准的hlist有何不同。

差异:

1.nulls hlist不再以NULL结尾,而以一个大到231空间的任意值结尾

2.nulls hlist以node最低位是不是1标识是不是链表的结束

于是nulls hlist的结尾节点的next字段可以编码为高31位和低1位,如果低1位为1,那么高31位便可以取出当初存进去的任意值,是不是很精妙呢?!之所以可以这么做,原因很简单,在计算机中,Linux内核数据结构的所有的地址都是对齐存放的,因此最低1位的数据位是空闲的,当然可以借为它用了。

现在我们考虑这个nulls node的高31位存什么数据好呢?答案很明确,当然是存该hlist的hash值了,这样以下的操作一目了然:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
init:
for (i = 0; i < INET_LHTABLE_SIZE; i++) {
	// 低1位和高31位的拼接:
	// 低1位保存1,代表结束,新节点会插入到其前面
	// 高31位保存该list的hash值
	listener_list[i].next = (1UL | (((long)i) << 1)) 
}

lookup:
hash1 = hashfn(skb);
hlist = listener_list[hash1];
sk_nulls_for_each_rcu...{
	...
}
hash2 = get_nulls_value(node);
if (hash1 != hash2) {
	// 发现结束的时候已经不在开始遍历的链表上了
	goto begin;
}
//.....

是不是很精妙呢?其实在Linux中,很多地方都用到了这个nulls hlist数据结构,我第一次看到它是在当年搞nf conntrack的时候。   以上的叙述大致解释了这个nulls hlist的精妙之处,说完了优点再看看它的问题,这个nulls hlist带啦的不断retry是一种消极尝试,非常类似顺序锁读操作,只要读冲突便一直重复,直到某次没有冲突,关于顺序锁,可以看一下read_seqbegin/read_seqretry以及write_seqlock这对夫妻和小三。   为什么需要这样?答案是,在无锁化的lookup中,必须这样!因为你取出一个node和从该node取出下一个node之间是有时间差的,你没有对这个时间差强制没有任何保护措施,这就是根本原因,所以,消极的尝试也未尝不是一个好办法。   总结下根本原因,取出node和取出下一个node之间存在race!

原子变量互斥

刚刚说完了lockless_lookup的第二部分,下面看看第三部分,atomic_inc_not_zero带来的互斥。

我们知道,在sk_nulls_for_each_rcu找到一个匹配的socket并且nulls node检查通过之后,在实际使用它之前,由于无锁化调用,会存在race,此期间可能会有别的线程将该socket释放到虚空,如何避免使用一个已经被释放的socket呢?这个很简单,操作原子计数器即可:

1
2
3
4
5
6
7
8
9
10
11
12
13
free:
if (atomic_dec_and_test(sk)) {
	// 此往后,由于已经将ref减为0,别处的inc_not_zero将失败,因此可以放心释放socket了。
	free(sk);
}

lookup:
if (ret && !atomic_inc_not_zero(ret)) {
	ret = NULL;
	goto done;
}
// 此处后,由于已经增加了ref,引用的数据将是有效数据
//...

虽然这个Atomic变量不是什么锁,但是在微观上,操作它是要锁总线的,即便在代码层面没有看到任何lock字眼,但这是指令集的逻辑。当面对ddos攻击的时候,试想同时会有多少的线程争抢这个Atomic底下的总线资源!!这是一笔昂贵的开销!

为什么非要有这么一个操作呢?答案很明确,怕取到一个被释放的socket从而导致内核数据混乱,简单点说就是怕panic。所以必然要有个原子变量来保护一下,事实证明,这么做还真不错呢。然而把问题更上一层来谈,为什么内核数据会混乱导致panic?因为取出node和使用node之间存在race,在这两个操作之间,node可能会被释放掉。这一点和上面的“取出node和取出下一个node之间存在race”是不同的。

现在发现了2个race:

1.取出node和取出下一个node之间;

2.取出node和使用node之间。

但归根结底,这两个race是同一个问题导致,那就是socket被释放(重新hash也有个先被释放的过程)!如果一个socket在被lookup期间,不允许被释放是否可以呢(你可以调用释放操作,但在此期间,你要保证数据有效)?当然可以,如何做到就是一个简单的事情了。如果能做到这一点并且真的做了,上述针对两个race的两个互斥就可以去掉了,TCP的新建连接数性能指标必然会有大幅度提升。

Linux 4.7的优化

Linux 4.7内核通过SOCK_RCU_FREE标识重构了sk_destruct的实现:

1
2
3
4
5
6
7
void sk_destruct(struct sock *sk)
{
	if (sock_flag(sk, SOCK_RCU_FREE))
		call_rcu(&sk->sk_rcu, __sk_destruct);
	else
		__sk_destruct(&sk->sk_rcu);
}

如果携带有SOCK_RCU_FREE标识,便通过RCU callback进行释放,我们知道,RCU callback的调用时机是必须经过一个grace period,而这个period通过rcu lock/unlock可以严格控制。

一切显得简单明了。Linux 4.7内核仅为Listener socket设置了SOCK_RCU_FREE标识:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 创建socket
__inet_hash(...)
{
	...
	sock_set_flag(sk, SOCK_RCU_FREE);
	...
}

// 从一个Listener socket派生子socket
inet_csk_clone_lock(...)
{
	struct sock *newsk = sk_clone_lock(sk, priority);
	if (newsk) {
		...
		/* listeners have SOCK_RCU_FREE, not the children */
		sock_reset_flag(newsk, SOCK_RCU_FREE);
		...
	}
	...
}

这保证了在lockless_lookup调用中不必再担心取到错误的数据和无效的数据,前提是lockless_lookup的调用必须有rcu锁的保护。这很容易:

1
2
3
4
5
	rcu_read_lock();
	sk = lockless_lookup(skb);
	...
done:
	rcu_read_unlock();12345

当然,这个lock/unlock没有体现在tcp_v4_rcv函数里,而是体现在了ip_local_deliver_finish里。

社区patch

以下是一个社区的patch:

[PATCH v2 net-next 06/11] tcp/dccp: do not touch listener sk_refcnt under synflood

http://www.spinics.net/lists/netdev/msg371229.html

本地下载 do-not-touch-listener-sk_refcnt-under-synflood.patch

作者详细说明了取消原子变量操作后带来的收益并且携带测试结果,我想这算是令人信服的,最重要的是,它已经被合入内核了。

crash执行shell脚本

crash执行shell脚本

1
2
3
4
5
crash> kmem -S TCP > /tmp/slabinfo

[root@vm1 ~]# cat /tmp/slabinfo | grep '\[fff' | awk -F[ '{print $2}' | awk -F] '{print "sock "$1" | grep skc_portpair >> /tmp/sock"}' > /tmp/sock.sh

crash> < /tmp/sock.sh

ip tcp_metric, 链路状态历史

开关

/proc/sys/net/ipv4/tcp_no_metrics_save

命令

https://www.linux.org/docs/man8/ip-tcp_metrics.html

1
2
3
4
5
6
7
8
9
10
11
12
NAME
       ip-tcp_metrics - management for TCP Metrics

SYNOPSIS
       ip [ OPTIONS ] tcp_metrics { COMMAND | help }


       ip tcp_metrics { show | flush } SELECTOR

       ip tcp_metrics delete [ address ] ADDRESS

       SELECTOR := [ [ address ] PREFIX ]

EXAMPLES

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
   ip tcp_metrics show address 192.168.0.0/24
       Shows the entries for destinations from subnet

   ip tcp_metrics show 192.168.0.0/24
       The same but address keyword is optional

   ip tcp_metrics
       Show all is the default action

   ip tcp_metrics delete 192.168.0.1
       Removes the entry for 192.168.0.1 from cache.

   ip tcp_metrics flush 192.168.0.0/24
       Removes entries for destinations from subnet

   ip tcp_metrics flush all
       Removes all entries from cache

   ip -6 tcp_metrics flush all
       Removes all IPv6 entries from cache keeping the IPv4 entries.

https://blog.csdn.net/dog250/article/details/52071132

在inet_peer/tcp_metrics_hash中记录通往一个IP地址的链路状况历史的metrics信息

2.6.32版本内核

路由cache项记录了一个标准的二元组,它记如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
struct rtable
{
	union
	{
		struct dst_entry    dst;
	} u;
	...
	// 以下为记录二元组的信息
	__be32            rt_dst;    /* Path destination    */
	__be32            rt_src;    /* Path source        */
	int            rt_iif;
 
	/* Info on neighbour */
	__be32            rt_gateway;
 
	/* Miscellaneous cached information */
	__be32            rt_spec_dst; /* RFC1122 specific destination */
	// peer很重要!
	struct inet_peer    *peer; /* long-living peer info */
};

注意这个peer字段,很重要!peer结构体记如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct inet_peer
{
	/* group together avl_left,avl_right,v4daddr to speedup lookups */
	struct inet_peer    *avl_left, *avl_right;
	__be32            v4daddr;    /* peer's address */
	__u16            avl_height;
	__u16            ip_id_count;    /* IP ID for the next packet */
	struct list_head    unused;
	__u32            dtime;        /* the time of last use of not
				         * referenced entries */
	atomic_t        refcnt;
	atomic_t        rid;        /* Frag reception counter */
	__u32            tcp_ts;
	unsigned long        tcp_ts_stamp;
};

已经初见雏形了,peer里面记录了一些关于tcp的描述信息,这个可以指导TCP进行拥塞控制。我需要在peer结构体里面添加诸如init_cwnd,RTT,ssthresh之类的就好了,这些信息从哪来?从上次的连接中来,或者从所有之前的连接数据的移动指数平均而来!

在建立或者接受连接的时候,甚至在每次发送数据包的时候,都需要查找路由,然后在命中路由cache的时候,自然而然就取到了peer字段,然后就可以用peer字段里面的数据指导TCP连接了,可以说,这个数据仅仅对TCP初始拥塞控制参数有效,其后的数据还是在本连接内学习为好。

3.10内核, inet_peer结构体依然存在,只是不再用它了

路由cache在3.5之后被去除了,因此rtable也就和peer脱了钩。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
struct rtable {
	struct dst_entry    dst;
 
	int            rt_genid;
	unsigned int        rt_flags;
	__u16            rt_type;
	__u8            rt_is_input;
	__u8            rt_uses_gateway;
 
	int            rt_iif;
 
	/* Info on neighbour */
	__be32            rt_gateway;
 
	/* Miscellaneous cached information */
	u32            rt_pmtu;
 
	struct list_head    rt_uncached;
};

inet_peer从此变成了一个独立的东西,随用随取,取到则用,取不到则罢。inet_getpeer接口非常好用,它完成以下措施:

1.如果二元组不存在,可以创建;

2.如果二元组存在,则立即取到。

这就是说,你可以调用唯一的这个接口完成查询,创建操作,至于销毁,完全靠系统的一个定时器来负责,完全不用用户操心。在认同了inet_peer框架带来的福音之后,我们再来看inet_peer结构体与2.6.32内核的不同:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
struct inet_peer {
	/* group together avl_left,avl_right,v4daddr to speedup lookups */
	struct inet_peer __rcu    *avl_left, *avl_right;
	struct inetpeer_addr    daddr;
	__u32            avl_height;
 
	// 此为关键!
	u32            metrics[RTAX_MAX];
	u32            rate_tokens;    /* rate limiting for ICMP */
	unsigned long        rate_last;
	union {
		struct list_head    gc_list;
		struct rcu_head     gc_rcu;
	};
	/*
	 * Once inet_peer is queued for deletion (refcnt == -1), following fields
	 * are not available: rid, ip_id_count
	 * We can share memory with rcu_head to help keep inet_peer small.
	 */
	union {
		struct {
			atomic_t            rid;        /* Frag reception counter */
			atomic_t            ip_id_count;    /* IP ID for the next packet */
		};
		struct rcu_head         rcu;
		struct inet_peer    *gc_next;
	};
 
	/* following fields might be frequently dirtied */
	__u32            dtime;    /* the time of last use of not referenced entries */
	atomic_t        refcnt;
};

注意metrics字段!看看RTAX_MAX即可:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
enum {
	RTAX_UNSPEC,
#define RTAX_UNSPEC RTAX_UNSPEC
	RTAX_LOCK,
#define RTAX_LOCK RTAX_LOCK
	RTAX_MTU,
#define RTAX_MTU RTAX_MTU
	RTAX_WINDOW,
#define RTAX_WINDOW RTAX_WINDOW
	RTAX_RTT,
#define RTAX_RTT RTAX_RTT
	RTAX_RTTVAR,
#define RTAX_RTTVAR RTAX_RTTVAR
	RTAX_SSTHRESH,
#define RTAX_SSTHRESH RTAX_SSTHRESH
	RTAX_CWND,
#define RTAX_CWND RTAX_CWND
	RTAX_ADVMSS,
#define RTAX_ADVMSS RTAX_ADVMSS
	RTAX_REORDERING,
#define RTAX_REORDERING RTAX_REORDERING
	RTAX_HOPLIMIT,
#define RTAX_HOPLIMIT RTAX_HOPLIMIT
	RTAX_INITCWND,
#define RTAX_INITCWND RTAX_INITCWND
	RTAX_FEATURES,
#define RTAX_FEATURES RTAX_FEATURES
	RTAX_RTO_MIN,
#define RTAX_RTO_MIN RTAX_RTO_MIN
	RTAX_INITRWND,
#define RTAX_INITRWND RTAX_INITRWND
	__RTAX_MAX
};
 
#define RTAX_MAX (__RTAX_MAX - 1)

几乎涵盖了大多数的TCP拥塞控制参数,这简直是荒漠甘泉!然而,然而我发现这个inet_peer框架几乎没有被调用的地方。这又是为何?这又一次在逼我重新造轮子吗?…从中,我看到了社区里面的点滴,inet_peer结构体依然存在,只是不再用它了,作为替代,作为替代一定有新的东西完成inet_peer的功能并且甚之!

3.10内核中,tcp_metrics_hash占据了主角

不同于inet_peer,在既有的3.10内核中,tcp_metrics_hash占据了主角,仔细看看这个架构,感觉还是比inet_peer好,比之更加正式。这个接口是靠以下两个维护的:

tcp_get_metrics

tcp_update_metrics

这个metrics框架也是一个类似inet_peer一样全局的信息记录,但是功能跟inet_peer有些重复。在TCP连接初始之时,调用tcp_get_metrics获取TCP拥塞参数,然后在TCP连接结束的时候,会调用tcp_update_metrics来更新metrics,这个貌似更加合理。