【Linux网络】 网络套接字（三）socket编程_TCP网络程序
目录
- TCP网络程序
-
- 服务端
-
- 创建套接字并绑定
- 服务端监听
- 服务端获取连接
- 服务器处理请求
- 客户端
-
- 客户端创建套接字
- 客户端连接服务器
- 客户端发起请求
- 测试
- 服务器存在的问题
-
- 多进程版的TCP网络程序
- 多线程版的TCP网络程序
- 线程池版的TCP网络程序
- TCP网络程序总结图
TCP网络程序
服务端
创建套接字并绑定
TCP创建套接字并绑定的过程和UDP创建套接字并绑定的过程一样，这里对一些参数进行说明。
#include TCP服务器在调用socket函数创建套接字时，参数设置如下：
- 协议家族选择AF_INET，因为我们要进行的是网络通信。
- 创建套接字时所需的服务类型应该是SOCK_STREAM，因为我们编写的是TCP服务器，SOCK_STREAM提供的就是一个有序的、可靠的、全双工的、基于连接的流式服务。
- 协议类型默认设置为0即可
服务端监听
UDP服务器的初始化只需要上述的创建套接字并绑定，因为UDP是面向数据报服务的，负责把消息传递即可。而TCP服务器是面向连接的，客户端在正式向TCP服务器发送数据之前需要进行连接，才能进行通信。
因此TCP服务端需要时刻监听客户端是否发来连接请求，那么我们上面创建的套接字需要用来监听。
listen 函数
设置套接字为监听状态的函数叫做listen，该函数的函数原型如下：
int listen(int sockfd, int backlog);
参数说明：
- sockfd：需要设置为监听状态的套接字对应的文件描述符。
- backlog：全连接队列的最大长度。如果有多个客户端同时发来连接请求，此时未被服务器处理的连接就会放入连接队列，该参数代表的就是这个全连接队列的最大长度，一般不要设置太大，设置为5或10即可。
返回值说明：
- 监听成功返回0，监听失败返回-1，同时错误码会被设置
服务器监听
#include TCP服务端的初始化与UDP服务端初始化相比，TCP需要监听服务。
服务端获取连接
上面的初始化工作已经完成，现在开始连接工作。
在TCP服务端与客户端进行通信之前，服务器需要先获取到客户端的连接请求。
accept函数
获取连接的函数叫做accept，该函数的函数原型如下：
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
参数说明：
- sockfd：特定的监听套接字，表示从该监听套接字中获取连接。
- addr：对端网络相关的属性信息，包括协议家族、IP地址、端口号等。
- addrlen：调用时传入期望读取的addr结构体的长度，返回时代表实际读取到的addr结构体的长度，这是一个输入输出型参数。
返回值说明：
- 获取连接成功返回接收到的套接字的文件描述符，获取连接失败返回-1，同时错误码会被设置。
注意这里的返回值是套接字的文件描述符
监听套接字和返回的套接字的区别：
- 监听套接字： 用来获取客户端发来的连接请求，accept 函数会不断从监听套接字当中获取新连接。
- 返回的套接字： 用于为本次accept 获取到的连接提供服务。
监听套接字只是用来获取客户端发来的连接请求，而accept 函数返回的套接字才是为这些连接提供服务的。
服务端获取连接
服务端在获取连接时需要注意：
- accept函数获取连接时可能会失败，但TCP服务器不会因为获取某个连接失败而退出，因此服务端获取连接失败后应该继续获取连接。
- 如果要将获取到的连接对应客户端的IP地址和端口号信息进行输出，需要调用inet_ntoa函数将整数IP转换成字符串IP，调用ntohs函数将端口号由网络序列转换成主机序列。
- inet_ntoa函数在底层实际做了两个工作，一是将网络序列转换成主机序列，二是将主机序列的整数IP转换成字符串风格的点分十进制的IP。
#include 服务端接收连接测试
现在我们可以做一下简单的测试，看看当前服务器能否成功接收请求连接。在运行服务端时需要传入一个端口号作为服务端的端口号，然后我们用该端口号构造一个服务端对象，对服务端进行初始化后启动服务端即可。
#include "tcp_server.hpp"
using namespace std;
int main()
{
TcpServer* tsvr = new TcpServer(8082);
tsvr->ServerInit();
tsvr->ServerStart();
return 0;
}
服务端运行后，通过netstat命令可以查看到一个程序名为tcp_server的服务程序，它绑定的端口就是8082，而由于服务器绑定的是INADDR_ANY，因此该服务器的本地IP地址是0.0.0.0，这就意味着该TCP服务器可以读取本地任何一张网卡里面的数据。此外，最重要的是当前该服务器所处的状态是LISTEN状态，表明当前服务器可以接收外部的请求连接。
虽然现在还没有编写客户端相关的代码，但是我们可以使用telnet命令远程登录到该服务器，因为telnet底层实际采用的就是TCP协议。
使用telnet命令连接当前TCP服务器后可以看到，此时服务器接收到了一个连接，为该连接提供服务的套接字对应的文件描述符就是4。因为0、1、2是默认打开的，其分别对应标准输入流、标准输出流和标准错误流，而3号文件描述符在初始化服务器时分配给了监听套接字，因此当第一个客户端发起连接请求时，为该客户端提供服务的套接字对应的文件描述符就是4。
服务器处理请求
此时服务端已经能够获取到连接的请求了，下面对获取到的连接进行处理。
为了能够让通信双方都能看到对应的现象，验证通信是正常的，我们设计一个服务端将客户端发来的数据接收到以后，再重新发回给客户端。
read函数
TCP服务器读取数据的函数叫做read，该函数的函数原型如下：
ssize_t read(int fd, void *buf, size_t count);
参数说明：
- fd：特定的文件描述符，表示从该文件描述符中读取数据。
- buf：数据的存储位置，表示将读取到的数据存储到该位置。
- count：数据的个数，表示从该文件描述符中读取数据的字节数。
返回值说明：
- 如果返回值大于0，则表示本次实际读取到的字节个数。
- 如果返回值等于0，则表示对端已经把连接关闭了。
- 如果返回值小于0，则表示读取时遇到了错误。
write函数
TCP服务器写入数据的函数叫做write，该函数的函数原型如下：
ssize_t write(int fd, const void *buf, size_t count);
参数说明：
- fd：特定的文件描述符，表示将数据写入该文件描述符对应的套接字。
- buf：需要写入的数据。
- count：需要写入数据的字节个数。
返回值说明：
- 写入成功返回实际写入的字节数，写入失败返回-1，同时错误码会被设置。
当服务端调用read函数收到客户端的数据后，就可以再调用write函数将该数据再响应给客户端。
服务端处理请求
服务端读取数据是从服务套接字中读取的，服务端写入数据是写入服务套接字的。也就是说，为客户端提供服务的套接字，即可以读取数据也可以写入数据，这就是TCP全双工通信的体现。
在从服务套接字中读取客户端发来的数据时，如果调用read函数后得到的返回值为0，或者读取出错了，此时就应该直接将服务套接字对应的文件描述符关闭。因为文件描述符本质就是数组的下标，因此文件描述符的资源是有限的，如果我们一直占用，那么可用的文件描述符就会越来越少，因此服务完客户端后要及时关闭对应的文件描述符，否则会导致文件描述符泄漏。
#include 客户端
客户端创建套接字
客户端不需要我们自己绑定，交给操作系统绑定。客户端一般不需要监听。
- 服务端要进行绑定是因为服务端的IP地址和端口号必须要众所周知，不能随意改变。而客户端虽然也需要IP地址和端口号，但是客户端并不需要我们进行绑定操作，客户端连接服务端时系统会自动指定一个端口号给客户端。
- 服务端需要进行监听是因为服务端需要通过监听来获取新连接，但是不会有人主动连接客户端，因此客户端是不需要进行监听操作的。
此外，客户端必须要知道它要连接的服务端的IP地址和端口号，因此客户端除了要有自己的套接字之外，还需要知道服务端的IP地址和端口号，这样客户端才能够通过套接字向指定服务器进行通信。
#include 客户端连接服务器
由于客户端不需要绑定，也不需要监听，因此当客户端创建完套接字后就可以向服务端发起连接请求。
connect函数
发起连接请求的函数叫做connect，该函数的函数原型如下：
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
参数说明：
- sockfd：特定的套接字，表示通过该套接字发起连接请求。
- addr：对端网络相关的属性信息，包括协议家族、IP地址、端口号等。
- addrlen：传入的addr结构体的长度。
返回值说明：
- 连接或绑定成功返回0，连接失败返回-1，同时错误码会被设置。
客户端连接服务器
此外，调用connect函数向服务端发起连接请求时，需要传入服务端对应的网络信息。
#include 客户端发起请求
当客户端连接到服务器后，客户端就可以发起请求了。我们这里每次发送一条消息给客户端，客户端处理后再发回来。
以下是发起请求的代码，Request（）函数里先向服务端发一条消息，然后再接收服务端的消息。
#include 在运行客户端程序时我们就需要携带上服务端对应的IP地址和端口号，然后我们就可以通过服务端的IP地址和端口号构造出一个客户端对象，对客户端进行初始后启动客户端即可。
#include "tcp_client.hpp"
int main()
{
TcpClient * tclt = new TcpClient("127.0.0.1",8082);
tclt->ClientInit();
tclt->ClientStart();
return 0;
}
测试
启动服务端后，用 netstat命令进行查看，此时就能看到名为tcp_server的服务进程，此时正处于监听状态。
此时就可以启动客户端连接服务端，进行服务了。
客户端给服务端发消息，服务端回显对应的消息。
当关闭该客户端后，服务端对该客户端的服务也就结束了。
服务器存在的问题
该TCP服务器存在一个问题：一次只能为一个客户端服务，如果有多个客户端连接，那么只能等一个客户端退出后，其他客户端才能被服务器服务。
如图所示，客户端1能够成功连接，正常通信。
当客户端2尝试连接的时候，会发现服务器没有显示客户端2的相关信息，客户端2向服务器发消息也没回应。
当我们关闭客户端1后，服务端就会显示客户端2的消息，并且接收和回应客户端2发来的消息。
单执行流的服务器
通过实验现象可以看到，这服务端只有服务完一个客户端后才会服务另一个客户端。因为我们目前所写的是一个单执行流版的服务器，这个服务器一次只能为一个客户端提供服务。
当服务端调用accept函数获取到连接后就给该客户端提供服务，但在服务端提供服务期间可能会有其他客户端发起连接请求，但由于当前服务器是单执行流的，只能服务完当前客户端后才能继续服务下一个客户端。
客户端2为什么会显示连接成功？
当服务端在给第一个客户端提供服务期间，第二个客户端向服务端发起的连接请求时是成功的，只不过服务端没有调用accept函数将该连接获取上来罢了。
实际在底层会为我们维护一个连接队列，服务端没有accept的新连接就会放到这个连接队列当中，而这个连接队列的最大长度就是通过listen函数的第二个参数来指定的，因此服务端虽然没有获取第二个客户端发来的连接请求，但是在第二个客户端那里显示是连接成功的。
如何解决？
单执行流的服务器一次只能给一个客户端提供服务，此时服务器的资源并没有得到充分利用，因此服务器一般是不会写成单执行流的。要解决这个问题就需要将服务器改为多执行流的，此时就要引入多进程或多线程
多进程版的TCP网络程序
当服务端调用accept函数获取连接成功后，不是由当前执行流为其提供服务，而是创建一个子进程，让子进程为父进程获取到的连接提供服务。
父进程不关系获取到的连接服务是否提供完毕，交给子进程后，自己又去监听是否有其他客户端想获取连接。
等待子进程问题
当父进程创建出子进程后，父进程是需要等待子进程退出的，否则子进程会变成僵尸进程，进而造成内存泄漏。因此服务端创建子进程后需要调用wait或waitpid函数对子进程进行等待。
阻塞式等待与非阻塞式等待：
- 如果服务端采用阻塞的方式等待子进程，那么服务端还是需要等待服务完当前客户端，才能继续获取下一个连接请求，此时服务端仍然是以一种串行的方式为客户端提供服务。
- 如果服务端采用非阻塞的方式等待子进程，虽然在子进程为客户端提供服务期间服务端可以继续获取新连接，但此时服务端就需要将所有子进程的PID保存下来，并且需要不断花费时间检测子进程是否退出。
总之，服务端要等待子进程退出，无论采用阻塞式等待还是非阻塞式等待，都不尽人意。此时我们可以考虑让服务端不等待子进程退出。
不等待子进程退出的方式
- 捕捉SIGCHLD信号，将其处理动作设置为忽略
多进程版本代码编写
#include 代码测试
重新编译程序运行服务端后，可以通过以下监控脚本对服务进程进行监控。
while :; do ps axj | head -1 && ps axj | grep tcp_server | grep -v grep;echo "######################";sleep 1;done
此时可以看到，一开始没有客户端连接该服务器，此时服务进程只有一个，该服务进程就是不断获取新连接的进程，而获取到新连接后也是由该进程创建子进程为对应客户端提供服务的。
此时我们运行一个客户端，让该客户端连接服务器，此时服务进程就会调用fork函数创建出一个子进程，由该子进程为这个客户端提供服务。
如果再有一个客户端连接服务器，此时服务进程会再创建出一个子进程，让该子进程为这个客户端提供服务。
最重要的是，由于这两个客户端分别由两个不同的执行流提供服务，因此这两个客户端可以同时享受到服务，它们发送给服务端的数据都能够在服务端输出，并且服务端也会对它们的数据进行响应。
当客户端一个个退出后，在服务端对应为之提供服务的子进程也会相继退出，但无论如何服务端都至少会有一个服务进程，这个服务进程的任务就是不断获取新连接。
多线程版的TCP网络程序
创建进程的成本是很高的，创建进程时需要创建该进程对应的进程控制块（task_struct）、进程地址空间（mm_struct）、页表等数据结构。而创建线程的成本比创建进程的成本会小得多，因为线程本质是在进程地址空间内运行，创建出来的线程会共享该进程的大部分资源，因此在实现多执行流的服务器时最好采用多线程进行实现。
当服务进程调用accept函数获取到一个新连接后，就可以直接创建一个线程，让该线程为对应客户端提供服务。
当然，主线程（服务进程）创建出新线程后，也是需要等待新线程退出的，否则也会造成类似于僵尸进程这样的问题。但对于线程来说，如果不想让主线程等待新线程退出，可以让创建出来的新线程调用pthread_detach函数进行线程分离，当这个线程退出时系统会自动回收该线程所对应的资源。此时主线程（服务进程）就可以继续调用accept函数获取新连接，而让新线程去服务对应的客户端。
各个线程共享同一张文件描述符表
文件描述符表维护的是进程与文件之间的对应关系，因此一个进程对应一张文件描述符表。而主线程创建出来的新线程依旧属于这个进程，因此创建线程时并不会为该线程创建独立的文件描述符表，所有的线程看到的都是同一张文件描述符表。
因此当服务进程（主线程）调用accept函数获取到一个文件描述符后，其他创建的新线程是能够直接访问这个文件描述符的。
需要注意的是，虽然新线程能够直接访问主线程accept上来的文件描述符，但此时新线程并不知道它所服务的客户端对应的是哪一个文件描述符，因此主线程创建新线程后需要告诉新线程对应应该访问的文件描述符的值，也就是告诉每个新线程在服务客户端时，应该对哪一个套接字进行操作。
参数结构体
实际新线程在为客户端提供服务时就是调用Service函数，而调用Service函数时是需要传入三个参数的，分别是客户端对应的套接字、IP地址和端口号。因此主线程创建新线程时需要给新线程传入三个参数，而实际在调用pthread_create函数创建新线程时，只能传入一个类型为void*的参数。
这时我们可以设计一个参数结构体Param，此时这三个参数就可以放到Param结构体当中，当主线程创建新线程时就可以定义一个Param对象，将客户端对应的套接字、IP地址和端口号设计进这个Param对象当中，然后将Param对象的地址作为新线程执行例程的参数进行传入。
此时新线程在执行例程当中再将这个void类型的参数强转为Param类型，然后就能够拿到客户端对应的套接字，IP地址和端口号，进而调用Service函数为对应客户端提供服务。
class Param
{
public:
Param(int sock,std::string ip,in_port_t port)
:_sock(sock),_ip(ip),_port(port)
{}
private:
int _sock;
std::string _ip;
in_port_t _port;
};
文件描述符关闭的问题
由于此时所有线程看到的都是同一张文件描述符表，因此当某个线程要对这张文件描述符表做某种操作时，不仅要考虑当前线程，还要考虑其他线程。
- 对于主线程accept上来的文件描述符，主线程不能对其进行关闭操作，该文件描述符的关闭操作应该又新线程来执行。因为是新线程为客户端提供服务的，只有当新线程为客户端提供的服务结束后才能将该文件描述符关闭。
- 对于监听套接字，虽然创建出来的新线程不必关心监听套接字，但新线程不能将监听套接字对应的文件描述符关闭，否则主线程就无法从监听套接字当中获取新连接了。
Service函数定义为静态成员函数
由于调用pthread_create函数创建线程时，新线程的执行例程是一个参数为void*，返回值为void*的函数。如果我们要将这个执行例程定义到类内，就需要将其定义为静态成员函数，否则这个执行例程的第一个参数是隐藏的this指针。
代码测试
此时我们再重新编译服务端代码，由于代码当中用到了多线程，因此编译时需要携带上-pthread选项。此外，由于我们现在要监测的是一个个的线程，因此在监控时使用的不再是ps -axj命令，而是ps -aL命令。
while :; do ps -aL|head -1&&ps -aL|grep tcp_server;echo "####################";sleep 1;done
运行服务端，通过监控可以看到，此时只有一个服务线程，该服务线程就是主线程，它现在在等待客户端的连接到来。
当一个客户端连接到服务端后，此时主线程就会为该客户端构建一个参数结构体，然后创建一个新线程，将该参数结构体的地址作为参数传递给这个新线程，此时该新线程就能够从这个参数结构体当中提取出对应的参数，然后调用Service函数为该客户端提供服务，因此在监控当中显示了两个线程。
当第二个客户端发来连接请求时，主线程会进行相同的操作，最终再创建出一个新线程为该客户端提供服务，此时服务端当中就有了三个线程。
由于为这两个客户端提供服务的也是两个不同的执行流，因此这两个客户端可以同时享受服务端提供的服务，它们发送给服务端的消息也都能够在服务端进行打印，并且这两个客户端也都能够收到服务端的回显数据。
此时无论有多少个客户端发来连接请求，在服务端都会创建出相应数量的新线程为对应客户端提供服务，而当客户端一个个退出后，为其提供服务的新线程也就会相继退出，最终就只剩下最初的主线程仍在等待新连接的到来。
线程池版的TCP网络程序
当前多线程版的服务器存在的问题：
- 每当有新连接到来时，服务端的主线程都会重新为该客户端创建为其提供服务的新线程，而当服务结束后又会将该新线程销毁。这样做不仅麻烦，而且效率低下，每当连接到来的时候服务端才创建对应提供服务的线程。
- 如果有大量的客户端连接请求，此时服务端要为每一个客户端创建对应的服务线程。计算机当中的线程越多，CPU的压力就越大，因为CPU要不断在这些线程之间来回切换，此时CPU在调度线程的时候，线程和线程之间切换的成本就会变得很高。此外，一旦线程太多，每一个线程再次被调度的周期就变长了，而线程是为客户端提供服务的，线程被调度的周期变长，客户端也迟迟得不到应答。
解决思路
针对这两个问题，对应的解决思路如下：
- 可以在服务端预先创建一批线程，当有客户端请求连接时就让这些线程为客户端提供服务，此时客户端一来就有线程为其提供服务，而不是当客户端来了才创建对应的服务线程。
- 当某个线程为客户端提供完服务后，不要让该线程退出，而是让该线程继续为下一个客户端提供服务，如果当前没有客户端连接请求，则可以让该线程先进入休眠状态，当有客户端连接到来时再将该线程唤醒。
- 服务端创建的这一批线程的数量不能太多，此时CPU的压力也就不会太大。此外，如果有客户端连接到来，但此时这一批线程都在给其他客户端提供服务，这时服务端不应该再创建线程，而应该让这个新来的连接请求在全连接队列进行排队，等服务端这一批线程中有空闲线程后，再将该连接请求获取上来并为其提供服务。
引入线程池
实际要解决这里的问题我们就需要在服务端引入线程池，因为线程池的存在就是为了避免处理短时间任务时创建与销毁线程的代价，此外，线程池还能够保证内核充分利用，防止过分调度。
其中在线程池里面有一个任务队列，当有新的任务到来的时候，就可以将任务Push到线程池当中，在线程池当中我们默认创建了5个线程，这些线程不断检测任务队列当中是否有任务，如果有任务就拿出任务，然后调用该任务对应的Run函数对该任务进行处理，如果线程池当中没有任务那么当前线程就会进入休眠状态。
#define NUM 5
//线程池
template<class T>
class ThreadPool
{
private:
bool IsEmpty()
{
return _task_queue.size() == 0;
}
void LockQueue()
{
pthread_mutex_lock(&_mutex);
}
void UnLockQueue()
{
pthread_mutex_unlock(&_mutex);
}
void Wait()
{
pthread_cond_wait(&_cond, &_mutex);
}
void WakeUp()
{
pthread_cond_signal(&_cond);
}
public:
ThreadPool(int num = NUM)
: _thread_num(num)
{
pthread_mutex_init(&_mutex, nullptr);
pthread_cond_init(&_cond, nullptr);
}
~ThreadPool()
{
pthread_mutex_destroy(&_mutex);
pthread_cond_destroy(&_cond);
}
//线程池中线程的执行例程
static void* Routine(void* arg)
{
pthread_detach(pthread_self());
ThreadPool* self = (ThreadPool*)arg;
//不断从任务队列获取任务进行处理
while (true){
self->LockQueue();
while (self->IsEmpty()){
self->Wait();
}
T task;
self->Pop(task);
self->UnLockQueue();
task.Run(); //处理任务
}
}
void ThreadPoolInit()
{
pthread_t tid;
for (int i = 0; i < _thread_num; i++){
pthread_create(&tid, nullptr, Routine, this); //注意参数传入this指针
}
}
//往任务队列塞任务（主线程调用）
void Push(const T& task)
{
LockQueue();
_task_queue.push(task);
UnLockQueue();
WakeUp();
}
//从任务队列获取任务（线程池中的线程调用）
void Pop(T& task)
{
task = _task_queue.front();
_task_queue.pop();
}
private:
std::queue<T> _task_queue; //任务队列
int _thread_num; //线程池中线程的数量
pthread_mutex_t _mutex;
pthread_cond_t _cond;
};
服务类新增线程池成员
现在服务端引入了线程池，因此在服务类当中需要新增一个指向线程池的指针成员：
- 当实例化服务器对象时，先将这个线程池指针先初始化为空。
- 当服务器初始化完毕后，再实际构造这个线程池对象，在构造线程池对象时可以指定线程池当中线程的个数，也可以不指定，此时默认线程的个数为5。
- 在启动服务器之前对线程池进行初始化，此时就会将线程池当中的若干线程创建出来，而这些线程创建出来后就会不断检测任务队列，从任务队列当中拿出任务进行处理。
现在当服务进程调用accept函数获取到一个连接请求后，就会根据该客户端的套接字、IP地址以及端口号构建出一个任务，然后调用线程池提供的Push接口将该任务塞入任务队列。
这实际也是一个生产者消费者模型，其中服务进程就作为了任务的生产者，而后端线程池当中的若干线程就不断从任务队列当中获取任务进行处理，它们承担的就是消费者的角色，其中生产者和消费者的交易场所就是线程池当中的任务队列。
#include "ThreadPool.hpp"
#include "Task.hpp"
#include 设计任务类
现在我们要做的就是设计一个任务类，该任务类当中需要包含客户端对应的套接字、IP地址、端口号，表示该任务是为哪一个客户端提供服务，对应操作的套接字是哪一个。
此外，任务类当中需要包含一个Run方法，当线程池中的线程拿到任务后就会直接调用这个Run方法对该任务进行处理，而实际处理这个任务的方法就是服务类当中的Service函数，服务端就是通过调用Service函数为客户端提供服务的。
我们可以直接拿出服务类当中的Service函数，将其放到任务类当中作为任务类当中的Run方法，但这实际不利于软件分层。我们可以给任务类新增一个仿函数成员，当执行任务类当中的Run方法处理任务时就可以以回调的方式处理该任务。
class Task
{
public:
Task()
{
}
Task(int sock, std::string client_ip, int client_port)
: _sock(sock), _client_ip(client_ip), _client_port(client_port)
{
}
void Run()
{
_handler(_sock,_client_ip,_client_port);
}
private:
int _sock;
std::string _client_ip;
u_int16_t _client_port;
Handler _handler;//处理方法
};
注意： 当任务队列当中有任务时，线程池当中的线程会先定义出一个Task对象，然后将这个Task对象作为输出型参数调用任务队列的Pop函数，从任务队列当中获取任务，因此Task类除了提供带参的构造函数以外，还需要提供一个无参的构造函数，方便我们可以定义无参对象。
设计Handler类
此时需要再设计一个Handler类，在Handler类当中对()操作符进行重载，将()操作符的执行动作重载为执行Service函数的代码。
class Handler
{
public:
void operator()(int sock, std::string ip, u_int16_t port)
{
char buffer[1024];
while (true)
{
ssize_t n = read(sock, buffer, sizeof(buffer) - 1);
if (n > 0)
{
buffer[n] = '\0';
std::cout << "read success" << std::endl;
std::string msg = "server get a message: ";
msg += buffer;
write(sock, msg.c_str(), msg.size());
}
else if (n == 0)
{
std::cout << "client close" << std::endl;
break;
}
else
{
std::cerr << "read error" << std::endl;
break;
}
}
close(sock);
std::cout << "server done" << std::endl;
}
};
实际我们可以让服务器处理不同的任务，当前服务器只是在进行字符串的回显处理，而实际要怎么处理这个任务完全是由任务类当中的handler成员来决定的。
如果想要让服务器处理其他任务，只需要修改Handler类当中对()的重载函数就行了，而服务器的初始化、启动服务器以及线程池的代码都是不需要更改的，这就叫做把通信功能和业务逻辑在软件上做解耦。
代码测试
运行服务端后，就算没有客户端发来连接请求，此时在服务端就已经有了6个线程，其中有一个是接收新连接的服务线程，而其余的5个是线程池当中为客户端提供服务的线程。
此时当客户端连接服务器后，服务端的主线程就会获取该客户端的连接请求，并将其封装为一个任务对象后塞入任务队列，此时线程池中的5个线程就会有一个线程从任务队列当中获取到该任务，并执行该任务的处理函数为客户端提供服务。
当第二个客户端发起连接请求时，服务端也会将其封装为一个任务类塞到任务队列，然后线程池当中的线程再从任务队列当中获取到该任务进行处理，此时也是不同的执行流为这两个客户端提供的服务，因此这两个客户端也是能够同时享受服务的。
之前不同的是，无论现在有多少客户端发来请求，在服务端都只会有线程池当中的5个线程为之提供服务，线程池当中的线程个数不会随着客户端连接的增多而增多，这些线程也不会因为客户端的退出而退出。
我们设置的线程池的最大线程容量为5，当连接的客户端大于5个后，从第六个客户端开始，就要在连接队列中进行等待。当有一个线程退出后，后面的一个线程就可以正常通信了。
TCP网络程序总结图
本文章参考自hguisu和2021dragon