低代码：现在我怎么样了

**2023 年 3 月 23 日，GitHub 官方发布了一条公告，称他们的 RSA SSH Host Key 受到了泄露。这一消息引起了广泛的关注和担忧，因为 RSA SSH Host Key 是保障 SSH 连接安全的关键。在本文中，我们将深入探讨这一事件的起因、影响和应对措施。**



## RSA SSH Host Key 是什么以及其在 GitHub 上的作用

RSA SSH Host Key 通过使用公钥/私钥对来实现身份验证。当客户端首次连接到 SSH 服务器时，服务器会将其 RSA SSH Host Key 发送给客户端，客户端使用该公钥对该 RSA SSH Host Key 进行验证。如果验证成功，客户端将 RSA SSH Host Key 添加到其本地的“known_hosts”文件中，并将来连接到该服务器时使用该 RSA SSH Host Key 进行身份验证。

区别于本地的公钥/私钥，RSA SSH Host Key 用于验证 SSH 服务器的身份，而公钥/私钥对用于验证客户端的身份，有点像双向校验，可以有效的防止中间人攻击。

## 事件发生的时间和经过

Github官方发现RSA SSH Host Key 私钥在一个公共 GitHub 存储库中短暂地公开了。他们立即采取行动控制暴露，并开始调查，以了解根本原因和影响。

