11 | 优雅地关闭还是粗暴地关闭 ?

问题一，为什么调用exit以后不需要调用close，shutdown？因为在调用exit之后进程会退出，而进程相关的所有的资源，文件，内存，信号等内核分配的资源都会被释放，在linux中，一切皆文件，本身socket就是一种文件类型，内核会为每一个打开的文件创建file结构并维护指向改结构的引用计数，每一个进程结构中都会维护本进程打开的文件数组，数组下标就是fd，内容就指向上面的file结构，close本身就可以用来操作所有的文件，做的事就是，删除本进程打开的文件数组中指定的fd项，并把指向的file结构中的引用计数减一，等引用计数为0的时候，就会调用内部包含的文件操作close，针对于socket，它内部的实现应该就是调用shutdown，只是参数是关闭读写端，从而比较粗暴的关闭连接。 第二个问题，信号的处理有三种，默认处理，忽略处理，自定义处理。默认处理就是采用系统自定义的操作，大部分信号的默认处理都是杀死进程，忽略处理就是当做什么都没有发生。

请问老师一个问题，像FIN，ACK等报文并不属于“数据”是么？比如对于4次挥手中，发起关闭的客户端在发送FIN报文后，表明客户端不再发送“数据”了（可以读数据），之后在服务端也发送FIN报文后，客户端还是会发送一个ACK报文给服务端。这里的最后一个ACK报文，并不属于“数据”是吗？T或者CP中这些所有的控制报文包都不属于所谓的“数据”吗？

老师我这个理解有问题么？ 客户端调用close并发送了FIN包，服务端接收到FIN包会将连接状态设置为对端已关闭写端，服务端在向客户端回送FIN包之前可以向对端发送数据也不可不发送，实例程序就是发送了数据，第一次发送数据对端会返回个RST包（因为客户端close已经关闭了读端），服务端调用read会返回-1，设置errno，此时服务端了解到客户端也不会再读数据了，如果服务端还是强行再次向客户端发送数据包，调用write后，协议栈会发现用户进程向一个没有读用户的管道做写操作，那么会触发SIGPIPE信号执行默认操作关闭用户进程。

那请问老师,什么情况下用close，什么情况下用shutdown？谢谢！

SUG_IGN是忽略信号吧，老师是不是代码有问题啊，SIG_DFL才是默认处理，示例中那样写不是应该是忽略了SIGPIPE信号么。

然后又引申了fin包和read返回0是怎样的关系呢？

close关闭比较粗暴，如果想要优雅的关闭，等处理完数据再关闭可以使用shutdown设置参数。 实际上在tcp协议中有个参数so_linger也可以设置比较优雅（规定时间处理缓冲区的字节，超时则清空缓冲区）的关闭tcp的socket。

今天我也写了代码测试上面的例子同时也想起了网上一句话 close是关闭掉socket 并且回收了socket相关资源,而shutdown一般只是关闭连接并不会关闭socket 这也是为啥调用close服务器端在进行写数据的时候会触发sigpipe信号,而shutdown却不会触发,那么调用shutdown关闭的套接字怎么回收呢？是由内核回收还是？ 服务器端和客户端又是怎样回收的呢？

老师，调用shutdown不会释放套接字资源，那么应该怎么处理呢

close 关闭两个方向的数据流时。输入方向，系统内核会将该套接字设置为不可读，任何读操作都会返回异常。在输出方向，系统内核尝试将发送缓冲区的数据发送给对端，那对端已经不可读了，这些数据该如何处理？