linux下socket的close和shutdown

最新推荐文章于 2023-11-30 07:00:00 发布

fz835304205

最新推荐文章于 2023-11-30 07:00:00 发布

阅读量4k

点赞数

分类专栏： linux

linux 专栏收录该内容

90 篇文章 0 订阅

订阅专栏

在Linux socket关闭连接的方法有两种分别是shutdown和close，首先看一下shutdown的定义

#include<sys/socket.h>

int shutdown(int sockfd,int how);

how的方式有三种分别是

SHUT_RD（0）：关闭sockfd上的读功能，此选项将不允许sockfd进行读操作。

SHUT_WR（1）：关闭sockfd的写功能，此选项将不允许sockfd进行写操作。

SHUT_RDWR（2）：关闭sockfd的读写功能。

成功则返回0，错误返回-1，错误码errno：EBADF表示sockfd不是一个有效描述符；ENOTCONN表示sockfd未连接；ENOTSOCK表示sockfd是一个文件描述符而不是socket描述符。

close的定义如下：

#include<unistd.h>

int close(int fd);

关闭读写。

成功则返回0，错误返回-1，错误码errno：EBADF表示fd不是一个有效描述符；EINTR表示close函数被信号中断；EIO表示一个IO错误。

下面摘用网上的一段话来说明二者的区别：

close-----关闭本进程的socket id，但链接还是开着的，用这个socket id的其它进程还能用这个链接，能读或写这个socket id

shutdown--则破坏了socket 链接，读的时候可能侦探到EOF结束符，写的时候可能会收到一个SIGPIPE信号，这个信号可能直到

socket buffer被填充了才收到，shutdown还有一个关闭方式的参数，0 不能再读，1不能再写，2 读写都不能。

socket 多进程中的shutdown, close使用

当所有的数据操作结束以后，你可以调用close()函数来释放该socket，从而停止在该socket上的任何数据操作：

close(sockfd);

你也可以调用shutdown()函数来关闭该socket。该函数允许你只停止在某个方向上的数据传输，而一个方向上的数据传输继

续进行。如你可以关闭某socket的写操作而允许继续在该socket上接受数据，直至读入所有数据。

int shutdown(int sockfd,int how);

Sockfd是需要关闭的socket的描述符。参数 how允许为shutdown操作选择以下几种方式：

SHUT_RD：关闭连接的读端。也就是该套接字不再接受数据，任何当前在套接字接受缓冲区的数据将被丢弃。进程将不能对该

套接字发出任何读操作。对TCP套接字该调用之后接受到的任何数据将被确认然后无声的丢弃掉。

SHUT_WR:关闭连接的写端，进程不能在对此套接字发出写操作

SHUT_RDWR:相当于调用shutdown两次：首先是以SHUT_RD,然后以SHUT_WR

使用close中止一个连接，但它只是减少描述符的参考数，并不直接关闭连接，只有当描述符的参考数为0时才关闭连接。

shutdown可直接关闭描述符，不考虑描述符的参考数，可选择中止一个方向的连接。

注意:

1>. 如果有多个进程共享一个套接字，close每被调用一次，计数减1，直到计数为0时，也就是所用进程都调用了close，套接字将被释放。

2>. 在多进程中如果一个进程中shutdown(sfd, SHUT_RDWR)后其它的进程将无法进行通信. 如果一个进程close(sfd)将不会影响到其它进程. 得自己理解引用计数的用法了. 有Kernel编程知识的更好理解了.

更多关于close和shutdown的说明

1，只要TCP栈的读缓冲里还有未读取（read）数据，则调用close时会直接向对端发送RST。

2，shutdown与socket描述符没有关系，即使调用shutdown(fd, SHUT_RDWR)也不会关闭fd，最终还需close(fd)。

3，可以认为shutdown(fd, SHUT_RD)是空操作，因为shutdown后还可以继续从该socket读取数据，这点也许还需要进一步证实。

4，在已发送FIN包后write该socket描述符会引发EPIPE/SIGPIPE。

5，当有多个socket描述符指向同一socket对象时，调用close时首先会递减该对象的引用计数，计数为0时才会发送FIN包结束TCP连接。shutdown不同，只要以SHUT_WR/SHUT_RDWR方式调用即发送FIN包。

6，SO_LINGER与close，当SO_LINGER选项开启但超时值为0时，调用close直接发送RST（这样可以避免进入TIME_WAIT状态，但破坏了TCP协议的正常工作方式），SO_LINGER对shutdown无影响。

7，TCP连接上出现RST与随后可能的TIME_WAIT状态没有直接关系，主动发FIN包方必然会进入TIME_WAIT状态，除非不发送FIN而直接以发送RST结束连接。

http://blog.163.com/gingko_1987/blog/static/1263679802010020467258/

http://hi.baidu.com/softguarder/blog/item/e971422bc1effc3f5343c1b9.html

http://www.tenouk.com/Module39c.html

http://brad.livejournal.com/2152593.html

http://www.developerweb.net/forum/showthread.php?t=3752

