# 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)


### 事件模型的选取
- **OS线程**, 简单的一个IO对应一个系统级别的线程，通常单进程创建的线程数是有限的，在线程与线程间同步数据会相当困难，线程间的调度争用会相当损耗效率，不适合IO密集的场景。
- **事件驱动(Event driven)**, 事件驱动基本上是最早的高并发的IO密集型的编程模式了，如C++的libevent，RUST的MIO，通过监听IO的可读可写从而进行编程设计，缺点通常跟回调( Callback )一起使用，如果使用不好，回调层级过多会有回调地狱的风险。
- **协程(Coroutines)** 可能是目前比较火的并发模型，火遍全球的```Go语言```的协程设计就非常优秀。协程跟线程类似，无需改变编程模型，同时它也跟```async```类似，可以支持大量的任务并发运行。
- **actor模型** 是erlang的杀手锏之一，它将所有并发计算分割成一个一个单元，这些单元被称为```actor```,单元之间通过消息传递的方式进行通信和数据传递，跟分布式系统的设计理念非常相像。由于```actor```模型跟现实很贴近，因此它相对来说更容易实现，但是一旦遇到流控制、失败重试等场景时，就会变得不太好用
- **async/await**， 该模型为异步编辑模型，```async```模型的问题就是内部实现机制过于复杂，对于用户来说，理解和使用起来也没有线程和协程简单。主要是等待完成状态```await```，就比如读socket数据，等待系统将数据送达再继续触发读操作的执行，从而答到无损耗的运行。
> 这里我们选择的是```async/await```的模式

### Rust中的async

