2019-09-03问题一，为什么调用exit以后不需要调用close，shutdown？因为在调用exit之后进程会退出，而进程相关的所有的资源，文件，内存，信号等内核分配的资源都会被释放，在linux中，一切皆文件，本身socket就是一种文件类型，内核会为每一个打开的文件创建file结构并维护指向改结构的引用计数，每一个进程结构中都会维护本进程打开的文件数组，数组下标就是fd，内容就指向上面的file结构，close本身就可以用来操作所有的文件，做的事就是，删除本进程打开的文件数组中指定的fd项，并把指向的file结构中的引用计数减一，等引用计数为0的时候，就会调用内部包含的文件操作close，针对于socket，它内部的实现应该就是调用shutdown，只是参数是关闭读写端，从而比较粗暴的关闭连接。
第二个问题，信号的处理有三种，默认处理，忽略处理，自定义处理。默认处理就是采用系统自定义的操作，大部分信号的默认处理都是杀死进程，忽略处理就是当做什么都没有发生。作者回复: 赞赞赞。
4 28
2019-09-03请问老师一个问题，像FIN，ACK等报文并不属于“数据”是么？比如对于4次挥手中，发起关闭的客户端在发送FIN报文后，表明客户端不再发送“数据”了（可以读数据），之后在服务端也发送FIN报文后，客户端还是会发送一个ACK报文给服务端。这里的最后一个ACK报文，并不属于“数据”是吗？T或者CP中这些所有的控制报文包都不属于所谓的“数据”吗？作者回复: 这是控制报文，是脱离应用程序掌握之外的控制协议部分，层这个层面来说，他们不被认为是"应用层数据"。
7
2019-08-27思考题
1. 调用exit(0) 是系统内核自动回收了一切资源，关闭了一切相关的文件
2. SIG_IGN是忽略该信号 如果是采用SIG_DEF默认处理方式则是由系统进行一些处理,而自定义函数的话 是捕捉到该信号并进入回调 自己处理相关事宜 3
2019-08-27SUG_IGN是忽略信号吧，老师是不是代码有问题啊，SIG_DFL才是默认处理，示例中那样写不是应该是忽略了SIGPIPE信号么。作者回复: 嗯，你试一下改改是不是可以的，我应该是写错了。
1 3- 2019-08-28今天我也写了代码测试上面的例子同时也想起了网上一句话 close是关闭掉socket 并且回收了socket相关资源,而shutdown一般只是关闭连接并不会关闭socket 这也是为啥调用close服务器端在进行写数据的时候会触发sigpipe信号,而shutdown却不会触发,那么调用shutdown关闭的套接字怎么回收呢？是由内核回收还是？ 服务器端和客户端又是怎样回收的呢？
作者回复: 我理解还是内核会回收的，只不过是等待双向连接都关闭掉才会回收。
1 2 - 2019-08-27然后又引申了fin包和read返回0是怎样的关系呢？
作者回复: 读到FIN包在read看来就是返回0.
2 - 2019-08-27老师，调用shutdown不会释放套接字资源，那么应该怎么处理呢
作者回复: 不会立即释放，最终还是会被系统内核回收的。
2 
2019-12-29那请问老师,什么情况下用close，什么情况下用shutdown？谢谢！作者回复: 你想彻底关闭双向连接的时候用close，你想只关闭自己这端到对端的连接时用shutdown。
1
2019-08-26老师你好, 上面的例子中有两个地方不是很清楚:
(1) close: client调用close后, 不是会马上关闭两个方向的连接吗, 那为啥"Hi, data1"还能被收到并显示?
(2) shutdown: client调用shutdown只是关闭写方向的连接, 是不是client不能发了只能收?那为啥server能读到EOF并发送"FIN"给client?作者回复: 1.那是之前发送的；
2.那是shutdown的结果，shutdown之后，就是往队列里扔了一个FIN报文，这个发送队列还是要被发送完成的。 1
2020-01-15第一个差别：close 会关闭连接，并释放所有连接对应的资源，而 shutdown 并不会释放掉套接字和所有的资源。--------------------请问下，shutdown两个方向也不会释放套接字资源吗？那什么时候释放的作者回复: 分别调用shutdown两个方向，可以释放掉两个方向的套接字资源。
2019-12-05这个程序服务端好像没有发送FIN包就直接退出了吧 我把服务端read返回0的情况下error注掉，服务端已在再向客户端发送Hi。作者回复: 哪个程序？是close的还是shutdown的？如果把read返回0注释掉，说明是对端已经发起结束，这个时候是服务端是需要正常退出的，不明白注释的想法是？
2019-11-23看完这篇，感觉自己跟不上了😁，有好多细节都是第一次听说，不过也有一点收获，所以，要坚持。
这节，感觉印证了我上节的猜想，老师对于四次挥手并没有像建立连接时的三次握手那么详细，我也没跳读的。
TCP连接的三次握手机制主要是为了解决，怎么确保信道安全可靠的问题，为了确认双方的收发能力都OK，需要四次通信，不过其中两次的收发可以合并，所以，三次握手就行了
TCP断链的四次挥手机制，主要为了解决双方的收发数据都能正常结束，才这么设计的，因为TCP连接的两个特点，一是传输的是字节流，二是通信方式为双工通信。所以，一端想关闭连接，就需要不再继续写且发送一个FIN，另一端需要处理完对应的读，然后发一个ACK进行响应。
我有个疑问，四次挥手的其中两次不能像三次握手一样合并为一次通信嘛？是因为处理读可能存在慢动作吗？怕耽误ACK的响应时间嘛？展开作者回复: 因为有双向连接的问题，所以一般不会合并。
2
2019-11-22实际测试时把shutdown 里的参数设置成了0，但是抓包客户端也发FIN包了，SHUT_RD(0)老师讲的不会发FIN包呢作者回复: 有点误解哦，FIN是会发的，只是一个方向的连接会被关闭，另一个方向正常的。
2019-10-29本文中例子，客户端发送data1和data2后无返回是因为sleep了吗？还有实验的时候是不是close和shutdown的输入必须在5s内完成，否则服务器端不休眠了直接把数据发到客户端了。作者回复: 第一个问题，是的，这个是因为close调用之后sleep了；
第二个问题，应该在10秒之内就可以了，这个例子是为了展示close和shutdown的区别。
2019-10-16代码移植到win10上，select总是返回-1， WSAGetLastError()为10038。老师，能说一下，如果是win10的话，使用哪种方式能实现与本文相同的功能？作者回复: 建议使用虚拟机安装一个ubutnu的Linux，在Linux下实验。
1
2019-09-21老师 请问FTP连接一半 服务端返回421是什么原因导致的 查了好久作者回复: 一个直观的解释就是太多ftp连接了，我google了一下，似乎还有被动连接和主动连接模式的问题，建议你看一下。
2019-09-16如果client端在close之后没有sleep直接exit退出，也就是client发送完FIN后不再等待server的FIN（也不会回应FIN ACK）， server端在LAST ACK状态下以什么形式退出？作者回复: 我认为还是会回到CLOSED状态，在LAST ACK状态下的等待ACK等不到，应该有容错处理逻辑。
2019-09-14初学了c 想把基础知识补一下
看到linux内核 第三版 p32 信号与进程间的通信
想起了老师的课后提问
原来这个SIG_是内核和进程间的通信作者回复: 嗯
- 2019-09-13在CLion中如何运行啊？
作者回复: 直接从菜单中选择“Run-Run"，然后找到想跑的应用程序名，就可以了。
2019-09-12_exit也可以的，就是更粗暴的一些