2X岁，是学生です

0%

网络编程

发表于 更新于 分类于
本文字数： 6.3k 阅读时长 ≈ 6 分钟

网络编程常见四种调用方式：

同步/异步主要针对client端。

同步(Sync)

所谓同步，就是在client端发出一个功能调用后，在没有得到结果之前，该调用就不返回。也就是必须一件一件事做,等前一件做完了才能做下一件事。

例：普通B/S模式(同步)：提交请求->等待服务器处理->处理完毕返回。这个期间客户端浏览器不能干任何事。

异步(Async)

异步的概念和同步相对。当client端一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者。
例：ajax请求(异步): 请求通过事件触发->服务器处理(这时浏览器仍然可以处理其他事务)->处理完毕

阻塞/非阻塞主要针对server端

阻塞(Block)

阻塞调用是指在当前线程的调用结果返回前，该线程会被挂起(线程进入非可执行状态，在这个状态下，CPU不会给线程分配时间片，即线程暂停运行)。函数只有在得到结果之后才返回。

非阻塞(Unblock)

非阻塞和阻塞的概念相对应，指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回。

总结

  • 同步IO和异步IO的区别就在于：数据拷贝的时候进程是否阻塞

  • 阻塞IO和非阻塞IO的区别就在于：应用程序的调用是否立即返回

阻塞和非阻塞是指当进程访问的数据如果尚未就绪,进程是否需要等待,简单说这相当于函数内部的实现区别,也就是未就绪时是直接返回还是等待就绪;

同步和异步是指访问数据的机制；同步一般指主动请求并等待I/O操作完毕的方式,当数据就绪后在读写的时候必须阻塞(区别就绪与读写二个阶段,同步的读写必须阻塞)。异步则指主动请求数据后便可以继续处理其它任务,随后等待I/O操作完毕的通知,这可以使进程在数据读写时也不阻塞。(等待“通知”)

I/O 模型

一个输入操作通常包括两个阶段：

  • 等待数据准备好
  • 从内核向进程复制数据

对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所等待数据到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用进程缓冲区。

Unix五种 I/O 模型：
同步：

  • 阻塞式 I/O
  • 非阻塞式 I/O
  • I/O 复用（select 和 poll）
  • 信号驱动式 I/O（SIGIO）

异步：

  • 异步 I/O（AIO）

阻塞式 I/O

应用进程会一直被阻塞，直到数据从内核缓冲区复制到应用进程缓冲区中才返回。

应该注意到，在阻塞的过程中，其它应用进程还可以执行，因此阻塞不意味着整个操作系统都被阻塞。因为其它应用进程还可以执行，所以不消耗 CPU 时间，这种模型的 CPU 利用率会比较高。

recvfrom() 函数用于接收 Socket 传来的数据，并复制到应用进程的缓冲区 buf 中。这里把 recvfrom() 当成系统调用。

在调用recv()/recvfrom()函数时，发生在内核中等待数据和复制数据的过程。

alt

当调用recv()函数时，系统首先查是否有准备好的数据。如果数据没有准备好，那么系统就处于等待状态。当数据准备好后，将数据从系统缓冲区复制到用户空间，然后该函数返回。在套接应用程序中，当调用recv()函数时，未必用户空间就已经存在数据，那么此时recv()函数就会处于等待状态。

优点：

  • 使用阻塞模式的套接字，开发网络程序比较简单，容易实现。
  • 当希望能够立即发送和接收数据，且处理的套接字数量比较少的情况下，使用阻塞模式来开发网络程序比较合适。

不足：

  • 在大量建立好的套接字线程之间进行通信时比较困难。
  • 当使用“生产者-消费者”模型开发网络程序时，为每个套接字都分别分配一个读线程、一个处理数据线程和一个用于同步的事件，那么这样无疑加大系统的开销。
  • 最大的缺点是当希望同时处理大量套接字时，将无从下手，其扩展性很差

非阻塞式I /O

非阻塞I/O通过进程反复调用I/O函数（多次系统调用，并马上返回）；在数据拷贝的过程中，进程是阻塞的。

应用进程执行系统调用之后，内核返回一个错误码。应用进程可以继续执行，但是需要不断的执行系统调用来获知 I/O 是否完成，这种方式称为轮询（polling）。

一个SOCKET接口设置为非阻塞即告诉内核：当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。此时I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间。

