%m表示errno和strerror(errno)
或者不怕麻烦的话添加头文件<error.h>
然后还是在出错的函数socket()后面添加打印信息printf("%d|%s\n", error, strerror(errno))
error表示该函数的出错码，后面的表示英文解释，具体的可以在linux下用慢查找
虽然这个办法笨了点。但是我只会这种方法....
你有抓包看了吗 linux下用tcpdump -w抓到本地来看 本地用wireshark抓 一抓包啥东西都清清楚楚
前端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<unistd.h>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的主要流程：
#include <iostream>#include <stdlib.h>
#include <winsock2.h>
#pragma comment(lib, "ws2_32.lib")
using namespace std
//头文件包含
int main()
{ int recvbytes
char temp[100]
char a[100] //一些变量的声明
WORD wVersionRequested
WSADATA wsaData
SOCKET sock_id, client_id //定义两个套接字
struct sockaddr_in serv_addr, remote_addr//定义两个结构
wVersionRequested = MAKEWORD(2, 0)//这个是固定用法 版本
if (0 != WSAStartup(wVersionRequested, &wsaData)) //此处初始化socke库
{
cout <<"加载Winsock库出错!" <<endl
exit(1)
}
if (-1 == (sock_id = socket(AF_INET, SOCK_STREAM, 0))) //建立一个类型为TCP的套接字
{
cout <<"创建套接字出错!" <<endl
exit(1)
}
//填充结构体内容
serv_addr.sin_family = AF_INET//固定
serv_addr.sin_port = htons(800)//端口
serv_addr.sin_addr.S_un.S_addr = inet_addr("127.0.0.1")//ip
memset(&(serv_addr.sin_zero), 0, sizeof(serv_addr.sin_zero))//其他填充为零
//绑定到套接字描述符
if (SOCKET_ERROR == bind(sock_id, (struct sockaddr *)&serv_addr, sizeof(struct sockaddr)))
{
cout <<"1出错!" <<endl
exit(1)
}
//开始监听
if (SOCKET_ERROR == listen(sock_id, 5))
{
cout <<"2出错!" <<endl
exit(1)
}
//如果来了一个连接请求 处理输入后发送给对方 输入的东东
int sin_size = sizeof(struct sockaddr_in)
if (SOCKET_ERROR == (client_id = accept(sock_id, (struct sockaddr *)&remote_addr, &sin_size)))
{
cout <<"3出错!" <<endl
exit(1)
}
cout<<"连接到一个客户端!!!请发送消息给他!!!"<<endl
cout<<"请输入要发送的消息!!!"<<endl
while(1)
{ cin>>a
send(client_id, a, strlen(a), 0)//把输入的东东发送出去
if (ERROR_SUCCESS == (recvbytes = recv(client_id, temp, 100, 0))) //接收数据到temp缓冲区
{
cout <<"接受数据出错!" <<endl
exit(1)
}
temp[recvbytes] = '\0'
cout <<temp <<endl
if(temp[0]!='8')
continue
else
break
}
closesocket(client_id)//关闭套接字
closesocket(sock_id)//关闭套接字
WSACleanup()//清理套接字库等收尾工作
system("pause")//暂停
return 0
}
