AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

从linux源码看socket的close

2018-08-22 2139
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 从linux源码看socket的close 笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。上篇博客讲了socket的阻塞和非阻塞，这篇就开始谈一谈socket的close(以tcp为例且基于linux-2.

从linux源码看socket的close

笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。上篇博客讲了socket的阻塞和非阻塞，这篇就开始谈一谈socket的close(以tcp为例且基于linux-2.6.24内核版本)

TCP关闭状态转移图:

众所周知，TCP的close过程是四次挥手，状态机的变迁也逃不出TCP状态转移图，如下图所示:
输入图片说明
tcp的关闭主要分主动关闭、被动关闭以及同时关闭(特殊情况,不做描述)

主动关闭

close(fd)的过程

以C语言为例，在我们关闭socket的时候，会使用close(fd)函数:

int    socket_fd;
socket_fd = socket(AF_INET, SOCK_STREAM, 0);
...
// 此处通过文件描述符关闭对应的socket
close(socket_fd)

而close(int fd)又是通过系统调用sys_close来执行的:

asmlinkage long sys_close(unsigned int fd)
{
    // 清除(close_on_exec即退出进程时）的位图标记
    FD_CLR(fd, fdt->close_on_exec);
    // 释放文件描述符
    // 将fdt->open_fds即打开的fd位图中对应的位清除
    // 再将fd挂入下一个可使用的fd以便复用
    __put_unused_fd(files, fd);
    // 调用file_pointer的close方法真正清除
    retval = filp_close(filp, files);
}

我们看到最终是调用的filp_close方法:

int filp_close(struct file *filp, fl_owner_t id)
{
    // 如果存在flush方法则flush
    if (filp->f_op && filp->f_op->flush)
        filp->f_op->flush(filp, id);
    // 调用fput    
    fput(filp);
    ......
}

紧接着我们进入fput:

void fastcall fput(struct file *file)
{
    // 对应file->count--,同时检查是否还有关于此file的引用
    // 如果没有，则调用_fput进行释放
    if (atomic_dec_and_test(&file->f_count))
        __fput(file);
}

同一个file(socket)有多个引用的情况很常见，例如下面的例子:
输入图片说明
所以在多进程的socket服务器编写过程中，父进程也需要close(fd)一次，以免socket无法最终关闭

然后就是_fput函数了:

void fastcall __fput(struct file *file)
{
    // 从eventpoll中释放file
    eventpoll_release(file);
    // 如果是release方法，则调用release
    if (file->f_op && file->f_op->release)
        file->f_op->release(inode, file);
}

由于我们讨论的是socket的close,所以，我们现在探查下file->f_op->release在socket情况下的实现:

f_op->release的赋值

我们跟踪创建socket的代码，即

socket(AF_INET, SOCK_STREAM, 0);
    |-sock_create  // 创建sock
    |-sock_map_fd  // 将sock和fd关联
            |-sock_attach_fd
                    |-init_file(file,...,&socket_file_ops);
                            |-file->f_op = fop; //fop赋值为socket_file_ops

socket_file_ops的实现为:

static const struct file_operations socket_file_ops = {
    .owner =    THIS_MODULE,
    ......
    // 我们在这里只考虑sock_close
    .release =    sock_close,
    ......
};

继续跟踪:

sock_close
    |-sock_release
        |-sock->ops->release(sock);

在上一篇博客中，我们知道sock->ops为下图所示:
输入图片说明
即(在这里我们仅考虑tcp,即sk_prot=tcp_prot):

inet_stream_ops->release
    |-inet_release
            |-sk->sk_prot->close(sk, timeout);
                |-tcp_prot->close(sk, timeout);
                    |->tcp_prot.tcp_close

关于fd与socket的关系如下图所示:
输入图片说明
上图中红色线标注的是close(fd)的调用链

tcp_close

void tcp_close(struct sock *sk, long timeout)
{
    if (sk->sk_state == TCP_LISTEN) {
        // 如果是listen状态，则直接设为close状态
        tcp_set_state(sk, TCP_CLOSE);
    }
    // 清空掉recv.buffer
    ......
    // SOCK_LINGER选项的处理
    ......
    else if (tcp_close_state(sk)){
        // tcp_close_state会将sk从established状态变为fin_wait1
        // 发送fin包
        tcp_send_fin(sk);
    }
    ......
}

四次挥手

现在就是我们的四次挥手环节了，其中上半段的两次挥手下图所示:
输入图片说明
首先，在tcp_close_state(sk)中已经将状态设置为fin_wait1,并调用tcp_send_fin

void tcp_send_fin(struct sock *sk)
{
    ......
    // 这边设置flags为ack和fin
    TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_FIN);
    ......
    // 发送fin包，同时关闭nagle
    __tcp_push_pending_frames(sk, mss_now, TCP_NAGLE_OFF);
}

