![](https://wandergeneral.cn/static/img/00e6cd2ef7f8290753956ad22d52e7a1.tcp-ip-start.webp)



## 前言
对于TCP与UDP， 这两个协议都是位于传输层的协议 。

对于传输层，它是TCP/IP协议五层模型中的第四层。它根据第四层网络层提供的层间接口，实现了TCP与UDP两种协议，为第五层应用层提供了`应用程序间的通信`，它负责数据能够从发送端传输到接收端。其功能包括：*格式化信息流*；*提供可靠传输*。为实现后者，传输层协议规定接收端必须发回确认，并且假如分组丢失，必须重新发送。

在计算机中，可能会有多个应用程序进行通信，为了标识这些不同的应用程序，我们加入了`端口号`来标识它们。

而在TCP/IP协议中, 用"源IP", "源端口号", "目的IP", "目的端口号", "协议号" 这样一个五元组来标识一个通信。

一个进程可以绑定多个端口号，但是一个端口号不能被多个进程绑定。

## TCP
**TCP**是一种面向连接的、可靠的、基于字节流的**传输控制**协议。

根据全称，我们可以得到以下特点：
- 面向连接：在真正的通信之前，必须建立连接。通信结束后，必须断开连接。
- 可靠：确保数据无差错、不丢失、不重复，按序到达。这也是`传输控制`的目的。
- 字节流：流动所体现的动态性。

要了解TCP的连接，首先要了解TCP报文段的格式。TCP报文段的格式如下：

![](https://wandergeneral.cn/static/img/7b704f4e4bc9225061987b59d2ca1e9f.1717570559764.webp)

但是，需要我们关注的是**序号，确认号，以及标志位（SYN，FIN等）**这三个。其他暂时无关紧要。

- 序号：报文段首字节的字节流编号。seq
- 确认号：期望从目标主机收到的下一字节的编号。ACK
- 标志位：SYN----连接建立，FIN----连接断开。

### TCP数据交换

TCP客户端与服务端的数据交换是建立在seq(发送序号)，ACK(确认应答)，标志位之上。

举个例子，看下图的数据传输：

![](https://wandergeneral.cn/static/img/ff14add9c136002e81e305922628d1d0.1717571749555.webp)

1. 客户端发送报文段：数据内容为c。seq = 42代表其为42号报文段（客户端）。ACK = 79代表客户端已经接收到了79之前的所有报文段，并请求服务端发送79号报文段（服务端）。
2. 服务端发送报文段：数据内容为d。seq = 79代表其为79号报文段（服务端）。ACK = 43代表服务端已经接收到了43之前的所有报文段，并请求客户端发送43号报文段（客户端）。
3. 客户端发送报文段：数据内容为e。seq = 43代表其为43号报文段（客户端）。ACK = 80代表客户端已经接收到了80之前的所有报文段，并请求服务端发送80号报文段（服务端）。

我们可以看到，对客户到服务器的数据的确认会被捎带在服务器到客户的报文段中。

同时我们也可以看到一种叫做**累计确认**的机制。例如，客户端收到了30之前的所有数据，在未收到30前提前收到了31，那么31是不会被确认的，因为30未收到。

### TCP的三次握手建立连接

如图，在TCP建立连接时，会有三次报文交换，因此称为三次握手。
![](https://wandergeneral.cn/static/img/efdb257cff5b44743f7a5966b97fe25d.1717577012534.webp)

首先，服务端已经打开。客户端发起连接。

1. **客户端发送请求报文。SYN置为1，代表此报文为请求连接的报文。seq为client_x，代表序号随机初始化值。**
2. *服务端收到客户端发来的请求报文时，为客户端分配缓存和变量。*
3. **服务端发送请求报文，携带确认信息。SYN置为1，代表此报文为请求连接的报文。ACK为client_x + 1代表服务端已经确认收到client_x + 1之前的所有数据，期望下次发送client_x + 1号的报文段。seq为serv_x，代表序号随机初始化值。** 
4. *客户端收到服务端发来的请求报文时，为服务端分配缓存和变量。此时双向通信已基本完成。
5. **客户端发送响应报文。ACK为serv_x + 1代表客户端已经确认收到serv_x + 1之前的所有数据，期望下次发送serv_x + 1号的报文段。seq为client_x + 1，代表此报文序号为client_x + 1。**

此时便可以看到三次握手在本质上还是在进行**请求与确认**。

#问题
`为什么是三次握手？能否改成四次或两次？`

TCP的三次握手分别代表了*请求*，*回应+请求*，*回应*三个目的，对于第二次，完全可以拆分为两个。
因此，三次握手不一定必须是三次，也可以是四次。

### TCP的四次挥手释放连接

有建立连接就会有释放连接，释放时会有四次的交流，因此被称为四次挥手。如图：

![](https://wandergeneral.cn/static/img/4855ba889658d1c61e81a98b63c7b8a7.1717592227398.webp)

请求与应答报文不用再多说了。

#问题 
`为什么是四次挥手？可不可以是三次？`

根据三次握手可以拆分成四次来分析的话，四次挥手应该也可以合并为三次。

但是，当第二次挥手会和第三次合并以后，就不能再进行传输数据，如果说此时服务端还有没传送玩的数据，就会存在数据缺失的问题。

因此，为了应对这种情况的发生，不能合并，第二次挥手完成后，要等数据传输完毕后，再进行第三次挥手。


### TCP状态

在一个TCP连接的生命周期内，每个主机上的TCP协议都有不同的状态，这种状态叫**TCP状态**。如图说明了一系列典型的TCP状态以及之间的变迁过程。

![](https://wandergeneral.cn/static/img/a6864dd46983a3283f6499c0dbf0effc.TCPç¶æè¿æ¥å¾.webp)


## UDP
**UDP**是无连接，不可靠的用户数据报协议。

根据全称，可以得到以下特点：
- 无连接：只知道对端的IP和端口号就可以发送，不需要实现建立连接。
- 不可靠：没有确认机制， 没有重传机制。如果因为网络故障该段无法发到对方， UDP协议层也不会给应用层返回任何错误信息。
- 面向数据报： 应用层交给UDP多长的报文， UDP原样发送既不会拆分，也不会合并。发多少，另一边就必须收多少，不能循环接收。



## 总结
|    \     |   TCP   |  UDP     |
|   ---    |   ---   |  ---     |
| 连接     | 面向连接 | 无连接   |
| 可靠性   | 可靠的   | 不可靠   |
| 传输效率 | 稍慢     | 快       |
| 传输方式 | 流式传输 | 数据报传输 |

TCP与UDP网络连接

![](https://wandergeneral.cn/static/img/a13788252e72236b28dff57f5c1ec33c.b1.webp)

当我们使用C++进行项目开发时，总是避免不了使用`new`来申请空间构建目标对象，但是频繁的申请和释放会导致系统性能的浪费和开销。



当我们设计一个类时，我们应该像以下方式这样设计：

```C++
class Airplane
{
private:
    struct AirplaneRep
    {
        unsigned long miles{ 10 }; // 8
        char type{ 'A' };          // 1       16
    };
    union
    {
        AirplaneRep rep{}; // 16
        Airplane* next;    // 8
    };                     // 16

public:
    unsigned long getMiles()
    {
        return rep.miles;
    }

    char getType() { return rep.type; }

    void set(unsigned long m, char t)
    {
        rep.miles = m;
        rep.type = t;
    }

    static void* operator new(size_t size);
    static void operator delete(void* ptr);
    ~Airplane() { std::cout << "Airplane::~Airplane()" << std::endl; }

private:
    static const int BLOCK_SIZE;
    static Airplane* headOfFreeList;
};

Airplane* Airplane::headOfFreeList;
const int Airplane::BLOCK_SIZE = 512;
```

对于new和delete需要我们重新设计和实现：

```C++
void* Airplane::operator new(size_t size) {
    // if (size != sizeof(Airplane))
    // {
    //     return ::operator new(size);
    // }

    Airplane* p = headOfFreeList;
    if (p) {
        headOfFreeList = p->next;
    }
    else {
        Airplane* newBlock = static_cast<Airplane*>(::operator new(BLOCK_SIZE * sizeof(Airplane)));
        for (int i = 1; i < BLOCK_SIZE - 1; ++i) {
            newBlock[i].next = &newBlock[i + 1];
        }
        newBlock[BLOCK_SIZE - 1].next = 0;
        p = newBlock;
        headOfFreeList = &newBlock[1];
    }
    return p;
}

void Airplane::operator delete(void* ptr) {
    if (ptr == 0) {
        return;
    }
    // if (size != sizeof(Airplane)) {
    //     ::operator delete(ptr);
    //     return;
    // }
    Airplane* deleteMe = static_cast<Airplane*>(ptr);
    deleteMe->next = headOfFreeList;
    headOfFreeList = deleteMe;
}
```

调用时不会有任何不适：

```C++
int main() {
    Airplane* p3 = new Airplane();
    std::cout << p3 << std::endl;
    // p3->set(1000, 'A');
    Airplane* p4 = new Airplane();
    std::cout << p4 << std::endl;
    // p4->set(5000, 'A');
    Airplane* p5 = new Airplane();
    std::cout << p5 << std::endl;

    delete p3;
    delete p5;
    delete p4;
    free(p3);
    // std::allocator<int> alloc;
    // alloc.allocate(10);
    return 0;
}
```

我们重写了operator new，至于重写的原因，就是因为`malloc与free`以及`new与delete`本身的缺陷所导致。

malloc在分配内存时会多分配一点内存至少用来存储具体分配的大小，因此，`malloc操作是有代价的`，每一次malloc都会浪费一点空间，所以*分配空间时malloc的次数越少越好*。

因此，如上方代码所示我们重写了new。看重写后的new分配空间时的内存分布如下：

![](https://wandergeneral.cn/static/img/4031744a7371f736dc1eeb419b5eae79.operator_new_for_class.webp)

当我们第一次调用operator new时，为其在栈上分配`栈帧`，首先创建`Airplane类型的指针p`，*指向`headOfFreeList`*。`headOfFreeList`是存在静态区的静态变量。这时若p即headOfFreeList为空，我们就调用`::operator new`一次分配足够多的栈空间，同时创建一个`Airplane类型的指针newBlock`指向堆空间，并且堆空间内的分区进行连接以便遍历。将`newBlock 所指向的0下标的空间的地址 给 p`，并将`下标为1的空间的地址给headOfFreeList`。将`p指向的空间给对象`。

当我们第二次调用operator new时，为其在栈上分配`栈帧`，首先创建`Airplane类型的指针p`，*指向`headOfFreeList`*。p不为空，将`p指向的空间给对象`。同时`使headOfFreeList指向下一部分空间`。

因此。虽然我们多次调用了operator new，但相较于原本的new会多次浪费资源，重写的new在一定次数的调用中只会浪费一次资源。

这也是一次开辟，多次使用的典型操作。

重写new的简单实例

![](https://wandergeneral.cn/static/img/017089084bc638f47280de615a5c2f77.bg.webp)

在程序中我们经常会遇到const关键字。





# const的作用

### 1.定义常量
定义的变量的值不能被改变，在整个作用域中都保持固定。换句话说，就是常类型的变量或对象的值不能被更新。

### 2.类型检查
const常量与#define宏定义的区别：[[const与define的区别|区别]]

### 3.防止修改，起保护作用，增加程序健壮性
void f(const int i) {     
	i++;//错误
}
确保不会改变const修饰的变量


### 4.可以节省空间，避免不必要的内存分配

const定义的常量在程序运行过程中只是一份拷贝，而#define定义的常量在内存中有若干个拷贝；


# 顶层const与底层const的区分

### !!!《C++Primer》: 当执行对象拷贝操作时，常量的顶层const不受影响，而底层const必须一致
```C
const int a = 10;
int b = a;
```
const为**顶层const**,**不受影响**即可忽略。

```C
const int *const p = new int(10);  
```
左侧const修饰指针，为底层const  
右侧const修饰变量，为顶层const,(根据原则，此const可忽略)  

const int * p;  
底层const

```C
int *p1 = p;//错误
```
p1为int * ，不能接const int *。


```C
int * const pc = new int(10); 
int * pb = pc;//正确
```
pc为int *，pb为int *，pb可以接受pc


```C
const int mm = 10;  
int * pd = &mm;错误
```
mm为顶层const，但对mm取地址后，为**底层const**，**必须一致**。
pd为int *，不能接const int *。


const int a = 10;  
顶层const,可忽略  

```
int b = a;  
const int b = a;
const int & ra = 10;
```
**引用**是起别名，底层为指针操作，此const为**底层const**。


```
const int & ra = b;
```
无论b是否改变，ra是b的别名，不会改变b（即**不能且不会通过ra来改变b的值**）

**常量引用可接任意值**

### 总结:

- **引用**不是对象时且不进行拷贝，则**不满足以上原则**
  
- **常量引用**如果**在左侧**，右侧**可接**受**任何值**
  
- **非常量引用 = 常量** （会**报错**）
  
- **引用**如果在**等号右侧**，请**忽略**它(&)
  
- **非常量 = 常量引用** （合理）

const关键字

![](https://wandergeneral.cn/static/img/a13788252e72236b28dff57f5c1ec33c.b1.webp)

在C++中有着各种类型转换，其中包括：

1. 隐式类型转换
2. 强制类型转换





对于隐式类型转换，其中存在小问题，例如：

```c++
float f = 10.f;
int i = f;
```

当我们在几千行代码中看到了第二句，我们的第一印象可能会是f本身就是int类型，当我们之后以 int 类型使用 f 时，问题就来了，这是很糟糕的。

因此，我们更应该使用C++特有的四种强制类型转换。

## 01.static_cast

static_cast为静态类型转换，它可以进行**基本内置类型**之间的转换

```c++
// static_cast 2.
float f = 10.f;
int i = static_cast<int>(f);
```

同时，他还可以通过 **void*** 来进行**任意指针类型**之间的转换

```c++
// static_cast 2.
A a;
void *vap = static_cast<void *>(&a);
int *ip = static_cast<int *>(vap);
std::cout << "*ip: " << *ip << std::endl;
```

当进行**类之间**的转换时（存在**继承**关系），如果**没有多态**，只支持**上行**。存在**多态**，也只支持**上行**，但**无法**继续完成**多态**

```C++
// static_cast 3.
CA ca;
A a_ = static_cast<A>(ca); // 上行ok
a_.funcA();
// CA ca_ = static_cast<CA>(a); // 下行报错

// static_cast 4.
Base base;
Derived derived;

Base _base = static_cast<Base>(derived); // 上行ok，但是没有多态
 _base.func();
// Derived _derived = static_cast<Derived>(base);// 下行报错

```

当进行的是**类指针之间**的转换时（存在**继承**关系），如果**没有多态**，那**都支持**，但**下行不安全**。存在多态，**都支持**，但**某些下行不安全**

```C++
// static_cast 5.
CA *ca_ = static_cast<CA *>(&a);
ca_->funcCA(); // 下行不安全
CA &car_ = static_cast<CA &>(a);
car_.funcCA(); // 下行不安全

// static_cast 6.
Base *_baseptr = static_cast<Base *>(&derived); // 上行ok，多态
_baseptr->func();
Derived *_derivedptr = static_cast<Derived *>(&base); // 下行不安全
_derivedptr->func();
Derived *_derivedptr_ = static_cast<Derived *>(_baseptr); // 下行安全
_derivedptr_->func();
```

因此对于静态类型转换，可以满足我们的大多数需求，在转换的同时为我们**指明了转换的目的和意图**，可以帮助我们更好的完成代码工作。

## 02.dynamic_cast

将基类类型的指针或引用**安全的转换**为派生类的指针或引用

```c++
// dynamic_cast
Base *_baseptr_d = dynamic_cast<Base *>(&derived); // 上行ok，多态
_baseptr_d->func();
Derived *_derivedptr_d = dynamic_cast<Derived *>(&base); // 下行不安全
if (_derivedptr_d) {
    _derivedptr_d->func();
}
Derived *_derivedptr__d = dynamic_cast<Derived *>(_baseptr); // 下行安全
_derivedptr__d->func();
```

## 03.const_cast

**去除const** 或 **添加const**

```c++
// const_cast
const char *pc = "hello world";
// char *p = pc;
char *p = const_cast<char *>(pc);
// p[2] = 'a'; // 段错误
std::string aas = "hello";
std::string bbs = "ll";
shorterString(aas, bbs);

const std::string& shorterString(const std::string &s1,
                                 const std::string &s2)
{
    return s1.size() <= s2.size() ? s1 : s2;
}

std::string& shorterString(std::string &s1,
                           std::string &s2)
{
    auto &r = shorterString(const_cast<const std::string &>(s1),
                            const_cast<const std::string &>(s2));
    // return r;
    return const_cast<std::string &>(r);
}
```

## 04.reinterpret_cast

为运算对象的位模式提供低层次上的重新解释

```c++
// reinterpred_cast 1.
int *i_ = reinterpret_cast<int *>(i);
int64_t cpi = reinterpret_cast<int64_t>(pc);

// reinterpred_cast 2.
int *vap_ = reinterpret_cast<int *>(&a);
```

## 测试代码

```c++
#include <iostream>
#include <string>

struct A
{
    int a{20};
    void funcA() { std::cout << "A::funA" << std::endl; }
};

struct B
{
    int b{};
    void funcB() { std::cout << "B::funB" << std::endl; }
};

struct CA : public A
{
    int c{25};
    void funcCA()
    {
        std::cout << "c is: " << c << std::endl;
        std::cout << "CA::funcCA" << std::endl;
    }
};

struct Base
{
    virtual void func()
    {
        std::cout << "Base::func()" << std::endl;
    }
};

struct Derived : public Base
{
    virtual void func() override
    {
        std::cout << "Derived::func()" << std::endl;
    }
};

const std::string &shorterString(const std::string &s1,
                                 const std::string &s2)
{
    return s1.size() <= s2.size() ? s1 : s2;
}

std::string &shorterString(std::string &s1,
                           std::string &s2)
{
    auto &r = shorterString(const_cast<const std::string &>(s1),
                            const_cast<const std::string &>(s2));
    // return r;
    return const_cast<std::string &>(r);
}
int main()
{
    // static_cast 1.
    float f = 10.f;
    int i = static_cast<int>(f);

    // static_cast 2.
    A a;
    void *vap = static_cast<void *>(&a);
    int *ip = static_cast<int *>(vap);
    std::cout << "*ip: " << *ip << std::endl;

    // static_cast 3.
    CA ca;
    A a_ = static_cast<A>(ca); // 上行ok
    a_.funcA();
    // CA ca_ = static_cast<CA>(a); // 下行报错

    // static_cast 4.
    Base base;
    Derived derived;

    Base _base = static_cast<Base>(derived); // 上行ok，但是没有多态
    _base.func();
    // Derived _derived = static_cast<Derived>(base);// 下行报错

    // static_cast 5.
    CA *ca_ = static_cast<CA *>(&a);
    ca_->funcCA(); // 下行不安全
    CA &car_ = static_cast<CA &>(a);
    car_.funcCA(); // 下行不安全

    // static_cast 6.
    Base *_baseptr = static_cast<Base *>(&derived); // 上行ok，多态
    _baseptr->func();
    Derived *_derivedptr = static_cast<Derived *>(&base); // 下行不安全
    _derivedptr->func();
    Derived *_derivedptr_ = static_cast<Derived *>(_baseptr); // 下行安全
    _derivedptr_->func();

    // dynamic_cast
    Base *_baseptr_d = dynamic_cast<Base *>(&derived); // 上行ok，多态
    _baseptr_d->func();
    Derived *_derivedptr_d = dynamic_cast<Derived *>(&base); // 下行不安全
    if (_derivedptr_d)
    {
        _derivedptr_d->func();
    }
    Derived *_derivedptr__d = dynamic_cast<Derived *>(_baseptr); // 下行安全
    _derivedptr__d->func();

    // const_cast
    const char *pc = "hello world";
    // char *p = pc;
    char *p = const_cast<char *>(pc);
    // p[2] = 'a'; // 段错误
    std::string aas = "hello";
    std::string bbs = "ll";
    shorterString(aas, bbs);

    // reinterpred_cast 1.
    int *i_ = reinterpret_cast<int *>(i);
    int64_t cpi = reinterpret_cast<int64_t>(pc);

    // reinterpred_cast 2.
    int *vap_ = reinterpret_cast<int *>(&a);

    return 0;
}
```

C++中的类型转换

![](https://wandergeneral.cn/static/img/a13788252e72236b28dff57f5c1ec33c.b1.webp)



在学习socket网络连接的过程中，我们经常会看到以下这种代码：

```cpp
int listenfd = socket();	
bind(listenfd);			          //绑定主机
listen(listenfd);		          //设置监听上限
while (1) {
    int connfd = accept(listenfd);	  //建立连接，获取fd
    int n = read(connfd, buff);		  //读取数据
    doSomeThing(buff);			  //处理数据
    close(connfd);		          //关闭连接
}
```

当其运行成功后，会出现两个阻塞：
- accept
- read

`accept`阻塞意味着监听套接字处于监听状态，没有客户端程序进行连接。`read`阻塞意味着已经有客户端连接成功，但是没有数据需要我们读取。

## 1. 阻塞IO

当用户程序调用read时，会从用户态切到内核态，首先将接收到的数据放入内核缓冲区，再从内核缓冲区拷入用户缓冲区，从内核态切回用户态。

如果数据未到达网卡，或者未从网卡的缓冲区拷贝到内核缓冲区，这样便会阻塞；这里便是`阻塞的IO`，如下图所示：

![](https://wandergeneral.cn/static/img/b35bce7f58a624b90232f913d27a1609.é»å¡çIO.webp)

如果客户端一直没传数据，那么便会一直阻塞在read的调用上，socket连接也不会进行，数据处理也不会进行。

这是非常糟糕的一件事。如何解决这一问题？有以下做法

```cpp
while(1) {
  	connfd = accept(listenfd);     // 阻塞建立连接
 	pthread_create（doWork);       // 创建一个新的线程
}
void doWork() {
  	int n = read(connfd, buf);     // 阻塞读取数据
  	doSomeThing(buf);              // 处理数据
  	close(connfd);                 // 关闭连接
}
```

此时，程序就不会发生 **因为一个连接上没有数据传来而导致不能进行下一个连接** 这种事情。

但是，这种做法仅仅是使用多线程理论使得read并没有阻塞在主线程上，而次线程仍会因read而阻塞等待，并非真正的非阻塞。

操作系统为我们提供的 read 函数仍然是阻塞的。所以真正的非阻塞 IO，不能是通过我们用户层的一点点小把戏实现，**而是要恳请操作系统为我们提供一个非阻塞的 read 函数**。 

这便有了非阻塞的IO。

## 2. 非阻塞IO

非阻塞 read 函数的效果是，如果没有数据到达或到达网卡但并未拷贝到了内核缓冲区（即 **读已就绪之前的所有状态**），则立刻返回一个错误值（-1），而不是阻塞地等待。

![](https://wandergeneral.cn/static/img/d79c3d3c9f2eeaa54963f8ab16e4d5d4.éé»å¡çIO.webp)

操作系统提供了这样的功能，只需要在调用 read 前，将文件描述符设置为非阻塞即可。 

```cpp
fcntl(connfd, F_SETFL, O_NONBLOCK);
int n = read(connfd, buffer) != SUCCESS);
```

这样才是真正的非阻塞IO。

:::info{title="非阻塞并非完全非阻塞"}
我们可以注意到的是，非阻塞IO并非完全的非阻塞，而是在`读已就绪`之前没有数据时是非阻塞的。

因此当我们讨论是使用阻塞还是非阻塞时应该看一看所处的状况下数据是否到达。
:::

## 3. IO多路复用


:::tip{title=" "}
在我们写socket网络程序时，需要考虑大量的客户端程序进行连接。
:::

我们可以简单的设计一下：

- 有一个线程只接受tcp连接，并把连接到文件描述符存放到数组。
- 另外一个线程，对数组内的描述符执行非阻塞read操作。

这样的话，连接与接收数据便会互不影响，就像下面这段代码：

```cpp
vector<int> fdlist;                      // 存放fd的容器  

while (1) {
    connfd = accept(listenfd);           // 建立连接，获取fd
        fdlist.add(connfd);              // 添加到容器
}
...
while (1) {
    for (fd <-- fdlist) {
	if (read(fd) != -1) {
	    doSomeThing();
	}
    }
}
```

但是，就像我们使用多线程去修改阻塞时一样，这也只是我们用户层的把戏，表面上实现了较高的并发，但是在for循环下的read由于`系统调用`也将会大大消耗系统资源。

因此，我们还得**恳请操作系统提供一个多路复用的方法**。我们将一批文件描述符通过一次系统调用传给内核，由内核层去遍历，才能真正解决这个由于大量系统调用而引发的问题。 

![](https://wandergeneral.cn/static/img/5c15249c48d3aacb79b324bacbdf737f.IOå¤ç¨.webp)

操作系统提供了三种IO多路复用的方法。

### 3.1 select

我们可以把一个文件描述符的数组发给操作系统，让操作系统去遍历，确定可以读写的描述符的数量，告诉我们，然后以较小的代价去找到这些描述符，并处理它们。select便是这样。

![](https://wandergeneral.cn/static/img/ba00a10a22fc5cb71e8acb0003e6c027.select.webp)

但是，值得注意的是：

- 数组存储文件描述符，那么数量是有限的。
- 调用select时必须传入数组，因此需从用户区域拷贝一个数组进内核区域，耗费大。
- 尽管只进行了一次系统调用，但是在内核中仍是以轮询的方式遍历数组，耗时耗力。
- 返回的仅仅是就绪的个数，用户态仍需再次遍历仅仅是遍历的少而已。但在某些特殊情况下，仍会全部遍历。

这便是select，系统提供的最初的多路复用。

### 3.2 poll

poll与select并没有本质区别，poll只是将select中的数组修改为链表，这样就会大大增加描述符的数量。

![](https://wandergeneral.cn/static/img/9c35b91470831b6b402ebb22367329cb.poll.webp)

### 3.3 epoll

select与poll有很多的问题需要解决，因此系统为我们提供了一种非常强大的多路复用方法epoll。

第一，不再使用数组或链表，而是使用**红黑树**，由于红黑树的特性，查找将会特别容易而且快速。

第二，用户态与内核态会共同对同一块内存进行映射，因此，免去了拷贝的消耗。

第三，epoll会返回已就绪的文件描述符的集合，因此不需要进行不必要的遍历，只对已就绪的进行操作即可。

![](https://wandergeneral.cn/static/img/827ea1a31d149f033ee93cb7a4df37f3.epoll.webp)

#### 3.3.1 epoll三大API

int epoll_create(int size);	//构建一个epoll实例，并返回这个实例的句柄。

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);	//阻塞等待事件的发生，返回时间的数目，并将触发的事件写入events数组中

epoll监控多个文件描述符的I/O事件。epoll支持边缘触发(edge trigger，ET)或水平触发（level trigger，LT)，通过epoll_wait等待I/O事件，如果当前没有可用的事件则阻塞调用线程。

#### 3.3.2 epoll的简单使用

```C
//创建 epoll
int epfd = epoll_crete(1000);
//将 listen_fd 添加进 epoll 中
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd,&listen_event);
while (1) {
    //阻塞等待 epoll 中 的fd 触发
    int active_cnt = epoll_wait(epfd, events, 1000, -1);
    for (i = 0 ; i < active_cnt; i++) {
        if (evnets[i].data.fd == listen_fd) {
            //accept. 并且将新accept 的fd 加进epoll中.
        }
        else if (events[i].events & EPOLLIN) {
            //对此fd 进行读操作
        }
        else if (events[i].events & EPOLLOUT) {
            //对此fd 进行写操作
        }
    }
}
```

select和poll只支持LT工作模式，epoll的默认的工作模式是LT模式。

#### 3.3.3 ET模式与LT模式

试想一下，发送端发送5个字符（HELLO），但在接受端读取时一次只能读一个。

![](https://wandergeneral.cn/static/img/24cf58a14a6c63da3e6ab518364686ea.bh.webp)

当我们使用LT模式时，可能会出现以下情况：

```
H
E
L
L
O
```

为什么呢？那是因为在LT模式下，只要接收缓冲区未被读取完，便会通知，因此五行代表了五次事件。

但当使用ET模式时，就会是这样：

```
H
```

因为ET模式对于一个事件只有一次通知，但同时只读一个，因此只有H。

但是仍有一个问题，我们应该使用阻塞还是非阻塞？

如果在LT模式下，其实使用阻塞与非阻塞没太大的区别，因为LT模式是有数据才触发，没数据不触发，而阻塞与非阻塞IO的区别就在没数据的时候。

假如，在ET模式下使用阻塞IO，那么因为读小于接收，因此需要使用while(1)之类的循环操作去反复读取，但是当读完最后一个值之后，因为使用的阻塞IO，所以一定会因为读不到值而停止等待。但对于非阻塞IO，读不到值时会立即返回-1，根据错误码便可判断读完成。

我们可以看到的是，在接收缓冲区与读之间大小分配不合理才会出现了这么多不一样的情况。因此只要在此之间建立好一定的联系，使其能够合理分配，便可无忧。


## 总结

看到这里，我们便会发现一切的一切都源于**阻塞的read**这个系统调用，为了解决其长时间等待的问题，我们在用户态使用多线程去解决它。但是这个功能太重要了，因此系统提供了一种**非阻塞的read**，此时我们便可以直接使用非阻塞read。

当我们有多个文件描述符需读取数据时，就需要遍历，当用户态遍历的文件描述符越来越多时，相当于在 while 循环里进行了越来越多的系统调用，这是糟糕的，因此系统又为我们提供了尽量少切换状态便可遍历的功能，那便是**IO 多路复用**。

IO复用模型

韩康慨的个人主页，记录计算机/互联网行业的一名普通人在学习和开发过程中的点滴，为自己留下一个憧憬。