- **Future 在 Rust 中是惰性的**，只有在被轮询(`poll`)时才会运行， 因此丢弃一个 `future` 会阻止它未来再被运行, 你可以将`Future`理解为一个在未来某个时间点被调度执行的任务。在Rust中调用异步函数没有用await会被编辑器警告，因为这不符合预期。
- **Async 在 Rust 中使用开销是零**， 意味着只有你能看到的代码(自己的代码)才有性能损耗，你看不到的(`async` 内部实现)都没有性能损耗，例如，你可以无需分配任何堆内存、也无需任何动态分发来使用 `async`，这对于热点路径的性能有非常大的好处，正是得益于此，Rust 的异步编程性能才会这么高。
- **Rust 异步运行时**，Rust社区生态中已经提供了非常优异的运行时实现例如[`tokio`](https://tokio.rs)，官方版本的async目前的生态相对```tokio```会差许多
- **运行时同时支持单线程和多线程**


### 流代码的封装
> 跟数据通讯相关的代码均放在```streams```目录下面。
1. ```center_client.rs```中的```CenterClient```表示中心客户端，提供主动连接服务端的能力并可选择为加密（```TLS```）或者普通模式，并且将该客户端收发的消息转给服务端
2. ```center_server.rs```中的```CenterServer```表示中心服务端，接受中心客户端的连接，并且将信息处理或者转发
3. ```trans_stream.rs```中的```TransStream```表示转发流量端，提供与中心端绑定的读出写入功能，在代理服务器中客户端接收的连接因为无需处理任何数据，直接绑定为```TransStream```将数据完整的转发给服务端
4. ```virtual_stream.rs```中的```VirtualStream```表示虚拟端，虚拟出一个流连接，并实现AsyncRead及AsyncRead，可以和流一样正常操作，在代理服务器中服务端接收到新连接，把他虚拟成一个```VirtualStream```，就可以直接和他连接的服务器上做双向绑定。

#### 几种流式在代码中的转化
##### HTTP代理
> 下面展示的是http代理，通过加密TLS中的转化

```mermaid
flowchart TD
    A[TcpStream请求到代理]<-->|建立连接/明文|B[代理转化成TransStream]
    B<-->|转发到/内部|C[中心客户端]
    C<-->|建立加密连接/加密|D[TlsStream< TcpStream>绑定中心服务端]
    D<-->|收到Create/内部|E[虚拟出VirtualStream]
    E<-->|解析到host并连接/明文|F[TcpStream连接到http服务器]
```
上述过程实现了程序中实现了http的代理转发

##### HTTP内网穿透
> 以下是http内网穿透在代理中的转化

```mermaid
flowchart TD
    A[服务端绑定http对外端口]<-->|接收连接/明文|B[外部的TcpStream]
    B<-->|转发到/内部|C[中心服务端并绑定TransStream]
    C<-->|通过客户的加密连接推送/加密|D[TlsStream< TcpStream>绑定中心客户端]
    D<-->|收到Create/内部|E[虚拟出VirtualStream]
    E<-->|解析对应的连接信息/明文|F[TcpStream连接到内网的http服务器]
```
上述过程可以主动把公网的请求连接转发到内网，由内网提供完服务后再转发到公网的请求，从而实现内网穿透。

### 流代码的介绍

#### CenterClient中心客端
> 下面是代码类的定义
```rust
/// 中心客户端
/// 负责与服务端建立连接，断开后自动再重连
pub struct CenterClient {
    /// tls的客户端连接信息
    tls_client: Option<Arc<rustls::ClientConfig>>,
    /// tls的客户端连接域名
    domain: Option<String>,
    /// 连接中心服务器的地址
    server_addr: SocketAddr,
    /// 内网映射的相关消息
    mappings: Vec<MappingConfig>,
    /// 存在普通连接和加密连接，此处不为None则表示普通连接
    stream: Option<TcpStream>,
    /// 存在普通连接和加密连接，此处不为None则表示加密连接
    tls_stream: Option<TlsStream<TcpStream>>,
    /// 绑定的下一个sock_map映射
    next_id: u32,

    /// 发送Create，并将绑定的Sender发到做绑定
    sender_work: Sender<(ProtCreate, Sender<ProtFrame>)>,
    /// 接收的Sender绑定，开始服务时这值move到工作协程中，所以不能二次调用服务
    receiver_work: Option<Receiver<(ProtCreate, Sender<ProtFrame>)>>,

    /// 发送协议数据，接收到服务端的流数据，转发给相应的Stream
    sender: Sender<ProtFrame>,
    /// 接收协议数据，并转发到服务端。
    receiver: Option<Receiver<ProtFrame>>,
}
```

> 主要的逻辑流程，循环监听数据流的到达，同时等待多个异步的到达，这里用的是```tokio::select!```宏
```rust
loop {
    let _ = tokio::select! {
        // 严格的顺序流
        biased;
        // 新的流建立，这里接收Create并进行绑定
        r = receiver_work.recv() => {
            if let Some((create, sender)) = r {
                map.insert(create.sock_map(), sender);
                let _ = create.encode(&mut write_buf);
            }
        }
        // 数据的接收，并将数据写入给远程端
        r = receiver.recv() => {
            if let Some(p) = r {
                let _ = p.encode(&mut write_buf);
            }
        }
        // 数据的等待读取，一旦流可读则触发，读到0则关闭主动关闭所有连接
        r = reader.read(&mut vec) => {
            match r {
                Ok(0)=>{
                    is_closed=true;
                    break;
                }
                Ok(n) => {
                    read_buf.put_slice(&vec[..n]);
                }
                Err(_err) => {
                    is_closed = true;
                    break;
                },
            }
        }
        // 一旦有写数据，则尝试写入数据，写入成功后扣除相应的数据
        r = writer.write(write_buf.chunk()), if write_buf.has_remaining() => {
            match r {
                Ok(n) => {
                    write_buf.advance(n);
                    if !write_buf.has_remaining() {
                        write_buf.clear();
                    }
                }
                Err(e) => {
                    println!("center_client errrrr = {:?}", e);
                },
            }
        }
    };

    loop {
        // 将读出来的数据全部解析成ProtFrame并进行相应的处理，如果是0则是自身消息，其它进行转发
        match Helper::decode_frame(&mut read_buf)? {
            Some(p) => {
                match p {
                    ProtFrame::Create(p) => {
                    }
                    ProtFrame::Close(_) | ProtFrame::Data(_) => {
                    },
                }
            }
            None => {
                break;
            }
        }
    }
}
```


#### CenterServer中心服务端
> 下面是代码类的定义
```rust
/// 中心服务端
/// 接受中心客户端的连接，并且将信息处理或者转发
pub struct CenterServer {
    /// 代理的详情信息，如用户密码这类
    option: ProxyOption,
    
    /// 发送协议数据，接收到服务端的流数据，转发给相应的Stream
    sender: Sender<ProtFrame>,
    /// 接收协议数据，并转发到服务端。
    receiver: Option<Receiver<ProtFrame>>,

    /// 发送Create，并将绑定的Sender发到做绑定
    sender_work: Sender<(ProtCreate, Sender<ProtFrame>)>,
    /// 接收的Sender绑定，开始服务时这值move到工作协程中，所以不能二次调用服务
    receiver_work: Option<Receiver<(ProtCreate, Sender<ProtFrame>)>>,
    /// 绑定的下一个sock_map映射，为双数
    next_id: u32,
}
```

> 主要的逻辑流程，循环监听数据流的到达，同时等待多个异步的到达，这里用的是```tokio::select!```宏，select处理方法与Client相同，均处理相同逻辑，不同的是接收数据包后数据端是处理的proxy的请求，而Client处理的是内网穿透的逻辑
```rust
loop {
    // 将读出来的数据全部解析成ProtFrame并进行相应的处理，如果是0则是自身消息，其它进行转发
    match Helper::decode_frame(&mut read_buf)? {
        Some(p) => {
            match p {
                ProtFrame::Create(p) => {
                    tokio::spawn(async move {
                        let _ = Proxy::deal_proxy(stream, flag, username, password, udp_bind).await;
                    });
                }
                ProtFrame::Close(_) | ProtFrame::Data(_) => {
                },
            }
        }
        None => {
            break;
        }
    }
}
```


#### TransStream转发流量端
> 下面是代码类的定义
```rust
/// 转发流量端
/// 提供与中心端绑定的读出写入功能
pub struct TransStream<T>
where
    T: AsyncRead + AsyncWrite + Unpin,
{
    // 流有相应的AsyncRead + AsyncWrite + Unpin均可
    stream: T,
    // sock绑定的句柄
    id: u32,
    // 读取的数据缓存，将转发成ProtFrame
    read: BinaryMut,
    // 写的数据缓存，直接写入到stream下，从ProtFrame转化而来
    write: BinaryMut,
    // 收到数据通过sender发送给中心端
    in_sender: Sender<ProtFrame>,
    // 收到中心端的写入请求，转成write
    out_receiver: Receiver<ProtFrame>,
}
```

> 主要的逻辑流程，循环监听数据流的到达，同时等待多个异步的到达，这里用的是```tokio::select!```宏，监听的对象有stream可读，可写，sender的写发送及receiver的可接收
```rust
loop {
    // 有剩余数据，优先转化成Prot，因为数据可能从外部直接带入
    if self.read.has_remaining() {
        link.push_back(ProtFrame::new_data(self.id, self.read.copy_to_binary()));
        self.read.clear();
    }

    tokio::select! {
        n = reader.read(&mut buf) => {
            let n = n?;
            if n == 0 {
                return Ok(())
            } else {
                self.read.put_slice(&buf[..n]);
            }
        },
        r = writer.write(self.write.chunk()), if self.write.has_remaining() => {
            match r {
                Ok(n) => {
                    self.write.advance(n);
                    if !self.write.has_remaining() {
                        self.write.clear();
                    }
                }
                Err(_) => todo!(),
            }
        }
        r = self.out_receiver.recv() => {
            if let Some(v) = r {
                if v.is_close() || v.is_create() {
                    return Ok(())
                } else if v.is_data() {
                    match v {
                        ProtFrame::Data(d) => {
                            self.write.put_slice(&d.data().chunk());
                        }
                        _ => unreachable!(),
                    }
                }
            } else {
                return Err(io::Error::new(io::ErrorKind::InvalidInput, "invalid frame"))
            }
        }
        p = self.in_sender.reserve(), if link.len() > 0 => {
            match p {
                Err(_)=>{
                    return Err(io::Error::new(io::ErrorKind::InvalidInput, "invalid frame"))
                }
                Ok(p) => {
                    p.send(link.pop_front().unwrap())
                }, 
            }
        }
    }
```


#### VirtualStream虚拟端
> 下面是代码类的定义，我们并未有真实的socket，通过虚拟出的端方便后续的操作
```rust
/// 虚拟端
/// 虚拟出一个流连接，并实现AsyncRead及AsyncRead，可以和流一样正常操作
pub struct VirtualStream
{
    // sock绑定的句柄
    id: u32,
    // 收到数据通过sender发送给中心端
    sender: PollSender<ProtFrame>,
    // 收到中心端的写入请求，转成write
    receiver: Receiver<ProtFrame>,
    // 读取的数据缓存，将转发成ProtFrame
    read: BinaryMut,
    // 写的数据缓存，直接写入到stream下，从ProtFrame转化而来
    write: BinaryMut,
}
```

> 虚拟的流主要通过实现AsyncRead及AsyncWrite
```rust

impl AsyncRead for VirtualStream
{
    // 有读取出数据，则返回数据，返回数据0的Ready状态则表示已关闭
    fn poll_read(
        mut self: std::pin::Pin<&mut Self>,
        cx: &mut [std](https://note.youdao.com/)[link](https://note.youdao.com/)::task::Context<'_>,
        buf: &mut tokio::io::ReadBuf<'_>,
    ) -> std::task::Poll<std::io::Result<()>> {
        loop {
            match self.receiver.poll_recv(cx) {
                Poll::Ready(value) => {
                    if let Some(v) = value {
                        if v.is_close() || v.is_create() {
                            return Poll::Ready(Ok(()))
                        } else if v.is_data() {
                            match v {
                                ProtFrame::Data(d) => {
                                    self.read.put_slice(&d.data().chunk());
                                }
                                _ => unreachable!(),
                            }
                        }
                    } else {
                        return Poll::Ready(Ok(()))
                    }
                },
                Poll::Pending => {
                    if !self.read.has_remaining() {
                        return Poll::Pending;
                    }
                },
            }


            if self.read.has_remaining() {
                let copy = std::cmp::min(self.read.remaining(), buf.remaining());
                buf.put_slice(&self.read.chunk()[..copy]);
                self.read.advance(copy);
                return Poll::Ready(Ok(()));
            }
        }
        
    }
}


impl AsyncWrite for VirtualStream
{
    fn poll_write(
        mut self: Pin<&mut Self>,
        cx: &mut std::task::Context<'_>,
        buf: &[u8],
    ) -> std::task::Poll<Result<usize, std::io::Error>> {
        self.write.put_slice(buf);
        if let Err(_) = ready!(self.sender.poll_reserve(cx)) {
            return Poll::Pending;
        }
        let binary = Binary::from(self.write.chunk().to_vec());
        let id = self.id;
        if let Ok(_) = self.sender.send_item(ProtFrame::Data(ProtData::new(id, binary))) {
            self.write.clear();
        }
        Poll::Ready(Ok(buf.len()))
    }

}
```

至此基本几个大类已设置完毕，接下来仅需简单的拓展就能实现内网穿透功能。

6-从零用Rust编写正反向代理, 通讯协议源码解读篇

# 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)


### 什么是通讯协议？
在tcp的流传输过程中，可以看做是一堆的字节的集合体，是一种“流”式协议，就像河里的水，中间没有边界。或者好比不懂汉语的来看古文，因为古文里没有任何的句读，不知何时另起一行。那我们如何正确的做到拆包解包，保证数据格式的正确呢？
> 以下是客户端发送两个30字节的包（P1及P2），服务端读取数据可能读出来的可能

```
gantt
    title 粘包的可能，例每个包30字节
    %% This is a comment
    dateFormat X
    axisFormat %s
    section 示例1
        P2          :a1, 1, 30
        P1          :after a1, 60
    section 示例2
        P2,P1 :1,60
    section 示例3
        P2部分          :a3, 1, 20
        P2部分P1全部    :after a3, 60
    section 示例4
        P2全部P1部分    :a4, 1, 40
        P1部分          :after a4, 60
```

> 若没有事先约定好格式，在服务端部分无法正确的解析出P1包和P2包，也就意味着无法理解客户端发的内容。若此时我们约定每个包的大小固定为30字节，那么2，3，4三种可能不管收到多少，都必须等待30字节填充完毕后解析出P1，剩余的数据待待60字节接收完毕后解析P2包

##### 粘包拆包常见的解决方案
对于粘包和拆包问题，常见的解决方案有四种：

- 发送端将每个包都封装成固定的长度，比如512字节大小。如果不足512字节可通过补0或空等进行填充到指定长度；
- 发送端在每个包的末尾使用固定的分隔符，例如\r\n。如果发生拆包需等待多个包发送过来之后再找到其中的\r\n进行合并；例如，Redis协议，每一行的结尾都是CRLF，在碰到结尾的时候才进行转发；
- 将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息，例如HTTP2协议，固定先读3个字节的长度，9个字节的长度头信息；
- 通过自定义协议进行粘包和拆包的处理。

##### 在此的解决方案
选择了分为头部和消息体方案，头部分为8个字节，然后前3个字节表示包体的长度，单包支持长度为8-167777215也就是16m的大小，足够应对大多数情况。


### 网络的拓扑图

> 因为每个链接的处理函数均在不同的协程里，所以这里用了Sender/Receiver来同步数据。

```mermaid
flowchart TD
    A[中心客户端/CenterClient]<-->|tls加密连接或普通连接|B[中心服务端/CenterServer]
    C[客户端链接]<-->|Sender/Receiver|A
    B<-->|Sender/Receiver|D[服务端链接]
```

### 协议的分类
> 协议相关的类均在```prot```目录下面，统一对外的为枚举```ProtFrame```，类的定义如下
```rust
pub enum ProtFrame {
    /// 收到新的Socket连接
    Create(ProtCreate),
    /// 收到旧的Socket连接关闭
    Close(ProtClose),
    /// 收到Socket的相关数据
    Data(ProtData),
}
```
主要涉及类的编码及解析在方法```encode```,```parse```，定义如下
```rust
/// 把字节流转化成数据对象
pub fn parse<T: Buf>(
    header: ProtFrameHeader,
    buf: T,
) -> ProxyResult<ProtFrame> {
    
}

/// 把数据对象转化成字节流
pub fn encode<B: Buf + BufMut>(
    self,
    buf: &mut B,
) -> ProxyResult<usize> {
    
}
```

##### 消息的包头
> 任何消息优先获取包头信息，从而才能进行相应的类型解析，类为```ProtFrameHeader```，定义如下，总共8个字节

```rust
pub struct ProtFrameHeader {
    /// 包体的长度, 3个字节, 最大为16m
    pub length: u32,
    /// 包体的类型, 如Create, Data等
    kind: ProtKind,
    /// 包体的标识, 如是否为响应包等
    flag: ProtFlag,
    /// 3个字节, socket在内存中相应的句柄, 客户端发起为单数, 服务端发起为双数
    sock_map: u32,
}
```

##### 消息类型的定义
> 暂时目前定义三种类型，```Create```, ```Close```, ```Data```，

- Socket创建，类为```ProtCreate```
```rust
/// 新的Socket连接请求, 
/// 接收方创建一个虚拟链接来对应该Socket的读取写入
#[derive(Debug)]
pub struct ProtCreate {
    sock_map: u32,
    mode: u8,
    domain: Option<String>,
}
```

- Socket关闭，类为```ProtClose```
```rust
/// 旧的Socket连接关闭, 接收到则关闭掉当前的连接
#[derive(Debug)]
pub struct ProtClose {
    sock_map: u32,
}
```

- Socket数据包，类为```ProtData```
```rust
/// Socket的数据消息包
#[derive(Debug)]
pub struct ProtData {
    sock_map: u32,
    data: Binary,
}
```

#### 一个数据包的自白
> 我是一段数据，我要去找服务器获得详细的数据

> 首先我得和服务器先能沟通上，建立一条可以通讯的线

```mermaid
flowchart TD
    A[我]-->|请求连接建立|B[客户端代理]
    B-->|把链接交由|C[中心客户端]
    C-->|生成sock_map如1,并发送ProtCreate|D[中心服务端]
    D-->|根据ProtCreate创建与sock_map对应的唯一id|E[虚拟TCP连接]
    E-->|根据相应信息连接到服务端|F[服务端]
```

> 此时我已经和服务端构建起了一条通讯渠道，接下来我要和他发送数据了

```mermaid
flowchart TD
    A[我]-->|发送字节数据|B[客户端代理]
    B-->|读出数据交由|C[中心客户端]
    C<-->|加工成ProtData发送|D[中心服务端]
    D-->|根据ProtData的sock_map发送给对应|E[虚拟TCP连接]
    E-->|解析成数据流写入|F[服务端]
    
    F-->|把数据流返回|E
    E-->|读出数据交由|D
    C-->|根据ProtData的sock_map发送给对应|B
    B-->|解析成数据流写入|A
```

> 至此一条我与服务端已经可以说悄悄话啦。

#### 内网穿透
内网穿秀本质上从中心服务端反向交由中心客户端构建起一条通讯渠道，如今数据协议已经建立，可由服务端推送数据到客户端进行处理，后续实现请看下篇

5-从零用Rust编写正反向代理, 通讯协议建立, 为内网穿透做准备

# 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
> 安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。
> 该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。

TLS版本的历程

| 版本 | 发表年份 | RFC文件 | 弃用年份 | RFC链接 |
| --- | --- | --- | --- | --- |
|  TLS1.0  |  1999年  | RFC2246 | 2021年弃用 | https://datatracker.ietf.org/doc/rfc2246/
|  TLS1.1  |  2006年  | RFC4346 | 2021年弃用 | https://datatracker.ietf.org/doc/rfc4346/
|  TLS1.2  |  2008年  | RFC5246 | 正在使用   | https://datatracker.ietf.org/doc/rfc5246/
|  TLS1.3  |  2018年  | RFC8446 | 正在使用   | https://datatracker.ietf.org/doc/rfc8446/

TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

> 我们此时正应用他与应用层完全不耦合，又经历20年的发展历程非常的完善和安全，完全可以信任。


```mermaid
sequenceDiagram
Client->>Server: TLS协议版本、随机数、支持的加密套件和对应公钥A

Server-)Server: 生成随机数B，根据信息生成密钥
Server-->>Client: 选用加密套件，服务端随机数，服务端证书
Server-->>Client: 使用的P、G、公钥B与签名
Server-->>Client: 握手报文的信息（服务端加密）

Client-)Client: 验证证书，使用a、B计算出K，得到密钥
Client->>Server: 握手报文的信息（客户端加密）
Client->>Server: 应用数据（客户端加密）
Server-->>Client: 应用数据（服务端加密）

```

#### 了解RSA算法
##### 1. 算法原理
> 算法本身基于一个简单的数论知识：给出两个素数，很容易将它们相乘，然而给出它们的乘积，想得到这两个素数就显得尤为困难。如果能够解决大整数（比如几百位的整数）分解的快速方法，那么 RSA 算法将轻易被破解。

##### 2.公钥私钥的生成
> 1) 准备两个非常大的素数p和q（转化成二进制后1024位或者4096或者更大位数，位数越多越难破解）;
> 2) 计算出两个大素数的乘积n=pq;
> 3) 同样的方法计算m=(p-1)(q-1)，这里的m为n的欧拉函数
> 4) 找到一个数e(1 < e < m)，满足(e,m)的最大公约数为1，即互素
> 5) 找到数字d，需满足ed mod m = 1，即余数为1
> 6) 此时生成完毕，公钥为(n,e)，私钥为(n, d)

