alchemystar资料

本文主要介绍alchemystar资料 方法和在新技术下所面对的“挑战”,方便大家深入理解alchemystar资料 过程。本文也将分享alchemystar资料 所遇到的问题和应对策略,怎么解决怎么做的问题。
通过深入本文可以理解代码原理,进行代码文档的下载,也可以查看相应 Demo 部署效果。

从Linux源码看Socket(TCP)Client端的Connect

前言

笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。
今天笔者就来从Linux源码的角度看下Client端的Socket在进行Connect的时候到底做了哪些事情。由于篇幅原因,关于Server端的Accept源码讲解留给下一篇博客。
(基于Linux 3.10内核)

一个最简单的Connect例子

int clientSocket; if((clientSocket = socket(AF_INET, SOCK_STREAM, 0)) < 0) { 	//  创建socket失败失败  	return -1; } ...... if(connect(clientSocket, (struct sockaddr *)&serverAddr, sizeof(serverAddr)) < 0) { 	// connect 失败 	return -1; } .......  

首先我们通过socket系统调用创建了一个socket,其中指定了SOCK_STREAM,而且最后一个参数为0,也就是建立了一个通常所有的TCP Socket。在这里,我们直接给出TCP Socket所对应的ops也就是操作函数。
alchemystar
如果你想知道上图中的结构是怎么来的,可以看下笔者以前的博客:

https://my.oschina.net/alchemystar/blog/1791017 

值得注意的是,由于socket系统调用操作做了如下两个代码的判断

sock_map_fd 	|->get_unused_fd_flags 			|->alloc_fd 				|->expand_files (ulimit) 	|->sock_alloc_file	 		|->alloc_file 			|->get_empty_filp (/proc/sys/fs/max_files) 

第一个判断,ulmit超限:

int expand_files(struct files_struct *files, int nr { 	...... 	if (nr >= current->signal->rlim[RLIMIT_NOFILE].rlim_cur) 		return -EMFILE; 	...... } 

这边的判断即是ulimit的限制!在这里返回-EMFILE对应的描述就是
"Too many open files"
alchemystar

第二个判断max_files超限

struct file *get_empty_filp(void) {  ...... 	/* 	 * 由此可见,特权用户可以无视文件数最大大小的限制! 	 */ 	if (get_nr_files() >= files_stat.max_files && !capable(CAP_SYS_ADMIN)) { 		/* 		 * percpu_counters are inaccurate.  Do an expensive check before 		 * we go and fail. 		 */ 		if (percpu_counter_sum_positive(&nr_files) >= files_stat.max_files) 			goto over; 	} 	  ...... } 

所以在文件描述符超过所有进程能打开的最大文件数量限制(/proc/sys/fs/file-max)的时候会返回-ENFILE,对应的描述就是"Too many open files in system",但是特权用户确可以无视这一限制,如下图所示:
alchemystar

connect系统调用

我们再来看一下connect系统调用:

int connect(int sockfd,const struct sockaddr *serv_addr,socklen_t addrlen) 

这个系统调用有三个参数,那么依据规则,它肯定在内核中的源码长下面这个样子

SYSCALL_DEFINE3(connect, ...... 

笔者全文搜索了下,就找到了具体的实现:

socket.c SYSCALL_DEFINE3(connect, int, fd, struct sockaddr __user *, uservaddr, 		int, addrlen) {    ...... 	err = sock->ops->connect(sock, (struct sockaddr *)&address, addrlen, 				 sock->file->f_flags); 	...... } 

前面图给出了在TCP下的sock->ops == inet_stream_ops,然后再陷入到更进一步的调用栈中,即下面的:

SYSCALL_DEFINE3(connect 	|->inet_stream_ops 		|->inet_stream_connect 			|->tcp_v4_connect 				|->tcp_set_state(sk, TCP_SYN_SENT);设置状态为TCP_SYN_SENT 			 	|->inet_hash_connect 				|->tcp_connect 

首先,我们来看一下inet_hash_connect这个函数,里面有一个端口号的搜索过程,搜索不到可用端口号就会导致创建连接失败!内核能够建立一个连接也是跋涉了千山万水的!我们先看一下搜索端口号的逻辑,如下图所示:
alchemystar

获取端口号范围

首先,我们从内核中获取connect能够使用的端口号范围,在这里采用了Linux中的顺序锁(seqlock)

void inet_get_local_port_range(int *low, int *high) { 	unsigned int seq;  	do { 		// 顺序锁 		seq = read_seqbegin(&sysctl_local_ports.lock);  		*low = sysctl_local_ports.range[0]; 		*high = sysctl_local_ports.range[1]; 	} while (read_seqretry(&sysctl_local_ports.lock, seq)); } 

顺序锁事实上就是结合内存屏障等机制的一种乐观锁,主要依靠一个序列计数器。在读取数据之前和之后,序列号都被读取,如果两者的序列号相同,说明在读操作的时候没有被写操作打断过。
这也保证了上面的读取变量都是一致的,也即low和high不会出现low是改前值而high是改后值得情况。low和high要么都是改之前的,要么都是改之后的!内核中修改的地方为:

cat /proc/sys/net/ipv4/ip_local_port_range  32768 61000  

通过hash决定端口号起始搜索范围

在Linux上进行connect,内核给其分配的端口号并不是线性增长的,但是也符合一定的规律。
先来看下代码:

int __inet_hash_connect(...) { 		// 注意,这边是static变量 		static u32 hint; 		// 这边的port_offset是用对端ip:port hash的一个值 		// 也就是说对端ip:port固定,port_offset固定 		u32 offset = hint + port_offset; 		for (i = 1; i <= remaining; i++) { 			port = low + (i + offset) % remaining; 			/* port是否占用check */ 			.... 			goto ok; 		} 		....... ok: 		hint += i; 		...... } 

这里面有几个小细节,为了安全原因,Linux本身用对端ip:port做了一次hash作为搜索的初始offset,所以不同远端ip:port初始搜索范围可以基本是不同的!但同样的对端ip:port初始搜索范围是相同的!
alchemystar
在笔者机器上,一个完全干净的内核里面,不停的对同一个远端ip:port,其以2进行稳定增长,也即38742->38744->38746,如果有其它的干扰,就会打破这个规律。

端口号范围限制

由于我们指定了端口号返回ip_local_port_range是不是就意味着我们最多创建high-low+1个连接呢?当然不是,由于检查端口号是否重复是将(网络命名空间,对端ip,对端port,本端port,Socket绑定的dev)当做唯一键进行重复校验,所以限制仅仅是在同一个网络命名空间下,连接同一个对端ip:port的最大可用端口号数为high-low+1,当然可能还要减去ip_local_reserved_ports。如下图所示:
alchemystar

检查端口号是否被占用

端口号的占用搜索分为两个阶段,一个是处于TIME_WAIT状态的端口号搜索,另一个是其它状态端口号搜索。

TIME_WAIT状态端口号搜索

众所周知,TIME_WAIT阶段是TCP主动close必经的一个阶段。如果Client采用短连接的方式和Server端进行交互,就会产生大量的TIME_WAIT状态的Socket。而这些Socket由占用端口号,所以当TIME_WAIT过多,打爆上面的端口号范围之后,新的connect就会返回错误码:

C语言connect返回错误码为 -EADDRNOTAVAIL,对应描述为Cannot assign requested address  对应Java的异常为 java.net.NoRouteToHostException: Cannot assign requested address (Address not available) 

ip_local_reserved_ports。如下图所示:
alchemystar
由于TIME_WAIT大概一分钟左右才能消失,如果在一分钟内Client端和Server建立大量的短连接请求就容易导致端口号耗尽。而这个一分钟(TIME_WAIT的最大存活时间)是在内核(3.10)编译阶段就确定了的,无法通过内核参数调整。 如下代码所示:

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT 				  * state, about 60 seconds	*/ 

Linux自然也考虑到了这种情况,所以提供了一个tcp_tw_reuse参数使得在搜索端口号时可以在某些情况下重用TIME_WAIT。代码如下:

__inet_hash_connect 	|->__inet_check_established static int __inet_check_established(......) { 	......	 	/* Check TIME-WAIT sockets first. */ 	sk_nulls_for_each(sk2, node, &head->twchain) { 		tw = inet_twsk(sk2); 		// 如果在time_wait中找到一个match的port,就判断是否可重用 		if (INET_TW_MATCH(sk2, net, hash, acookie, 					saddr, daddr, ports, dif)) { 			if (twsk_unique(sk, sk2, twp)) 				goto unique; 			else 				goto not_unique; 		} 	} 	...... } 

如上面代码中写的那样,如果在一堆TIME-WAIT状态的Socket里面能够有当前要搜索的port,则判断是否这个port可以重复利用。如果是TCP的话这个twsk_unique的实现函数是:

int tcp_twsk_unique(......) { 	...... 	if (tcptw->tw_ts_recent_stamp && 	    (twp == NULL || (sysctl_tcp_tw_reuse && 			     get_seconds() - tcptw->tw_ts_recent_stamp > 1))) { 		tp->write_seq = tcptw->tw_snd_nxt + 65535 + 2 		...... 		return 1; 	} 	return 0;	 } 

上面这段代码逻辑如下所示:
alchemystar
在开启了tcp_timestamp以及tcp_tw_reuse的情况下,在Connect搜索port时只要比之前用这个port的TIME_WAIT状态的Socket记录的最近时间戳>1s,就可以重用此port,即将之前的1分钟缩短到1s。同时为了防止潜在的序列号冲突,直接将write_seq加上在65537,这样,在单Socket传输速率小于80Mbit/s的情况下,不会造成序列号冲突。
同时这个tw_ts_recent_stamp设置的时机如下图所示:
alchemystar
所以如果Socket进入TIME_WAIT状态后,如果一直有对应的包发过来,那么会影响此TIME_WAIT对应的port是否可用的时间。我们可以通过下面命令开始tcp_tw_reuse:

echo '1' > /proc/sys/net/ipv4/tcp_tw_reuse 

ESTABLISHED状态端口号搜索

ESTABLISHED的端口号搜索就简单了许多

	/* And established part... */ 	sk_nulls_for_each(sk2, node, &head->chain) { 		if (INET_MATCH(sk2, net, hash, acookie, 					saddr, daddr, ports, dif)) 			goto not_unique; 	}  

以(网络命名空间,对端ip,对端port,本端port,Socket绑定的dev)当做唯一键进行匹配,如果匹配成功,表明此端口无法重用。

端口号迭代搜索

Linux内核在[low,high]范围按照上述逻辑进行port的搜索,如果没有搜索到port,即port耗尽,就会返回-EADDRNOTAVAIL,也即Cannot assign requested address。但还有一个细节,如果是重用TIME_WAIT状态的Socket的端口的话,就会将对应的TIME_WAIT状态的Socket给销毁。

__inet_hash_connect(......) { 		...... 		if (tw) { 			inet_twsk_deschedule(tw, death_row); 			inet_twsk_put(tw); 		} 		...... } 		 

寻找路由表

在我们找到一个可用端口号port后,就会进入搜寻路由阶段:

ip_route_newports 	|->ip_route_output_flow 			|->__ip_route_output_key 				|->ip_route_output_slow 					|->fib_lookup 

这也是一个非常复杂的过程,限于篇幅,就不做详细阐述了。如果搜索不到路由信息的话,会返回。

-ENETUNREACH,对应描述为Network is unreachable 

Client端的三次握手

在前面一大堆前置条件就绪后,才进入到真正的三次握手阶段。

tcp_connect 	|->tcp_connect_init 初始化tcp socket 	|->tcp_transmit_skb 发送SYN包 	|->inet_csk_reset_xmit_timer 设置SYN重传定时器 

tcp_connect_init初始化了一大堆TCP相关的设置,例如mss_cache/rcv_mss等一大堆。而且如果开启了TCP窗口扩大选项的话,其窗口扩大因子也在此函数里进行计算:

tcp_connect_init 	|->tcp_select_initial_window int tcp_select_initial_window(...) { 	...... 	(*rcv_wscale) = 0; 	if (wscale_ok) { 		/* Set window scaling on max possible window 		 * See RFC1323 for an explanation of the limit to 14 		 */ 		space = max_t(u32, sysctl_tcp_rmem[2], sysctl_rmem_max); 		space = min_t(u32, space, *window_clamp); 		while (space > 65535 && (*rcv_wscale) < 14) { 			space >>= 1; 			(*rcv_wscale)++; 		} 	} 	...... }	  

如上面代码所示,窗口扩大因子取决于Socket最大可允许的读缓冲大小和window_clamp(最大允许滑动窗口大小,动态调整)。搞完了一票初始信息设置后,才开始真正的三次握手。
在tcp_transmit_skb中才真正发送SYN包,同时在紧接着的inet_csk_reset_xmit_timer里设置了SYN超时定时器。如果对端一直不发送SYN_ACK,将会返回-ETIMEDOUT。
alchemystar
重传的超时时间和

/proc/sys/net/ipv4/tcp_syn_retries 

息息相关,Linux默认设置为5,建议设置成3,下面是不同设置的超时时间参照图。
alchemystar
在设置了SYN超时重传定时器后,tcp_connnect就返回,并一路返回到最初始的inet_stream_connect。在这里我们就等待对端返回SYN_ACK或者SYN定时器超时。

int __inet_stream_connect(struct socket *sock,...,) { 	// 如果设置了O_NONBLOCK则timeo为0 	timeo = sock_sndtimeo(sk, flags & O_NONBLOCK); 	...... 	// 如果timeo=0即O_NONBLOCK会立刻返回 	// 否则等待timeo时间 	if (!timeo || !inet_wait_for_connect(sk, timeo, writebias)) 		goto out; } 

Linux本身提供一个SO_SNDTIMEO来控制对connect的超时,不过Java并没有采用这个选项。而是采用别的方式进行connect的超时控制。仅仅就C语言的connect系统调用而言,不设置SO_SNDTIMEO,就会将对应用户进程进行睡眠,直到SYN_ACK到达或者超时定时器超时才将次用户进程唤醒。
alchemystar
如果是NON_BLOCK的话,则是通过select/epoll等多路复用机制去捕获超时或者连接成功事件。

对端SYN_ACK到达

在Server端SYN_ACK到达之后会按照下面的代码路径传递,并唤醒用户态进程:

tcp_v4_rcv 	|->tcp_v4_do_rcv 		|->tcp_rcv_state_process 			|->tcp_rcv_synsent_state_process 				|->tcp_finish_connect 					|->tcp_init_metrics 初始化度量统计 					|->tcp_init_congestion_control 初始化拥塞控制 					|->tcp_init_buffer_space 初始化buffer空间 					|->inet_csk_reset_keepalive_timer 开启包活定时器 					|->sk_state_change(sock_def_wakeup) 唤醒用户态进程 				|->tcp_send_ack 发送三次握手的最后一次握手给Server端 			|->tcp_set_state(sk, TCP_ESTABLISHED) 设置为ESTABLISHED状态 
alchemystar资料部分资料来自网络,侵权毕设源码联系删除

区块链毕设网(www.qklbishe.com)全网最靠谱的原创区块链毕设代做网站
部分资料来自网络,侵权联系删除!
资源收费仅为搬运整理打赏费用,用户自愿支付 !
qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台 » alchemystar资料

提供最优质的资源集合

立即查看 了解详情