【技术分享会】IO 编年史

提出问题

• Redis 是个单线程应用，为什么这么快？
• 只知道 Nginx 牛，那么它是怎么支持高并发的？

数据交互流程

最基本的 Socket 通信

​ 客户端与服务器之间是怎么交互的？那就是 socket，socket 可以跨进程通信，更 NB 的就是可以跨主机的的进程通信。那么 socket 是个啥？百度说是“插口”，有道说是“插座”，应该还有人听说叫二元组，或者四元组，实际理解起来很简单，就像是两个主机各开一个“口子”，插了同一根网线，然后通过这个口子进行数据交互。

那么是怎么创建？怎么就运行起来的的呢？

int main() {//创建套接字int serv_sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);//将套接字和IP、端口绑定struct sockaddr_in serv_addr;memset(&serv_addr, 0, sizeof(serv_addr));  //每个字节都用0填充serv_addr.sin_family = AF_INET;  //使用IPv4地址serv_addr.sin_addr.s_addr = inet_addr("127.0.0.1");  //具体的IP地址serv_addr.sin_port = htons(1234);  //端口bind(serv_sock, (struct sockaddr *) &serv_addr, sizeof(serv_addr));//进入监听状态，等待用户发起请求listen(serv_sock, 20);//接收客户端请求struct sockaddr_in clnt_addr;socklen_t clnt_addr_size = sizeof(clnt_addr);int clnt_sock = accept(serv_sock, (struct sockaddr *) &clnt_addr, &clnt_addr_size);char buffer[40];read(clnt_sock, buffer, sizeof(buffer) - 1);printf("Message form client: %s\n", buffer);//向客户端发送数据char str[] = "hi, server's msg ~~~";write(clnt_sock, str, sizeof(str));//关闭套接字close(clnt_sock);close(serv_sock);return 0;
}

解析一下上面的代码：

服务端首先调用 socket() 函数，创建网络协议为 IPv4，以及传输协议为 TCP 的 Socket ，接着调用 bind() 函数，给这个 Socket 绑定一个 IP 地址和端口，绑定这两个的目的是什么？

• 绑定端口的目的：当内核收到 TCP 报文，通过 TCP 头里面的端口号，来找到我们的应用程序，然后把数据传递给我们。
• 绑定 IP 地址的目的：一台机器是可以有多个网卡的，每个网卡都有对应的 IP 地址，当绑定一个网卡时，内核在收到该网卡上的包，才会发给我们；

server 端通过调用 listen() 函数进行监听。

服务端进入了监听状态后，通过调用 accept() 函数，来从内核获取客户端的连接，如果没有客户端连接，则会阻塞等待客户端连接的到来，只到有客户端连接成功了，accept() 就能拿到一个 socketfd，然后处理这个 socket 要处理的事情。

那客户端是怎么发起连接的呢？

int main() {//创建套接字int sock = socket(AF_INET, SOCK_STREAM, 0);//向服务器（特定的IP和端口）发起请求struct sockaddr_in serv_addr;memset(&serv_addr, 0, sizeof(serv_addr));  //每个字节都用0填充serv_addr.sin_family = AF_INET;  //使用IPv4地址serv_addr.sin_addr.s_addr = inet_addr("127.0.0.1");  //具体的IP地址serv_addr.sin_port = htons(1234);  //端口connect(sock, (struct sockaddr *) &serv_addr, sizeof(serv_addr));//向客户端发送数据char str[] = "halo, 我是个 client ~~~";write(sock, str, sizeof(str));//读取服务器传回的数据char buffer[40];read(sock, buffer, sizeof(buffer) - 1);printf("Message form server: %s\n", buffer);//关闭套接字close(sock);return 0;
}

客户端在创建好 Socket 后，调用 connect()函数发起连接，该函数的参数要指明服务端的 IP 地址和端口号，然后经典的 TCP 三次握手就开始了。

在 TCP 连接的过程中，服务器的内核实际上为每个 Socket 维护了两个队列：

• 一个是还没完全建立连接的队列，称为 TCP 半连接队列，这个队列都是没有完成三次握手的连接；
• 一个是已经建立连接的队列，称为 TCP 全连接队列，这个队列都是完成了三次握手的连接；

当 TCP 全连接队列不为空后，服务端的 accept() 函数，就会从内核中的 TCP 全连接队列里拿出一个已经完成连接的 Socket 返回应用程序，后续数据传输都用这个 Socket。