如上图Step1所示。
接着，主动关闭的这一端等待对端的ACK，如果ACK回来了，就设置TCP状态为FIN_WAIT2,如上图Step2所示,具体代码如下:

tcp_v4_do_rcv
    |-tcp_rcv_state_process
int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb, struct tcphdr *th, unsigned len)    
{
    ......
    /* step 5: check the ACK field */
    if (th->ack) {
        ...
        case TCP_FIN_WAIT1:
            // 这处判断是确认此ack是发送Fin包对应的那个ack
            if (tp->snd_una == tp->write_seq) {
                // 设置为FIN_WAIT2状态
                tcp_set_state(sk, TCP_FIN_WAIT2);
                ......
                // 设定TCP_FIN_WAIT2定时器，将在tmo时间到期后将状态变迁为TIME_WAIT
                // 不过是这时候改的已经是inet_timewait_sock了
                tcp_time_wait(sk, TCP_FIN_WAIT2, tmo);
                ......
            }
    }
    /* step 7: process the segment text */
    switch(sk->sk_state) {
    case TCP_FIN_WAIT1:
    case TCP_FIN_WAIT2:
        ......
    case TCP_ESTABLISHED:
        tcp_data_queue(sk, skb);
        queued = 1;
        break;
    }
    .....
}

值的注意的是，从TCP_FIN_WAIT1变迁到TCP_FIN_WAIT2之后，还调用tcp_time_wait设置一个TCP_FIN_WAIT2定时器，在tmo+(2MSL或者基于RTO计算超时)超时后会直接变迁到closed状态(不过此时已经是inet_timewait_sock了）。这个超时时间可以配置,如果是ipv4的话,则可以按照下列配置:

net.ipv4.tcp_fin_timeout   
/sbin/sysctl -w net.ipv4.tcp_fin_timeout=30

如下图所示:
输入图片说明
有这样一步的原因是防止对端由于种种原因始终没有发送fin,防止一直处于FIN_WAIT2状态。

接着在FIN_WAIT2状态等待对端的FIN，完成后面两次挥手:
输入图片说明
由Step1和Step2将状态置为了FIN_WAIT_2，然后接收到对端发送的FIN之后,将会将状态设置为time_wait,如下代码所示:

tcp_v4_do_rcv
    |-tcp_rcv_state_process
        |-tcp_data_queue
                |-tcp_fin
static void tcp_fin(struct sk_buff *skb, struct sock *sk, struct tcphdr *th)
{
    switch (sk->sk_state) {
        ......    
        case TCP_FIN_WAIT1:
            // 这边是处理同时关闭的情况
            tcp_send_ack(sk);
            tcp_set_state(sk, TCP_CLOSING);
            break;
        case TCP_FIN_WAIT2:
            /* Received a FIN -- send ACK and enter TIME_WAIT. */
            // 收到FIN之后，发送ACK同时将状态进入TIME_WAIT
            tcp_send_ack(sk);
            tcp_time_wait(sk, TCP_TIME_WAIT, 0);
    }
}

time_wait状态时，原socket会被destroy,然后新创建一个inet_timewait_sock,这样就能及时的将原socket使用的资源回收。而inet_timewait_sock被挂入一个bucket中，由
inet_twdr_twcal_tick定时从bucket中将超过(2MSL或者基于RTO计算的时间)的time_wait的实例删除。
我们来看下tcp_time_wait函数

void tcp_time_wait(struct sock *sk, int state, int timeo)
{
    // 建立inet_timewait_sock
    tw = inet_twsk_alloc(sk, state);
    // 放到bucket的具体位置等待定时器删除
    inet_twsk_schedule(tw, &tcp_death_row, time,TCP_TIMEWAIT_LEN);
    // 设置sk状态为TCP_CLOSE,然后回收sk资源
    tcp_done(sk);
}

具体的定时器操作函数为inet_twdr_twcal_tick,这边就不做描述了

被动关闭

close_wait

在tcp的socket时候，如果是established状态，接收到了对端的FIN,则是被动关闭状态,会进入close_wait状态,如下图Step1所示:
输入图片说明
具体代码如下所示:

tcp_rcv_state_process
    |-tcp_data_queue
static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
{
    ...
    if (th->fin)
        tcp_fin(skb, sk, th);
    ...
}

我们再看下tcp_fin

static void tcp_fin(struct sk_buff *skb, struct sock *sk, struct tcphdr *th)
{
    ......
    // 这一句表明当前socket有ack需要发送
    inet_csk_schedule_ack(sk);
    ......
    switch (sk->sk_state) {
            case TCP_SYN_RECV:
            case TCP_ESTABLISHED:
                /* Move to CLOSE_WAIT */
                // 状态设置程close_wait状态
                tcp_set_state(sk, TCP_CLOSE_WAIT);
                // 这一句表明，当前fin可以延迟发送
                // 即和后面的数据一起发送或者定时器到时后发送
                inet_csk(sk)->icsk_ack.pingpong = 1;
                break;
    }
    ......
}

这边有意思的点是，收到对端的fin之后并不会立即发送ack告知对端收到了，而是等有数据携带一块发送,或者等携带重传定时器到期后发送ack。

如果对端关闭了，应用端在read的时候得到的返回值是0,此时就应该手动调用close去关闭连接

if(recv(sockfd, buf, MAXLINE,0) == 0){
    close(sockfd)
}

我们看下recv是怎么处理fin包，从而返回0的,上一篇博客可知，recv最后调用tcp_rcvmsg,由于比较复杂，我们分两段来看:
tcp_recvmsg第一段

        ......
        // 从接收队列里面获取一个sk_buffer
        skb = skb_peek(&sk->sk_receive_queue);
        do {
            // 如果已经没有数据，直接跳出读取循环，返回0
            if (!skb)
                break;
            ......
            // *seq表示已经读到多少seq
            // TCP_SKB_CB(skb)->seq表示当前sk_buffer的起始seq
            // offset即是在当前sk_buffer中已经读取的长度
            offset = *seq - TCP_SKB_CB(skb)->seq;
            // syn处理 
            if (tcp_hdr(skb)->syn)
                offset--;
            // 此处判断表示，当前skb还有数据可读，跳转found_ok_skb
            if (offset < skb->len)
                goto found_ok_skb;
            // 处理fin包的情况    
            // offset == skb->len,跳转到found_fin_ok然后跳出外面的大循环
            // 并返回0
            if (tcp_hdr(skb)->fin)
                goto found_fin_ok;
            BUG_TRAP(flags & MSG_PEEK);
            skb = skb->next;
        } while (skb != (struct sk_buff *)&sk->sk_receive_queue);
        ......

上面代码的处理过程如下图所示:
输入图片说明
我们看下tcp_recmsg的第二段:

found_ok_skb:
        // tcp已读seq更新
        *seq += used;
        // 这次读取的数量更新
        copied += used;
        // 如果还没有读到当前sk_buffer的尽头，则不检测fin标识
        if (used + offset < skb->len)
            continue;
        // 如果发现当前skb有fin标识，去found_fin_ok
        if (tcp_hdr(skb)->fin)
            goto found_fin_ok;
        ......
found_fin_ok:
        /* Process the FIN. */
        // tcp已读seq++
        ++*seq;
        ...
        break;
} while(len > 0);