##### 3. RSA加密
    对明文x，用公钥(n, e)对x加密，将x转换成数字，通过公式得出密文y
```math
y = x^e mod n
```

#### 4. RSA解密
    对明文y，用私钥(n, d)对y解密
```math
x = y^d mod n
```

#### 5. 小数测试
> 取p=5，q=11，得到n=p*q=55
> m=(p-1)(q-1) = 40
> 取e=3，根据ed mod m = 1，可取d=27
> 此时公钥(n, e)=(55, 3)
> 此时私钥(n, d)=(55, 27)
> 提供明文a = 14，用公钥加密则密文c = a ^ e mod n = 14 ^ 3 mod 55 = 49
> 解密密文b = 49，用私钥解密则明文d = b ^ d mod n = 49 ^ 27 mod 55 = 14

#### 6. 性能分析
因为RSA用到了指数级的计算，位数又是至少1024位起的，所以计算量非常的庞大，所以RSA的算法效率并不高，所以TLS除一开始密文交换的时候用到RSA，后续均用得到的密文做对称加密以减少计算量，TLS1.3所用如下```TLS_AES_128_GCM_SHA256```，```TLS_AES_256_GCM_SHA384```，```TLS_CHACHA20_POLY1305_SHA256```，```TLS_AES_128_CCM_SHA256```，```TLS_AES_128_CCM_8_SHA256```等对称加密算法。

