CS-Notes/docs/notes/Socket.md

329 lines
13 KiB
Java
Raw Normal View History

2019-04-21 10:36:08 +08:00
<!-- GFM-TOC -->
2019-03-27 20:57:37 +08:00
* [I/O 模型](#一io-模型)
* [阻塞式 I/O](#阻塞式-io)
* [非阻塞式 I/O](#非阻塞式-io)
* [I/O 复用](#io-复用)
* [信号驱动 I/O](#信号驱动-io)
* [异步 I/O](#异步-io)
* [五大 I/O 模型比较](#五大-io-模型比较)
* [I/O 复用](#二io-复用)
* [select](#select)
* [poll](#poll)
* [比较](#比较)
* [epoll](#epoll)
* [工作模式](#工作模式)
* [应用场景](#应用场景)
* [参考资料](#参考资料)
2019-04-21 10:36:08 +08:00
<!-- GFM-TOC -->
2019-03-27 20:57:37 +08:00
# I/O 模型
2018-05-27 14:29:16 +08:00
一个输入操作通常包括两个阶段
2019-03-27 20:57:37 +08:00
- 等待数据准备好
- 从内核向进程复制数据
2018-05-27 14:29:16 +08:00
2018-08-28 21:52:21 +08:00
对于一个套接字上的输入操作第一步通常涉及等待数据从网络中到达当所等待数据到达时它被复制到内核中的某个缓冲区第二步就是把数据从内核缓冲区复制到应用进程缓冲区
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
Unix 有五种 I/O 模型
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
- 阻塞式 I/O
- 非阻塞式 I/O
- I/O 复用select poll
- 信号驱动式 I/OSIGIO
- 异步 I/OAIO
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## 阻塞式 I/O
2018-05-27 14:29:16 +08:00
2019-02-24 12:11:47 +08:00
应用进程被阻塞直到数据从内核缓冲区复制到应用进程缓冲区中才返回
2018-05-27 14:29:16 +08:00
2019-05-06 00:13:45 +08:00
应该注意到在阻塞的过程中其它应用进程还可以执行因此阻塞不意味着整个操作系统都被阻塞因为其它应用进程还可以执行所以不消耗 CPU 时间这种模型的 CPU 利用率会比较高
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
下图中recvfrom() 用于接收 Socket 传来的数据并复制到应用进程的缓冲区 buf 这里把 recvfrom() 当成系统调用
2018-05-27 14:29:16 +08:00
```c
2019-03-27 20:57:37 +08:00
ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);
2018-05-27 14:29:16 +08:00
```
2019-04-25 18:43:33 +08:00
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/1492928416812_4.png"/> </div><br>
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## 非阻塞式 I/O
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
应用进程执行系统调用之后内核返回一个错误码应用进程可以继续执行但是需要不断的执行系统调用来获知 I/O 是否完成这种方式称为轮询polling
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
由于 CPU 要处理更多的系统调用因此这种模型的 CPU 利用率比较低
2018-05-27 14:29:16 +08:00
2019-04-25 18:43:33 +08:00
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/1492929000361_5.png"/> </div><br>
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## I/O 复用
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
使用 select 或者 poll 等待数据并且可以等待多个套接字中的任何一个变为可读这一过程会被阻塞当某一个套接字可读时返回之后再使用 recvfrom 把数据从内核复制到进程中
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
它可以让单个进程具有处理多个 I/O 事件的能力又被称为 Event Driven I/O即事件驱动 I/O
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
如果一个 Web 服务器没有 I/O 复用那么每一个 Socket 连接都需要创建一个线程去处理如果同时有几万个连接那么就需要创建相同数量的线程相比于多进程和多线程技术I/O 复用不需要进程线程创建和切换的开销系统开销更小
2018-05-27 14:29:16 +08:00
2019-04-25 18:43:33 +08:00
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/1492929444818_6.png"/> </div><br>
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## 信号驱动 I/O
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
应用进程使用 sigaction 系统调用内核立即返回应用进程可以继续执行也就是说等待数据阶段应用进程是非阻塞的内核在数据到达时向应用进程发送 SIGIO 信号应用进程收到之后在信号处理程序中调用 recvfrom 将数据从内核复制到应用进程中
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
相比于非阻塞式 I/O 的轮询方式信号驱动 I/O CPU 利用率更高
2018-05-27 14:29:16 +08:00
2019-04-25 18:43:33 +08:00
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/1492929553651_7.png"/> </div><br>
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## 异步 I/O
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
应用进程执行 aio_read 系统调用会立即返回应用进程可以继续执行不会被阻塞内核会在所有操作完成之后向应用进程发送信号
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
异步 I/O 与信号驱动 I/O 的区别在于异步 I/O 的信号是通知应用进程 I/O 完成而信号驱动 I/O 的信号是通知应用进程可以开始 I/O
2018-05-27 14:29:16 +08:00
2019-04-25 18:43:33 +08:00
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/1492930243286_8.png"/> </div><br>
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## 五大 I/O 模型比较
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
- 同步 I/O将数据从内核缓冲区复制到应用进程缓冲区的阶段应用进程会阻塞
- 异步 I/O不会阻塞
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
阻塞式 I/O非阻塞式 I/OI/O 复用和信号驱动 I/O 都是同步 I/O它们的主要区别在第一个阶段
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
非阻塞式 I/O 信号驱动 I/O 和异步 I/O 在第一阶段不会阻塞
2018-05-27 14:29:16 +08:00
2019-04-25 18:43:33 +08:00
<div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/1492928105791_3.png"/> </div><br>
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
# I/O 复用
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
select/poll/epoll 都是 I/O 多路复用的具体实现select 出现的最早之后是 poll再是 epoll
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## select
2018-05-27 14:29:16 +08:00
```c
2019-03-27 20:57:37 +08:00
int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
2018-05-27 14:29:16 +08:00
```
2019-03-27 20:57:37 +08:00
有三种类型的描述符类型readsetwritesetexceptset分别对应读异常条件的描述符集合fd_set 使用数组实现数组大小使用 FD_SETSIZE 定义
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
timeout 为超时参数调用 select 会一直阻塞直到有描述符的事件到达或者等待的时间超过 timeout
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
成功调用返回结果大于 0出错返回结果为 -1超时返回结果为 0
2018-05-27 14:29:16 +08:00
```c
2019-03-27 20:57:37 +08:00
fd_set fd_in, fd_out;
struct timeval tv;
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
// Reset the sets
FD_ZERO( &fd_in );
FD_ZERO( &fd_out );
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
// Monitor sock1 for input events
FD_SET( sock1, &fd_in );
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
// Monitor sock2 for output events
FD_SET( sock2, &fd_out );
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
// Find out which socket has the largest numeric value as select requires it
int largest_sock = sock1 > sock2 ? sock1 : sock2;
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
// Wait up to 10 seconds
tv.tv_sec = 10;
tv.tv_usec = 0;
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
// Call the select
int ret = select( largest_sock + 1, &fd_in, &fd_out, NULL, &tv );
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
// Check if select actually succeed
if ( ret == -1 )
// report error and abort
else if ( ret == 0 )
// timeout; no event detected
2018-05-27 14:29:16 +08:00
else
{
2019-03-27 20:57:37 +08:00
if ( FD_ISSET( sock1, &fd_in ) )
// input event on sock1
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
if ( FD_ISSET( sock2, &fd_out ) )
// output event on sock2
2018-05-27 14:29:16 +08:00
}
```
2019-03-27 20:57:37 +08:00
## poll
2018-05-27 14:29:16 +08:00
```c
2019-03-27 20:57:37 +08:00
int poll(struct pollfd *fds, unsigned int nfds, int timeout);
2018-05-27 14:29:16 +08:00
```
2019-03-27 20:57:37 +08:00
pollfd 使用链表实现
2018-05-27 14:29:16 +08:00
```c
2019-03-27 20:57:37 +08:00
// The structure for two events
struct pollfd fds[2];
// Monitor sock1 for input
fds[0].fd = sock1;
fds[0].events = POLLIN;
// Monitor sock2 for output
fds[1].fd = sock2;
fds[1].events = POLLOUT;
// Wait 10 seconds
int ret = poll( &fds, 2, 10000 );
// Check if poll actually succeed
if ( ret == -1 )
// report error and abort
else if ( ret == 0 )
// timeout; no event detected
2018-05-27 14:29:16 +08:00
else
{
2019-03-27 20:57:37 +08:00
// If we detect the event, zero it out so we can reuse the structure
if ( fds[0].revents & POLLIN )
fds[0].revents = 0;
// input event on sock1
if ( fds[1].revents & POLLOUT )
fds[1].revents = 0;
// output event on sock2
2018-05-27 14:29:16 +08:00
}
```
2019-03-27 20:57:37 +08:00
## 比较
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
### 1. 功能
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
select poll 的功能基本相同不过在一些实现细节上有所不同
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
- select 会修改描述符 poll 不会
- select 的描述符类型使用数组实现FD_SETSIZE 大小默认为 1024因此默认只能监听 1024 个描述符如果要监听更多描述符的话需要修改 FD_SETSIZE 之后重新编译 poll 的描述符类型使用链表实现没有描述符数量的限制
- poll 提供了更多的事件类型并且对描述符的重复利用上比 select
- 如果一个线程对某个描述符调用了 select 或者 poll另一个线程关闭了该描述符会导致调用结果不确定
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
### 2. 速度
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
select poll 速度都比较慢
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
- select poll 每次调用都需要将全部描述符从应用进程缓冲区复制到内核缓冲区
- select poll 的返回结果中没有声明哪些描述符已经准备好所以如果返回值大于 0 应用进程都需要使用轮询的方式来找到 I/O 完成的描述符
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
### 3. 可移植性
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
几乎所有的系统都支持 select但是只有比较新的系统支持 poll
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
## epoll
2018-05-27 14:29:16 +08:00
```c
2019-03-27 20:57:37 +08:00
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);
2018-05-27 14:29:16 +08:00
```
2019-03-27 20:57:37 +08:00
epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态已注册的描述符在内核中会被维护在一棵红黑树上通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理进程调用 epoll_wait() 便可以得到事件完成的描述符
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
从上面的描述可以看出epoll 只需要将描述符从进程缓冲区向内核缓冲区拷贝一次并且进程不需要通过轮询来获得事件完成的描述符
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
epoll 仅适用于 Linux OS
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
epoll select poll 更加灵活而且没有描述符数量限制
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
epoll 对多线程编程更有友好一个线程调用了 epoll_wait() 另一个线程关闭了同一个描述符也不会产生像 select poll 的不确定情况
2018-05-27 14:29:16 +08:00
```c
2019-03-27 20:57:37 +08:00
// Create the epoll descriptor. Only one is needed per app, and is used to monitor all sockets.
// The function argument is ignored (it was not before, but now it is), so put your favorite number here
int pollingfd = epoll_create( 0xCAFE );
if ( pollingfd < 0 )
// report error
// Initialize the epoll structure in case more members are added in future
struct epoll_event ev = { 0 };
// Associate the connection class instance with the event. You can associate anything
// you want, epoll does not use this information. We store a connection class pointer, pConnection1
ev.data.ptr = pConnection1;
// Monitor for input, and do not automatically rearm the descriptor after the event
ev.events = EPOLLIN | EPOLLONESHOT;
// Add the descriptor into the monitoring list. We can do it even if another thread is
// waiting in epoll_wait - the descriptor will be properly added
if ( epoll_ctl( epollfd, EPOLL_CTL_ADD, pConnection1->getSocket(), &ev ) != 0 )
// report error
// Wait for up to 20 events (assuming we have added maybe 200 sockets before that it may happen)
struct epoll_event pevents[ 20 ];
// Wait for 10 seconds, and retrieve less than 20 epoll_event and store them into epoll_event array
int ready = epoll_wait( pollingfd, pevents, 20, 10000 );
// Check if epoll actually succeed
if ( ret == -1 )
// report error and abort
else if ( ret == 0 )
// timeout; no event detected
2018-05-27 14:29:16 +08:00
else
{
2019-03-27 20:57:37 +08:00
// Check if any events detected
for ( int i = 0; i < ret; i++ )
{
if ( pevents[i].events & EPOLLIN )
{
// Get back our connection pointer
Connection * c = (Connection*) pevents[i].data.ptr;
c->handleReadEvent();
}
}
2018-05-27 14:29:16 +08:00
}
```
2019-03-27 20:57:37 +08:00
## 工作模式
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
epoll 的描述符事件有两种触发模式LTlevel trigger ETedge trigger
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
### 1. LT 模式
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
epoll_wait() 检测到描述符事件到达时将此事件通知进程进程可以不立即处理该事件下次调用 epoll_wait() 会再次通知进程是默认的一种模式并且同时支持 Blocking No-Blocking
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
### 2. ET 模式
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
LT 模式不同的是通知之后进程必须立即处理事件下次再调用 epoll_wait() 时不会再得到事件到达的通知
2018-07-19 23:39:27 +08:00
2019-03-27 20:57:37 +08:00
很大程度上减少了 epoll 事件被重复触发的次数因此效率要比 LT 模式高只支持 No-Blocking以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
## 应用场景
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
很容易产生一种错觉认为只要用 epoll 就可以了select poll 都已经过时了其实它们都有各自的使用场景
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
### 1. select 应用场景
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
select timeout 参数精度为 1ns poll epoll 1ms因此 select 更加适用于实时性要求比较高的场景比如核反应堆的控制
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
select 可移植性更好几乎被所有主流平台所支持
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
### 2. poll 应用场景
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
poll 没有最大描述符数量的限制如果平台支持并且对实时性要求不高应该使用 poll 而不是 select
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
### 3. epoll 应用场景
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
只需要运行在 Linux 平台上有大量的描述符需要同时轮询并且这些连接最好是长连接
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
需要同时监控小于 1000 个描述符就没有必要使用 epoll因为这个应用场景下并不能体现 epoll 的优势
2018-09-08 10:14:41 +08:00
2019-03-27 20:57:37 +08:00
需要监控的描述符状态变化多而且都是非常短暂的也没有必要使用 epoll因为 epoll 中的所有描述符都存储在内核中造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用频繁系统调用降低效率并且 epoll 的描述符存储在内核不容易调试
2018-09-08 10:14:41 +08:00
2019-03-27 20:57:37 +08:00
# 参考资料
2018-05-27 14:29:16 +08:00
2019-03-27 20:57:37 +08:00
- Stevens W R, Fenner B, Rudoff A M. UNIX network programming[M]. Addison-Wesley Professional, 2004.
- [Boost application performance using asynchronous I/O](https://www.ibm.com/developerworks/linux/library/l-async/)
- [Synchronous and Asynchronous I/O](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx)
- [Linux IO 模式及 selectpollepoll 详解](https://segmentfault.com/a/1190000003063859)
- [poll vs select vs event-based](https://daniel.haxx.se/docs/poll-vs-select.html)
- [select / poll / epoll: practical difference for system architects](http://www.ulduzsoft.com/2014/01/select-poll-epoll-practical-difference-for-system-architects/)
- [Browse the source code of userspace/glibc/sysdeps/unix/sysv/linux/ online](https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/)
2019-06-09 22:32:10 +08:00
<img width="580px" src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/other/公众号海报1.png"></img>