http://stackoverflow.com/questions/41602/how-to-forcibly-close-a-socket-in-time-wait

http://www.stolk.org/debian/timewait.html

假设server和client 已经建立了连接，server调用了close, 发送FIN 段给client（其实不一定会发送FIN段，后面再说），此时server不能再通过socket发送和接收数据，此时client调用read，如果接收到FIN 段会返回0，但client此时还是可以write 给server的，write调用只负责把数据交给TCP发送缓冲区就可以成功返回了，所以不会出错，而server收到数据后应答一个RST段，表示服务器已经不能接收数据，连接重置，client收到RST段后无法立刻通知应用层，只把这个状态保存在TCP协议层。如果client再次调用write发数据给server，由于TCP协议层已经处于RST状态了，因此不会将数据发出，而是发一个SIGPIPE信号给应用层，SIGPIPE信号的缺省处理动作是终止程序。

有时候代码中需要连续多次调用write，可能还来不及调用read得知对方已关闭了连接就被SIGPIPE信号终止掉了，这就需要在初始化时调用sigaction处理SIGPIPE信号，对于这个信号的处理我们通常忽略即可，signal(SIGPIPE, SIG_IGN); 如果SIGPIPE信号没有导致进程异常退出（捕捉信号），write返回-1并且errno为EPIPE。

#include <unistd.h>
int close(int fd);

close 关闭了自身数据传输的两个方向。

#include <sys/socket.h>
int shutdown(int sockfd, int how);

shutdown 可以选择关闭某个方向或者同时关闭两个方向，shutdown how = 1 or how = 2 (SHUT_WR or SHUT_RDWR)，可以保证对等方接收到一个EOF字符（即发送了一个FIN段），而不管其他进程是否已经打开了这个套接字。而close不能保证，只有当某个sockfd的引用计数为0，close 才会发送FIN段，否则只是将引用计数减1而已。也就是说只有当所有进程（可能fork多个子进程都打开了这个套接字）都关闭了这个套接字，close 才会发送FIN 段。

所以说，如果是调用shutdown how = 1 ，则意味着往一个已经发送出FIN的套接字中写是允许的，接收到FIN段仅代表对方不再发送数据，但对方还是可以读取数据的，可以让对方可以继续读取缓冲区剩余的数据。

下面使用shutdown 修改客户端程序，在前面讲过的使用select函数修改后的客户端程序基础上，修改很小一部分：

    C++ Code  
 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

if (FD_ISSET(fd_stdin, &rset))
{

     if (fgets(sendbuf, sizeof(sendbuf), stdin) == NULL)
    {
        stdineof = 1; //表示已经输入完毕
         /* 关闭sock的写端，还能够接收数据，在sock的缓冲区末尾添加一个FIN段 */
        shutdown(sock, SHUT_WR);
    }
     else
    {
        writen(sock, sendbuf, strlen(sendbuf));
        memset(sendbuf, 0, sizeof(sendbuf));

    }
}

为了测试我们想要的效果，需要在select函数修改后的服务器端程序的 134 行代码之后，即writen 之前 sleep(4); 目的是接收到客户端数据后不马上回射回去，睡眠4s 后在客户端已经关闭连接的情况下再发送数据。

先运行服务器端程序，再运行客户端程序，在客户端标准输入，迅速敲入两行：AAAAA\n BBBBB\n 然后按下ctrl+d 即fgets 会返回NULL，然后调用shutdown关闭写端，虽然服务器端延时才发送数据，此时客户端写端已经关闭，但还是可以读取到回射回来的数据，服务器端最后得到一个FIN段，read 返回0，打印输出 client close ，并且close(conn); 而客户端在读取服务端回射回来的两次数据后，再次read 也返回0，故打印 server connect close，break退出循环，进程顺利退出。从下面的输出还可以看出，因为延时的关系，所以不像以前那样发射一行就回射一行。

simba@ubuntu:~/Documents/code/linux_programming/UNP/socket$ ./echoser_select
recv connect ip=127.0.0.1 port=54010
fdsgfgd
gfedg
client close

...........................

simba@ubuntu:~/Documents/code/linux_programming/UNP/socket$ ./echocli_select_shutdown
local ip=127.0.0.1 port=54010
fdsgfgd
gfedg
fdsgfgd
gfedg
server connect close

如果我们将客户端程序中的shutdown 改成了 close，那么当延时后服务器端发送数据给客户端时，客户端的读端和写端都已经关闭，第一次发AAAAA会返回一个RST段，根据本文前面所说，再次发BBBBB直接产生SIGPIPE信号，默认会终止进程，但因为我们已经设置了忽略SIGPIPE信号，所以服务器端进程不会被终止，但客户端也会出错，因为回到while循环开头，select阻塞等待时发现套接字的读端已经关闭，所以不能再关心可读事件了，select会返回-1，错误码是 EBADF: Bad File Descriptor。

参考：

《Linux C 编程一站式学习》

《TCP/IP详解卷一》

《UNP》