#### 7. Nginx证书文件pem及key
> key文件，即包含```-----BEGIN RSA PRIVATE KEY-----```的文件，这里面包含的信息有n, e, d, p, q等完整的RSA信息，也是保证安全最重要的信息，格式类似如下
```
RSAPrivateKey ::= SEQUENCE {
  version           Version,
  modulus           INTEGER,  -- n
  publicExponent    INTEGER,  -- e
  privateExponent   INTEGER,  -- d
  prime1            INTEGER,  -- p
  prime2            INTEGER,  -- q
  exponent1         INTEGER,  -- d mod (p-1)
  exponent2         INTEGER,  -- d mod (q-1)
  coefficient       INTEGER,  -- (inverse of q) mod p
  otherPrimeInfos   OtherPrimeInfos OPTIONAL
}
```
> pem文件，包含了公钥信息(n, d)及证书链信息，可以知道谁签发的。
#### 加密节点实现
> 角色说明，在wmproxy中存在两种角色，
> 1. 末端的处理服务器
> 2. 中间方只进行流量转发

> 关于TLS的参数有以下参数
```rust
pub struct Proxy {
    /// 连接服务端是否启用tls
    ts: bool,
    /// 接收客户端是否启用tls
    tc: bool,
    /// tls证书所用的域名
    domain: Option<String>,
    /// 公开的证书公钥文件
    cert: Option<String>,
    /// 隐私的证书私钥文件
    key: Option<String>,
}
```
因为加密存在可能的性能损耗，若在私有网络里不存在传输安全理论上可以不用开启加密传输。如果存在多个节点，前面节点已启用过加密，理论上后面节点也无需多次加密。