套接字创建时一般默认是阻塞的，因此需要通过调用 ioctlsocket() 或 fcntl() 函数设置为非阻塞。

alt

图中进程多次调用revc() 函数，在数据报未准备完毕时立即返回。

由于 CPU 要处理更多的系统调用，因此这种模型的 CPU 利用率比较低。

I/O 复用

使用 select 或者 poll 等待数据，并且可以等待多个套接字中的任何一个变为可读。这一过程会被阻塞，当某一个套接字可读时返回，之后再使用 recvfrom 把数据从内核复制到进程中。

这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。

它可以让单个进程具有处理多个 I/O 事件的能力。又被称为 Event Driven I/O，即事件驱动 I/O。

如果一个 Web 服务器没有 I/O 复用，那么每一个 Socket 连接都需要创建一个线程去处理。如果同时有几万个连接，那么就需要创建相同数量的线程。相比于多进程和多线程技术，I/O 复用不需要进程线程创建和切换的开销，系统开销更小。

alt

信号驱动 I/O

应用进程使用 sigaction 系统调用，内核立即返回，应用进程可以继续执行，也就是说等待数据阶段应用进程是非阻塞的。内核在数据到达时向应用进程发送 SIGIO 信号，应用进程收到之后在信号处理程序中调用 recvfrom 将数据从内核复制到应用进程中。

相比于非阻塞式 I/O 的轮询方式，信号驱动 I/O 的 CPU 利用率更高。

alt

异步I/O

数据拷贝的时候进程无需阻塞。

应用进程执行 aio_read 系统调用会立即返回，应用进程可以继续执行，不会被阻塞，内核会在所有操作完成之后向应用进程发送信号。

异步 I/O 与信号驱动 I/O 的区别在于，异步 I/O 的信号是通知应用进程 I/O 完成，而信号驱动 I/O 的信号是通知应用进程可以开始 I/O。

当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者的输入输出操作

alt

同步IO引起进程阻塞，直至IO操作完成。异步IO不会引起进程阻塞。IO复用是先通过select调用阻塞。

I/O 模型比较

alt

  • 同步 I/O：将数据从内核缓冲区复制到应用进程缓冲区的阶段（第二阶段），应用进程会阻塞。
  • 异步 I/O：第二阶段应用进程不会阻塞。

同步 I/O 包括阻塞式 I/O、非阻塞式 I/O、I/O 复用和信号驱动 I/O ，它们的主要区别在第一个阶段。

非阻塞式 I/O 、信号驱动 I/O 和异步 I/O 在第一阶段不会阻塞。

I/O 复用

select/poll/epoll 都是 I/O 多路复用的具体实现，select 出现的最早，之后是 poll，再是 epoll。

select

1
int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

select 允许应用程序监视一组文件描述符，等待一个或者多个描述符成为就绪状态，从而完成 I/O 操作。本质上是通过设置或者检查存放 fd 标志位的数据结构来进行下一步处理。

  • fd_set 使用数组实现，数组大小使用 FD_SETSIZE 定义，所以只能监听少于 FD_SETSIZE 数量的描述符。有三种类型的描述符：readset、writeset、exceptset，分别对应读、写、异常条件的描述符集合。

  • timeout 为超时参数，调用 select 会一直阻塞直到有描述符的事件到达或者等待的时间超过 timeout。

  • 成功调用返回结果大于 0，出错返回结果为 -1，超时返回结果为 0。

由于是通过检查 fd 标志位，可能带来以下缺点：

  • 单个进程可监视的fd数量被限制，即能监听端口的大小有限。与系统内存有关，32位机默认是1024个，64位机默认是2048。

  • 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低。当套接字比较多的时候，每次select()不管哪个Socket是活跃的,都遍历一遍，浪费CPU时间。

  • 需要维护一个用来存放大量 fd 的数据结构，使得用户空间和内核空间在传递该结构时复制开销变大。

poll

1
int poll(struct pollfd *fds, unsigned int nfds, int timeout);

poll 中的描述符是 pollfd 类型的数组，pollfd 的定义如下：

1
2
3
4
5
struct pollfd {
    int fd;         /* file descriptor */
    short events;     /* requested events */
    short revents;    /* returned events */
    };

poll 的功能与 select 类似，也是等待一组描述符中的一个成为就绪状态。

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