在3月24日世界时大约05:00时，出于谨慎，官方更换了用于保护 [GitHub.com](http://GitHub.com) 的 Git 操作的 RSA SSH 主机密钥。这样做是为了保护用户免受任何对手模仿 GitHub 或通过 SSH 窃听他们的 Git 操作的机会。此密钥不授予对 GitHub 基础设施或客户数据的访问权限。此更改仅影响通过使用 RSA 的 SSH 进行的 Git 操作。

## 可能对GitHub 用户带来的风险

一旦RSA SSH Host Key泄露，攻击者就有可能冒充GitHub服务器，获取用户的敏感信息，进而危及用户的代码和账户的安全。以下是可能对开发者和GitHub用户带来的风险：

1. 篡改代码：攻击者可能会利用RSA SSH Host Key的泄露，篡改开发者的代码，使得开发者提交的代码被修改或者添加恶意代码，从而导致开发者在不知情的情况下发布了不安全的代码。
2. 窃取敏感信息：攻击者可能会利用RSA SSH Host Key的泄露，窃取开发者和GitHub用户的敏感信息，如用户名、密码、SSH私钥等。一旦敏感信息泄露，攻击者可能会利用这些信息进行恶意操作，如篡改代码、冒充用户进行恶意访问等。
3. 拒绝服务攻击：攻击者可能会利用RSA SSH Host Key的泄露，进行拒绝服务攻击，使得GitHub服务器无法正常运行，影响开发者和用户的正常使用。

总之RSA SSH Host Key泄露可能会对开发者和GitHub用户带来严重的安全风险。

官方是这样回复的：请注意，这个问题不是任何 GitHub 系统或客户信息泄露的结果。相反，这次曝光是我们认为是无意中泄露了私人信息的结果。我们没有理由相信暴露的钥匙被滥用，并采取了这一行动出于充分的谨慎。

**并且官方已经更换了RSA SSH Host Key，这将会导致我们的clone、push、pull等操作无法正常运行。**

## 应对措施

Github官方修改SSH Host Key 以后，会导致用户无法使用SSH连接[GitHub.com](http://GitHub.com)，

如果在通过 SSH 连接到 [GitHub.com](http://GitHub.com) 时看到以下消息，请继续阅读

```
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Host key for github.com has changed and you have requested strict checking.
Host key verification failed.
```

在终端中运行以下命令：

```bash
# 删除known_hosts文件中github.com条目，从而使下一次连接 github.com 时，客户端会重新验证 github.com 的 RSA SSH Host Key，以确保安全连接
ssh-keygen -R github.com
# 更新本地 SSH 客户端的 known_hosts 文件，以确保在使用 SSH 连接到 GitHub 时，能够正确地验证 GitHub 的身份，并保证连接的安全性
curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts
```

接着就可以愉快的往Github上面拉取、提交代码了。

## 参考

****[We updated our RSA SSH host key](https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/)****

Github RSA SSH Host Key 泄露事件详解

**当今，软件开发的速度和效率已经成为企业发展的重要因素之一。然而，传统的软件开发流程通常需要大量的时间和资源来完成。因此，很多企业开始转向low-code平台，以提高软件开发的效率和速度。阿里的`lowcode-engine`是其中的一款优秀平台，它为用户提供了一个基于云的可视化编程环境，使得用户可以通过简单的拖放操作，快速地创建出高质量的应用程序。**



## 什么是低代码？

零代码、低代码的概念在整个全球行业内已经流行了很长一段时间。通常意义上的低代码定义会有三个关键点：

1. 一个用于生产软件的可视化编辑器
2. 中间包含了一些用于组装的物料，可以通过编排、组合和配置它们以生成丰富的功能或表现
3. 最后的实施结果是成本降低

**注：低代码不是银弹，它往往是某个具体层面的解决方案**

## 如何开发一个低代码平台？

从零开发一个低代码的平台，需要考虑到很多事项：

- 平台的架构设计：低代码平台需要一个灵活、可扩展、高可用性的架构，能够支持不同的应用场景和不同的开发人员，同时保证数据安全和用户隐私
- 可视化编辑器的设计：低代码平台的核心功能是可视化编辑器，它需要具备良好的用户体验和易用性，能够支持拖拽式的界面设计和流程设计，同时能够生成高质量的代码和文档
- 集成第三方组件和服务：低代码平台需要能够集成各种第三方组件和服务，如数据库、API、消息队列、人工智能等，以便开发人员可以快速构建各种应用
- 自定义代码的扩展性：低代码平台需要支持开发人员在平台上自定义代码，以满足特定的业务需求和技术要求

当然考虑的不只仅仅上面这几点，一个成熟的低代码平台还需要考虑数据安全和用户隐私、运维和监控……，综上所述，构建一个低代码平台需要面对众多的难点，需要具备较高的技术实力和业务理解能力，如果你和我一样，不想从头开始去考虑这些复杂的事情，可以选择一个完备的低代码引擎，我选择的是 [alibaba/lowcode-engine](https://github.com/alibaba/lowcode-engine)，他的优势在于：

- 低代码设计器：包括入料、编排、组件配置、画布渲染等等
- 定制扩展能力：支持面板扩展、物料扩展、编排扩展、设置器扩展
- 提供基础物料、插件（数据源、JS面板、预览、出码等等）
- 提供CLI工具，快速创建物料、设置器、插件、编辑器扩展
- 高质量的中文文档

## lowcode-engine 优势

### 低代码设计器

`lowcode-engine`直接提供了画布渲染、组件编排、组件属性配置等功能

![image.png](https://blog.ccz.life/static/img/e3c9442d0c33f0d66a5b6989fa96531e.image.png)

### 定制扩展能力

面板 API 提供了面板扩展和管理的能力，如下图蓝色内容都是扩展出来的

![image.png](https://blog.ccz.life/static/img/99dc005775322e9141a8d3bbfb4f8bb3.image.png)

此外，也可以对物料扩展、编排扩展、设置器扩展、操作辅助区扩展

![image.png](https://blog.ccz.life/static/img/3534c1f5a17b9e5db630d531da63dc3d.image.png)

### 提供基础物料、插件

官方提供了`antd、fusion`低代码物料

![image.png](https://blog.ccz.life/static/img/37487476f42964fa2c92adebe4dc16ea.image.png)

提供了历史插件、源码面板、Schema编辑等功能

![image.png](https://blog.ccz.life/static/img/86aaba56f8a5d2238d49dd89eda70d10.image.png)

### 提供CLI工具

通过官方的`CLI`工具，快速创建扩展，下面举一个插件开发的例子：

```bash
npm init @alilc/element your-plugin-name
```

![image.png](https://blog.ccz.life/static/img/9529e7eccd1462fd9643bd214c309671.image.png)

根据操作完善信息

![image.png](https://blog.ccz.life/static/img/c6655349d6770ba88b88fcaf71b099e1.image.png)

### 高质量的中文文档

[文档地址](https://lowcode-engine.cn/site/docs/guide/quickStart/intro)


![image.png](https://blog.ccz.life/static/img/9c2c6c4317603a56f7d212d993e2d728.image.png)

## 渲染模块、出码模块

低代码引擎的编辑器将产出两份数据：

- 资产包数据 assets：包含物料名称、包名及其获取方式，对应协议中的[《低代码引擎资产包协议规范》](https://lowcode-engine.cn/site/docs/specs/assets-spec)
- 页面数据 schema：包含页面结构信息、生命周期和代码信息，对应协议中的[《低代码引擎搭建协议规范》](https://lowcode-engine.cn/site/docs/specs/lowcode-spec)

经过上述两份数据，可以直接交由渲染模块或者出码模块来运行，二者的区别在于：

- 渲染模块：使用资产包数据、页面数据和低代码运行时，并且允许维护者在低代码编辑器中用 `低代码（LowCode）`的方式继续维护；
- 出码模块：不依赖低代码运行时和页面数据，直接生成可直接运行的代码，并且允许维护者用 `源码（ProCode）` 的方式继续维护，但无法再利用低代码编辑器；

### **低代码的生产和消费流程总览**

![image.png](https://blog.ccz.life/static/img/40182787ffdf2c739154a1e54707cb73.image.png)

## 架构

### 分层架构

![image.png](https://blog.ccz.life/static/img/c52415eeaeed511a0c75aab32dda9a4a.image.png)
自下而上分别是协议 - 引擎 - 生态 - 平台

- 底层协议栈定义的是标准，标准的统一让上层产物的互通成为可能。
- 引擎是对协议的实现，同时通过能力的输出，向上支撑生态开放体系，提供各种生态扩展能力。
- 生态就好理解了，是基于引擎核心能力上扩展出来的，比如物料、设置器、插件等，还有工具链支撑开发体系。
- 最后，各个平台基于引擎内核以及生态中的产品组合、衔接形成满足其需求的低代码平台。

### **引擎内核简述**

![image.png](https://blog.ccz.life/static/img/89b01e504ebefa9b080007c07a275060.image.png)

低代码引擎分为 4 大模块，入料 - 编排 - 渲染 - 出码：

- 入料模块就是将外部的物料，比如海量的 npm 组件，按照《物料描述协议》进行描述。将描述后的数据通过引擎 API 注册后，在编辑器中使用。
- 编排，本质上来讲，就是不断在生成符合[《低代码引擎搭建协议规范》](https://lowcode-engine.cn/site/docs/specs/lowcode-spec)的页面描述，将编辑器中的所有物料，进行布局设置、组件 CRUD 操作、以及 JS / CSS 编写/ 逻辑编排 等，最终转换成页面描述，技术细节后文会展开。
- 渲染，顾名思义，就是将编排生成的页面描述结构渲染成视图的过程，视图是面向用户的，所以必须处理好内部数据流、生命周期、事件绑定、国际化等。
- 出码，就是将编排过程产生的符合[《低代码引擎搭建协议规范》](https://lowcode-engine.cn/site/docs/specs/lowcode-spec)的页面描述转换成另一种 DSL 或 编程语言代码的过程。

## 参考

[阿里低代码引擎简介](https://lowcode-engine.cn/site/docs/guide/quickStart/intro)

全面了解 Low Code 引擎之什么是低代码

**当我们踏入 2023 年之际，回顾 2022 年的所见所闻，让我不禁想起那句“岁月匆匆，时光荏苒”。在这个充满变化与挑战的一年里，我也经历了许多值得回顾和总结的事情。**




# 上半年：


## **工作：**

- 项目日常迭代 
- 项目改造 `微前端、MUI，后续项目被推翻`
- Vite 在项目中落地
- Node 日志服务落地
- 结构组织变更 `业务部门 ⇒  平台架构`

## **个人成长：**

- 团队内部分享：《孙子兵法》
- 微前端 `qiankun`
- MUI
- Vite学习
- Node：最佳规范学习、日志相关学习 `winston`
- 复习计划：基础知识、React Fiber深究、React 18 UI Concurrent Mode学习、Webpack、算法学习
- 书籍：《被讨厌的勇气》

## **总结：**

**有新技术的尝试，但是不多，好在有两项落地**

- 微前端、MUI
- Vite落地
- Node最佳规范学习
- Node日志服务落地
- 复习计划

上半年`币圈跌太狠，心态发生变化`

**技术⇒业务落地能力差**

Vite去年规划的落地，但是在落地过程中经常出现Vite因开发环境和生产环境构建工具链不一致产生的问题，即开发环境代码正常运行，生产环境代码运行出错。

个人产生疑虑：

①.怕上线前，某些模块测试不到位，引发线上bug

②.后续应用开发时也会出现开发环境可用，但是生产环境不可用

但其实这些问题都是可以通过自己解决的，还是`缺乏冒险者精神`**。**

后续可以落地，也是在组内同事的牵头下才得以完成。

**看书方面，自驱力太差**

明明安排好的时间，却都在刷短视频，`时间管理差`，一周只有两三个小时看书

好在读书的时候认真，吸收较多，但是得加多看书的时间

**结构组织变更**

影响较大，改变不了环境，只能改变自己了

# 下半年：

## **工作：**

- 项目日常迭代 
- 开放平台、开放平台后台页开发 `DNA改版新规划、微前端落地`
- 六路监控平台改造 `作为开发平台应用进行上架`

## **个人成长：**

- 团队内部分享：《印度种姓制度》
- 新建脚手架 `quick-vite-web`
- 微前端 `MicroApp、Wujie`
- CSS原子化 `Tailwindcss`
- MUI组件封装
- 前端 + 客户端 = 终端 认知
- 复习计划：上半年涉及到的知识重新梳理、React源码、Vue和React实现上的区别
- 书籍：《骆驼祥子》

## **总结：**

**没有后端方面的知识涉猎，前端知识方面也无建树**

- 新建脚手架
- 微前端
- MUI组件封装
- 复习计划

**项目管理方面太弱，需要提前学习相关知识，主动出击承担任务**

项目管控方面一直没有过多参与，一直是作为开发者的身份

开发者⇒项目管理者，需要注意的事项，如何处理好人际关系

自身能力的突破，得靠自己一步一步的积累

**UI组件封装没有做到位**

MUI组件本身更多的是为我们提供原子化的组件，细粒化程度非常高。我们需要像搭积木一样，将这些原子化的组件进行组装。

```jsx
//antd 
<Table columns={columns} dataSource={data} />

//mui 
<TableContainer component={Paper}>
      <Table>

        <TableHead>
          <TableRow>
          {columns.map((col)=>(
            <TableCell>
                   ......
              </TableCell>
            ))}
          </TableRow>
        </TableHead>

        <TableBody>
          {data.map((row) => (
            <TableRow>
              <TableCell>
                   ......
              </TableCell>
            </TableRow>
          ))}
        </TableBody>

      </Table>
    </TableContainer>
```

目标是将这一大串的Table相关组件，封装为<Table/>，前期进行封装的时候，也探讨过相关细节。

但是在最后使用的时候，总感觉不得劲，很多情况下需要往组件里面新增属性以应对新需求。

后续应该注意的点：

①.封装的组件，所有的Element都应该加class类名，不准使用style或者sx的方式修改样式

②.规划时，不应该将Table、Form这类组件定义为业务组件，如果有很复杂的Table组件，应该考虑使用基础组件组装的方式进行拼接。

定义为业务组件的劣势在与，UI、内部逻辑处理都会高度耦合，但实际上每套页面都会有自己的复杂度，有自己的相互逻辑，强行结合后，在其它页面进行使用，需要大费周章的修改样式。

和UI设计师也很难定义出一套可以通用的业务组件。

③.无非必要，不新增组件Props。现在我们是通过组装MUI的组件，去达到一个我们理想中的基础组件的效果。但MUI组件颗粒度非常细，譬如我现在分别要在`TableContainer、Table`上新增Props时，比较好的做法是

```jsx
<Table props={{
 TableProps:
 TableContainerProps:
}}>
```

使用MUI组件需要投入较大的精力，去做好组件的封装，要不然真的非常难，很难组件都需要自己去实现，比如Form、Upload、（Modal、Message Api方式调用）……

还是Antd做的更大更全而且还免费，拿上来可以直接开发项目，不过喜欢自己动手封装组件的话，MUI也是不错的选择。

**事情还是得多记多写，不能只停留于看**

年初看了几篇神文，但是当时仅仅是看，没有上手操作，一直没能懂文章封神的原因。

年尾再次阅读到，一步一步根据文章操作，才发现真是一步一步娓娓道来，使我眼前一亮，豁然开朗。而且这一两年，我发现自己看文章，仅仅停留于看，很少会上手操作，当时认为的懂，我觉得和实际上的懂，有着很大的差距。可能和近年来刷短视频有关系，短暂的知识碎片，并没有对我的大脑进行输入。

**终端认知**

此终端，非彼终端。

终端概念是我今年在D2圆桌之夜听到的，那何为终端，前端+客户端，那这和我们的大前端区别于哪里，为什么兴起终端呢？

说白了，我们可以把终端理解成一个岗位，以后没有前端开发工程师，也没有客户端开发工程师，

只有终端开发工程师，终端开发工程师具有处理前端和客户端的能力，那这样就意味着终端开发工程师相较于其他岗位，至少需要有更广的知识面。

那终端开发工程师的优势在哪里？

第一点当然是降本，2022年的互联网冬天比去年更冷，各大互联网巨头都在裁员降本，如果能将终端这条路实践走通，真正意义上的将两个岗位合并成一个岗位，是有利于公司降本。

第二点是提效，原先在会议上讨论这个业务需求是客户端做还是前端做，如果现在你属于一位终端开发工程师，那就不会有这样的争论。至于是选前端技术来做还是客户端技术来做，技术方案都由你这边敲定。原先因为工种不同的薄纱被掀开，你也会真正的站在一个开发者的角度去进行选型，而不是把时间浪费在无意义的争论上，可能因为这块业务没有绩效的增长点，你就会说这一块我们做不了，需要给你们做，你们更适合。

走通终端这条路，一定会遇到很多问题，两端的融合，不是一蹴而就的，是需要人才的积累加上实践的真知，如果走通，将大大提高入行门槛。可能是3年后，也可能是10年后，也可能是30年后

但我相信终端这条路是可以被实践走通的，打破两端壁垒，只是时间问题。

面对可能即将到来的风暴，加强自身的计算机基础会显得格外重要。

2022年自我总结

**Node.js是一个事件驱动、非阻塞I/O模型的JavaScript运行时环境，拥有高性能的I/O操作能力。其中，多路复用是Node.js实现高性能I/O操作的核心机制之一。它允许单个线程同时处理多个I/O请求，并在I/O完成时通知应用程序。在本文中，我们将深入探讨Node.js中的I/O多路复用机制，包括它的原理、实现方式、优势、适用场景。**



# 一段话讲清楚I/O多路复用

下面举一个例子，模拟一个tcp服务器处理30个客户socket。
假设你是一个老师，让30个学生解答一道题目，然后检查学生做的是否正确，你有下面几个选择：
1. 第一种选择：按顺序逐个检查，先检查A，然后是B，之后是C、D。。。这中间如果有一个学生卡主，全班都会被耽误。
这种模式就好比，你用循环挨个处理socket，根本不具有并发能力。
2. 第二种选择：你创建30个分身，每个分身检查一个学生的答案是否正确。 这种类似于为每一个用户创建一个进程或者线程处理连接。
3. 第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。
这种就是IO复用模型，Linux下的select、poll和epoll就是干这个的。将用户socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。
这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor模式。

# IO 多路复用实现机制
## 概念说明

IO 多路复用有三种实现，在介绍select、poll、epoll之前，首先介绍一下Linux操作系统中**基础的概念**：

- 用户空间和内核空间
- 进程切换
- 进程的阻塞
- 文件描述符
- 缓存 I/O

### 用户空间 / 内核空间

现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。
操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操作系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。

针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。

### 进程切换

为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的，并且进程切换是非常耗费资源的。

从一个进程的运行转到另一个进程上运行，这个过程中经过下面这些变化：

1. 保存处理机上下文，包括程序计数器和其他寄存器。
2. 更新PCB信息。
3. 把进程的PCB移入相应的队列，如就绪、在某事件阻塞等队列。
4. 选择另一个进程执行，并更新其PCB。
5. 更新内存管理的数据结构。
6. 恢复处理机上下文。

### 进程阻塞

正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得了CPU资源），才可能将其转为阻塞状态。当进程进入阻塞状态，是不占用CPU资源的。

### 文件描述符

文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。
文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

### 缓存I/O

缓存I/O又称为标准I/O，大多数文件系统的默认I/O操作都是缓存I/O。在Linux的缓存I/O机制中，操作系统会将I/O的数据缓存在文件系统的页缓存中，即数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。

**缓存 I/O 的缺点：**

数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作，这些数据拷贝操作所带来的 CPU 以及内存开销是非常大的。

## 什么是IO多路复用？

- IO 多路复用是一种同步IO模型，实现一个线程可以监视多个文件句柄；
- 一旦某个文件句柄就绪，就能够通知应用程序进行相应的读写操作；
- 没有文件句柄就绪就会阻塞应用程序，交出CPU。

> 多路是指网络连接，复用指的是同一个线程
> 

## 为什么有IO多路复用机制？

没有IO多路复用机制时，有BIO、NIO两种实现方式，但它们都有一些问题

### 同步阻塞（BIO）

- 服务端采用单线程，当 `accept` 一个请求后，在 `recv` 或 `send` 调用阻塞时，将无法 `accept` 其他请求（必须等上一个请求处理 `recv` 或 `send` 完 ）（无法处理并发）

```js
// 伪代码描述
while (true) {
	// accept阻塞
    client_fd = accept(listen_fd);
    fds.append(client_fd);
    for (fd in fds) {
    	// recv阻塞（会影响上面的accept）
        if (recv(fd)) {
        	// logic
        }
    }
}
复制代码
```

- 服务端采用多线程，当 accept 一个请求后，开启线程进行 recv，可以完成并发处理，但随着请求数增加需要增加系统线程，大量的线程占用很大的内存空间，并且线程切换会带来很大的开销，10000个线程真正发生读写实际的线程数不会超过20%，每次accept都开一个线程也是一种资源浪费。

```js
// 伪代码描述
while(true) {
  // accept阻塞
  client_fd = accept(listen_fd)
  // 开启线程read数据（fd增多导致线程数增多）
  new Thread func() {
    // recv阻塞（多线程不影响上面的accept）
    if (recv(fd)) {
      // logic
    }
  }
}
复制代码
```

### 同步非阻塞（NIO）

- 服务器端当 `accept` 一个请求后，加入 `fds` 集合，每次轮询一遍 `fds` 集合 `recv` (非阻塞)数据，没有数据则立即返回错误，每次轮询所有 fd （包括没有发生读写实际的 fd）会很浪费 CPU。

```js
// 伪代码描述
while(true) {
  // accept非阻塞（cpu一直忙轮询）
  client_fd = accept(listen_fd)
  if (client_fd != null) {
    // 有人连接
    fds.append(client_fd)
  } else {
    // 无人连接
  }
  for (fd in fds) {
    // recv非阻塞
    setNonblocking(client_fd)
    // recv 为非阻塞命令
    if (len = recv(fd) && len > 0) {
      // 有读写数据
      // logic
    } else {
       无读写数据
    }
  }
}
复制代码
```

### IO多路复用

服务器端采用单线程通过 `select/poll/epoll` 等系统调用获取 fd 列表，遍历有事件的 fd 进行 `accept/recv/send` ，使其能支持更多的并发连接请求。

```js
// 伪代码描述
while(true) {
  // 通过内核获取有读写事件发生的fd，只要有一个则返回，无则阻塞
  // 整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，accept/recv是不会阻塞
  for (fd in select(fds)) {
    if (fd == listen_fd) {
        client_fd = accept(listen_fd)
        fds.append(client_fd)
    } elseif (len = recv(fd) && len != -1) {
      // logic
    }
  }
}
```

## IO多路复用的三种实现

- select
- poll
- epoll

### select

它仅仅知道了，有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以**select具有O(n)的无差别轮询复杂度**，同时处理的流越多，无差别轮询时间就越长。

### select缺点

select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：

- 单个进程所打开的FD是有限制的，通过 `FD_SETSIZE` 设置，默认1024 ;
- 每次调用 select，都需要把 fd 集合从用户态拷贝到内核态，这个开销在 fd 很多时会很大；

> 需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
> 
- 对 socket 扫描时是线性扫描，采用轮询的方法，效率较低（高并发）

> 当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
> 

### poll

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态， **但是它没有最大连接数的限制**，原因是它是基于链表来存储的.

### poll缺点

**它没有最大连接数的限制**，原因是它是基于链表来存储的，但是同样有缺点：

- 每次调用 poll ，都需要把 fd 集合从用户态拷贝到内核态，这个开销在 fd 很多时会很大；
- 对 socket 扫描是线性扫描，采用轮询的方法，效率较低（高并发时）

### epoll

**epoll可以理解为event poll**，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是**事件驱动（每个事件关联上fd）**的，此时我们对这些流的操作都是有意义的。（复杂度降低到了O(1)）
epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

### epoll缺点

- epoll只能工作在 linux 下

### select/poll/epoll之间的区别

select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。**但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的**，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现

epoll是Linux目前大规模网络并发程序开发的首选模型。在绝大多数情况下性能远超select和poll。目前流行的高性能web服务器Nginx正式依赖于epoll提供的高效网络套接字轮询服务。但是，在并发连接不高的情况下，多线程+阻塞I/O方式可能性能更好。

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

- select：单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是32_32，同理64位机器上FD_SETSIZE为32_64），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试。
- poll：poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的。
- epoll：虽然连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接。

### FD剧增后带来的IO效率问题

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

### 消息传递方式

- select：内核需要将消息传递到用户空间，都需要内核拷贝动作
- poll：同上
- epoll：epoll通过内核和用户空间共享一块内存来实现的。

### 总结

select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。

# 参考
[彻底理解 IO 多路复用实现机制](https://juejin.cn/post/6882984260672847879#heading-26)