注意，监听的 Socket 和真正用来传数据的 Socket 是两个：

• 一个叫作监听 Socket；
• 一个叫作已连接 Socket；

连接建立后，客户端和服务端就开始相互传输数据了，双方都可以通过 read()和 write() 函数来读写数据。

至此， TCP 协议的 Socket 程序的调用过程就结束了，整个过程如下图：

服务器那么贵，怎么可以只服务一个用户？

刚才说的通信方式是最简单、最基本的，它基本只能一对一通信，因为使用的是同步阻塞的方式，当服务端在还没处理完一个客户端的网络 I/O 时，或者 读写操作发生阻塞时，其他客户端是无法与服务端连接的。

可如果我们服务器只能服务一个客户，那这样就太浪费资源了，于是我们要改进这个网络 I/O 模型，以支持更多的客户端。

你知道服务器单机理论最大能连接多少个客户端？

TCP 连接唯一性怎么确定？通过四元组，本机IP + 端口, 对端IP + 端口。

服务器作为服务方，通常会在本地固定监听一个端口，等待客户端的连接。因此服务器的本地 IP 和端口是固定的，于是对于服务端 TCP 连接的四元组只有对端 IP 和端口是会变化的，所以最大 TCP 连接数 = 客户端 IP 数× 客户端端口数。

对于 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数约为 2 的 48 次方。

这个理论值相当NB，但是服务器肯定承载不了那么大的连接数，主要会受两个方面的限制：

• 文件描述符，Socket 实际上是一个文件，也就会对应一个文件描述符。在 Linux 下，单个进程打开的文件描述符数是有限制的，没有经过修改的值一般都是 1024，不过可以通过 ulimit 增大文件描述符的数目；
• 系统内存，每个 TCP 连接在内核中都有对应的数据结构，意味着每个连接都是会占用一定内存的；

那如果服务器的内存只有 2 GB，网卡是千兆的，能支持我们经常说的 C10K 问题吗？

从硬件资源角度看，对于 2GB 内存千兆网卡的服务器，如果每个请求处理占用不到 200KB 的内存和 100Kbit 的网络带宽就可以满足并发 1 万个请求。

不过，理想很丰满，现实很骨感，这种阻塞式的处理方式，效率太低了，连接的客户端越多呢，离 C10K 的目标也就越来越远了。

多进程模型

如果服务器要支持多个客户端，其中比较经典的方式，就是使用多进程模型，也就是为每个客户端分配一个进程来处理请求。

服务器的主进程负责监听客户的连接，一旦与客户端连接完成，accept() 函数就会返回一个已连接 Socket，这时就通过 fork() 函数创建一个子进程，把父进程所有相关的东西都复制一份，包括文件描述符、内存地址空间、程序计数器、执行的代码等。

正因为子进程会复制父进程的文件描述符，于是就可以直接使用已连接 Socket 和客户端通信了，

可以发现，子进程不需要关心「监听 Socket」，只需要关心「已连接 Socket」；父进程则相反，将客户服务交给子进程来处理，因此父进程不需要关心「已连接 Socket」，只需要关心「监听 Socket」。

另外，当「子进程」退出时，实际上内核里还会保留该进程的一些信息，也是会占用内存的，如果不做好“回收”工作，就会变成僵尸进程，随着僵尸进程越多，会慢慢耗尽我们的系统资源。

因此，父进程要“善后”好自己的儿子，怎么善后呢？那么有两种方式可以在子进程退出后回收资源，分别是调用 wait() 和 waitpid() 函数。

这种用多个进程来应付多个客户端的方式，在应对 100 个客户端还是可行的，但是当客户端数量高达一万时，肯定扛不住的，因为每产生一个进程，必会占据一定的系统资源，而且进程间上下文切换的“包袱”是很重的，性能会大打折扣。

多线程模型

既然进程间上下文切换的“包袱”很重，那我们就搞个比较轻量级的模型来应对多用户的请求 —— 多线程模型。

线程是运行在进程中的一个“逻辑流”，单进程中可以运行多个线程，同进程里的线程可以共享进程的部分资源的，比如文件描述符列表、进程空间、代码段、全局数据、堆等，这些共享些资源在上下文切换时是不需要切换，而只需要切换线程的私有数据、寄存器等不共享的数据，因此同一个进程下的线程上下文切换的开销要比进程小得多。