由于采用链表存储，因此没有最大连接数的限制，但有以下缺点：

  • 大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
  • poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

select 与 poll 比较

1. 功能

  • select 会修改描述符，而 poll 不会；
  • select 的描述符类型使用数组实现，FD_SETSIZE 大小默认为 1024，因此默认只能监听少于 1024 个描述符。如果要监听更多描述符的话，需要修改 FD_SETSIZE 之后重新编译；而 poll 没有描述符数量的限制；
  • poll 提供了更多的事件类型，并且对描述符的重复利用上比 select 高。
  • 如果一个线程对某个描述符调用了 select 或者 poll，另一个线程关闭了该描述符，会导致调用结果不确定。

2. 速度

select 和 poll 速度都比较慢，每次调用都需要将全部描述符从应用进程缓冲区复制到内核缓冲区。

3. 可移植性

几乎所有的系统都支持 select，但是只有比较新的系统支持 poll。

epoll

1
2
3
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理，进程调用 epoll_wait() 便可以得到事件完成的描述符。

从上面的描述可以看出，epoll 只需要将描述符从进程缓冲区向内核缓冲区拷贝一次，并且进程不需要通过轮询来获得事件完成的描述符。

epoll 仅适用于 Linux OS。

epoll 比 select 和 poll 更加灵活而且没有描述符数量限制。

epoll 对多线程编程更有友好，一个线程调用了 epoll_wait() 另一个线程关闭了同一个描述符也不会产生像 select 和 poll 的不确定情况。

工作模式

epoll 的描述符事件有两种触发模式：LT（水平触发，level trigger）和 ET（边缘触发，edge trigger）。

1. LT 模式（默认工作模式）

当 epoll_wait() 检测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该事件，下次调用 epoll_wait() 会再次通知进程。是默认的一种模式，并且同时支持 Blocking 和 No-Blocking。

即只要 fd 处于可读或可写状态，就会通知用户。

2. ET 模式（高速工作模式）

和 LT 模式不同的是，通知之后进程必须立即处理事件，下次再调用 epoll_wait() 时不会再得到事件到达的通知。

很大程度上减少了 epoll 事件被重复触发的次数，因此效率要比 LT 模式高。只支持 No-Blocking，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

即 ET 只有不可读变为可读，或不可写变为可写之时，才会通知用户。因此 ET 对系统的调用比 LT 要少得多，所以 ET 是高速工作模式，效率高很多。

I/O 复用三种具体实现：select、poll 和 epoll 的区别总结：

1. 支持一个进程所能打开的最大连接数

类型 特点
select 单个进程所能打开的最大连接数由FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是 $32 \times 32$，同理 64 位机器上FD_SETSIZE为 $32 \times 64$ ）；可以对进行修改，然后重新编译内核，但是性能可能会受到影响。
poll 没有最大连接数的限制，原因是它是基于链表来存储的。
epoll 连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接。

2. FD(描述符)剧增后带来的I/O效率问题

类型 特点
select 每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。
poll 存在与 select 相同的问题。
epoll 因为 epoll 内核中是根据每个 fd 上的 callback() 函数实现的，只有活跃的 socket 才会主动调用 callback，所以在活跃 socket 较少的情况下，使用 epoll 没有线性下降的性能问题；但是所有socket都很活跃的情况下，可能会有性能问题。

3. 消息传递方式

类型 特点
select 内核需要将消息传递到用户空间，都需要内核拷贝动作。
poll 存在与 select 相同的问题。
epoll epoll通过内核和用户空间共享一块内存实现。

应用场景

1. select 应用场景

select 的 timeout 参数精度为微秒，而 poll 和 epoll 为毫秒，因此 select 更加适用于实时性要求比较高的场景，比如核反应堆的控制。

select 可移植性更好，几乎被所有主流平台所支持。

2. poll 应用场景

poll 没有最大描述符数量的限制，如果平台支持并且对实时性要求不高，应该使用 poll 而不是 select。

3. epoll 应用场景

只需要运行在 Linux 平台上，有大量的描述符需要同时轮询，并且这些连接最好是长连接。

需要同时监控小于 1000 个描述符，就没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势。

需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且 epoll 的描述符存储在内核，不容易调试。

参考资料

CS-Notes
socket阻塞与非阻塞，同步与异步、I/O模型