由上面代码可知，一旦当前skb读完了而且携带有fin标识，则不管有没有读到用户期望的字节数量都会返回已读到的字节数。下一次再读取的时候则在刚才描述的tcp_rcvmsg上半段直接不读取任何数据再跳转到found_fin_ok并返回0。这样应用就能感知到对端已经关闭了。
如下图所示:
输入图片说明

last_ack

应用层在发现对端关闭之后已经是close_wait状态，这时候再调用close的话，会将状态改为last_ack状态，并发送本端的fin,如下代码所示:

void tcp_close(struct sock *sk, long timeout)
{
    ......
    else if (tcp_close_state(sk)){
        // tcp_close_state会将sk从close_wait状态变为last_ack
        // 发送fin包
        tcp_send_fin(sk);
    }
}

在接收到主动关闭端的last_ack之后，则调用tcp_done(sk)设置sk为tcp_closed状态，并回收sk的资源,如下代码所示:

tcp_v4_do_rcv
    |-tcp_rcv_state_process
int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb, struct tcphdr *th, unsigned len)    
{
    ......
    /* step 5: check the ACK field */
    if (th->ack) {
        ...
        case TCP_LAST_ACK:
            // 这处判断是确认此ack是发送Fin包对应的那个ack
            if (tp->snd_una == tp->write_seq) {
                    tcp_update_metrics(sk);
                    // 设置socket为closed，并回收socket的资源
                    tcp_done(sk);
                    goto discard;
            }
        ...
    }
}