##### 直接用https传输可能暴露什么？
因为客户端发起```Client Hello```的时候必须带上访问的domain，也就是网络的嗅探方虽然无法知道你访问的具体内容，但是可以知道你访问的网站列表。如：

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


##### 启动二级代理
1. 在本地启动代理
```bash
wmproxy -b 127.0.0.1 -p 8090 -S 127.0.0.1:8091 --ts
```
因为纯转发，所以在当前节点设置账号密码没有意义`-S`表示连接到的二级代理地址，**有该参数则表示是中转代理，否则是末端代理。**```--ts```表示连接父级代理的时候需要用加密的方式链接

2. 在远程启动代理
```bash
wmproxy --user proxy --pass proxy -b 0.0.0.0 -p 8091 --tc
```
```--tc```表示接收子级代理的时候需要用加密的方式链接，可以```--cert```指定证书的公钥，```--key```指定证书的私钥，```--domain```指定证书的域名，如果不指定，则默认用自带的证书参数
> 至此通过代理访问的，我们已经没有办法得到真正的请求地址，只能得到代理发起的请求

##### 源码说明
关于TLS依赖，选择的是```rustls```，```tokio-rustls```。
那么关于客户端的连接，那就有两种情况，一种是```TcpStream```，另一种是```TlsStream<TcpStream>```，我们的处理函数不确定传入的是哪种类型，所以此前的入参TcpStream全部改成泛型T，类似
```rust
async fn deal_stream<T>(&mut self, inbound: T) -> ProxyResult<()>
where T: AsyncRead + AsyncWrite + Unpin {
}
```
这样子只要可以异步读和写都可以成为入参的流。

如果存在```tc```参数，那么会将客户端转成TlsStream以便继续处理
```rust
if let Some(a) = accept.clone() {
    let inbound = a.accept(inbound).await;
    if let Ok(inbound) = inbound {
        // 获取的流跟正常内容一样读写, 在内部实现了自动加解密
        let _ = self.deal_stream(inbound).await;
    } else {
        println!("accept error = {:?}", inbound.err());
    }
} else {
    let _ = self.deal_stream(inbound).await;
};
```

客户端连接
```rust
let connector = TlsConnector::from(tls_client.unwrap());
let stream = TcpStream::connect(&server).await?;
// 这里的域名只为认证设置
let domain = rustls::ServerName::try_from(&*domain.unwrap_or("soft.wm-proxy.com".to_string()))
    .map_err(|_| io::Error::new(io::ErrorKind::InvalidInput, "invalid dnsname"))?;

if let Ok(mut outbound) = connector.connect(domain, stream).await {
    // connect 之后的流跟正常内容一样读写, 在内部实现了自动加解密
    let _ = tokio::io::copy_bidirectional(&mut inbound, &mut outbound).await?;
}
```
这里利用的是TLS与上层解藕，只要他参与握手完之后，完全按我们的通讯来定。