当服务器与客户端 TCP 完成连接后，通过 pthread_create() 函数创建线程，然后将「已连接 Socket」的文件描述符传递给线程函数，接着在线程里和客户端进行通信，从而达到并发处理的目的。

如果每来一个连接就创建一个线程，线程运行完后，还得操作系统还得销毁线程，虽说线程切换的上写文开销不大，但是如果频繁创建和销毁线程，系统开销也是不小的。

那么，我们可以使用线程池的方式来避免线程的频繁创建和销毁，所谓的线程池，就是提前创建若干个线程，这样当由新连接建立时，将这个已连接的 Socket 放入到一个队列里，然后线程池里的线程负责从队列中取出已连接 Socket 进程处理。

需要注意的是，这个队列是全局的，每个线程都会操作，为了避免多线程竞争，线程在操作这个队列前要加锁。

上面基于进程或者线程模型的，其实还是有问题的。新到来一个 TCP 连接，就需要分配一个进程或者线程，那么如果要达到 C10K，意味着要一台机器维护 1 万个连接，相当于要维护 1 万个进程/线程，操作系统肯定是扛不住的。

I/O 多路复用

既然为每个请求分配一个进程/线程的方式不能高效利用系统资源，那有没有可能只使用一个进程来维护多个 Socket 呢？答案是有的，那就是 I/O 多路复用技术。

一个进程虽然任一时刻只能处理一个请求，但是处理每个请求的事件时，耗时控制在 1 毫秒以内，这样 1 秒内就可以处理上千个请求，把时间拉长来看，多个请求复用了一个进程，这就是多路复用，这种思想很类似一个 CPU 并发多个进程，所以也叫做时分多路复用。

我们熟悉的 select/poll/epoll 就是内核提供应用程序多路复用的方式，进程可以通过一个系统调用函数从内核中获取多个事件。

select/poll/epoll 是如何获取网络事件的呢？在获取事件时，先把所有连接（文件描述符）传给内核，再由内核返回产生了事件的连接，然后在用户态中再处理这些连接对应的请求即可。

select/poll

select 实现多路复用的方式是，将已连接的 Socket 都放到一个文件描述符集合，然后调用 select 函数将文件描述符集合拷贝到内核里，让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的 Socket，然后再对其处理。

// 进程A执行伪代码:
int s = socket(AF INET,SOCK STREAMO);
bind(s, …);
listen(s, …);
....int fds[]= //存放需要监听的客户端socket;
&rset= //根据fds数组构建出的 bitmap;//读监听while(1){// bitmap 位置零FD_ZERO(&rset);for(i =0:i<20;i++){// 遍历集合，将对应的编号改为 1FD_SET(fds[i],&rset);}// 内核提供的封装，拷贝-> 标记 -> 拷贝select(max+1,&rset,NULL,NULL,NULL);for(i=0; i<20;i++){if(FD_ISSET(fds[i], &rset)){memset(buffer,0,MAXBUF);read(fds[i],buffer, MAXBUF);}}
}

所以，对于 select 这种方式，需要进行 2 次 遍历文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次 拷贝文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。

select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制， 默认最大值为 1024（系统定义个常量，当然如果重新编译内核的话，也可以修改改），只能监听 0~1023 的文件描述符。

poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。

但是 poll 和 select 并没有太大的本质区别，都是使用 线性结构 存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，使用这种方式，如果管理的 socket 文件描述符越多的时候，性能的损耗越严重。

epoll

epoll 通过两个方面，很好解决了 select/poll 的问题。

第一点，epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述字，把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里，红黑树是个高效的数据结构，增删查一般时间复杂度是 O(logn)，通过对这棵黑红树进行操作，这样就不需要像 select/poll 每次操作时都传入整个 socket 集合，只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。

第二点， epoll 使用事件驱动的机制，内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时，通过回调函数内核会将其加入到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的文件描述符的个数，不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测的效率。

从下图你可以看到 epoll 相关的接口作用：

// 创建一个 epoll， 监听 10 个fd
int epfd = epoll_create(10);
...
...struct epoll event events[5];
for(i=0; i<5;i++){static struct epoll_event ev;memset(&client,0,sizeof(client));addrlen = sizeof(client);ev.data.fd=accept(sockfd,(struct sockaddr*)&client,&addrlen);ev.events=EPOLLIN;epoll_ctl(epfd,EPOLL_CTL_ADD,ev.data.fd,&ev);
}
while(1){prints("round again");nfds=epoll_wait(epfd,events,5,10000);for(i=0; i

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！