接着上一篇网络编程Socket之TCP之close/shutdown具体解释

如今我们看看对于不同情况的close的返回情况和可能遇到的一些问题：

1.默认操作的close

说明：我们已经知道write操作返回成功仅仅能说明数据已经发送到套接字的发送缓冲区，不能代表对端已经成功收到数据，close的默认返回成功也仅仅是成功发出了一个FIN分节，也不代表对端已经确认

问题1：假设中途网络发生问题，非常有可能服务端接收不到这个来自client的FIN分节；

问题2：如果server忙，那么来自client的数据由TCP添?到套接字接收缓冲区，下一个FIN分节也被添?到套接字接收缓冲区，然后等待处理，如果正好此时server应用进程崩溃掉，那么这些数据就丢失掉了，server并没有真正收到，而client也永远不会知道；

2.设置SO_LINGER套接字选项且l_linger为正值时的close

说明：这样的情况下客户的close要到它的数据和FIN已经被server的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.应用级确认，可由client和服务端指定一个终止协议

tcp本身不提供记录结束标志，tcp是一个字节流协议，没有不论什么记录边界：假设应用程序须要确定记录的边界，它就要自己去实现；

參考：

《UNIX Network ProgrammingVolume 1, Third Edition: TheSockets Networking API》