#### 后续改进
现在每个请求都和代理服务端进行一次请求握手，当开启断开非常多的时候会比较耗性能，可以考虑共用一条socket然后内部做协议解析，会减少握手时间，只是在流量非常大的时候会出现某条请求耗光了所有的带宽。





4. 从零用Rust编写正反向代理, TLS加密通讯

# 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)



### 了解UDP

##### 特点
UDP是基于IP的简单协议，不可靠的协议。
UDP的优点：简单，轻量化。
UDP的缺点：没有流控制，没有应答确认机制，不能解决丢包、重发、错序问题。

这里需要注意一点，并不是所有使用UDP协议的应用层都是不可靠的，应用程序可以自己实现可靠的数据传输，通过增加确认和重传机制，所以使用UDP 协议最大的特点就是速度快。如HTTP3就是用UDP标准下实现的上层协议。

##### 适用场景
UDP协议一般作为重速度，但可以接受轻微损失的如流媒体应用、语音交流、视频会议所使用的传输层协议，还有许多基于互联网的电话服务使用的VOIP也是基于UDP运行的，实时视频和音频流协议旨在处理偶尔丢失的数据包，因此，如果重新传输丢失的数据包，则只会发生质量略有下降，而不是出现较大的延迟。
最常用到的为DNS协议，希望能以更小的包（包头tcp20字节，udp8字节），更快速的解析得到地址。


### socks5 udp协议

#### 协议说明

UDP 关联请求用于在UDP中继进程内建立关联以处理UDP数据报。DST.ADDR和DST.PORT字段包含客户端期望用于发送UDP数据报的地址和端口。服务器可以使用此信息来限制对关联的访问。如果客户端在UDP 关联请求时没有掌握此信息，客户端必须使用端口号和地址都为零的地址。

UDP关联会在随着的TCP连接终止时终止。

在UDP 关联请求的回复中，BND.PORT和BND.ADDR字段指示客户端必须发送UDP请求消息以进行中继的端口号/地址。

#### 协议详情

基于UDP的客户端必须将其数据报发送到UDP端口，该端口在UDP关联请求的回复中的BND.PORT指示。如果所选的认证方法提供了封装用于身份验证、完整性、和/或机密性，则数据报必须使用适当的封装。每个UDP数据报都带有UDP请求头：
```
  +----+------+------+----------+----------+----------+
  |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
  +----+------+------+----------+----------+----------+
  | 2  |  1   |  1   | Variable |    2     | Variable |
  +----+------+------+----------+----------+----------+
  
  RSV: 保留2字节
  FRAG：当前分片, 请求时为0
  ATYP：地址类型，0x01为ipv4，0x03为域名地址，0x04为ipv6
  DST.ADDR：目标地址，根据类型读取相应字节
  DST.PORT: 目标端口号，2字节
  DATA：发送数据
```
当一个UDP中继服务器决定中继UDP数据报时，它会默默地这样做，不需要向请求的客户端发送任何通知。同样，它会丢弃它不能或不愿意中继的数据报。当一个UDP中继服务器从远程主机接收到回复数据报时，它必须使用上述UDP请求头和任何与认证方法相关的封装对数据报进行封装。

UDP中继服务器必须从SOCKS服务器获取将发送数据报到BND.PORT的客户端的预期IP地址，该地址在UDP关联请求的回复中给出。它必须丢弃来自除为特定关联记录的IP地址以外的任何源IP地址的所有数据报。

FRAG字段指示此数据报是否是多个片段之一。如果实现，高位比特指示片段序列的结束，而值为X'00'表示此数据报是独立的。值在1和127之间的值表示片段在片段序列中的位置。每个接收器都有一个重新组装队列和与这些片段关联的重新组装定时器。每当重新组装定时器到期或接收到携带FRAG字段值小于为该片段序列处理的最高FRAG值的新数据报时，必须重新初始化重新组装队列并丢弃关联的片段。重新组装定时器必须不小于5秒。建议应用程序尽可能避免分片。

分片实施是可选项；不支持分片的实现必须丢弃任何FRAG字段值不是X'00'的数据报。


#### 协议流程图
UDP协议实现的是本地和远程地址中间构建出一条UDP链路，常用的如DNS解析。
```mermaid
graph TD
    A[客户端] -->|请求UDP| B[代理] --> C[代理UDP对内] 
    
    B -->|返回UDP地址| A
    
    AA[客户端UDP] <-->|UDP发送数据| C --> |内存读取| D[代理UDP对外] --> E[远程UDP]
    
    E -->|返回| D -->|内存读取| C --> |写入头信息| AA
```
```对内的UDP端口```接收到信息先读取远程地址的信息再做相应的转发
```对外的UDP端口```接收到远程的信息先加上相应的头信息再转发给客户端。
客户端的TCP长链信息必须保持活跃，一旦TCP连接关掉则通知UDP断掉连接。


#### 代码实现
在我们详细了解了协议的内容之后，就可以开始写代码

- 在我们收到UDP的command之后，把数据交由udp关联函数处理
```rust
pub async fn udp_execute_assoc(
    mut stream: TcpStream,
    proxy_addr: SocketAddr,
    bind_ip: IpAddr,
) -> ProxyResult<()> {
}
```
- 此刻我们对UDP进行监听，得到相应的端口，然后再将传入的bind_ip和端口返回给tcp的客户端，让客户端建立udp与当前的端口绑定
```rust
let peer_sock = UdpSocket::bind("0.0.0.0:0").await?;
let port = peer_sock.local_addr()?.port();
ProxySocks5::tcp_write_reply(&mut stream, true, SocketAddr::new(bind_ip, port)).await?;

```
- 接下来开始进行转发逻辑，用异步函数，主要用三个对象，tcp的连接，对内的udp端口，对外的udp端口
```rust
async fn udp_transfer(stream: TcpStream, inbound: UdpSocket) -> ProxyResult<()> {
    let outbound = UdpSocket::bind("0.0.0.0:0").await?;
}
```
- 因为在tcp连接被断开的时间，我们要通知udp关联结束，那么我们要监听tcp是否被断开，被断开后通知udp结束监听。在这里采用了```tokio::sync::broadcast```，可以一个Sender多个接收
```rust
// 使tcp断开的时候通知udp结束关联,结束处理函数
let (sender, _) = channel::<()>(1);

async fn upd_handle_tcp_block(mut stream: TcpStream, mut receiver: Receiver<()>, sender: Sender<()>) -> ProxyResult<()> {
    let mut buf = [0u8; 100];
    loop {
        let n = tokio::select! {
            r = stream.read(&mut buf) => {
                r?
            },
            _ = receiver.recv() => {
                return Ok(());
            }
        };
        if n == 0 {
            let _ = sender.send(());
            return Ok(());
        }
    }
}
```


