接着上一篇网络编程Socket之TCP之close/shutdown详解
现在我们看看对于不同情况的close的返回情况和可能遇到的一些问题：
1.默认操作的close
说明：我们已经知道write操作返回成功只能说明数据已经发送到套接字的发送缓冲区，不能代表对端已经成功收到数据，close的默认返回成功也只是成功发出了一个FIN分节，也不代表对端已经确认
问题1：如果中途网络发生故障，很有可能服务端接收不到这个来自客户端的FIN分节；
问题2：假设服务器忙，那么来自客户端的数据由TCP加入到套接字接收缓冲区，下一个FIN分节也被加入到套接字接收缓冲区，然后等待处理，如果正好此时服务器应用进程崩溃掉，那么这些数据就丢失掉了，服务器并没有真正收到，而客户端也永远不会知道；
2.设置SO_LINGER套接字选项且l_linger为正值时的close
说明：这种情况下客户的close要到它的数据和FIN已经被服务器的TCP确认以后才会返回；
问题：同上问题2
3.设置SO_LINGER套接字选项且l_linger为偏小正值时的close
说明：在服务端的确认到达之前，SO_LINGER套接字选项设置的延滞时间到，close将会返回EWOULDBLOCK错误，且套接字发送缓冲区中的任何残留数据被丢弃。
问题：同问题2
总结：设置SO_LINGER套接字选项以后，close的成功返回只是告诉我们先前发送的数据的FIN已经由对端TCP确认，而不能告诉我们对端应用进程是否已经读取数据，如果不设置该套接字选项，那么我们连对端TCP是否确认了数据都不知道。
解决方法：
1.使用shutdown（设置SHUT_WR）+read
说明：调用写关闭的shutdown以后发送FIN分节，然后执行read，返回0则说明服务端已经读取数据然后发送终止连接的第三个分节（FIN分节）。
2.应用级确认，可由客户端和服务端指定一个终止协议
tcp本身不提供记录结束标志，tcp是一个字节流协议，没有任何记录边界：如果应用程序需要确定记录的边界，它就要自己去实现；
参考：
《UNIX Network ProgrammingVolume 1, Third Edition: TheSockets Networking API》