# wmproxy
`wmproxy`是由`Rust`编写，已实现`http/https`代理，`socks5`代理， 反向代理，静态文件服务器，内网穿透，配置热更新等， 后续将实现`websocket`代理等，同时会将实现过程分享出来， 感兴趣的可以一起造个轮子法

## 项目 wmproxy

[gite: https://gitee.com/tickbh/wmproxy](https://gitee.com/tickbh/wmproxy)

[github: https://github.com/tickbh/wmproxy](https://github.com/tickbh/wmproxy)

## 了解反向代理
反向代理（Reverse Proxy）是一种服务器架构的技术，位于客户端和目标服务器之间，处理来自客户端的所有请求，并代表目标服务器处理与客户端的交互。
#### 保护源站
在客户端访问服务器的时候，其实并不关心目标的地址在哪，只要数据能够正常返回，签名能够正常的握手，就认为是正常的。
而通常源站的防护等级相对会较弱，比如源站一般没有防御DDOS的能力，暴露了源站的地址也就意味着被渗透被攻击的概率大大升高，从而使服务变得极不稳定。
#### 加速传输
通常反向代理可以遍布各个节点，然后再通过专有线路来访问源站，或者一次请求缓存结果多次返回就可以减少和源站通讯，减少源站压力，就典型的结构如`CDN`就可以大大的提高客户端的访问速度，减少延迟
#### 防火墙作用
由于所有的客户机请求都必须通过代理服务器访问远程站点，因此可以在代理服务器上设定限制，过滤某些不安全信息，如WAF防火墙之类。

## 反向代理有哪些配置
以下是一份nginx的反向代理的配置
``` conf
http {
    upstream backend {
        server 192.168.0.14:8080 weight=10 fail_timeout=3s ; 
        server 192.168.0.15:8081 weight=10; 
    }
    server {
        listen 80;  #监听80的服务端口
        server_name wm-proxy.com;  #监听的域名
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        location /products {
            proxy_pass http://backend;
            proxy_set_header Host $host;
            add_header 'Access-Control-Allow-Credentials' 'true';
            add_header 'Access-Control-Allow-Origin' '*';
        }
        
        location / {
            root wmproxy;
            index index.html index.htm;
        }
    }
    server {
        listen 80;  #监听80的服务端口
        server_name localhost;  #监听的域名
       
        location / {
            proxy_pass http://www.baidu.com;
            proxy_set_header Host $host;
            add_header 'Access-Control-Allow-Credentials' 'true';
            add_header 'Access-Control-Allow-Origin' '*';
        }
    }
}
```
> 以上配置内容主要有几点需实现：

##### upstream
这是反向连接的代理池，可能配置了多个的数据可访问的源地址，此处需要实现各种策略来平衡访问它，如`weight`权重模式，`ip_hash`按客户端地址来映射相同的源站地址，保证同一个客户端只进入一个源站，如`fair`按后端服务器的响应时间来分配请求，响应时间短的优先分配。
> 各自的健康检查参数需要和全局的进行区分

`fail_timeout`失败的重试时间
`max_fails`超过这失败次数则认为不可连

#### 多个server同时监听同一个端口
反向代理可配置多个server同时监听同一个端口，按server_name来区分要访问的的源站地址

#### 同一个端口，多个证书的问题
需要根据客户端传输的域名来自动选择对应的证书进行解析来返回数据，保证数据的正确。

#### 父级的配置要映射到子级的选项
比如配置在`proxy_set_header`的每个选项在他子级的location都需要进行设置，而在Rust中要获取父类的结构相当的麻烦，这点需要正确的解决

#### location的多种结构支持
location可能是反向代理，可能是文件服务器，需要多种配置支持

## 实现源码
> 以下是各`upstream`的定义
```rust
#[serde_as]
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct SingleStreamConfig {
    /// 访问地址
    pub addr: SocketAddr,
    /// 权重
    #[serde(default = "default_weight")]
    pub weight: u16,
    /// 失败的恢复时间
    #[serde_as(as = "DurationSeconds<u64>")]
    #[serde(default = "fail_timeout")]
    fail_timeout: Duration,
    /// 当前连续失败的次数
    #[serde(default = "default_fall_times")]
    fall_times: usize,
    /// 当前连续成功的次数
    #[serde(default = "default_rise_times")]
    rise_times: usize,
}
```
这边用到了`serde_with`库中的`serde_as`，把数字秒解析成`Duration`类型。我们在检查是否存活的时候会带入相应的参数与全局的做区分开来
```rust
/// 检测状态是否能连接
pub fn check_fall_down(addr: &SocketAddr, fail_timeout: &Duration, fall_times: &usize, rise_times: &usize) -> bool {
    ...
}
```
> 关于多个端口监听，开始时我们会遍历所有的端口，且只会绑定一次
```rust
let mut bind_port = HashSet::new();
for value in &self.server.clone() {
    // 已监听的端口存到Set里面
    if bind_port.contains(&value.bind_addr.port()) {
        continue;
    }
    bind_port.insert(value.bind_addr.port());
    let listener = TcpListener::bind(value.bind_addr).await?;
    listeners.push(listener);
}
```
保证只会绑定一次端口。等解析完Req的时候再进行转发，保证能正确的处理转发

> 同一个端口多个证书的问题

因为客户端发送`ClientHello`的时候我们可以知道是从哪个域名过来的，所以我们可以根据发过来的域名选择正确的证书，就可以解决多个证书的问题，在rustls中，我们用`ResolvesServerCertUsingSni`来进行解决，下面相关源码
```rust
let config = rustls::ServerConfig::builder().with_safe_defaults();
let mut resolve = ResolvesServerCertUsingSni::new();
for value in &self.server.clone() {
    let mut is_ssl = false;
    if value.cert.is_some() && value.key.is_some() {
        let key = sign::any_supported_type(&Self::load_keys(&value.key)?)
            .map_err(|_| ProtError::Extension("unvaild key"))?;
        let ck = CertifiedKey::new(Self::load_certs(&value.cert)?, key);
        resolve.add(&value.server_name, ck).map_err(|e| {
            println!("{:?}", e); ProtError::Extension("key error")
        })?;
        is_ssl = true;
    }

    tlss.push(is_ssl);
}

let config = config
    .with_no_client_auth()
    .with_cert_resolver(Arc::new(resolve));
Ok((Some(TlsAcceptor::from(Arc::new(config))), tlss, listeners))
```
ResolvesServerCertUsingSni可以配置多个域名的证书，但证书必须和域名强匹配，Accept的时候会根据域名选择相应的证书。

> 子级需要能访问父级的配置问题
在Rust因为所有权的问题，一个对象肯定会归属于一个地方的所有权，所以无法在不经常加工的情况实现类似其它语言的`parent->getChild()`及`child->getParent()`，而此处比如location需要共享server的数据，如`root`参数。目前查资料比较公认的有以下方式：
用指针的方向(raw pointer)，但是指针无法Send，也就是无法在线程间转移。
```rust
struct Parent {
    child: Child,
}

struct Child {
    parent: *const Parent,
}

fn main() {
    let mut child = Child {
        parent: std::ptr::null(),
    };
    let parent = Parent { child };
    child.parent = &parent;
}
```
用共享计数方法(Rc)
```rust
use std::rc::Rc;

// 所有的Child都将拥有该对象的引用
struct Inner;

struct Parent {
    child: Child,
    inner: Rc<Inner>,
}

struct Child {
    parent: Rc<Inner>, // or Weak<Inner> if that's desirable
}

fn main() {
    let inner = Rc::new(Inner);
    let child = Child {parent: Rc::clone(&inner)};
    let parent = Parent {child, inner};
}
```
用临时的生命周期，获取Child的时候做特殊处理
```rust
struct Parent {
  pub children: Vec<Child>,
}

impl Parent {
 fn get_child(&'a self, name) -> DynamicChild<'a> {
   DynamicChild { parent: self, child: ...}
 }
}

struct Child {
 a: u64,
 b: String,
}

struct DynamicChild<'a> {
 pub data: &'a Child,
 pub parent: &'a Parent,
}

impl<'a> DynamicChild<'a> {
 fn do_thing_with_parent(&self) -> usize {
  self.parent.children.len()
 }
}
```

Rust为了保证安全，但凡有所有权归属的问题，就会变得比较麻烦，我们这里会在数据序列化的时候，把父级的配置直接写入到子级的配置，以这种方式子级就有完整的数据，也可以避免访问父级的内容。
```rust
/// 将配置参数提前共享给子级
pub fn copy_to_child(&mut self) {
    for server in &mut self.server {
        server.upstream.append(&mut self.upstream.clone());
        server.copy_to_child();
    }
}
```
此时保证location这一层处理的能得到完整的数据，即可以避免访问父级节点。

> location的多种结构支持

location可能是静态文件服务器，也可能是反向代理，也可能是后续的`fast-cgi`等。
location根据rule进行req中的path匹配，如果填有Method方法也根据Method是否匹配。然后再根据相应的分支选项进行处理匹配。
```rust
let host = req.get_host().unwrap_or(String::new());
// 不管有没有匹配, 都执行最后一个
for (index, s) in value.server.iter().enumerate() {
    if s.server_name == host || host.is_empty() || index == server_len - 1 {
        let path = req.path().clone();
        for l in s.location.iter() {
            if l.is_match_rule(&path, req.method()) {
                return l.deal_request(req).await;
            }
        }
        // ...
    }
}
```

## 结语
此时关于反向代理的几个初步问题已经处理完成反向代理操作。反向代理在互联网已经组成了密不可分的组成部分，成为了互联网的基石之一。像云服务器的负载均衡，K8S中的数据同步等大的小的均用到了这一项技术。

16-从零用Rust编写正反向代理, 反向代理upstream源码实现

# wmproxy
`wmproxy`是由`Rust`编写，已实现`http/https`代理，`socks5`代理， 反向代理，静态文件服务器，内网穿透，配置热更新等， 后续将实现`websocket`代理等，同时会将实现过程分享出来， 感兴趣的可以一起造个轮子法

## 项目 ++wmproxy++

[gite: https://gitee.com/tickbh/wmproxy](https://gitee.com/tickbh/wmproxy)

[github: https://github.com/tickbh/wmproxy](https://github.com/tickbh/wmproxy)

## 了解三种格式
### Json
- JSON是一种轻量级的数据交换格式，被广泛使用在Web应用程序之间传输数据。
- JSON使用大括号{}来表示数据结构，使用冒号:来连接键和值。
- JSON支持字符串、数字、布尔值、null、数组和对象等多种数据类型。
- JSON文件通常用于数据交换、存储等场景，也可以用作配置文件。
JSON简单易读存储通用，但JSON原生不支持注释用来做配置文件比较硬伤。

> 它流行度极高，基本上每个程序员都和他打过交道。
> 多层级时，对齐和缩进不好控制，容易出错

### Yaml
- YAML被设计为一种可读性极强的数据序列化标准，可以用来表达层次化数据。
- YAML使用空格缩进来表示数据层次结构。
- YAML支持浮点数、布尔值、字符串、数组、映射等多种数据类型。
- YAML文件通常用于配置文件、数据交换等场景。

> 与JSON及TOML相比，结构比较紧凑
> 但相对用空格缩近，编写及拷贝时出错的机率比JSON及TOML高许多

### Toml
TOML 旨在成为一个语义明显且易于阅读的最小化配置文件格式。
TOML 应该能很容易地被解析成各种语言中的数据结构。
- TOML是一种简洁明了的键值对格式，被设计成可以很容易地映射为哈希表。
- TOML使用等号（=）来连接键和值，使用缩进来表示数据层次结构。
- TOML支持整数、浮点数、字符串、布尔值、数组、字典等多种数据类型。
- TOML文件通常用于配置文件、数据交换等场景。

> 它`易于阅读和编写`，`语法灵活`
> 与JSON配置相比，TOML在简洁性方面远远胜出；
> 与YAML配置相比，TOML在简洁性以及语法灵活性方面远远胜出。

### 三种格式测试数据的对比
我们用Rust的项目配置文件来做对比，为了展示所有的类型，格式有所变更。它以Toml来做配置文件，我们首先先展示toml的格式

> 内容包含创建者，创建时间，项目名称，项目依赖等信息，如果我们将其转化成可配置的JSON格式时

#### toml
```toml
create="tickbh"
create_time=2023-09-08T10:30:00Z
[project]
# 项目名称
name="wmproxy"
version="1.1"
editor=2022
# 项目依赖
[project.dependencies]
wenmeng={version = "0.1.21", default-features = false, features = ["std", "tokio"]}
webparse={version = "0.1", default-features = false}
```
行数12行，注释两行，全部顶格开头，原生支持时间格式
#### json
```json
{
  "create": "tickbh",
  "create_time": "2023-09-08T10:30:00.000Z",
  "project": {
    "name": "wmproxy",
    "version": "1.1",
    "editor": 2022,
    "dependencies": {
      "wenmeng": {
        "version": "0.1.21",
        "default-features": false,
        "features": [
          "std",
          "tokio"
        ]
      },
      "webparse": {
        "version": "0.1",
        "default-features": false
      }
    }
  }
}
```
行数23行，层次的递进比较多，不容易对齐，无法注释，不支持时间格式

#### yaml
```yaml
create: tickbh
create_time: 2023-09-08T10:30:00.000Z
project:
  # 项目名称
  name: wmproxy
  version: "1.1"
  editor: 2022
  # 项目依赖
  dependencies:
    wenmeng:
      version: 0.1.21
      default-features: false
      features:
        - std
        - tokio
    webparse:
      version: "0.1"
      default-features: false
```
行数18行，注释两行，原生支持时间格式，到`features`这级行，深度相对较高，但是一眼看上去比`json`清晰

> 相对来说JSON比较不适合做比较复杂的配置文件，但`VSCODE`使用的拓展的JSON以支持注释功能。

### 接下来尝试将nginx.conf格式做转换
以下尝试的将
``` conf
http {
    gzip on;
    server {
        listen 80;  #监听80的服务端口
        server_name wm-proxy.com;  #监听的域名
       
        location /products {
            proxy_pass http://127.0.0.1:8090/proxy;
            add_header 'Access-Control-Allow-Credentials' 'true';
            add_header 'Access-Control-Allow-Origin' '*';
        }
        
        location / {
            root wmproxy;
            index index.html index.htm;
        }
    }
}
```

我们也模仿类似的结构，但是对于`toml`,`yaml`,`json`来说，都没有一个key两个值的，要么我们只能用对应的数组，此时我来先来初步重构类似的结构。以下我们以toml结构为例，我们分析table的级数有三级，最外层为`http`，中间层为`server`为数组，最内层为`location`也为数组，`headers`我们用之前提到过的`mappings`，用`proxy`开头来表示重写`Reqeust`，其它的来表示重写`Response`，文件系统我们用上节提到的`file_server`。
我们先定义`http`的table，他只有一个属性gzip为on
```toml
[http]
gzip="on"
```
其次`server`为一个数组，那么我们可以如下定义，有绑定地址和server_name
```toml
[[http.server]]
bind_addr="127.0.0.1:80"
server_name="wm-proxy.com"
```
再然后`location`也为一个数组，定义如下
```toml
[[http.server.location]]
rule = "/products"
reverse_proxy = "http://127.0.0.1:8090/proxy"
headers = [
  ["+", "Access-Control-Allow-Credentials", "true"],
  ["+", "Access-Control-Allow-Origin", "*"]
]
[[http.server.location]]
rule = "/"
file_server = { root="wmproxy", browse = true, index=["index.html", "index.htm"] }
```

那么，最终的结构为如下：
```toml
[http]
gzip="on"
[[http.server]]
bind_addr="127.0.0.1:80"
server_name="wm-proxy.com"
[[http.server.location]]
rule = "/products"
reverse_proxy = "http://127.0.0.1:8090/proxy"
headers = [
  ["+", "Access-Control-Allow-Credentials", "true"],
  ["+", "Access-Control-Allow-Origin", "*"]
]
[[http.server.location]]
rule = "/"
file_server = { root="wmproxy", browse = true, index=["index.html", "index.htm"] }
```
而yaml的格式结构如下：
```yaml
http:
  gzip: on
  server:
    - bind_addr: 127.0.0.1:80
      server_name: wm-proxy.com
      location:
        - rule: /products
          reverse_proxy: http://127.0.0.1:8090/proxy
          headers:
            - - +
              - Access-Control-Allow-Credentials
              - "true"
            - - +
              - Access-Control-Allow-Origin
              - "*"
        - rule: /
          file_server:
            root: wmproxy
            browse: true
            index:
              - index.html
              - index.htm
```
而json的格式结构如下：
```json
{
  "http": {
    "gzip": "on",
    "server": [
      {
        "bind_addr": "127.0.0.1:80",
        "server_name": "wm-proxy.com",
        "location": [
          {
            "rule": "/products",
            "reverse_proxy": "http://127.0.0.1:8090/proxy",
            "headers": [
              [
                "+",
                "Access-Control-Allow-Credentials",
                "true"
              ],
              [
                "+",
                "Access-Control-Allow-Origin",
                "*"
              ]
            ]
          },
          {
            "rule": "/",
            "file_server": {
              "root": "wmproxy",
              "browse": true,
              "index": [
                "index.html",
                "index.htm"
              ]
            }
          }
        ]
      }
    ]
  }
}
```
- 自建的好处是比较清晰，可以自定义自己合适的结构，但是编写者需要重新开始学习，而用能用的配置文件需要遵循它的格式定义
- 像toml文件，如果层级很深，他的key值配置会很长，因为他一旦定义一个table，就是从最顶级来解析，但是编写者只要熟悉过这配置文件很快就能写出满意的配置文件
- 而yaml的层级结构相对会需要去看对齐与否，编写的时候需要额外注意，因为弄错了缩进，层级就会发生错误
- 而json最后结尾的会有相当多的花括号，相对比较容易弄错。JSON总体来说不太适合做比较复杂的配置文件

### 结语
在不考虑自建格式的情况下，如nginx的`nginx.conf`，如caddy的`Caddyfile`，将会同时兼容`toml`及`yaml`格式的配置文件。

15-从零用Rust编写正反向代理, 如果将nginx.conf转成yaml,toml,json会怎么样

# wmproxy
`wmproxy`是由`Rust`编写，已实现`http/https`代理，`socks5`代理， 反向代理，静态文件服务器，内网穿透，配置热更新等， 后续将实现`websocket`代理等，同时会将实现过程分享出来， 感兴趣的可以一起造个轮子法

## 项目 ++wmproxy++

[gite: https://gitee.com/tickbh/wmproxy](https://gitee.com/tickbh/wmproxy)

[github: https://github.com/tickbh/wmproxy](https://github.com/tickbh/wmproxy)

## HTTP文件服务器的意义

HTTP文件服务器的意义是可以**放置网站文件，可以放置数据文件**。
HTTP服务器一般指网站服务器，是指驻留于因特网上某种类型计算机的程序，可以处理浏览器等Web客户端的请求并返回相应响应。
当前大量的应用会依赖到文件服务器，比如我们非常熟悉的网站（会加载index.html)文件及各种css及js文件，比如我们的各种APP会有相对应的版本信息，会有相应的版本文件，又或者小程序本身就是一个可执行文件，当你点击的时候，应用去下载相应的小程序文件，然后在本地进行加载，然后打开提供服务。目前我们的互联网上冲浪完全无法离开文件服务器。

## HTTP文件服务器几大作用

**1. 文件共享**

> 文件服务器的主要功能是提供文件共享功能。它允许用户从他们自己的计算机或设备访问共享文件和文件夹，而不管他们的物理位置。用户可以查看、编辑和保存存储在服务器上的文件，所有有权访问该文件的用户都会自动更新更改。
> 以下是我们在聊天软件上发送一张图片给另一个人的流程

```mermaid
flowchart TD
A[你]
B[APP]
C[文件服务器]
D[APP服务器]
E[聊天对象]

A -->|将图片共享|B
B -->|将图片上传|C
C -->|返回图片地址|B
B -->|将图片地址推送给|D
D -->|将地址通知给|E
E -->|从文件服务器中获取图片|C
```

**2. 集中存储**

> 此时你的不小心将数据删除，此时你想找回原来的图片，以下是整个过程

```mermaid
flowchart TD
A[你]
B[APP]
C[文件服务器]
D[APP服务器]

D -->|同步旧的聊天记录, 获取图片地址|B
B -->|重新下载图片|C
B -->|获取完图片后推送给|A
```

此时文件服务器担任着集中存储的角色，海量的数据将汇聚在中心服务器上，我们可以通过网络访问到海量的数据资源。
**3. 备份与恢复**
上述过程，相当于服务器帮你备份了图片数据，在你不小心丢失的时候，可以恢复您的数据，我们最经常使用的如图片备份到网盘，一方面可以释放掉本地的空间，另一方面我们可以将数据保存到很久之后。
**4. 访问控制**
我们在获取到图片地址的时候，并不是任何的角色都可以获取到该图片的资源，在服务器内部中，会有相关的权限验证，在为您提供数据的同时，并保护着您的数据安全。

## file_server文件服务器

一个静态文件服务器，支持真实和虚拟文件系统。它通过将请求的URI路径附加到站点的根路径来形成文件路径。
最常见的是，file_server指令与root指令配对，为整个网站设置文件根。其中保证所有的访问仅能在root指定的目录之下，不能访问其上级的任何数据，故在root下的目录理论上即使禁目录访问也可能被全部访问到（暴力遍历），但在root上级的目录不可能被以任何的方式进行访问，即使添加`../`相对路径也不行。

## file_server参数相关

结构定义如下：

```rust
pub struct FileServer {
    #[serde(default = "default_root")]
    pub root: String,
    #[serde(default)]
    pub prefix: String,
    #[serde(default="default_hide")]
    pub hide: Vec<String>,
    #[serde(default = "default_index")]
    pub index: Vec<String>,
    #[serde(default = "default_status")]
    pub status: u16,
    #[serde(default = "default_precompressed")]
    pub precompressed: Vec<String>,
    #[serde(default)]
    pub disable_compress: bool,
    #[serde(default = "default_bool_true")]
    pub browse: bool,
}
```

*   **browse** 对没有索引文件的目录的请求，当前又是一个目录的情况下启用文件列表。
*   **root** 设置网站根目录。指向的是当前文件磁盘下的路径前缀，如`/file/`，那么提供服务的将是`/file/`的文件服务
*   **prefix** Url的前缀，如`/static/`，如果我们获取到一个请求路径如`/static/src/wmproxy.md`，那么我们会去掉前缀得到`src/wmproxy.md`，那么实际的指向为`/file/src/wmproxy.md`进行文件服务
*   **hide** 是一个要隐藏的文件或文件夹的列表；如果要求，文件服务器将假装它们不存在。该指令接受占位符和glob模式。注意，这些是 文件系统 路径，不是请求路径。换句话说，相对路径使用当前工作目录作为基础，而不是网站根目录；所有的路径在比较之前都会被转换为绝对形式（如果可能的话）。指定一个没有路径分隔符的文件名或模式，将隐藏所有具有匹配名称的文件，无论其位置如何；
*   **index** 是一个寻找索引文件的文件名列表。默认：`index.html index.htm`。
*   **precompressed** 是用于搜索预压缩挎包文件的编码格式列表。支持的格式有gzip（.gz），和br（.br）。所有的文件查找将首先寻找未压缩文件的存在。一旦找到，我们将以未添加之前的格式做`mimetype`，如`README.md.gz`取的是md的```mimetype```，也就是```text/plain```。并适当地设置Content-Encoding响应头。否则，将以正常的未压缩文件进行响应。如果encode指令被启用，那么如果没有预压缩，它可能会对响应进行即时压缩。如我们访问`README.md`，但此时目录下存在`README.md.gz`，那我们我们响应的是gz的文件，并设置`Content-Encoding: gzip`，如此做的好处，我们对该文件的任何请求，我们都无须耗任何压缩的时间，响应更快，我们可以用更高的压缩比来进行预压缩，可节省更多时间。
*   **status** 是一个可选的状态代码覆盖，在编写响应时使用。在用自定义错误页面响应请求时特别有用。可以是一个3位数的状态代码，例如：```404```。支持占位符。默认情况下，写入的状态代码通常是```200```，或```206```，用于部分内容。

- 当前目录外的静态文件服务器。
```yaml
reverse:
  file_server:
```
- 启用了文件列表:
```yaml
reverse:
  file_server:
    browse: true
```
- 只服务于`/static`文件夹中的静态文件:
```yaml
reverse:
  file_server:
    root: /static/
    browse: true
 ```
 - 隐藏所有.git文件夹及其内容。
```yaml
reverse:
  file_server:
    root: /static/
    browse: true
    hide: [.git]
 ```
 - 如果客户端支持（Accept-Encoding头），发送`gzip,br`，则检查请求的文件是否存在预压缩的文件。因此，如果/path/to/file被请求，/path/to/file.br和/path/to/file.gz`，并提供第一个具有相应内容编码的可用文件。
```yaml
reverse:
  file_server:
    root: /static/
    browse: true
    hide: [.git]
    precompressed: [br, gzip]
```

 ## `mimetype`作用
 多用途互联网邮件扩展`（MIME，Multipurpose Internet Mail Extensions）`是一个 互联网标准，它扩展了 电子邮件标准，使其能够支持非 ASCII字符、 二进制格式附件等多种格式的邮件消息。
 内容类型（Content-Type），这个头部领域用于指定消息的类型。一般以下面的形式出现。`[type]/[subtype]`

> type有下面的形式。

**Text**：用于标准化地表示的文本信息，文本消息可以是多种字符集和或者多种格式的；
**Multipart**：用于连接消息体的多个部分构成一个消息，这些部分可以是不同类型的数据；
**Application**：用于传输应用程序数据或者二进制数据；
**Message**：用于包装一个E-mail消息；
**Image**：用于传输静态图片数据；
**Audio**：用于传输音频或者音声数据；
**Video**：用于传输动态影像数据，可以是与音频编辑在一起的视频数据格式。

> `subtype`用于指定type的详细形式。type/subtype配对的集合和与此相关的参数，将随着时间而增长。为了确保这些值在一个有序而且公开的状态下开发，MIME使用Internet Assigned Numbers Authority (IANA)作为中心的注册机制来管理这些值。常用的subtype值如下所示：

- **text/plain**（纯文本）
- **text/html**（HTML文档）
- **application/xhtml+xml**（XHTML文档）
- **image/gif**（GIF图像）
- **image/jpeg**（JPEG图像）
- **image/png**（PNG图像）
- **video/mpeg**（MPEG动画）
- **application/octet-stream**（任意的二进制数据）
- **application/pdf**（PDF文档）
- **application/msword**（Microsoft Word文件）
- **message/rfc822**（ RFC 822形式）
- **multipart/alternative**（HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示）
- **application/x-www-form-urlencoded**（使用HTTP的POST方法提交的表单）
- **multipart/form-data**（同上，但主要用于表单提交时伴随文件上传的场合）

我们根据现有的已知的，我们用了静态变量做了以下数据定义，后续将会进行数据补充或者自定义
```rust
lazy_static! {
    static ref DEFAULT_MIMETYPE: HashMap<&'static str, &'static str> = {
        let mut m = HashMap::<&'static str, &'static str>::new();
        m.insert("doc", "application/msword");
        m.insert("pdf", "application/pdf");
        m.insert("rtf", "application/rtf");
        m.insert("xls", "application/vnd.ms-excel");
        m.insert("ppt", "application/vnd.ms-powerpoint");
        m.insert("rar", "application/application/x-rar-compressed");
        m.insert("swf", "application/x-shockwave-flash");
        m.insert("zip", "application/zip");
        m.insert("json", "application/json");
        m.insert("yaml", "text/plain");
        m.insert("mid", "audio/midi");
        m.insert("midi", "audio/midi");
        m.insert("kar", "audio/midi");
        m.insert("mp3", "audio/mpeg");
        m.insert("ogg", "audio/ogg");
        m.insert("m4a", "audio/m4a");
        m.insert("ra", "audio/x-realaudio");
        m.insert("gif", "image/gif");
        m.insert("jpeg", "image/jpeg");
        m.insert("jpg", "image/jpeg");
        m.insert("png", "image/png");
        m.insert("tif", "image/tiff");
        m.insert("tiff", "image/tiff");
        m.insert("wbmp", "image/vnd.wap.wbmp");
        m.insert("ico", "image/x-icon");
        m.insert("jng", "image/x-jng");
        m.insert("bmp", "image/x-ms-bmp");
        m.insert("svg", "image/svg+xml");
        m.insert("svgz", "image/svg+xml");
        m.insert("webp", "image/webp");
        m.insert("svg", "image/svg+xml");
        m.insert("css", "text/css");
        m.insert("html", "text/html");
        m.insert("htm", "text/html");
        m.insert("shtml", "text/html");
        m.insert("txt", "text/plain");
        m.insert("md", "text/plain");
        m.insert("xml", "text/xml");
        m.insert("3gpp", "video/3gpp");
        m.insert("3gp", "video/3gpp");
        m.insert("mp4", "video/mp4");
        m.insert("mpeg", "video/mpeg");
        m.insert("mpg", "video/mpeg");
        m.insert("mov", "video/quicktime");
        m.insert("webm", "video/webm");
        m.insert("flv", "video/x-flv");
        m.insert("m4v", "video/x-m4v");
        m.insert("wmv", "video/x-ms-wmv");
        m.insert("avi", "video/x-msvideo");
        m
    };
}
```

## 源码实现
> 源码主要实现在`file_server.rs`的`deal_request`函数。节选
```rust
pub async fn deal_request(
    &self,
    req: Request<RecvStream>,
) -> ProtResult<Response<RecvStream>> {
    let path = req.path().clone();
    // 无效前缀，无法处理
    if !path.starts_with(&self.prefix) {
        return Ok(self.ret_error_msg("unknow path"));
    }
    let root_path = Path::new(&self.root);
    let mut real_path = Path::new(&real_path).to_owned();
    // 必须保证不会跑出root设置的目录之外，如故意访问`../`之类的
    if !real_path.starts_with(root_path) || self.is_hide_path(root_path.as_ref()) {
        return Ok(self.ret_error_msg("can't view parent file"));
    }
    // 访问路径是目录，尝试是否有index的文件，如果有还是以文件访问
    if real_path.is_dir() {
        for index in &self.index {
            let new_path = real_path.join(index);
            if new_path.exists() {
                real_path = new_path;
                break;
            }
        }
    }

    // 访问为目录，如果启用目录访问，则返回当前的文件夹的内容
    if real_path.is_dir() {
        if !self.browse {
            return Ok(self.ret_error_msg("can't view parent file"));
        }
        let mut binary = BinaryMut::new();
        // ... 
        let recv = RecvStream::only(binary.freeze());
        let builder = Response::builder().version(req.version().clone());
        let mut response = builder
            .header(HeaderName::CONTENT_TYPE, "text/html; charset=utf-8")
            .body(recv)
            .map_err(|_err| io::Error::new(io::ErrorKind::Other, ""))?;
        if self.disable_compress {
            response.headers_mut().insert(HeaderName::CONTENT_ENCODING, "");
        }
        return Ok(response);
    } else {

        // 访问为文件，判断当前的后缀，返回合适的mimetype，如果有合适的预压缩文件，也及时返回
        if self.is_hide_path(path.as_ref()) {
            return Ok(self.ret_error_msg("can't view file"));
        }
        // 获取后缀
        let extension = if let Some(s) = real_path.extension() {
            s.to_string_lossy().to_string()
        } else {
            String::new()
        };
        let application = DEFAULT_MIMETYPE.get(&*extension).unwrap_or(&"");
        //查找是否有合适的预压缩文件
        if let Some(accept) = req.headers().get_option_value(&HeaderName::ACCEPT_ENCODING) {
            for pre in &self.precompressed {
                // 得客户端发送支持该格式
                if !accept.contains(pre.as_bytes()) {
                    continue;
                }
                let mut new = real_path.clone();
                new.as_mut_os_string().push(".");
                match &**pre {
                    "gzip" => new.as_mut_os_string().push("gz"),
                    "br" => new.as_mut_os_string().push("br"),
                    _ => continue,
                };
                // 如果预压缩文件存在
                if new.exists() {
                    println!("convert to new file {}", new.to_string_lossy());
                    let file = File::open(new).await?;
                    let mut recv = RecvStream::new_file(file, BinaryMut::new(), false);
                    match &**pre {
                        "gzip" => recv.set_compress_origin_gzip(),
                        "br" => recv.set_compress_brotli(),
                        _ => unreachable!(),
                    }
                    // ...
                    return Ok(response);
                }
            }
        }

        if !real_path.exists() {
            return Ok(self.ret_error_msg("can't view file"));
        }

        // ...
        return Ok(response);
    }
}
```

## 结语
> 如此静态文件服务器则已初步实现，文件服务中的压缩及流式传输已基本完成

14-从零用Rust编写正反向代理, HTTP文件服务器的实现过程及参数

# wmproxy
`wmproxy`是由`Rust`编写，已实现`http/https`代理，`socks5`代理， 反向代理，静态文件服务器，内网穿透，配置热更新等， 后续将实现`websocket`代理等，同时会将实现过程分享出来， 感兴趣的可以一起造个轮子法

## 项目 ++wmproxy++
[gite: https://gitee.com/tickbh/wmproxy](https://gitee.com/tickbh/wmproxy)

[github: https://github.com/tickbh/wmproxy](https://github.com/tickbh/wmproxy)


## HTTP中压缩的意义
HTTP中压缩的意义在于降低了网络传输的数据量，从而提高客户端浏览器的访问速度。当然，同时也会增加一点服务器的负担。
HTTP/1.1协议中压缩主要包括gzip压缩和deflate压缩两种方法。其中gzip压缩使用的是LZ77和哈夫曼编码，而deflate压缩使用的是LZ77和哈夫曼编码以及霍夫曼编码。
此外在2015年由Google公司开发的Brotli算法是也基本全面普及开来，Brotli算法的核心原理包括两个部分：预定义的字典和无损压缩算法。预定义的字典是Brotli算法中的一项关键技术，它包含了一些常见的字符序列，例如Web标记、HTML、CSS和JavaScript代码等。Brotli算法的无损压缩算法采用了一种基于模式匹配的压缩方法。它通过预测数据中出现的重复模式，对数据进行压缩。
在HTTP的压缩协议中，这三种压缩算法基本上可以全部被支持。

### gzip,deflate,brotli的优劣势
gzip、deflate和brotli这三种压缩算法都有各自的优势和劣势，具体如下：

1. **gzip**
- 优势：是Web上最常见的压缩算法之一，具有较高的压缩效率和广泛的支持程度，可以被几乎所有的浏览器和服务器支持。
- 劣势：算法的压缩比相对较低，可能会增加文件的大小。
2. **deflate**
- 优势：具有较高的压缩效率和广泛的支持程度，同时算法的实现在不同的浏览器和服务器之间非常一致。
- 劣势：由于某些实现上的缺陷，可能会导致一些浏览器和服务器无法正常解压缩。
3. **brotli**
- 优势：具有更高的压缩效率和更快的压缩速度，可以进一步减少传输数据的大小，从而提高页面加载速度，并且被较新版本的浏览器和服务器支持。
- 劣势：由于算法目前仅被较新版本的浏览器和服务器支持，因此需要根据实际情况进行选择。

以下是压缩解压的数率图：

![图片.png](http://47.97.231.149/static/img/29413bd86ad6b2d32cef60110c03955d.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

![图片.png](http://47.97.231.149/static/img/989ceea229dfb2c23dcd3046788486d2.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

![图片.png](http://47.97.231.149/static/img/a5c13f4a39699d772cceb9e5cc6f9265.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

数据来源[src](https://quixdb.github.io/squash-benchmark/#results-table)

> 可以看出brotli的压缩比大概在9左右，gzip大概在7左右，deflate也大概在7左右，压缩比brotli最高，适应网络传输慢的情况，压缩速度gzip和deflate相对较快，解压缩deflate较快，brotli和gzip差不多。

### rust中三种压缩方式库的选择
通常寻找rust中的第三方库的时候，可以通过```https://crates.io/```进行选择，这里公开的第三方库都会在这里显示，包括使用次数，流行热度，最近下载量，最近更新时间等，可以从多维度的知道该库的好与坏再进行相应的选择。
- **flate2**
![image.png](https://note.youdao.com/yws/res/6325/WEBRESOURCE8827be6409e7683acdcf8577c3125cd5)
该库支持三种压缩格式的算法，```deflate```, ```zlib```, ```gzip```，我们选择用它来做```deflate```, ```gzip```的支持。

- **brotli**
![image.png](https://note.youdao.com/yws/res/6334/WEBRESOURCE486c9e72871b6399f83ab8084c43d3b5)
该库如库名一般，只支持```brotli```算法，相对热度较高，算是支持brolti里最好的一个，我们进行选择。

### 三种方式的压缩实现
> 三种方式均可实现流式的压缩，即边写入数据，边读出压缩数据，不用完全的写入所有数据，完整的实现方法在 [RecvStream](https://github.com/tickbh/wenmeng/blob/main/src/protocol/recv_stream.rs)里，将压缩的数据缓存到```self.cache_body_data```中

定义压缩方法值
```rust
pub const COMPRESS_METHOD_NONE: i8 = 0;
pub const COMPRESS_METHOD_GZIP: i8 = 1;
pub const COMPRESS_METHOD_DEFLATE: i8 = 2;
pub const COMPRESS_METHOD_BROTLI: i8 = 3;
```

- **gzip**
> 此处利用的是类```use flate2::write::GzEncoder```，定义为```GzEncoder<BinaryMut>```，其中BinaryMut为压缩后的数据，需要具备```std::io::Write```方法。
```rust
Consts::COMPRESS_METHOD_GZIP => {
    // 数据结束，需要主动调用结束以导出全部结果
    if data.len() == 0 {
        self.compress.open_write_gz();
        let gz = self.compress.write_gz.take().unwrap();
        let value = gz.finish().unwrap();
        if value.remaining() > 0 {
            Self::inner_encode_data(&mut self.cache_body_data, &value, self.is_chunked)?;
        }
        if self.is_chunked {
            Helper::encode_chunk_data(&mut self.cache_body_data, data)
        } else {
            Ok(0)
        }
    } else {
        self.compress.open_write_gz();
        let gz = self.compress.write_gz.as_mut().unwrap();
        gz.write_all(data).unwrap();
        // 每次写入，在尝试读取出数据
        if gz.get_mut().remaining() > 0 {
            let s =
                Self::inner_encode_data(&mut self.cache_body_data, &gz.get_mut().chunk(), self.is_chunked);
            gz.get_mut().clear();
            s
        } else {
            Ok(0)
        }
    }
}
```

- **deflate**
> 此处利用的是类```use flate2::write::DeflateEncoder```，定义为```DeflateEncoder<BinaryMut>```，其中BinaryMut为压缩后的数据，需要具备```std::io::Write```方法。
```rust
Consts::COMPRESS_METHOD_DEFLATE => {
    // 数据结束，需要主动调用结束以导出全部结果
    if data.len() == 0 {
        self.compress.open_write_de();
        let de = self.compress.write_de.take().unwrap();
        let value = de.finish().unwrap();
        if value.remaining() > 0 {
            Self::inner_encode_data(&mut self.cache_body_data, &value, self.is_chunked)?;
        }
        if self.is_chunked {
            Helper::encode_chunk_data(&mut self.cache_body_data, data)
        } else {
            Ok(0)
        }
    } else {
        self.compress.open_write_de();
        let de = self.compress.write_de.as_mut().unwrap();
        de.write_all(data).unwrap();
        // 每次写入，在尝试读取出数据
        if de.get_mut().remaining() > 0 {
            let s =
                Self::inner_encode_data(&mut self.cache_body_data, &de.get_mut().chunk(), self.is_chunked);
            de.get_mut().clear();
            s
        } else {
            Ok(0)
        }
    }
}
```


- **brotli**
> 此处利用的是类```use brotli::CompressorWriter;```，定义为```CompressorWriter<BinaryMut>```，其中BinaryMut为压缩后的数据，需要具备```std::io::Write```方法。
```rust
Consts::COMPRESS_METHOD_BROTLI => {
    // 数据结束，需要主动调用结束以导出全部结果
    if data.len() == 0 {
        self.compress.open_write_br();
        let mut de = self.compress.write_br.take().unwrap();
        de.flush()?;
        let value = de.into_inner();
        if value.remaining() > 0 {
            Self::inner_encode_data(&mut self.cache_body_data, &value, self.is_chunked)?;
        }
        if self.is_chunked {
            Helper::encode_chunk_data(&mut self.cache_body_data, data)
        } else {
            Ok(0)
        }
    } else {
        self.compress.open_write_br();
        let de = self.compress.write_br.as_mut().unwrap();
        de.write_all(data).unwrap();
        // 每次写入，在尝试读取出数据
        if de.get_mut().remaining() > 0 {
            let s =
                Self::inner_encode_data(&mut self.cache_body_data, &de.get_mut().chunk(), self.is_chunked);
            de.get_mut().clear();
            s
        } else {
            Ok(0)
        }
    }
}
```

### 三种方式的解压实现
> 和压缩不同的是，解压的时候必须将完整的数据进行解压，所以需要收到全部的数据的时候才尝试进行解压，可能我的理解有误，欢迎指出，当下的实现方式可能会占用大量的内存，非我所愿。主要源码在 [SendStream](https://github.com/tickbh/wenmeng/blob/main/src/protocol/send_stream.rs)中实现。

三种方式均类似，以下
```rust
// 收到数据进行缓存，只有到结束时才进行解压缩
match self.compress_method {
    Consts::COMPRESS_METHOD_GZIP => {
        self.cache_body_data.put_slice(data);
        if self.is_end {
            self.compress.open_reader_gz(self.cache_body_data.clone());
            let gz = self.compress.reader_gz.as_mut().unwrap();
            let s = Self::read_all_data(&mut self.cache_buf, &mut self.real_read_buf, gz);
            self.cache_body_data.clear();
            s
        } else {
            Ok(0)
        }
    }
    Consts::COMPRESS_METHOD_DEFLATE => {
        self.cache_body_data.put_slice(data);
        if self.is_end {
            self.compress.open_reader_de(self.cache_body_data.clone());
            let de = self.compress.reader_de.as_mut().unwrap();
            let s = Self::read_all_data(&mut self.cache_buf, &mut self.real_read_buf, de);
            self.cache_body_data.clear();
            s
        } else {
            Ok(0)
        }
    }
    Consts::COMPRESS_METHOD_BROTLI => {
        self.cache_body_data.put_slice(data);
        if self.is_end {
            self.compress.open_reader_br(self.cache_body_data.clone());
            let br = self.compress.reader_br.as_mut().unwrap();
            let s = Self::read_all_data(&mut self.cache_buf, &mut self.real_read_buf, br);
            self.cache_body_data.clear();
            s
        } else {
            Ok(0)
        }
    }
    _ => {
        self.real_read_buf.put_slice(data);
        Ok(data.len())
    },
}
```
如果数据包非常的巨大的时候，可能需要将内存内容写入缓存文件来缓解内存的压力。

### 结语
压缩为了可以更好的存储，也可以更好的传输，是我们日常生活中必不可少的存在，虽然现在比以前带宽更高，存储比之前的更便宜，但是现在的数据更多，传输延时要求更少，所以高压缩的能力依然非常受欢迎。

13-从零用Rust编写正反向代理, HTTP中的压缩gzip,deflate,brotli算法

# wmproxy
`wmproxy`是由`Rust`编写，已实现`http/https`代理，`socks5`代理， 反向代理，静态文件服务器，内网穿透，配置热更新等， 后续将实现`websocket`代理等，同时会将实现过程分享出来， 感兴趣的可以一起造个轮子法

## 项目 ++wmproxy++
[gite: https://gitee.com/tickbh/wmproxy](https://gitee.com/tickbh/wmproxy)

[github: https://github.com/tickbh/wmproxy](https://github.com/tickbh/wmproxy)


## 什么是TLS双向认证
TLS双向认证是指**客户端和服务器端都需要验证对方的身份**，也称```mTLS```。

在建立Https连接的过程中，握手的流程比单向认证多了几步。
- 单向认证的过程，客户端从服务器端下载服务器端公钥证书进行验证，然后建立安全通信通道。
- 双向通信流程，客户端除了需要从服务器端下载服务器的公钥证书进行验证外，还需要把客户端的公钥证书上传到服务器端给服务器端进行验证，等双方都认证通过了，才开始建立安全通信通道进行数据传输。

TLS是安全套接层(SSL)的继任者，叫传输层安全(transport layer security)。说直白点，就是在明文的上层和TCP层之间加上一层加密，这样就保证上层信息传输的安全，然后解密完后又以原样的数据回传给应用层，做到与应用层无关，所以http加个s就成了https，ws加个s就成了wss，ftp加个s就成了ftps，都是从普通tcp传输转换成tls传输实现安全加密，应用相当广泛。

### 单向与双向的差别
#### SSL单向验证
单向通讯的示意图如下
```mermaid
sequenceDiagram
Client->>Server: Client Hello
Client->>Server: 包含SSL/TLS版本，对称加密算法列表，随机数A

Server-->>Client: Server Hello，服务端先进行选择
Server-->>Client: 双方都支持的SSL/TLS协议版本，对称加密算法
Server-->>Client: 公钥证书，服务端生成的随机数B
Server-->>Client: Change Cipher Spec，收到这消息后开始密文传输

Client-)Client: 验证证书，是否过期，是否被吊销，是否可信，域名是否一致
Client->>Server: Change Cipher Spec
Client->>Server: 应用数据（客户端加密）
Server-->>Client: 应用数据（服务端加密）
```
双向通讯的示意图如下，差别
```mermaid
sequenceDiagram
    Client->>Server: Client Hello
    Server-->>Client: Server Hello
    
    rect rgba(0, 0, 255, 0.5)
    Server-->>Client: 额外要求客户端提供客户端证书
    end
    
    Client-)Client: 验证证书
    
    rect rgba(0, 0, 255, 0.5)
    Client-->>Server: 客户端证书
    Client-->>Server: 客户端证书验证信息（CertificateVerify message）
    Server->Server: 验证客户端证书是否有效
    Server->Server: 验证客户端证书验证消息的签名是否有效
    end
    
    Server-->>Client: 握手结束
    Client->>Server: 握手结束
    
```
> 备注：客户端将之前所有收到的和发送的消息组合起来，并用hash算法得到一个hash值，然后用客户端密钥库的私钥对这个hash进行签名，这个签名就是CertificateVerify message；
### 代码实现
将原来的```rustls```中的TlsAcceptor和TlsConnector进行相应的改造，变成可支持双向认证的加密结构。
> 获取TlsAcceptor的认证
```
/// 获取服务端https的证书信息
pub async fn get_tls_accept(&mut self) -> ProxyResult<TlsAcceptor> {
    if !self.tc {
        return Err(ProxyError::ProtNoSupport);
    }
    let certs = Self::load_certs(&self.cert)?;
    let key = Self::load_keys(&self.key)?;

    let config = rustls::ServerConfig::builder().with_safe_defaults();

    // 开始双向认证，需要客户端提供证书信息
    let config = if self.two_way_tls {
        let mut client_auth_roots = rustls::RootCertStore::empty();
        for root in &certs {
            client_auth_roots.add(&root).unwrap();
        }
        let client_auth = rustls::server::AllowAnyAuthenticatedClient::new(client_auth_roots);

        config
            .with_client_cert_verifier(client_auth.boxed())
            .with_single_cert(certs, key)
            .map_err(|err| io::Error::new(io::ErrorKind::InvalidInput, err))?
    } else {
        config
            .with_no_client_auth()
            .with_single_cert(certs, key)
            .map_err(|err| io::Error::new(io::ErrorKind::InvalidInput, err))?
    };

    let acceptor = TlsAcceptor::from(Arc::new(config));
    Ok(acceptor)
}
```


> 获取TlsAcceptor的认证
```rust
/// 获取客户端https的Config配置
pub async fn get_tls_request(&mut self) -> ProxyResult<Arc<rustls::ClientConfig>> {
    if !self.ts {
        return Err(ProxyError::ProtNoSupport);
    }
    let certs = Self::load_certs(&self.cert)?;
    let mut root_cert_store = rustls::RootCertStore::empty();
    // 信任通用的签名商
    root_cert_store.add_trust_anchors(
        webpki_roots::TLS_SERVER_ROOTS
            .iter()
            .map(|ta| {
                rustls::OwnedTrustAnchor::from_subject_spki_name_constraints(
                    ta.subject,
                    ta.spki,
                    ta.name_constraints,
                )
            }),
    );
    for cert in &certs {
        let _ = root_cert_store.add(cert);
    }
    let config = rustls::ClientConfig::builder()
        .with_safe_defaults()
        .with_root_certificates(root_cert_store);

    if self.two_way_tls {
        let key = Self::load_keys(&self.key)?;
        Ok(Arc::new(config.with_client_auth_cert(certs, key).map_err(
            |err| io::Error::new(io::ErrorKind::InvalidInput, err),
        )?))
    } else {
        Ok(Arc::new(config.with_no_client_auth()))
    }
}
```
这里默认信任的通用的CA签发证书平台，像系统证书，浏览器信任的证书，只有第一步把基础的被信任才有资格做签发证书平台。

> 至此双向TLS的能力已经达成，感谢前人的经典代码才能如此轻松。

### token验证
首先先定义协议的Token结构，只有sock_map为0接收此消息
```rust
/// 进行身份的认证
#[derive(Debug)]
pub struct ProtToken {
    username: String,
    password: String,
}
```
下面是编码解码，密码要求不超过255个字符，即长度为1字节编码
```rust
pub fn parse<T: Buf>(_header: ProtFrameHeader, mut buf: T) -> ProxyResult<ProtToken> {
    let username = read_short_string(&mut buf)?;
    let password = read_short_string(&mut buf)?;
    Ok(Self { username, password })
}

pub fn encode<B: Buf + BufMut>(self, buf: &mut B) -> ProxyResult<usize> {
    let mut head = ProtFrameHeader::new(ProtKind::Token, ProtFlag::zero(), 0);
    head.length = self.username.as_bytes().len() as u32 + 1 + self.password.as_bytes().len() as u32 + 1;
    let mut size = 0;
    size += head.encode(buf)?;
    size += write_short_string(buf, &self.username)?;
    size += write_short_string(buf, &self.password)?;
    Ok(size)
}
```

#### 服务端处理
如果服务端启动的时候配置了```username``` 及 ```password```则表示他需要密码验证，
```rust
let mut verify_succ = option.username.is_none() && option.password.is_none();
```
如果```verify_succ```不为true，那么我们接下来的第一条消息必须为```ProtToken```，否则客户端不合法，关闭
收到该消息则进行验证
```rust
match &p {
    ProtFrame::Token(p) => {
        if !verify_succ
            && p.is_check_succ(&option.username, &option.password)
        {
            verify_succ = true;
            continue;
        }
    }
    _ => {}
}
if !verify_succ {
    ProtFrame::new_close_reason(0, "not verify so close".to_string())
        .encode(&mut write_buf)?;
    is_ready_shutdown = true;
    break;
}
```

> 认证通过后消息处理和之前的一样，验证流程完成

12-从零用Rust编写正反向代理, TLS的双向认证信息及token验证

用Rust实现http/https代理, socks5代理, 负载均衡, 反向代理, 静态文件服务器，四层TCP/UDP转发，websocket转发, 内网穿透nat 