服务端高性能网络IO编程模型简析
多数网络应用可以分为客户端(client)和服务器端(server)模型,然后中间通过各种定义的协议来进行两端的通信。
比如常用的 Nginx 软件。可以把它当做一个 web 服务器。我们可以在 web 浏览器(客户端)与 Nginx 进行通信。
我们常说 Nginx 的并发服务很高,指的就是通过客户端访问服务端的用户很多,并发用户多,Nginx 服务器还能很好的进行服务。
客户端与服务端的通信涉及各种通信协议。大家最熟悉的通信协议就是 TCP/IP。根据 TCP/IP 通信服务模型如下:
上面图中的应用层协议有很多,比如最常见的就是 http 协议。
TCP/IP 协议是一个很复杂的协议,前面文章有讲这个tcp协议。这里主要不是讲tcp协议内容,而是讲 TCP 套接字接口编程-socket。
应用层:就是接收网络数据,处理网络数据,然后返回数据给用户。比如 Nginx web 服务器就是在这一层。
数据怎么组织客户端才能识别出来呢?这就要用到协议了,这一层最有名的协议就是 HTTP 应用协议。
TCP/IP 协议是一个很复杂的协议,那在编程中怎么简化它来进行网络编程呢?
套接字 socket 网络编程 API 是起源于 BSD 操作系统。
BSD 操作系统为应用程序提供的套接字(socket) API:
建立一个TCP连接的3次握手:
1.服务器准备好接收外来连接,通过调用 socket,bind,listen 函数来完成。
2.客户端可以通过connect进行主动打开连接。客户端发起一个 tcp 的 SYN(SYN J)。
3.服务器确认客户的的 SYN,同时服务器也发送一个 SYN(SYN K) 和对客户 SYN 的 确认 ACK(ACK J + 1)。
4.客户端发送一个 ACK(ACK K + 1) 确认服务端的 SYN。
网络数据处理流程简图:
上面是从数据的流动方向来看待数据处理过程。
如果从用户空间的数据到内核空间的数据,IO模型来看,数据传递方式有 5 种IO模型,见这篇文章:5种IO模型。
上面图片显示的是一个用户访问 web 应用服务器的数据流方向。如果是多个用户访问,成百上千的用户访问,服务端怎么处理这么多用户呢?
web 服务器会不会崩溃?
下面就来看看多用户的服务器端处理模型。
上面说到成百上千的用户访问 web 服务器,从服务端编程角度来说,就涉及到了服务端并发编程,服务器端怎么处理这么多用户访问呢?
一种方法就是为每个客户端用户创建一个独立的处理流程,这就是并发程序。常见的并发编程有三种,多进程,多线程,最后一个 I/O 多路复用。
客户端的每一个用户访问服务端产生的连接,就起一个线程/进程来进行服务处理(如上图)。
如果用户数过多,并发数就会很大,那么所创建的线程/进程也会很多,服务端系统资源可能会耗光。
还有服务端的read,accept等函数基本用法都是阻塞的,从5种IO模型也可以看出来。
从上面第二小节可以得知,一般的服务端网络编程步骤,socket,bind,listen,accept,read,write,close,这几个
步骤。首先,有这么多步骤,可不可以分步骤来处理,当然是可以的。再次,换一种理解方法,把这些步骤看成是一次处理事件(Event),
accept 接收socket描述符事件,read、write 分别是读事件、写事件。如果我们把 accept 接收的socket描述符存放在一个列表中,
只要知道在列表中的socket描述符准备好了读、写事件,那么我们就可以去进行读和写操作了。这就是IO多路复用最基本的由来。
操作系统准备了3个IO多路复用的函数:select,poll,epoll。最常用的是 epoll。
epoll 是对 select 和poll 的改进:
- 不需要每次向内核传入文件socket文件描述符,内核自己保存了一份
- 不像poll通过轮询的方式来找出就绪的文件描述符,而是通过异步IO事件来通知用户
- 内核会通过 IO 事件告诉用户就绪的文件描述符
有人把这种模式叫做 Reactor 模式,也叫事件分发(event dispatch)模式。
java.util.concurrent 包的作者 Doug Lea 有一篇分析与构建可伸缩的高性能 IO 服务的一篇经典文章:《Scalable IO in Java》。虽然是 java 描述,但是编程思想是相通的。
这篇文章中总结了一般的网络服务或分布式服务等应用程序中,大都具备的一些相同处理流程:
Read Request,读取请求数据
Decode request,解码请求数据
Process service,对数据进行加工处理
Encode reply,对返回数据进行编码
Send reply,发送返回数据
在实际应用中,每一步的运行效率都是不同的。
一般的网络服务中会为每一个连接开启一个新的线程、进程,如下图:
(来自《Scalable IO in Java》作者:Doug Lea)
上面这种模式有个缺点就是如果用户成百上千,那么系统资源会逐渐耗尽。那怎么才能构建高性能可伸缩的IO服务。作者列了几点希望达成的目标:
在海量负载连接情况下能够优雅降级
能够随着硬件资源的增加,应用性能能随着持续改进
具备低延时、高吞吐量、可调节的服务治理
基于事件驱动的架构设计通常比其他架构设计模型更加的有效率,可以节省一定的资源,事件驱动模式不需要为每一个客户端建立一个线程,这意味着更少的资源开销、上下文切换等。但事件任务调度可能会慢一些,通常实现复杂度也会增加。相关功能可以分解成非阻塞操作,但不可能把所有阻塞消除。
由于是时间驱动,所以需要跟踪事件任务相关的状态,知道在什么时候会发生事件,就可以进行相应的处理。
分发模式几个机制:
- 将一个完整的处理过程分解为一个一个小的任务或事件来处理
- 每个任务执行相关的动作而且不产生阻塞
- 在任务执行状态触发时才会执行,比如只有有数据时才会触发读操作
在服务器网络开发中,多数处理的是 IO 事件,当某个 IO 事件准备就绪时,然后触发某时间的操作。
(来自《Scalable IO in Java》作者:Doug Lea)
Reactor 也可以称为反应器模式:
1.Reactor模式中会通过分配适当的handler(处理程序)来响应IO事件
2.每个handler执行非阻塞的操作
3.通过将handler绑定到事件进行管理
下图展示的就是单线程下基本的Reactor设计模式
单 Reactor 单线程模式 (来自《Scalable IO in Java》作者:Doug Lea)
在多处理器常见下,为了实现服务器更高性能可以采用多线程模式:
- 增加 worker 线程,专门处理非 IO 操作
- 拆分并增加反应器 Reactor 线程,一方面在压力较大时可以饱和处理 IO 操作,提高处理能力。另外多个 Reactor 线程也可以做负载均衡使用。线程的数量可以根据程序本身是 CPU 密集型还是 IO 密集型操作来进行合理的分配
单 Reactor 多线程模式 (来自《Scalable IO in Java》作者:Doug Lea)
当然还有一个 Proactor 模式,它是异步 IO 相关。
前面文章 5种IO模型,异步 IO 模型有关。
Proactor 在时间发生时基于异步 IO 完成读写操作(由内核完成),等待 IO 完成后才返回到应用程序进行逻辑的处理。而 Reactor 通知读写事件是在应用程序中完成的。