为什么需要监听套接字?
监听套接字 连接套接字的区别
摘要：对于服务器编程中最重要的一步等待并接受客户的连接，那么这一步在编程中如何完成，accept函数就是完成这一步的。它从内核中取出已经建立的客户连接，然后把这个已经建立的连接返回给用户程序，此时用户程序就可以与自己的客户进行点到点的通信了。
accept函数等待并接受客户请求：
#include<sys/socket.h>
int accept(int sockfd, struct sockaddr* addr, socklen_t* len)
返回：非负描述字——成功， -1——失败
accept默认会阻塞进程，直到有一个客户连接建立后返回，它返回的是一个新可用的套接字，这个套接字是连接套接字。此时我们需要区分两种套接字，一种套接字正如accept的参数sockfd，它是监听套接字，在调用listen函数之后，一个套接字会从主动连接的套接字变身为一个监听套接字；而accept返回是一个连接套接字，它代表着一个网络已经存在的点点连接。自然要问的是：为什么要有两种套接字？原因很简单，如果使用一个描述字的话，那么它的功能太多，使得使用很不直观，同时在内核确实产生了一个这样的新的描述字。
参数sockfd
参数sockfd就是上面解释中的监听套接字，这个套接字用来监听一个端口，当有一个客户与服务器连接时，它使用这个一个端口号，而此时这个端口号正与这个套接字关联。当然客户不知道套接字这些细节，它只知道一个地址和一个端口号。
参数addr
这是一个结果参数，它用来接受一个返回值，这返回值指定客户端的地址，当然这个地址是通过某个地址结构来描述的，用户应该知道这一个什么样的地址结构。如果对客户的地址不感兴趣，那么可以把这个值设置为NULL。
参数len
如同大家所认为的，它也是结果的参数，用来接受上述addr的结构的大小的，它指明addr结构所占有的字节个数。同样的，它也可以被设置为NULL。
如果accept成功返回，则服务器与客户已经正确建立连接了，此时服务器通过accept返回的套接字来完成与客户的通信。
这周同学们在做网络编程的时候，碰到一个监听套接字的问题，在这里大概描述一下：
比如我的程序开了一个监听端口，与客户端建立连接之后，生成了一个新套接字。这时我执行了只关闭监听端口的语句，结果却发现监听端口和已建立的连接仍然存在。我都已经关闭了监听套接字，为什么客户端还可以继续往监听端口发信息？这到底是因为什么呢？新套接字和监听套接字有什么关系呢？
比如，你开了80监听端口，有一个客户连接你accept了，这时关闭80端口。但此时客户端发信息的时候必然是发向80断口，但是80已经关了啊，但是通信依然正常进行。其实我刚接触套接字的时候也是认为所有从客户端发来的数据都需要经过监听套接字转一下才能收到。所有的初学者都容易犯这个误解。
经过一段时间的使用，我现在是明白了，监听套接字就是个牵线指路的，你实质上是跟它指的那个人说话。因为你要找的那个人不可能随时等你来，而监听套接字就是专职等你来问，它回答你要找的人在哪，并唤醒你要找的人，于是通话就建立起来了，就像现实生活中的接线员一样。
也就是说，在连接建立后，客户端用发出连接的那个SOCKET向服务器发数据，是发给服务器新创建的SOCKET，而不是服务器的监听SOCKET。服务器的监听SOCKET永远只是用来接受连接请求。
这就好比你去吃饭，饭馆门口有迎宾小姐（监听SOCKET）看到你来后和你打招呼，然后（ACCEPT）找来一个新的服务员（NEW SOCKET）来接待你，然后守在门口继续监听下一个。监听的小姐走了，接待你的服务员当然不受影响。
说到这里有必要说一下accept()函数。以下是《Linux网络编程》一书，第六章 Berkeley套接字对accept()函数的描述：
函数 accept()有一些难懂。当调用它的时候，大致过程是下面这样的：
● 有人从很远很远的地方尝试调用 connect()来连接你的机器上的某个端口（当然是你已经在 listen()的）。
● 他的连接将被 listen 加入等待队列等待 accept()函数的调用（加入等待队列的最多数目由调用 listen()函数的第二个参数 backlog 来决定）。
● 你调用 accept()函数，告诉他你准备连接。
● accept()函数将回返回一个新的套接字描述符，这个描述符就代表了这个连接！
好，这时候你有了两个套接字描述符，返回给你的那个就是和远程计算机的连接，而第一个套接字描述符仍然在你的机器上原来的那个端口上 listen()。
这时候你所得到的那个新的套接字描述符就可以进行 send()操作和recv()操作了。
通过上面的解释，相信您一定已经对监听套接字有了进一步的了解了吧！
---------------------
作者：Rain-晴天
来源：CSDN
原文：https://blog.csdn.net/rain_qingtian/article/details/12570951
版权声明：本文为博主原创文章，转载请附上博文链接！
为什么有监听socket和连接socket,为什么产生两个socket
先看一半的socket建立连接的双方的过程:
客户端:
socket()---->创建出 active_socket_fd (client_socket_fd)
bind()--->把active_socket_fd与ip,port绑定起来
connect()--->client_socket_fd 主动请求服务端的 listen_socket_fd
read()/write()---->读/写 socket io
close()---->关闭socket_fd
服务端:
socket()---->创建出 active_socket_fd
bind()--->把active_socket_fd与ip,port绑定起来
listen()---->active_socket_fd--> listen_socket_fd 等待客户端的client_socket_fd来请求连接
accept()---->listen_socket_fd-->connec_socket_fd 把监听socket转变为连接socket,用于建立连接购的读写数据
read()/write()---->读/写 socket io
close()---->关闭socket_fd
linux内核, socket函数创建的套接字是主动套接字
一开始socket函数, 不管在客户端还是在服务端, 创建的都是主动socket, 但是在服务端经过listen(), 后把其转变为listen_socket_fd(被动监听socket),
经过accept()后转变为connect_socket_fd(已连接socket).
在转变为connect_socket_fd之前, 都是同一个socket, 只不过是socket的状态改变了, 但是服务端经过accept()后返回的socket是新的socket, 用于连接后的read()/write()
为什么服务端这么特殊, 需要两种状态的socket, 并且在这个过程中产生两个socket?
需要两种状态的socket?
对于前者, 这个比较好理解, 因为是现在的网络程序中是C/S结构的, 一般是客户端主动向服务端请求建立连接. 这个过程中, 主要涉及到两个状态, 一个是主动, 一个是被动的. 因此, 客户端的socket只用于主动向服务端的socket请求建立连接, 服务端的socket一直被动的等待客户端的请求连接就ok了. 所以这就解答了为什么需要两种状态的socket, 只有一方是主动, 另一方是被动, 才能否完成上面的过程. 如果双方都是主动, 或者被动, 就完成不了上面的过程了.
1.产生两个socket?
等等, 上面好像没有说到为什么服务端需要产生两个socket(监听socket和已连接socket)
这个我认为是, 监听socket，是服务器作为客户端连接请求的一个对端，只需创建一次能够让客户端请求到有这个端点就ok，所以监听socket(listen_socket_fd)存在于服务器的整个生命周期, 不需要每个连接都创建一个新的监听socket出来, 没必要呢。已连接socket(connect_socket_fd)是客户端与服务器之间已经建立起来了的连接的一个端点，服务器每次接受连接请求时都会创建一个新已连接socket，它的生命周期只是客户端请求服务端的时间范围内。
2.为什么不只使用一个listen_socket_fd完成从创建监听socket(listen_socket_fd), 到被请求连接, 处理请求, 关闭socket的整个过程呢? 而需要用一个listen_socket_fd作为监听客户端请求, 然后每个连接创建一个新的connect_socket_fd来完成服务端与客户端的"交流"?
- 假设前者那种情况, 只用一个socket完成整个过程. 那么这个socket就会一直被占用, 而不能被另外的客户端请求, 造成了服务端的性能极其低下, 如果没有存储后面的客户端请求, 就会被错过而丢弃, 因为当前的socket正在与当前一个客户端的socket建立连接.
- 所以从上面的情况可以得知, 在请求连接和连接后需要的socket应该不是同一个, 它们负责的工作是不一样的. 有了listen_socket_fd和connect_socket_fd后, 就可以专门用一listen_socket_fd负责响应客户端的请求, 每次新的connect_socket_fd专门负责当前这次连接的数据交互.
总结
为什么需要两种socket(监听socket和已连接socket)已经说得明白了, 总的来说是, 是为了职责分工, 分层协作, 提高服务端性能.
我的理解：listen之后，有监听套接字的应用程序，等同于一个注册，是告诉操作系统和下层网络协议，当有匹配此程序的包裹时，需要分发递交给此程序，而不是屏蔽掉。假如没有提前设置监听套接字的话，网络层收到了有连接请求的包，也不知道应该把包继续分发到哪一个应用程序。 所以，socket函数确定用到的协议，bind函数确定本机地址和端口，确定一个本地的通信进程，listen函数将套接字变成监听套接字，注册给操作系统。在分析这个问题时，应该关注的焦点是：各个函数如何作用改变了应用进程？如何让一个普通进程变为了可以网络通信的进程？
参考链接：
监听套接字与已连接套接字 - Leo的博客 - CSDN博客 https://blog.csdn.net/lihao21/article/details/64951446
为什么TCP服务器的监听套接字要设置为非阻塞 - zhwenx3的博客 - CSDN博客 https://blog.csdn.net/zhwenx3/article/details/88107428
为什么有监听socket和连接socket,为什么产生两个socket - 那一抹风 - 博客园 https://www.cnblogs.com/liangjf/p/9900928.html