上述代码就是被动关闭端的后两次挥手了,如下图所示:

输入图片说明

出现大量close_wait的情况

linux中出现大量close_wait的情况一般是应用在检测到对端fin时没有及时close当前连接。有一种可能如下图所示:
输入图片说明
当出现这种情况，通常是minIdle之类参数的配置不对(如果连接池有定时收缩连接功能的话)。给连接池加上心跳也可以解决这种问题。
如果应用close的时间过晚，对端已经将连接给销毁。则应用发送给fin给对端，对端会由于找不到对应的连接而发送一个RST(Reset)报文。

操作系统何时回收close_wait

如果应用迟迟没有调用close_wait,那么操作系统有没有一个回收机制呢，答案是有的。
tcp本身有一个包活(keep alive)定时器，在(keep alive)定时器超时之后，会强行将此连接关闭。可以设置tcp keep alive的时间

/etc/sysctl.conf
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200

默认值如上面所示，设置的很大，7200s后超时，如果想快速回收close_wait可以设置小一点。但最终解决方案还是得从应用程序着手。
关于tcp keepalive包活定时器可见笔者另一篇博客:
https://my.oschina.net/alchemystar/blog/833981

进程关闭时清理socket资源

进程在退出时候(无论kill,kill -9 或是正常退出)都会关闭当前进程中所有的fd(文件描述符)

do_exit
    |-exit_files
        |-__exit_files
            |-close_files
                    |-filp_close

这样我们又回到了博客伊始的filp_close函数，对每一个是socket的fd发送send_fin

Java GC时清理socket资源

Java的socket最终关联到AbstractPlainSocketImpl,且其重写了object的finalize方法

abstract class AbstractPlainSocketImpl extends SocketImpl 
{
    ......
    /**
     * Cleans up if the user forgets to close it.
     */
    protected void finalize() throws IOException {
        close()
    }
    ......
}

所以Java会在GC时刻会关闭没有被引用的socket,但是切记不要寄希望于Java的GC,因为GC时刻并不是以未引用的socket数量来判断的，所以有可能泄露了一堆socket,但仍旧没有触发GC。

总结

linux内核源代码博大精深，阅读其代码很费周折。之前读<<TCP/IP详解卷二>>的时候由于有先辈引导和梳理，所以看书中所使用的BSD源码并不觉得十分费劲。直到现在自己带着问题独立看linux源码的时候，尽管有之前的基础，仍旧被其中的各种细节所迷惑。希望笔者这篇文章能帮助到阅读linux网络协议栈代码的人。

原文链接

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

