从Linux源码看Socket(TCP)Client端的Connect
从Linux源码看Socket(TCP)Client端的Connect
前言
笔者一直以为若是能知道从应用到框架再到操做系统的每一处代码，是一件Exciting的事情。
今天笔者就来从Linux源码的角度看下Client端的Socket在进行Connect的时候到底作了哪些事情。因为篇幅缘由，关于Server端的Accept源码讲解留给下一篇博客。
(基于Linux 3.10内核)java
一个最简单的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也就是操做函数。
若是你想知道上图中的结构是怎么来的，能够看下笔者之前的博客:node
https://my.oschina.net/alchemystar/blog/1791017
值得注意的是，因为socket系统调用操做作了以下两个代码的判断linux
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"
cookie
第二个判断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",可是特权用户确能够无视这一限制,以下图所示:
框架
connect系统调用
咱们再来看一下connect系统调用:socket
int connect(int sockfd,const struct sockaddr *serv_addr,socklen_t addrlen)
这个系统调用有三个参数，那么依据规则，它确定在内核中的源码长下面这个样子tcp
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这个函数，里面有一个端口号的搜索过程，搜索不到可用端口号就会致使建立链接失败！内核可以创建一个链接也是跋涉了千山万水的！咱们先看一下搜索端口号的逻辑,以下图所示:
获取端口号范围
首先，咱们从内核中获取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初始搜索范围是相同的！
在笔者机器上，一个彻底干净的内核里面，不停的对同一个远端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。以下图所示:
检查端口号是否被占用
端口号的占用搜索分为两个阶段，一个是处于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。以下图所示:
因为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;
}
上面这段代码逻辑以下所示:
在开启了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设置的时机以下图所示:
因此若是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。
重传的超时时间和
/proc/sys/net/ipv4/tcp_syn_retries
息息相关，Linux默认设置为5，建议设置成3，下面是不一样设置的超时时间参照图。
在设置了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到达或者超时定时器超时才将次用户进程唤醒。
若是是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状态
公众号
关注笔者公众号，获取更多干货文章
总结
Client(TCP)端进行Connect的过程真是跋山涉水，从一开始文件描述符的限制到端口号的搜索再到路由表的搜索再到最后的三次握手，任何一个环节有问题就会致使建立链接失败,笔者详细的描述了这些机制的源码实现。但愿本篇文章能够对读者在之后遇到Connect失败问题时候有所帮助。
- 1. 从Linux源码看Socket(TCP)Client端的Connect
- 2. 从linux源码看epoll
- 3. 从linux源码看socket的close
- 4. 从linux源码看socket(tcp)的timeout
- 5. 从Linux源码看Socket(TCP)的accept
- 6. 从源码看React.PureComponent
- 7. React Redux: 从文档看源码 - Connect工具类篇（1）
- 8. React Redux: 从文档看源码 - Connect工具类篇（2）
- 9. 从String源码看Java中的编码
- 10. 从JDK源码看InputStream
- 更多相关文章...
- • MySQL查看表中的约束 - MySQL教程
- • Docker 资源汇总 - Docker教程
- • Java Agent入门实战（二）-Instrumentation源码概述
- • 使用阿里云OSS+CDN部署前端页面与加速静态资源
-
每一个你不满意的现在，都有一个你没有努力的曾经。