socket关闭close,socket中shutdown和closesocket的区别
socket关闭close,socket中shutdown和closesocket的区别详细介绍
本文目录一览： 前端socket有多个怎么关闭某一个
前端socket有多个怎么关闭某一个，Copyright ? 1999-2020, CSDN.NET, All Rights Reserved
?
?
打开APP
?
?
socket的连接关闭的方式和过程 转载
2020-07-03 10:27:38
? 2点赞
?
NeverGx ?
码龄5年
关注
socket的关闭有close 和shutdown两种API，那么他们的区别在哪里呢？
close ----- 在多进程的情况下，关闭本进程的socket，但这只是socket的引用计数减1，用这个socket的其它进程还能用这个链接，能读或写这个socket，直到所有的进程都进行了close，才真正关闭这个套接字，但当它真正执行关闭的时候是完全关闭，既不处理发送也不处理接收数据。
shutdown – 即便在多进程的情况下面，也是直接进行关闭的，关闭了socket 文件描述符，其他进程的也会被关闭，但他关闭的时候只关闭一半，即发送数据通道关闭，接收数据还是可以的**。如果对写操作被关闭的socket执行写操作会触发写就绪(EPOLLOUT)事件，同时触发一个SIGPIPE信号。**
close的主要流程：
?
1）关闭监听句柄
先从最右边的分支说说关闭监听socket的那些事。用于listen的监听句柄也是使用close关闭，关闭这样的句柄含义当然很不同，它本身并不对应着某个TCP连接，但是，附着在它之上的却可能有半成品连接。什么意思呢？之前说过TCP是双工的，它的打开需要三次握手，三次握手也就是3个步骤，其含义为：客户端打开接收、发送的功能；服务器端认可并也打开接收、发送的功能；客户端认可。当第1、2步骤完成、第3步步骤未完成时，就会在服务器上有许多半连接，close这个操作主要是清理这些连接。
参照上图，close首先会移除keepalive定时器。keepalive功能常用于服务器上，防止僵死、异常退出的客户端占用服务器连接资源。移除此定时器后，若ESTABLISH状态的TCP连接在tcp_keepalive_time时间（如服务器上常配置为2小时）内没有通讯，服务器就会主动关闭连接。
接下来，关闭每一个半连接。如何关闭半连接？这时当然不能发FIN包，即正常的四次握手关闭连接，而是会发送RST复位标志去关闭请求。处理完所有半打开的连接close的任务就基本完成了。
2）关闭普通ESTABLISH状态的连接（未设置so_linger）
首先检查是否有接收到却未处理的消息。
如果close调用时存在收到远端的、没有处理的消息，这时根据close这一行为的意义，是要丢弃这些消息的。但丢弃消息后，意味着连接远端误以为发出的消息已经被本机收到处理了（因为ACK包确认过了），但实际上确是收到未处理，此时也不能使用正常的四次握手关闭，而是会向远端发送一个RST非正常复位关闭连接。这个做法的依据请参考draft-ietf-tcpimpl-prob-03.txt文档3.10节，Failure to RST on close with data pending。所以，这也要求我们程序员在关闭连接时，要确保已经接收、处理了连接上的消息。
如果此时没有未处理的消息，那么进入发送FIN来关闭连接的阶段。
这时，先看看是否有待发送的消息。前一篇已经说过，发消息时要计算滑动窗口、拥塞窗口、angle算法等，这些因素可能导致消息会延迟发送的。如果有待发送的消息，那么要尽力保证这些消息都发出去的。所以，会在最后一个报文中加入FIN标志，同时，关闭用于减少网络中小报文的angle算法，向连接对端发送消息。如果没有待发送的消息，则构造一个报文，仅含有FIN标志位，发送出去关闭连接。
3）使用了so_linger的连接
首先要澄清，为何要有so_linger这个功能？因为我们可能有强可靠性的需求，也就是说，必须确保发出的消息、FIN都被对方收到。例如，有些响应发出后调用close关闭连接，接下来就会关闭进程。如果close时发出的消息其实丢失在网络中了，那么，进程突然退出时连接上发出的RST就可能被对方收到，而且，之前丢失的消息不会有重发来保障可靠性了。
so_linger用来保证对方收到了close时发出的消息，即，至少需要对方通过发送ACK且到达本机。
怎么保证呢？等待！close会阻塞住进程，直到确认对方收到了消息再返回。然而，网络环境又得复杂的，如果对方总是不响应怎么办？所以还需要l_linger这个超时时间，控制close阻塞进程的最长时间。注意，务必慎用so_linger，它会在不经意间降低你程序中代码的执行速度（close的阻塞）。
所以，当这个进程设置了so_linger后，前半段依然没变化。检查是否有未读消息，若有则发RST关连接，不会触发等待。接下来检查是否有未发送的消息时与第2种情形一致，设好FIN后关闭angle算法发出。接下来，则会设置最大等待时间l_linger，然后开始将进程睡眠，直到确认对方收到后才会醒来，将控制权交还给用户进程。
这里需要注意，so_linger不是确保连接被四次握手关闭再使close返回，而只是保证我方发出的消息都已被对方收到。例如，若对方程序写的有问题，当它收到FIN进入CLOSE_WAIT状态，却一直不调用close发出FIN，此时，对方仍然会通过ACK确认，我方收到了ACK进入FIN_WAIT2状态，但没收到对方的FIN，我方的close调用却不会再阻塞，close直接返回，控制权交还用户进程。
从上图可知，so_linger还有个偏门的用法，若l_linger超时时间竟被设为0，则不会触发FIN包的发送，而是直接RST复位关闭连接。我个人认为，这种玩法确没多大用处。
最后做个总结。调用close时，可能导致发送RST复位关闭连接，例如有未读消息、打开so_linger但l_linger却为0、关闭监听句柄时半打开的连接。更多时会导致发FIN来四次握手关闭连接，但打开so_linger可能导致close阻塞住等待着对方的ACK表明收到了消息。
最后来看看较为简单的shutdown。
1）shutdown可携带一个参数，取值有3个，分别意味着：只关闭读、只关闭写、同时关闭读写。
对于监听句柄，如果参数为关闭写，显然没有任何意义。但关闭读从某方面来说是有意义的，例如不再接受新的连接。看看最右边蓝色分支，针对监听句柄，若参数为关闭写，则不做任何事；若为关闭读，则把端口上的半打开连接使用RST关闭，与close如出一辙。
2）若shutdown的是半打开的连接，则发出RST来关闭连接。
3）若shutdown的是正常连接，那么关闭读其实与对端是没有关系的。只要本机把接收掉的消息丢掉，其实就等价于关闭读了，并不一定非要对端关闭写的。实际上，shutdown正是这么干的。若参数中的标志位含有关闭读，只是标识下，当我们调用read等方法时这个标识就起作用了，会使进程读不到任何数据。
4）若参数中有标志位为关闭写，那么下面做的事与close是一致的：发出FIN包，告诉对方，本机不会再发消息了。
c语言socket关闭,如何在c语言下关闭socket_慕容圆月的博客
1、shutdown()在如何关闭套接字上有多一点的控制。shutdown 可以单向关闭,Close不可以。 2、当多线程共享/调用同一个Socket时,Close只是会减1,直到减到0才会真正去关闭Socket, 而shutdown则不会理会有多少线程在用,强制直接关闭sock...
继续访问
socket关闭_mengfick的博客
时,意思是说,发送FIN的一端就不能发送数据,也就是关闭了其中一条数据通路。被动关闭的一端发送 了ACK后,应用层通常就会检测到这个连接即将断开,然后被动断开的应用层调用close关闭连接。 我可以告诉你,一旦当你调用close(or closesocke...
继续访问
热门推荐 Socket的正确关闭(改良版)
TIME_WAIT状态 如果服务端的Socket比客户端的Socket先关闭，会导致客户端出现TIME_WAIT状态，占用系统资源。 所以，必须等客户端先关闭Socket后，服务器端再关闭Socket才能避免TIME_WAIT状态的出现。 判断客户端Socket的关闭 最近试验发现，当客户端Socket关闭时，服务端的Socket会接收到0字节的通知。 private int Receive(StringBuilder sb) { int read = 0, total
继续访问
socket连接建立与关闭
close函数 定义 close函数可以用于关闭套接字，并中只能TCP连接。 #include
int close(int sockfd); close一个TCP套接字的默认行为是把该套接字标记为已关闭，然后立即返回到调用进程。该套接字不能再由调用进程使用，也就是说它不能再作为read或write等函数的第一个参数。 套接字发送缓冲区的数据将尝试被发送到对端，发...
继续访问
关闭Socket_wkend的博客_js 关闭socket
当客户与服务器的通信结束,应该及时关闭Socket,已释放Socket占用的包括端口在内的各种资源。Socket的close()方法负责关闭Socket。当一个socket对象被关闭,就不能能在通过它的输入流和输出流进行I/O操作,否则会导致IOException。 为了确保...
继续访问
socket链接的关闭close和shutdown的区别_TIME_WAIT和CLOSE_WAIT什么时刻出现_如何处理
TCP主动关闭连接 appl: close(), --> FIN FIN_WAIT_1 //主动关闭socket方，调用close关闭socket,发FIN //对方操作系统的TCP层，给ACK响应。然后给FIN
继续访问
socket关闭
无论是服务端还是客户端,一旦有一方调用socket.close(),都表明此次通信终止,调用close会同时关闭输入输出.. 在回显例子,客户端知道接收完了数据,可以先调用close(),然后服务端再调用read将返回-1,表明服务端接收来自客户端的数据完成,然后服务端也可以调用close() 对于Http协议,客户端不知道服务端发送消息的大小,必须先由服务端关闭socket,然后客户端再关闭s
继续访问
主动断开socket链接_socket - 关闭连接
应用层的场景1 数据中断socket的特点是随时可能关闭，即发送和接受的数据随时可能中断。应用层必须能处理socket数据中断的情况。2 无感知关闭socket的另一边有可能已关闭，并且我们无法感知。应用层必须有一个心跳机制，当超过一定时间未收到心跳，则关闭socket。SOCKET层的场景调用close注意事项：(1)调用close是无阻塞返回的。(2)调用close之后，并没有马上释放sock...
继续访问
socket优雅关闭连接
优雅关闭连接前言closeshutdown若被动方一直不发第三次挥手代码 前言 今天突然发现最近搞的那个HTTP服务器的一个bug。 以前有个突然服务器崩溃的问题，不过是偶然发生的，所以一直搁置没有解决。 今天调试过程中突然发现一个致命问题，就是客户端发的HTTP请求在最后一次执行后直接调用了close，而服务端返回的数据导致这个客户端无法接受到，因为服务端的write函数，所以会触发一个SIGPIPE的中断。 close close函数或者shutdown函数调用后都会向对端发送FIN。 一般是客户端
继续访问
最新发布 socket流的关闭
在使用socket进行全双工通信时，原本以为输入流和输出流是分开关闭的，然而不socket的关闭有close 和shutdown两种API，那么他们的区别在哪里呢？
close ----- 在多进程的情况下，关闭本进程的socket，但这只是socket的引用计数减1，用这个socket的其它进程还能用这个链接，能读或写这个socket，直到所有的进程都进行了close，才真正关闭这个套接字，但当它真正执行关闭的时候是完全关闭，既不处理发送也不处理接收数据。
shutdown – 即便在多进程的情况下面，也是直接进行关闭的，关闭了socket 文件描述符，其他进程的也会被关闭，但他关闭的时候只关闭一半，即发送数据通道关闭，接收数据还是可以的**。如果对写操作被关闭的socket执行写操作会触发写就绪(EPOLLOUT)事件，同时触发一个SIGPIPE信号。**
close的主要流程：
怎么在服务器端关闭websocket连接
1、关闭连接：使用WebSocketAPI中的close()方法关闭WebSocket连接。在客户端中，您可以使用以下代码来关闭连接：Copysocket.close()；服务器端编写：在服务器端，您需要使用WebSocket库来处理WebSocket连接和消息传输。2、console.log(WebSocket连接已关闭。)；}；3，发送消息：使用WebSocket对象的send()方法向服务器发送消息。3、是由于web.xml里面的filter-mapping的url配置错误导致的，原来url配置的是*然后改了之后就好了。WebSocketWebSocket协议是基于TCP的一种新的网络协议。4、ws-URI：ws：//host[：port]path[？query]wss-URI：wss：//host[：port]path[？query]WebSocket握手阶段，需要用到一些HTTP头，升级HTTP连接为WebSocket连接如下表所示。5、安装moodle时，需安装easyphp，在安装easyphp的时候，要看看端口是否被web信息服务器和MySQL服务器占用。修改的方法是：控制面板——管理工具——web信息服务器——打开——本地计算机——网站——停止，即关掉了端口。6、在四次挥手过程中ACK包都是协议栈自动完成的，而FIN包则必须由应用层通过closesocket或shutdown主动发送，通常连接正常关闭后，recv会得到返回值0，send会得到错误码10058。
jmeter压测时出现socket close关闭的问题
当端口空闲时，就直接断开，导致报错。
所以request请求，需要将use KeepAlive勾选上。
并且需要在高级选项中选择 HttpClient4请求，connect时间为空闲并保持多久后才断开。
还需要在JMeter.properties中修改httpclient4.idletimeout=30000，单位为ms。客户端的连接保持时间最好与服务器的保持时间一致，vim?/proc/sys/net/ipv4/tcp_fin_timeout，默认时间为60s，单位为s。
关于关闭 Socket 的一些坑
最近踩到一个 "Socket 连接持续处于 Fin_Wait2 和 Close_Wait 状态无法关闭" 的坑中。起因是在维护大量连接时调用 socket.close() 时，看到部分连接并没有正常关闭，而是从 ESTABLISHED 的状态变成 FIN_WAIT2 并且连接状态没有后续迁移，而对端的连接状态则是从 ESTABLISHED 变成了 CLOSE_WAIT 。
后来发现这和 TCP/IP 栈的4次挥手断开连接有关，列出一些踩坑时的收获。
先看一张 Socket 关闭连接的状态迁移路径图:
在 Client 端调用 socket.close() 时，首先会往对端(即 Server 端)发送一个 FIN 包，接着将自身的状态置为 FIN_WAIT1 ，此时主动关闭端(即 Client 端)处于持续等待接收对端的响应 FIN 包的 ACK 回应状态，此时对端的状态是处于 ESTABLISHED ，一旦收到了 Client 发来的 close 连接请求，就回应一个 FIN 包，表示收到该请求了，并将自身状态置为 CLOSE_WAIT ，这时开始等待 Server 端的应用层向 Client 端发起 close 请求。
这时 Client 端一旦收到 Server 端对第一个 FIN 包的回应 ACK 就会将进入下一个状态 FIN_WAIT_2 来等待 Server 发起断开连接的 FIN 包。在FIN_WAIT_1 的 time_wait 中， Server 端会发起 close 请求，向 Client 端发送 FIN 包，并将自身状态从 CLOSE_WAIT 置为 LAST_ACK ，表示 Server 端的连接资源开始释放了。同时 Client 端正处于 FIN_WAIT2 状态，一旦接收到 Server 端的 FIN 包，则说明 Server 端连接已释放，接着就可以释放自身的连接了，于是进入 TIME_WAIT 状态，开始释放资源，在经过设置的 2个 MSL 时间后，状态最终迁移到 CLOSE 说明连接成功关闭，一次 TCP 4次挥手 关闭连接的过程结束。
通常会出现状态滞留的情况有下面几种:
此外，如果在单台服务器上并且不做负载均衡而处理大量连接的话，可以在 /proc/sys/net/ipv4/ip_local_port_range 中减少端口的极限值，限制每个时间段的最大端口使用数，从而保证服务器的稳定性，一旦出现大量的 TIME_WAIT 阻塞后续连接，是比较致命的。
此外还遇到了另一个小问题，在关闭连接时，一开始用的是 socket.terminate() ，然而 netstat 时却发现大量连接没有释放，后来发现 Python Socket 的 terminate() 只是发送 socket.SHUT_WR 和 socket.SHUT_RD 来关闭通道的读写权限而并没有释放连接句柄。导致了连接已经无法使用，但仍然处于 ESTABLISHED 状态。
解决方法就是使用 socket.close() 来替换 socket.terminate()
后来又看到如果是 DDoS 攻击的话，可能会阻塞住 socket.close() ，导致后续连接未关闭，大量流量进入服务器。
所以比较好的方式是在 socket.close() 之前先调用 socket.terminate() 关闭通道的读写权限，再调用 socket.close()
Socket 编程中 close() 和 shutdown() 有什么区别？
下面说说close和shutdown两个函数的差别，两个函数在网络编程中都被人为是来关闭套接字的，差别如下:
1.操作本质不同
close是文件系统VFS的一个通用函数
shutdown是专门针对socket套接字设立的函数
SOCKET在unix中本就是以文件的形式呈现给大家的，在每创建一个socket时，会对应创建一个文件与之对应，返回文件描述符，
具体的结构在此不详述，在调用close时实际是关闭了减少了文件描述符，当文件描述符引用为0时，则会删除文件，关闭套接字。
而shutdown是直接对socket的操作，相当于设置了socket的属性，可以设置为只读，只写，或者直接关闭，但不会操作与此socket相关
的文件
2.两者操作的效果一同
close的操作跟设置选项LINGER有关，此选项是设置当用户调用close后是否等待把当前缓冲区的数据发送完毕后再关闭套接字
LINGER结构有两个值，一个是on，一个是time
当on为0时，默认情况，用户发送完分组，然后发送FIN分组
当on为1时，time为0，则用户直接发送RST分组
当on为1时，time为非0，则用户等待time值然后发送FIN分组，如果time到了但用户没有发送完数据，则返回错误EWOULDBLOCK
SHUTDOWN
SHUT_RD，套接字不能再发出接收请求，进程仍然可以往套接字发送数据，套接字接收缓冲区中所有数据被丢弃，再接收到的任何数据由TCP丢弃，对套接字发送缓冲区没有任何影响
SHUT_WD ,套接字不能再发出发送请求，套接字发送缓冲区的数据将被发送到对端，然后跟着正常的FIN终止序列
close是关闭连接并释放资源。 而shutdown只是关闭发送或者接收或者两者，而并不是关闭连接。
具体参考：http://msdn.microsoft.com/zh-cn/library/windows/desktop/ms740481.aspx
一、指代不同
1、shutdown() ：是指禁止在一个套接口上进行数据的接收与发送。
2、close()：关闭一个套接口。更确切地说，它释放套接口描述字s，以后对s的访问均以WSAENOTSOCK错误返回。
二、原理不同
1、shutdown() ：how参数为0，则该套接口上的后续接收操作将被禁止。这对于低层协议无影响。对于TCP协议，TCP窗口不改变并接收前来的数据（但不确认）直至窗口满。对于UDP协议，接收并排队前来的数据。任何情况下都不会产生ICMP错误包。
2、close()：为对套接口的最后一次访问，则相应的名字信息及数据队列都将被释放。closesocket()的语义受SO_LINGER与SO_DONTLINGER选项影响。
三、特点不同
1、shutdown() ：一个应用程序不应依赖于重用一个已被shutdown()禁止的套接口。特别地，一个WINDOWS套接口实现不必支持在这样的套接口上使用connect()调用。
2、close()：如无错误发生，则closesocket()返回0。否则的话，返回SOCKET_ERROR错误，应用程序可通过WSAGetLastError()获取相应错误代码。
参考资料来源：百度百科-shutdown()
参考资料来源：百度百科-closesocket()
socket shutdown和close的区别
close(sockfd);关闭socket,不管该socket上是否有没收万的数据,还是未发送的数据,强行关闭socket读和写.int shutdown(int sockfd,int how);关闭socket ,但是要看第二个参数how参数 how允许为shutdown操作选择以下几种方式： SHUT_RD：关闭连接的读端。也就是该套接字不再接受数据，任何当前在套接字接受缓冲区的数据将被丢弃。进程将不能对该套接字发出任何读操作。对 TCP套接字该调用之后接受到的任何数据将被确认然后无声的丢弃掉。 SHUT_WR:关闭连接的写端，进程不能在对此套接字发出写操作 SHUT_RDWR:相当于调用shutdown两次：首先是以SHUT_RD,然后以SHUT_WR
如何优雅地关闭一个socket
1. 关闭Socket时究竟做了什么
关闭socket分为主动关闭（Active closure）和被动关闭（Passive closure）两种情况。前者是指有本地主机主动发起的关闭；而后者则是指本地主机检测到远程主机发起关闭之后，作出回应，从而关闭整个连接。
其状态图如下图所示：
起初每个socket都是CLOSED状态，当客户端初使化一个连接，他发送一个SYN包到服务器，客户端进入SYN_SENT状态。
服务器接收到SYN包，反馈一个SYN-ACK包，客户端接收后返馈一个ACK包客户端变成ESTABLISHED状态，如果长时间没收到SYN-ACK包，客户端超时进入CLOSED状态。
当服务器绑定并监听某一端口时，socket的状态是LISTEN，当客户企图建立连接时，服务器收到一个SYN包，并反馈SYN-ACK包。服务器状态变成SYN_RCVD，当客户端发送一个ACK包时，服务器socket变成ESTABLISHED状态。
当一个程序在ESTABLISHED状态时有两种图径关闭它， 第一是主动关闭，第二是被动关闭。如果你要主动关闭的话，发送一个FIN包。当你的程序closesocket或者shutdown（标记），你的程序发送一个FIN包到peer，你的socket变成FIN_WAIT_1状态。peer反馈一个ACK包，你的socket进入FIN_WAIT_2状态。如果peer也在关闭连接，那么它将发送一个FIN包到你的电脑，你反馈一个ACK包，并转成TIME_WAIT状态。
TIME_WAIT状态又号2MSL等待状态。MSL意思是最大段生命周期（Maximum Segment Lifetime)表明一个包存在于网络上到被丢弃之间的时间。每个IP包有一个TTL(time_to_live)，当它减到0时则包被丢弃。每个路由器使TTL减一并且传送该包。当一个程序进入TIME_WAIT状态时，他有2个MSL的时间，这个充许TCP重发最后的ACK，万一最后的ACK丢失了，使得FIN被重新传输。在2MSL等待状态完成后，socket进入CLOSED状态。
被动关闭：当程序收到一个FIN包从peer，并反馈一个ACK包，于是程序的socket转入CLOSE_WAIT状态。因为peer已经关闭了，所以不能发任何消息了。但程序还可以。要关闭连接，程序自已发送给自已FIN，使程序的TCP socket状态变成LAST_ACK状态，当程序从peer收到ACK包时，程序进入CLOSED状态。
2. Winsock2 API中的相关函数
先当然是查MSDN，看到winsocks2 API中的相关函数有:closesocket,shutdown,WSASendDisconnect. 我大致说一下，具体详细的资料还请自行查MSDN.
int closesocket( SOCKET s)的作用是关闭指定的socket，并且回收其所有的资源。
int shutdown( SOCKET s, int how)则是禁止在指定的socket s上禁止进行由how指定的操作，但并不对资源进行回收，shutdown之后而closesocket之前s还不能再次connect或者WSAConnect.
int WSASendDisconnect( SOCKET s, LPWSABUF lpOutboundDisconnectData)则和shutdown基本类似，稍有不同的就是WSASendDisconnect函数多了一个lpOutboundDisconnectData参数，可以允许发送“断开数据”（disconnect data）.但MSDN上写了“The native implementation of TCP/IP on Windows does not support disconnect data.”，所以一般我们就用shutdown函数就行了。
3. Socket的优雅关闭
在MSDN中对shutdown函数中的Remarks部分有下面一段话，指出了如何进行一次优雅的slcket关闭:
To assure that all data is sent and received on a connected socket before it is closed, an application should use shutdown to close connection before calling closesocket. For example, to initiate a graceful disconnect:
Call WSAAsyncSelect to register for FD_CLOSE notification.
Call shutdown with how=SD_SEND.
When FD_CLOSE received, call recv until zero returned, or SOCKET_ERROR.
Call closesocket.
closesocket的行为也是随setsockopt()中参数的不同而有不同的表现，这里影响它的行为的主要就是那个linger结构。
SO_DONTLINGER 若为真，则SO_LINGER选项被禁止。
SO_LINGER 延迟关闭连接 struct linger
上面这两个选项影响close行为
选项 间隔 关闭方式 等待关闭与否
SO_DONTLINGER 不关心 优雅 否
SO_LINGER 零 强制 否
SO_LINGER 非零 优雅 是
若设置了SO_LINGER（亦即linger结构中的l_onoff域设为非零），并设置了零超时间隔，则closesocket()不被阻塞立即执行，不论是否有排队数据未发送或未被确认。这种关闭方式称为“强制”或“失效”关闭，因为套接口的虚电路立即被复位，且丢失了未发送的数据。在远端的recv()调用将以WSAECONNRESET出错。
若设置了SO_LINGER并确定了非零的超时间隔，则closesocket()调用阻塞进程，直到所剩数据发送完毕或超时。这种关闭称为“优雅的”关闭。请注意如果套接口置为非阻塞且SO_LINGER设为非零超时，则closesocket()调用将以WSAEWOULDBLOCK错误返回。
若在一个流类套接口上设置了SO_DONTLINGER（也就是说将linger结构的l_onoff域设为零），则closesocket()调用立即返回。但是，如果可能，排队的数据将在套接口关闭前发送。请注意，在这种情况下WINDOWS套接口实现将在一段不确定的时间内保留套接口以及其他资源，这对于想用所以套接口的应用程序来说有一定影响。
所以一般来说，不应该把linger设置为SO_LINGER 并且设置timeout为0，这样的话，当本地主机调用closesocket时将会造成一个“强制”或“失效”的非优雅关闭。可以根据实际情况设置为另外两种情况。
socket中shutdown和closesocket的区别
close-----关闭本进程的socket id，但链接还是开着的，用这个socket id的其它进程还能用这个链接，能读或写这个socket id
shutdown--则破坏了socket 链接，读的时候可能侦探到EOF结束符，写的时候可能会收到一个SIGPIPE信号，这个信号可能直到
socket buffer被填充了才收到，shutdown还有一个关闭方式的参数，0 不能再读，1不能再写，2 读写都不能。
closesocket（）和close（）区别
一个是window下的函数(closesocket)，一个是linux下的函数(close)
一个是window下的函数(closesocket)
一个是linux下的函数(close)
close socket意思是封闭插座。
close adj.亲密的; 紧密的; 亲近的; vt.关; 结束; 使靠近; vi.关闭; 关; 结束; adv.紧密地; n.结束;
close socket直接是封闭插座的意思，而close则侧重指关闭后面的物体。
例句
1 A book about the close love-hate relationship between two boys
一本关于两个男孩爱恨交加的亲密关系的书
2 It faces pressure to close stores as sales lag as well as cutthroat competition from online retailers such as Amazon.
面对亚马逊（Amazon）等在线零售商带来的残酷竞争，百思买实体店的销售下滑，公司面临关闭店铺的压力。
3 Don't forget to close the window after you.
别忘了跟手儿关窗。
4 Do place a shaving mirror close to the shaver socket.
在剃须刀插座边上装一面放大镜。
5 In TCP, it's possible for a peer to close its end of a socket ( resulting in a FIN packet being sent) but then to continue to receive data.
在TCP中，一端可以关闭自己这端的socket（这样会导致发送一个FIN报文），但是仍然可以继续接收数据。
如何才能正确的关闭Socket连接
从TCP协议角度来看，一个已建立的TCP连接有两种关闭方式，一种是正常关闭，即四次挥手关闭连接；还有一种则是异常关闭，我们通常称之为连接重置（RESET)。
首先说一下正常关闭时四次挥手的状态变迁，关闭连接的主动方状态变迁是FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT，而关闭连接的被动方的状态变迁是CLOSE_WAIT->LAST_ACK->TIME_WAIT。在四次挥手过程中ACK包都是协议栈自动完成的，而FIN包则必须由应用层通过closesocket或shutdown主动发送，通常连接正常关闭后，recv会得到返回值0，send会得到错误码10058。
除此之外，在我们的日常应用中，连接异常关闭的情况也很多。比如应用程序被强行关闭、本地网络突然中断(禁用网卡、网线拔出)、程序处理不当等都会导致连接重置，连接重置时将会产生RST包，同时网络络缓冲区中未接收（发送）的数据都将丢失。连接重置后，本方send或recv会得到错误码10053(closesocket时是10038)，对方recv会得到错误码10054，send则得到错误码10053(closesocket时是10054)。
操作系统为我们提供了两个函数来关闭一个TCP连接，分别是closesocket和shutdown。通常情况下，closesocket会向对方发送一个FIN包，但是也有例外。比如有一个工作线程正在调用recv接收数据，此时外部调用closesocket，会导致连接重置，同时向对方发送一个RST包，这个RST包是由本方主动产生的。
shutdown可以用来关闭指定方向的连接，该函数接收两个参数，一个是套接字，另一个是关闭的方向，可用值为SD_SEND,SD_RECEIVE和SD_BOTH。方向取值为SD_SEND时，无论socket处于什么状态(recv阻塞，或空闲状态)，都会向对方发送一个FIN包，注意这点与closesocket的区别。此时本方进入FIN_WAIT_2状态，对方进入CLOSE_WAIT状态，本方依然可以调用recv接收数据；方向取值为SD_RECEIVE时，双发连接状态没有改变，依然处于ESTABLISHED状态，本方依然可以send数据，但是，如果对方再调用send方法，连接会被立即重置，同时向对方发送一个RST包，这个RST包是被动产生的，这点注意与closesocket的区别。