文章标签：
容器服务Kubernetes版
网络协议
Linux
Java
关键词：
Linux socket
Linux源码
socket linux
Linux close
socket源码
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用，部署一个新的应用用于新的发布，并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程，本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术，这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时，本课程也会向您介绍可以采取的工具、方法和可操作步骤，以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后，您将能够： 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
无毁的湖光
目录
相关文章
小狮子安度因1
|
4月前
|
Linux
Linux源码阅读笔记10-进程NICE案例分析2
Linux源码阅读笔记10-进程NICE案例分析2
小狮子安度因1
41 2
小狮子安度因1
|
4月前
|
Linux
Linux源码阅读笔记09-进程NICE案例分析1
Linux源码阅读笔记09-进程NICE案例分析1
小狮子安度因1
42 1
蓝易云
|
2月前
|
网络协议 Linux 网络性能优化
Linux基础-socket详解、TCP/UDP
综上所述，Linux下的Socket编程是网络通信的重要组成部分，通过灵活运用TCP和UDP协议，开发者能够构建出满足不同需求的网络应用程序。掌握这些基础知识，是进行更复杂网络编程任务的基石。
蓝易云
147 1
小狮子安度因1
|
4月前
|
存储 缓存 编译器
Linux源码阅读笔记06-RCU机制和内存优化屏障
Linux源码阅读笔记06-RCU机制和内存优化屏障
小狮子安度因1
85 7
小狮子安度因1
|
4月前
|
Linux
Linux源码阅读笔记13-进程通信组件中
Linux源码阅读笔记13-进程通信组件中
小狮子安度因1
59 3
小狮子安度因1
|
4月前
|
消息中间件 安全 Java
Linux源码阅读笔记13-进程通信组件上
Linux源码阅读笔记13-进程通信组件上
小狮子安度因1
57 3
小狮子安度因1
|
4月前
|
Linux 开发者
Linux源码阅读笔记18-插入模型及删除模块操作
Linux源码阅读笔记18-插入模型及删除模块操作
小狮子安度因1
45 2
小狮子安度因1
|
4月前
|
数据采集 Linux
Linux源码阅读笔记20-PCI设备驱动详解
Linux源码阅读笔记20-PCI设备驱动详解
小狮子安度因1
52 1
小狮子安度因1
|
4月前
|
Linux
Linux源码阅读笔记19-插入删除模块实战
Linux源码阅读笔记19-插入删除模块实战
小狮子安度因1
38 1
小狮子安度因1
|
4月前
|
Linux
Linux源码阅读笔记17-资源分配及总线系统
Linux源码阅读笔记17-资源分配及总线系统
小狮子安度因1
37 1

热门文章

最新文章

  • 1
    3种在Linux命令行查看图像的方法
  • 2
    linux集群相关的
  • 3
    重装linux服务器后开不了机
  • 4
    Linux 下采用软件实现RAID
  • 5
    Ubuntu Linux 创建root用户并且允许远程登录
  • 6
    运行MeeGo S“.NET研究”DK 的linux版本
  • 7
    Linux 2 unit1 虚拟机,自动安装
  • 8
    linux之bash配置文件
  • 9
    LINUX新建和增加SWAP分区
  • 10
    如何在Linux下使用TCP封装器来加强网络服务安全
  • 1
    socket，tcp，http三者之间的原理和区别
    62
  • 2
    xenomai内核解析--xenomai与普通linux进程之间通讯XDDP(一)--实时端socket创建流程
    479
  • 3
    【探索Linux】P.26（网络编程套接字基本概念—— socket编程接口 | socket编程接口相关函数详细介绍 ）
    72
  • 4
    Java中如何使用Socket类检测端口是否存在
    130
  • 5
    【Go 语言专栏】Go 语言中的 WebSocket 与 Socket.IO 集成
    309
  • 6
    [emerg] 15060#200: bind() to 0.0.0.0:80 failed (10013: An attempt was made to access a socket ......
    215
  • 7
    Go语言TCP Socket编程（下)
    97
  • 8
    Go语言TCP Socket编程(上）
    149
  • 9
    Python从入门到精通：2.3.2数据库操作与网络编程——学习socket编程，实现简单的TCP/UDP通信
    105
  • 10
    TCP/IP、Http、Socket之间的区别
    148

    • 相关课程

    更多
  • Linux高级网络应用 - 网络管理与配置实战
  • Linux MySQL服务器搭建与应用
  • Linux基本命令
  • Linux企业运维实战 - 入门及常用命令
  • Linux Shell 编程入门与实战
  • Linux网络进阶 - TCP/IP协议及OSI七层模型

    • 相关电子书

    更多
  • Alibaba Cloud Linux 3 发布
  • ECS系统指南之Linux系统诊断
  • ECS运维指南 之 Linux系统诊断

    • 相关实验场景

    更多
  • 使用计算巢企业应用，一键获取专属的Linux服务器管理软件
  • 部署Linux主机管理系统WDCP
  • 快速配置Linux云服务器
  • 基于Linux命令实现WordPress手动建站
  • Linux系统的安全登录
  • Linux指令入门-文件管理

    • 推荐镜像

    更多
  • mxlinux-iso
  • archlinuxarm
  • archlinuxcn
    • 下一篇
    阿里云对象存储OSS收费标准：存储、流量和请求等多个计费项详解