- 因为```tokio::try_join!```是发生错误或者所有的均正确返回才结束，我们需要在发生错误的时候通知其它的异步停止，我们此时用的是```tokio::select!```都同时监听```receiver.recv()```收到消息则表示需要关闭此关联。以下是代理接收请求
```rust
async fn udp_handle_request(
    inbound: &UdpSocket,
    outbound: &UdpSocket,
    mut receiver: Receiver<()>,
) -> ProxyResult<()> {
    let mut buf = BinaryMut::with_capacity(0x10000);
    loop {
        //...
        // 代理对内的端口只会跟客户端的通讯, 所以建立connect
        inbound.connect(client_addr).await?;

        let (flag, addr) = Self::udp_parse_request(&mut buf).await?;
        if flag != 0 {
            return Ok(());
        }
        outbound.send_to(buf.chunk(), addr).await?;
    }
}
```
- 代理方收到远程的消息 添加头发送到客户端
```rust
async fn udp_handle_response(
    inbound: &UdpSocket,
    outbound: &UdpSocket,
    mut receiver: Receiver<()>,
) -> ProxyResult<()> {
    let mut buf = BinaryMut::with_capacity(0x10000);
    loop {

        //...
        let mut buffer = BinaryMut::with_capacity(100);
        buffer.put_slice(&[0, 0, 0]);
        ProxySocks5::encode_socket_addr(&mut buffer, &client_addr)?;
        buffer.put_slice(buf.chunk());

        // 因为已经建立了绑定, 所以直接发送
        inbound.send(buffer.chunk()).await?;
    }
}
```
至此客户端与服务端的UDP通讯已完成。

### 如何验证
接下来推荐一个工具```brook```他提供了命令行，可以完美的测试是否正确实现了SOCKS5的UDP功能。
###### testsocks5
```doc
Test UDP and TCP of socks5 server

--dns="": DNS server for connecting (default: 8.8.8.8:53)

--domain="": Domain for query (default: http3.ooo)

--password, -p="": Socks5 password

--socks5, -s="": Like: 127.0.0.1:1080

--username, -u="": Socks5 username

-a="": The A record of domain (default: 137.184.237.95)
```
所以我们此时开启服务器监听
```bash
wmproxy --user aaa --pass bbb -b 0.0.0.0 --udp 127.0.0.1
```
此时我们开启了一个代理，用户是aaa密码是bbb，udp是绑定127.0.0.1的一个代理，我们运行以下命令进行测试
```bash
brook testsocks5 -s 192.168.179.133:8090 --username aaa --password bbb
```
我们可以看下以下返回则表示成功
```
Testing TCP: query http3.ooo A on 8.8.8.8:53
TCP: OK

Testing UDP: query http3.ooo A on 8.8.8.8:53
2023/09/19 14:13:56 Sent Request: 0x5 0x3 0x0 0x1 []byte{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0} []byte{0x0, 0x0}
2023/09/19 14:13:58 Got Reply: 0x5 0x0 0x0 0x1 []byte{0x7f, 0x0, 0x0, 0x1} []byte{0xd8, 0x3}
2023/09/19 14:13:58 Sent Datagram. []byte{0xba, 0xe4, 0x1, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5, 0x68, 0x74, 0x74, 0x70, 0x33, 0x3, 0x6f, 0x6f, 0x6f, 0x0, 0x0, 0x1, 0x0, 0x1}
2023/09/19 14:13:58 Got Datagram. data: []byte{0x0, 0x0} 0x0 0x1 []byte{0x8, 0x8, 0x8, 0x8} []byte{0x0, 0x35} []byte{0xba, 0xe4, 0x81, 0x80, 0x0, 0x1, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x5, 0x68, 0x74, 0x74, 0x70, 0x33, 0x3, 0x6f, 0x6f, 0x6f, 0x0, 0x0, 0x1, 0x0, 0x1, 0xc0, 0xc, 0x0, 0x1, 0x0, 0x1, 0x0, 0x0, 0x0, 0x3c, 0x0, 0x4, 0x89, 0xb8, 0xed, 0x5f} datagram address: "8.8.8.8:53"
UDP: OK
```
他会进行TCP测试和UDP测试，如果看到UDP: OK则表示测试通过。

至此UDP功能已实现

3. 从零用Rust编写正反向代理, UDP绑定篇

# 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)


## 设计流程图
```mermaid
flowchart LR
    A[客户端] -->|Http| B[代理端] --> C[代理服务端] --> D[服务端]
    B -->|直达| D
    A -->|Https| B
    A -->|Socks5| B
```
代理端和代理服务端之间可用自有格式来实现多路复用以减少连接的建立断开的开销，目前暂未实现代理服务端。


## 类结构
- proxy.rs 负责代理结构的存储，监听类型，监听地址，是否有父级地址，认证账号密码等。
- flag.rs 监听类型的二进制结构，可同时支持多结构比较http/https/socks5，如果解析http失败则尝试socks5格式，从而实现多种代理方式的同时支持
- http.rs http及https代理的实现，如果解析失败则返回ProxyError::Continue，并把已经读取的数据带回，以便后续解析
- socks5.rs socks5的代理实现，如果数据正确，则均在此处进行转发，解析失败返回Continue


### 命令行解析
使用[Commander](https://github.com/tickbh/Commander)对命令行的的数据处理，如-p 8090，-b 127.0.0.1，完整的命令行如wmproxy -p 8090，则可在8090端口上实现http及https的转发，代码示例
```rust
let command = Commander::new()
            .version(&env!("CARGO_PKG_VERSION").to_string())
            .usage("-b 127.0.0.1 -p 8090")
            .usage_desc("use http proxy")
            .option_list(
                "-f, --flag [value]",
                "可兼容的方法, 如http https socks5",
                None,
            )
            .option_int("-p, --port [value]", "listen port", Some(8090))
            .option_str(
                "-b, --bind [value]",
                "bind addr",
                Some("0.0.0.0".to_string()),
            )
            .parse_env_or_exit();

let listen_port: u16 = command.get_int("p").unwrap() as u16;
let listen_host = command.get_str("b").unwrap();
```

### 启动入口
启动通过tokio的异步协议进行数据的处理，逻辑均在```tokio::spawn```的异步函数中，所有针对句柄数据的读取写入均由异步完成，从而实现高效率的处理。
```rust
while let Ok((mut inbound, _)) = listener.accept().await {
    tokio::spawn(async move {
        // tcp的连接被移动到该协程中，我们只要专注的处理该stream即可
    })
}
``` 

#### HTTP代理
如果该代理信息配置支持http/https则会尝试进行http解析，代码实现在`proxy.rs`中的`process`方法，
```rust
pub async fn process(mut inbound: TcpStream) -> ProxyResult<()> {
    let request = webparse::Request::new();
    // 通过该方法解析标头是否合法, 若是partial(部分)则继续读数据
    // 若解析失败, 则表示非http协议能处理, 则抛出错误
    match request.parse_buffer(&mut buffer.clone()) {
    }
}
```

该方法会循环的读取客户端的内容，如果内容为
```
GET / HTTP/1.1\r\nHost: wwww.baidu.com\r\n\r\n
```
这表示该请求为普通的http代理，我们解析完HTTP的头文件信息，得出包含的头信息，如果无法解析完整的地址（域名加端口或者ip加端口），则返回错误，无法处理该http信息。
```mermaid
flowchart TD
    A[客户端] --> B[代理] --> C[读取头信息] --> D[取得地址] -->|成功| E[连接目标地址] -->|成功| F[写入头信息] --> G[双向通道]
    
    D -->|不合法关闭| A
    E -->|连接失败关闭| A
    A <-->|双向| G
```
注意：客户端和服务端之前可能会存在大数据上传下载的情况，超过百兆数据的上传下载，所以我们为了减少序列化带来的性能损失和保证在低内存能正确运行，不做http的完整解析，仅仅只处理http头信息。

curl测试
```bash
export http_proxy=http://127.0.0.1:8090
curl http://www.baidu.com -I
```
可以正常的返回
```
HTTP/1.1 200 OK...
```
#### HTTPS代理
https处理是在http的基础在在额外解析connect协议来实现， 代理是客户端优先给代理发送connect协议，比如访问https://www.baidu.com那么先优先发如下消息。
```
CONNECT www.baidu.com:443 HTTP/1.1\r\n
Host: www.baidu.com:443\r\n\r\n
```
如果收到HTTP的CONNECT的方法则表示他是https的代理协议，那么此时对PATH提示的地址进行连接，连接成功后只需对该连接和客户端做双向绑定即可实现HTTPS代理协议。

curl测试
```bash
export https_proxy=http://127.0.0.1:8090
curl https://www.baidu.com -I
```
可以正常的返回两次，因为在connect的时候要求代理返回一次数据，另一次是https服务器返回，故而显示g
```
HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
```



#### socks5协议
socks5由[rfc1928](https://datatracker.ietf.org/doc/html/rfc1928)进行定义
代码实现在`socks5.rs`中的`process`方法实现
因为在处理`socks5`之前可能进行过http的尝试，所以socket中的内容已经被读出了一部分，在处理时则带上了`Option<BinaryMut>`，表示预读的内容。
在socks5中通常需要预读一个字节来获取后续的长度，比如NMethod，或者用户名长度等，所以我们定义了函数
```rust
/// 读取至少长度为size的大小的字节数, 如果足够则返回Ok(())
pub async fn read_len<T>(stream: &mut T, buffer: &mut BinaryMut, size: usize) -> ProxyResult<()>
where
    T: AsyncRead + Unpin {
        
    }
```
> 这里的stream用的是泛型，只要具有异步读的类型都可以

保证已读内容须不少于多少字节数，然后再进行数据的预处理。
根据我们是否传用用户密码信息来确定socks5的验证方式，如果我们传入了用户密码，如果客户端不支持2的验证方式，则返回(0xFF)表示无验证方法。
```bash
curl http://www.baidu.com --socks5 127.0.0.1:8090
## curl: (97) No authentication method was acceptable.
```

验证成功或者无需验证后
```mermaid
graph TD
    A[验证成功] --> B[读取地址] --> C[连接地址] -->|连接成功| D[双向通道]
    E[返回失败]
    B -->|读取失败| E
    C -->|连接失败| E
    A <-->|双向| D
```
双向通道建立后，客户端已和服务器能正常的TCP操作，包括Http/Https/Websocket/自定义tcp信息，代理直到一方关闭则正常后续关闭。

### 错误处理方法
这里主要说明如何多协议兼容处理代理协议。以下定义的Continue协议包含了一个已读的字节表和当前的Tcp连接。
```rust
pub enum ProxyError {
    /// 该错误发生协议不可被解析,则尝试下一个协议
    Continue((Option<BinaryMut>, TcpStream)),
}

```

例如在http里协议解决头失败，
```
// 此处clone为浅拷贝，不确定是否一定能解析成功，不能影响偏移
match request.parse_buffer(&mut buffer.clone()) {
    Err(_) => {
        return Err(ProxyError::Continue((Some(buffer), inbound)));
    }
}
```
则返回当前已读的buffer和tcp连接，且游标为初始位置，buffer并未被读取过。下个解析器可以拿到完整的数据进行解析。

2. 从零用Rust编写正反向代理, 动工，基本理论准备

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