# wmproxy
`wmproxy`已用`Rust`实现`http/https`代理, `socks5`代理, 反向代理, 静态文件服务器，四层TCP/UDP转发，内网穿透，后续将实现`websocket`代理等，会将实现过程分享出来，感兴趣的可以一起造个轮子

## 项目地址

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

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


## 容器化
> 现在服务器环境已经大部分转为了docker这类容器类的部署方式，因为容器化可以与宿主机隔离，又可以虚拟出统一的环境，保证程序在任何系统上表现是一样的。
> 我们需要将当前的Rust程序打包成docker的image然后发布到部署的整个过程。

## 初始化
1. 将项目的源码clone下来
```BASH
git clone https://github.com/tickbh/wmproxy.git
```
2. 安装`docker desktop`版本，需要比较新的版本
3. 进入到当前的目录下执行`docker init`，如果提示没有`init`则表示docker版本过低，建议升级
```doc
docker init
Welcome to the Docker Init CLI!

This utility will walk you through creating the following files with sensible defaults for your project:
 - .dockerignore
 - Dockerfile
 - compose.yaml

Let's get started!

? What application platform does your project use? Rust
? What version of Rust do you want to use? 1.71.1
? What port does your server listen on? 82
```



4. 执行完毕后将会创建三个文件，我们来分析`Dockerfile`处理了什么
```DOCKERFILE
# 拉取了可以编译的RUST版本
FROM rust:${RUST_VERSION}-slim-bullseye AS build
ARG APP_NAME
WORKDIR /app

# 挂载相应的文件目录结构
RUN --mount=type=bind,source=src,target=src \
 --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
 --mount=type=bind,source=.cargo,target=.cargo \
 --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
 --mount=type=cache,target=/app/target/ \
 --mount=type=cache,target=/usr/local/cargo/registry/ \
 <<EOF
set -e
cargo build --locked --release
cp ./target/release/$APP_NAME /bin/wmproxy
EOF

# 用较小的发行版本做载体，保证较小的image
# 目标image中不包含Rust环境
FROM debian:bullseye-slim AS final

ARG UID=10001
RUN adduser \
 --disabled-password \
 --gecos "" \
 --home "/nonexistent" \
 --shell "/sbin/nologin" \
 --no-create-home \
 --uid "${UID}" \
 appuser
USER root

# 拷贝编译好的可执行文件到目标系统，到时可直接执行目标程序
COPY --from=build /bin/wmproxy /bin/
# 拷贝相应的配置文件
COPY config /etc/config

EXPOSE 82:82 8837:8837 8090:8090
```

5. 接下来编译镜像
```BASH
docker build --tag wmproxy .
```
按照正常情况将会像正常环境编译Rust项目编译成image，但是在国内的环境下，下载crates.io数据可能有频繁失败的可能，此时应该把Cargo设置成国内源，Cargo的配置是和git类似的分层结构，即当前目录会优先寻找当前，然后再往上级推，最终找用户目录下的。例如`/projects/foo/bar/baz`调用Cargo
```
/projects/foo/bar/baz/.cargo/config
/projects/foo/bar/.cargo/config
/projects/foo/.cargo/config
/projects/.cargo/config
/.cargo/config
$HOME/.cargo/config
```
所以此时我们在项目下建立`.cargo/config.toml`的文件，其中的内容为
```TOML
[source.crates-io]
replace-with = 'ustc'
[source.ustc]
registry = "git://mirrors.ustc.edu.cn/crates.io-index"
[http]
check-revoke = false
```
如此我们在重新编译一次，将显示表示成功
```
...
 => exporting to image 0.1s 
 => => exporting layers 0.1s 
 => => writing image sha256:ca62d7bf9c2684912b27994c2d09917a4836c0fd63867cc9765bf 0.0s 
 => => naming to docker.io/library/wmproxy 0.0s 
```

6. 查询image
此时可以利用`docker images`查询当前的images

```
REPOSITORY TAG IMAGE ID CREATED SIZE
wmproxy latest ca62d7bf9c26 2 minutes ago 101MB
```

7. 运行docker
因为代理端有监听82（http反向），8090代理，8837控制端，并且需要将本地的配置文件映射到容器中。
```
docker run -p 82:82 -p 8090:8090 -p 127.0.0.1:8837:8837 --name proxy_bash -v $PWD/config/reverse.toml:/etc/config/reverse.toml:rw wmproxy /bin/./wmproxy -c /etc/config/reverse.toml
```
通过netstat可以查看到
```
TCP 0.0.0.0:82 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8090 0.0.0.0:0 LISTENING
TCP 127.0.0.1:8837 0.0.0.0:0 LISTENING
```
查看当前服务器状态`curl http://127.0.0.1:8837/now`

![图片.png](https://wmproxy.net/static/img/eb9e5d17917e01dfc3cebe0de3cfa44a.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
可以正常的获取当前配置

8090为http代理，接下来测试代理是否工作
```BASH
export http_proxy=http://127.0.0.1:8090/
```
接下来进行curl测试

![图片.png](https://wmproxy.net/static/img/adb1e607ebace6980f5de0eb2f2efa41.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
可以通过代理正常访问，关掉docker就会返回错误。

## 发布image
1. 在`https://hub.docker.com/`注册登陆你的账号
2. 创建`respository`

![图片.png](https://wmproxy.net/static/img/9426a1257047a4d59453e183be275d6e.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
3. 创建成功后，本地images打标签
```bash
docker tag wmproxy dreamwhat/wmporxy
```
4. 登陆seesion到docker hub
```BASH
docker login
```
如果安装desktop版会自动读取token
5. 接下来直接把目标镜像push
```bash
docker push dreamwhat/wmproxy
```
此时后台上可以查看到，表示已发表成功

![图片.png](https://wmproxy.net/static/img/6dbb49270091c83a0bfa846343ff0ce2.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

6. 此时可以在别的机器拉取远程库`docker pull dreamwhat/wmproxy`

![图片.png](https://wmproxy.net/static/img/c7808b773c504eea2e02d567e092e8ee.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

7. 直接运行docker，可以查看已经可以运行成功
```
docker run -p 82:82 -p 8090:8090 -p 127.0.0.1:8837:8837 --name proxy_bash -v $PWD/reverse.toml:/etc/config/reverse.toml:rw dreamwhat/wmproxy /bin/./wmproxy -c /etc/config/reverse.toml
```

8. 打tag发布版本
```
docker tag wmproxy dreamwhat/wmproxy:0.2.3
docker push dreamwhat/wmproxy:0.2.3
```

至此已经可以运行完毕

### 结语
容器化已经在服务器中属于密不可分的一环，包括k8s等编排技术也是基于容器化的基本上去大规模部署的，保证不会因为系统的差别而带来不一致的体验。

点击 **[关注]**，**[在看]**，**[点赞]** 是对作者最大的支持

26干货系列从零用Rust编写正反向代理，如何发布Rust项目到Docker

# wmproxy
`wmproxy`已用`Rust`实现`http/https`代理, `socks5`代理, 反向代理, 静态文件服务器，四层TCP/UDP转发，内网穿透，后续将实现`websocket`代理等，会将实现过程分享出来，感兴趣的可以一起造个轮子

## 项目地址

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

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


## 序列化
&emsp;&emsp;序列化`（Serialization）`是指将数据结构或对象状态转化为可以存储或传输的形式的过程。

&emsp;&emsp;在序列化过程中，对象的成员属性和类型信息一起被转换为一个字节流或可打印字符流，以便于存储或网络传输。

&emsp;&emsp;这个字节流或字符流可以再次被反序列化`（Deserialization）`还原为原始对象状态。

&emsp;&emsp;字符流比如`JSON`，字节流比如`ProtoBuf`。

## Rust中的序列化
&emsp;&emsp;在Rust中序列化最常用且支持最广的为第三方库`serde`，当前在`github`上已有8000颗`star`。

&emsp;&emsp;常用的比如`JSON`库的`serde_json`，比如`YAML`，`TOML`，`BSON`等，依靠serde库之上，对常用的格式已经有了广泛的的支持。

&emsp;&emsp;在代码中，`Serde`数据模型的序列化部分由特定义 `Serializer`，反序列化部分由特征定义`Deserializer`。这些是将每个 Rust 数据结构映射到 `29` 种可能类型之一的方法。特征的每个方法Serializer对应于数据模型的一种类型。

&emsp;&emsp;支持基础类型如常用的布尔值，整型，浮点型，字符串，字节流

&emsp;&emsp;支持的高级类型，如`tuple`，`struct`，`seq`，`enum`可以映射成各种内置的数据结构。

## 如何使用serde
> 假如用现有的数据格式，如json之类的，可以轻松的实现。

1. 配置`Cargo.toml`
```TOML
[package]
name = "wmproxy"
version = "0.1.0"
authors = ["wenmeng <user@wm-proxy.com>"]

[dependencies]
serde = { version = "1.0", features = ["derive"] }

# 这仅仅是测试用例，需要用哪个可以选择添加
serde_json = "1.0"
```
2. 现在`src/main.rs`使用Serde的自定义导出：
```RUST
use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, Debug)]
struct Point {
 x: i32,
 y: i32,
}

fn main() {
 let point = Point { x: 1, y: 2 };

 let serialized = serde_json::to_string(&point).unwrap();
 println!("serialized = {}", serialized);

 let deserialized: Point = serde_json::from_str(&serialized).unwrap();
 println!("deserialized = {:?}", deserialized);
}
```
以下输出：
```BASH
$ cargo run
serialized = {"x":1,"y":2}
deserialized = Point { x: 1, y: 2 }
```

## serde中的属性参数
> 在使用serde中经常可以看到在字段前加一些属性参数，这些是约定该字段序列化或反序列化时将如何处理的，下面我们看以下的例子：
- **`#[serde(default)]`**
这是设置默认参数，或者可以带上`#[serde(default="???")]`，这里`???`将是一个函数名，不能带参数，可以直接访问，如`Vec::new`可以直接访问的函数。
```
fn default_y() -> i32 {
 1024
}
#[derive(Serialize, Deserialize, Debug)]
struct Point {
 #[serde(default)]
 x: i32,
 #[serde(default="default_y")]
 y: i32,
}
```
此时我们反序化一个值时，如果没有x的参数会将x默认设置成0，如果没有y参数，将会调用default_y函数，也就是y会默认为1024。
- **`#[serde(rename = "name")]`**
重命名字段名字，在内存中显示长的名字好理解，在配置中可以用短的名字好配置。此外还有`#[serde(rename_all = "...")]`可以将所有的名字结构变成全小写，或者全大写之类或者驼峰结构等。
- **`#[serde(skip)]`**
该字段跳过序列化及反序列化，也就是一些内存对象或者临时数据不适合做序列化，用此来做约束。还有`#[serde(skip_serializing)]`跳过序列化和`#[serde(skip_deserializing)]`跳过反序列化等。
- **`#[serde(flatten)]`**
将不能解析的数据统一挪入到另一个数据结构，在此项目中用到的通用的配置化结构，就将其均挪到了`CommonConfig`，可以极好的精简配置结构
```RUST
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct HttpConfig {
 #[serde(default = "Vec::new")]
 pub server: Vec<ServerConfig>,
 #[serde(default = "Vec::new")]
 pub upstream: Vec<UpstreamConfig>,
 #[serde(flatten)]
 #[serde(default = "CommonConfig::new")]
 pub comm: CommonConfig,
}
```
- **`#[serde(with = "module")]`**
这个是自定义序列化的关键，也是他强大的基础，可以很好的实现自定义的一些操作，就比如配置一个整型，现在要把他转成`Duration`或者原来是一个字符串"4k"表示大小，现在需要把他按数据大小转成数字4096，就需要自定义的序列化过程。
该声名同时包含了`serialize_with`和`deserialize_with`，该模块需实现`$module::serialize`及`$module::deserialize`做对应的序列化和反序列化。

## serde的工作原理

#### 序列化
> 以下过程是Rust中的数据结构是如何转化成目标格式的
```
Rust （结构体枚举） 
 ↓
 -- Serialize（序列化） --> 当前结构体中，有对字段进行协议说明的，加属性标记
 ↓
 -- 数据的格式（如JSON/BSON/YAML等） --> 根据对应的输出库（serde_json/serde_yaml）输出相应的字节流
```


#### 反序列化
> 以下以JSON格式是如何转化成Rust的结构，在JSON中属于键值对且值有特定的数据格式，其中key将解析成数据结构中的字段名，值value将根据反序列化可以尝试解析的类型尝试是否能转成目标类型。

比如value值为字符串，且反序列反时选择`deserialize_str`，将在反序列化的时候会尝试调用
```RUST
/// 我们将根据该字符串的值能否解析成目标类型，如果失败返回错误
fn visit_str<E>(self, value: &str) -> Result<Self::Value, E>
where
 E: de::Error,
{
}
```
比如value值为数值，且反序列反时选择`deserialize_i64`，将在反序列化的时候会尝试调用
```RUST
/// 我们将根据该数值的值能否解析成目标类型，如果失败返回错误
fn visit_i64<E>(self, v: i64) -> Result<Self::Value, E>
 where
 E: Error, {
}
```
或者以上两种格式我们都是支持的，比如时间可以支持数字`8`或者`"8s"`，此时我们需要同时将数字或者字符串同时支持转成`Duration::new(8,0)`，那么此时我们自定义的反序列化函数可以我选择`deserialize_any`，并分别实现`visit_i64`及`visit_str`

#### 举个例子
以下是通过标准的Display做输出及FromStr做反序列化，但是此时我们又需要同时支持数字的处理，首先我们先定义模块
```RUST
pub struct DisplayFromStrOrNumber;
```
此时该模块需要实现序列化及反序列化。
实现序列化，将用标准的Display做输出：
```rust
impl<T> SerializeAs<T> for DisplayFromStrOrNumber
where
 T: Display,
{
 fn serialize_as<S>(source: &T, serializer: S) -> Result<S::Ok, S::Error>
 where
 S: Serializer,
 {
 serializer.collect_str(source)
 }
}
```
实现反序列化，我们将数字统一转成字符串，然后用FromStr做反序列化：
```rust

impl<'de, T> DeserializeAs<'de, T> for DisplayFromStrOrNumber
where
 T: FromStr,
 T::Err: Display,
{
 fn deserialize_as<D>(deserializer: D) -> Result<T, D::Error>
 where
 D: Deserializer<'de>,
 {
 struct Helper<S>(PhantomData<S>);
 impl<'de, S> Visitor<'de> for Helper<S>
 where
 S: FromStr,
 <S as FromStr>::Err: Display,
 {
 type Value = S;

 fn expecting(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result {
 write!(formatter, "a string")
 }

 fn visit_str<E>(self, value: &str) -> Result<Self::Value, E>
 where
 E: de::Error,
 {
 value.parse::<Self::Value>().map_err(de::Error::custom)
 }

 /// 将数字转成字符串从而能调用FromStr函数
 fn visit_i64<E>(self, v: i64) -> Result<Self::Value, E>
 where
 E: Error, {
 format!("{}", v).parse::<Self::Value>().map_err(de::Error::custom)
 }
 }

 deserializer.deserialize_any(Helper(PhantomData))
 }
}
```

&emsp;&emsp;此时我们已有了标准模块了，我们只能重新实现类的`Display`及`FromStr`，由于现有的类型如`Duration`我们不能重新实现`impl Display for Duration`因为接口`Display`和类型`Duration`均不是我们定义的，如果我们可以重新实现，那么此有可能其它第三方库也实现了，那么我们在引用的时候可能就有多种实现方法，从而无法确定调用函数。

&emsp;&emsp;那么此时我们做一层包裹方法
```RUST
pub struct ConfigDuration(pub Duration);
```
此时我们只需要重新实现`Display`及`FromStr`就可以了
```RUST

impl FromStr for ConfigDuration {
 type Err=io::Error;

 fn from_str(s: &str) -> Result<Self, Self::Err> {
 if s.len() == 0 {
 return Err(io::Error::new(io::ErrorKind::InvalidInput, ""));
 }

 let d = if s.ends_with("ms") {
 let new = s.trim_end_matches("ms");
 let s = new.parse::<u64>().map_err(|_| io::Error::new(io::ErrorKind::InvalidInput, ""))?;
 Duration::new(0, (s * 1000_000) as u32)
 } else if s.ends_with("h") {
 let new = s.trim_end_matches("h");
 let s = new.parse::<u64>().map_err(|_| io::Error::new(io::ErrorKind::InvalidInput, ""))?;
 Duration::new(s * 3600, 0)
 } else if s.ends_with("min") {
 let new = s.trim_end_matches("min");
 let s = new.parse::<u64>().map_err(|_| io::Error::new(io::ErrorKind::InvalidInput, ""))?;
 Duration::new(s * 60, 0)
 } else if s.ends_with("s") {
 let new = s.trim_end_matches("s");
 let s = new.parse::<u64>().map_err(|_| io::Error::new(io::ErrorKind::InvalidInput, ""))?;
 Duration::new(s, 0)
 } else {
 let s = s.parse::<u64>().map_err(|_| io::Error::new(io::ErrorKind::InvalidInput, ""))?;
 Duration::new(s, 0)
 };

 Ok(ConfigDuration(d))
 }
}


impl Display for ConfigDuration {
 fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
 let ms = self.0.subsec_millis();
 let s = self.0.as_secs();
 if ms > 0 {
 f.write_str(&format!("{}ms", ms as u64 + s * 1000))
 } else {
 if s >= 3600 && s % 3600 == 0 {
 f.write_str(&format!("{}h", s / 3600))
 } else if s >= 60 && s % 60 == 0 {
 f.write_str(&format!("{}min", s / 60))
 } else {
 f.write_str(&format!("{}s", s))
 }
 }
 }
}

```
这样子我们在加上声名即可以实现自定义的序列化过程了：
```RUST
pub struct CommonConfig {
 #[serde_as(as = "Option<DisplayFromStrOrNumber>")]
 pub rate_limit_per: Option<ConfigDuration>,
}
```

## 结语
序列化不管在配置还是在传输等过程中，都是必不可少的存在，了解序列化及反序列化的过程我们将可以更快的找到切入点去实现自己的功能。


点击 **[关注]**，**[在看]**，**[点赞]** 是对作者最大的支持

25干货系列从零用Rust编写正反向代理，序列化之serde是如何工作的

# wmproxy
`wmproxy`已用`Rust`实现`http/https`代理, `socks5`代理, 反向代理, 静态文件服务器，四层TCP/UDP转发，内网穿透，后续将实现`websocket`代理等，会将实现过程分享出来，感兴趣的可以一起造个轮子

## 项目地址

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

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


## 敏感的时间
&emsp;&emsp;现实生活中大家都对时间有着概念，比如“快上班了，要不然要迟到了。”、“这班怎么这么久，怎么还没下班？”、“啊？已经晚上12点啦，等我这把游戏玩完。”、“叮叮叮，起床闹钟一直在催着你起床了。”

&emsp;&emsp;闹钟、自然变化、生物钟为我们提供着时间的保证。而计算机的世界里，就靠着`硬件定时器`，控制着时间的流逝，如果哪一天本地时间和别人的时间不一致了，此时需要找别人对时，这也就是经典的`网络时间协议(NTP)`。

&emsp;&emsp;现实的生活中，通常以分钟或者小时乃至天去和别人约定时间，而在计算机的世界里，在我们看来那就是朝生暮死的蚍蜉一般，他们生命较短，所以对他们来说，通常用`s`或者`ms`来乃至`μs`做通知，所以需要严格的遵守时间约定，绝对不允许有赖床的行为。

## HTTP行为中的定时器
> HTTP/HTTPS/WebSocket的访问撑起了互联网总流量的半臂江山，日常接触中APP或者游戏这种对外服务的基本上均是通过HTTP及HTTPS进行服务，长链接由于兼容小程序这类的大部分游戏直接也从普通的Socket转为WebSocket直接做全网的兼容。WebSocket的基础协议是由HTTP升级而来，所以也归于HTTP协议。

主要有以下列行为定时器
1. **连接超时定时器**
2. **读操作超时定时器**
3. **写操作超时定时器**
4. **读/写操作超时定时器**（在规则的时间内同时完成读和写）
5. **keep-alive超时定时器**（连接保持的最长时间）


### 定时器类的定义
相关的超时数据均存放在该类里，接下来类型进行相应的处理
```RUST
#[derive(Debug)]
pub struct TimeoutLayer {
 pub connect_timeout: Option<Duration>,
 pub read_timeout: Option<Duration>,
 pub write_timeout: Option<Duration>,
 pub timeout: Option<Duration>,
 /// keep alive 超时时长
 pub ka_timeout: Option<Duration>,

 read_timeout_sleep: Option<Pin<Box<Sleep>>>,
 write_timeout_sleep: Option<Pin<Box<Sleep>>>,
 timeout_sleep: Option<Pin<Box<Sleep>>>,
 ka_timeout_sleep: Option<Pin<Box<Sleep>>>,
}
```

### 连接超时定时器
&emsp;&emsp;此时约定的是客户端向服务端请求TCP连接建立的最长时间，如果没有约定，将由系统连接超时的或者确认不可达的时候才返回失败。

&emsp;&emsp;如果没有连接超时，那么以下我们的型业务场景模拟：

1. 在弱网的环境下，比如手机信号不好的地方，一次连接请求建立可能会花费10秒左右才能返回，那么如果我们没有连接超时，用户在等待了8秒，客户端的界面都没有办法给出任何的响应，就会认为服务端出现了问题或者频繁的重启客户端应用不断的进行重试而得不到预期的反馈。在App设计中，对这种情况的用户体验极差，需要在指定的时间内给用户反馈出当前网络无法访问。

2. 客户端的设计模型中，如果有定时请求或者埋点数据之类，如果没有超时机制，容易出现短时间内打开的socket过多出现资源耗尽的情况，其次客户端不知道是否将数据已经进行发送，不确认是否需要将该条数据进行缓存以便下一次推送。

> 在设计模型中，连接超时必不可少，因为各种业务场景的不同，需要要不同的时间内得到预期的反馈。以下是连接超时在Rust中的实现，因为只存在于客户端主动连接服务端，所以连接超时只在客户端实现。

```RUST
async fn inner_connect<A: ToSocketAddrs>(&self, addr: A) -> ProtResult<TcpStream> {
 if self.inner.timeout.is_some() {
 // 获取是否配置了连接超时, 如果有连接超时那么指定timeout
 if let Some(connect) = &self.inner.timeout.as_ref().unwrap().connect_timeout {
 match tokio::time::timeout(*connect, TcpStream::connect(addr)).await {
 Ok(v) => {
 return Ok(v?)
 }
 Err(_) => return Err(ProtError::Extension("connect timeout")),
 }
 }
 }
 let tcp = TcpStream::connect(addr).await?;
 Ok(tcp)
}
```

通过指定超时时间来对连接的建立监听。

### 读操作超时定时器
> 大部分HTTP请求，只有得到完整的数据才能进行处理，少部分如文件上传这种可以边上传边操作，而是否能开始操作关系到请求的响应时间。

读超时大概有以下的可能：
1. 服务器处理请求的时间太长，导致客户端等待超时。
2. 服务器返回的数据量过大，导致客户端读取数据的时间超过了规定的时间。
3. 网络延迟或网络不稳定，导致客户端无法在规定的时间内读取完数据。

这造成客户端无法及时处理数据，可以报错好让客户端换备用线路或者备用服务器等以便及时的处理数据。

读操作我们不管服务端或者客户端，不管http/1.1或者http/2均由`is_read_end`字段来判定，在未读完当前请求的数据前，判断是否超时。
```RUST
pub fn poll_ready(
 &mut self,
 cx: &mut Context<'_>,
 ready_time: Instant,
 is_read_end: bool,
 is_write_end: bool,
 is_idle: bool,
) -> ProtResult<()> {
 let now = Instant::now();
 if !is_read_end {
 if let Some(read) = &self.read_timeout {
 let next = ready_time + *read;
 if now >= next {
 return Err(crate::ProtError::Extension("read timeout"));
 }
 if self.read_timeout_sleep.is_some() {
 self.read_timeout_sleep.as_mut().unwrap().as_mut().set(tokio::time::sleep_until(next.into()));
 } else {
 self.read_timeout_sleep = Some(Box::pin(tokio::time::sleep_until(next.into())));
 }
 let _ = Pin::new(self.read_timeout_sleep.as_mut().unwrap()).poll(cx);
 }
 }
 
 Ok(())
}
```

其中比较复杂的是如何判断`is_read_end`，因为需要区分服务端客户端或者是http/1.1及http/2，这个源码实现 [http2核心](https://github.com/tickbh/wenmeng/blob/main/src/protocol/http2/control.rs)，[http1.1核心](https://github.com/tickbh/wenmeng/blob/main/src/protocol/http1/io.rs)

### 写操作超时定时器
> 对于客户端的写，就是将请求发送到服务端，而服务端的写，刚好是将返回发送给客户端。这是数据处理的重要的一环。

&emsp;&emsp;在异步的处理socket中，都会将socket设置成非阻塞，也就是`nonblocking`，此时我们会得到一个默认的内核缓冲区大小。如果在该缓冲区未满前，我们写入数据将是0等待，该缓冲区的数据将由系统进行数据发送给另一端。

&emsp;&emsp;如果对方不将我们的缓冲区数据读走，那么我们此时是无法在写入到该缓冲区的，如果远程端不读，我们的传输速度将会无限的接近于0KB/S。

&emsp;&emsp;此时如果是服务端，有数千上万个这种该连接，每分钟只读走几个字节的数据，那么没有写入操作，我们将要保持上万的空闲连接，而默认的端口连接数为65535，那么客户端将会耗尽我们的服务资源。此种为 **[慢速攻击]**。

该操作是通过`is_write_end`来判断是否写入完成。监听方式和读的一致，核心代码在 [timeout](https://github.com/tickbh/wenmeng/blob/0.2.0/src/protocol/layer/timeout.rs)，此处不再赘述


### 读/写操作超时定时器
> 该定时器是由读和写需要共同来完成的，在很多场景中，我们只关心该请求需要耗时多少时间来完成，此时我们不关心是读的时间或者写的时间，所以此时表示请求完成的需要在这个时间下完成

就比如HTTP/1.1中的`Slow headers`，也就是慢速头攻击。正常来说，我们的http/1.1的头类似如下：
```
GET / HTTP/1.1\r\n
Host : wm-proxy.com\r\n
Connection: keep-alive\r\n
Keep-Alive: 900\r\n
Content-Length: 100000000\r\n
Content_Type: application/x-www-form-urlencoded\r\n
Accept: *.*\r\n
\r\n
```
整个报文的结束将有一个空白的`\r\n`，如果没有收到该标记，服务端无法得到完整的头信息，也无法正确的把数据转成`Request`，那么此时客户端可以占用了大量的连接，从而使服务端拒绝服务。

此定时器判断由`is_read_end`及`is_write_end`有一方为false，监听方法略。

### keep-alive操作超时定时器
> 在http/1.1中，端口是可以复用的，从而减少socket的反复建立关闭，并可以一定程度上快速的响应，这是端口请求完成后，又没有后续的请求，此时当前socket线路为空闲，即当前空闲线路的保持时间。

&emsp;&emsp;keep-alive为保持连接，此参数用的好可以极大的加速服务的访问，此参数设置不好的时候，如设置成`9999s`，那么客户端将会保持当前的空闲socket很久，从而另一个程度上造成了拒绝服务了。

&emsp;&emsp;此判定由`is_idle`来判定，判断当前是否空闲，也就是上一个请求已经读写均已完成，后一个请求还未进来，此时就为空闲时间。监听方法雷同，略。

### 测试客户端
```RUST
let url = "http://www.baidu.com";
let req = Request::builder().method("GET").header(HeaderName::ACCEPT_ENCODING, "gzip").url(url).body("").unwrap(); Instant::now());
let client = Client::builder()
 // 是否支持HTTP2
 // .http2(false)
 // 是否仅使用HTTP2
 .http2_only(true)
 // 连接使时时间3秒
 .connect_timeout(Duration::new(5, 0))
 // 设置keep-alive时间10秒
 .ka_timeout(Duration::new(10, 0))
 // 设置读超时5秒
 // .read_timeout(Duration::new(5, 0))
 // 设置写超时5秒
 .write_timeout(Duration::new(5, 0))
 .connect(url).await.unwrap();
//发起请求
let (mut recv, sender) = client.send2(req.into_type()).await?;
//接收请求
let mut res = recv.recv().await.unwrap();
//接收所有body数据
res.body_mut().wait_all().await;
```

### 测试服务端
```RUST
let mut server = Server::new(stream, Some(addr));
// 设置读操作5秒
server.set_read_timeout(Some(Duration::new(5, 0)));
// 设置写超时5秒
server.set_write_timeout(Some(Duration::new(5, 0)));
// 设置读写超时5秒
server.set_timeout(Some(Duration::new(5, 0)));
async fn operate(req: Request<RecvStream>) -> ProtResult<Response<String>> {
 let response = Response::builder()
 .version(req.version().clone())
 .body("Hello World\r\n".to_string())?;
 Ok(response)
}
let _ = server.incoming(operate).await;
```

### 结语
&emsp;&emsp;时间的尺度越小，那么对时间的敏感度越高，定时器是约束，也是保护，保护不受攻击。感谢定时器给我们构建一个更加稳定的互联网世界。

点击 **[关注]**，**[在看]**，**[点赞]** 是对作者最大的支持

24从零用Rust编写正反向代理，细说HTTP行为中的几种定时器

# wmproxy
`wmproxy`已用`Rust`实现`http/https`代理, `socks5`代理, 反向代理, 静态文件服务器，四层TCP/UDP转发，内网穿透，后续将实现`websocket`代理等，会将实现过程分享出来，感兴趣的可以一起造个轮子

## 项目地址

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

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


## 温柔的小姐姐
&emsp;&emsp;我的名字叫 **流控**，至于我的工作你们看到我的名字也想必很清楚，我被创造出来为了的这世界更美好，期望这世界永远不会堵车，所以他们称我为温柔的小姐姐。

## 与数据不得不说的故事
&emsp;&emsp;数据是个急性子的家伙，每次看他总是充充忙忙的带着一大推的大部分，想在我这里横冲直撞的。这就不得不说上一次他那急忙的模样了。

&emsp;&emsp;还记得上次他带着一大帮的兄弟，成千上万个的，知道的人知道他们在护送重要资料，不知道的还以为他们去打仗呢！

&emsp;&emsp;我守护的是一个广场，还有广场后面的一条路。

&emsp;&emsp;那一次他带着兄弟来的太快，就跟我说：“流控姐姐，快点通往广场的门打开，我这边有兄弟们来了”。

&emsp;&emsp;我就把门打开，让他带着他的兄弟们过来快速的进入广场。

&emsp;&emsp;不一会儿广场慢慢的有点挤了起来，他就跟我说：“你快点把广场前面的路开大点，后面的兄弟来的太快，这条路又不能快速的通过，会把你的广场挤满的”。

&emsp;&emsp;我就说：“不行哦，我接到上级的指令，通知说现在这条路只能开这么大，每秒通过100人最多了（`限速1M/S`），前面那条大路现在的人太多了，你这边要是太多的人会全部堵在一起的。”

&emsp;&emsp;他就急忙的问：“那怎么办，我现在数据很重要，也很急，你看旁边那些无关的也一直在占用着路，你能不能向你的上级反馈一下？”

&emsp;&emsp;我就说：“我现在就帮你反馈一下，但是要等下上级的调度哦。暂时你还是只能通过这么多！”

&emsp;&emsp;我转身向上级说：“这边有大量的重要数据拥堵在广场这，他们请求调高优先级，提高缓冲区及通行速度。”

&emsp;&emsp;上级答：“我现在去协调一下，把其它的数据叫他们先缓缓，你叫他先耐心等待下”

&emsp;&emsp;眼看着上级的指定还没有下来，但是广场上已经快挤满了人了，我赶紧去那个广场的入口处理，我就把那个广场前的那个闸机打开，不让新的人进来。要不然等下广场出事故了。

&emsp;&emsp;数据兄弟看着我，我也表示我暂时也无能为力，我说：“让你后面的兄弟缓缓，我这广场暂时容纳不下那么多人了（数据缓冲区已满，不再接收新的数据，也不会读出socket上的数据，反向的压着流量的传输）。”

&emsp;&emsp;此时正在我们焦急等待的时候，上级传来了指令，说其它位置已经暂缓处理了，你当下可以把广场外围开起来，并把广场前面的路两边都放开（优先级调高，优先传输重要数据）。

&emsp;&emsp;我就立马启动了扩容的按钮，只见广场外围的大圈全部打开，可以容纳10倍的人，并把广场前的出口路打开，可以通行`10000人/s`（`限速100M/S`）。

&emsp;&emsp;数据说：“快快快，已经可以通行了，快把闸机打开，我要赶紧带着兄弟们把资料送到。”

&emsp;&emsp;只看到广场出去的人比进入的人多了很多，广场一下子空了起来。

&emsp;&emsp;很快数据就全部带着他的兄弟走了，去完成任务了，说：“等我完成这任务，我向你来讨教讨教你这边的管理法，怎么能保证高效的完成调度的任务”。


## 当起了老师
> 数据完成了他的任务，回来的时候在跟我请教了起来。

&emsp;&emsp;数据说：“我就是想问问，你的那个广场是怎么个情况，怎么一满了就可以自动防止人进入，然后一空了就可以通知人进入的。”

&emsp;&emsp;我跟他解答说：“我这是一个异步处理的一把刀，我可以在空闲的时候完全的不占用任何的资源，在忙碌的时候又可以把全部的CPU用上。完成高效的运转。”

&emsp;&emsp;数据问：“那你用了什么秘密法宝，他这么厉害？”

&emsp;&emsp;我说：“我就是用了一种古代就开始在用的——旗语，也就是`PollSemaphore`，我这里存一把旗，并存了一把钥匙，当我有钥匙的时候，也就是广场人没满的时间，你来了我就放你进场，这样子我也不用管广场里有没有满。当你进入后，如果 广场满了，他会将我手上的钥匙拿走。没有钥匙的话，新进来的人我就不会让你们进入了。”

&emsp;&emsp;数据问：“那如果广场有位置的话，那你怎么样才能重新得到钥匙？”

&emsp;&emsp;我说：“这就是我高效的时候了，刚刚我钥匙交出去的时候，我已经调用了`self.sem.poll_acquire(cx)`，当广场有人出去的话，他就会通知`Waker`，然后我就可以主动去找他拿到钥匙了，这样子我就可以重新拥有钥匙了。”

&emsp;&emsp;数据说：“原来你缓冲区是这样子的吖，那你出口的那条路上，怎么限定人流量的？”

&emsp;&emsp;我说：“这个就要有请`RateLimitLayer`了，他有定义了`per`每个周期的时间就比如每秒，或者每分钟，或者每小时，`nums`就是每个周期内可以通行的字节数。下面是详细的定义。”
```RUST
pub struct RateLimitLayer {
 /// 周期内可以通行的数据
 nums: u64,
 /// 每个周期的时间
 per: Duration,
 /// 当前周期下，还剩下可通行的数据
 left_nums: u64,
 /// 下一个时间重新计算的日期
 util: Instant,
 sleep: Pin<Box<Sleep>>,
}
```

&emsp;&emsp;数据问：“那如果当前周期耗完的话，是不是还没有到下个周期前就不能继续通行了？”

&emsp;&emsp;我答：“确实是的，你当前周期耗光了可用的额度，那不能通行了哦，我就会向`Pin::new(&mut self.sleep).poll(cx).is_pending()`，如果他现在不能用，就等会到那个时间，他就会通知我啦。他通知我，我就会重置掉到前的数据，这样子你就可以继续通行了。”
```RUST
self.left_nums = self.nums;
self.util = Instant::now() + self.per;
self.sleep.as_mut().set(tokio::time::sleep_until(Instant::now() + self.per));
```
&emsp;&emsp;数据说：“小姐姐你好厉害，还好有你在这里严格的控制着，我才能那么准时的到达”。

&emsp;&emsp;我答：“那是，请叫我温柔的一刀，该严格的时候我就会严格，不严格那只会更麻烦。你说是吧。”

> 流控在互联网中是很重要的概念，因为基本上大部分的公网出口都不是无限的，就同一个网站，API的接口重要性肯定会比静态文件重要性来的高，所以为了使系统更稳定，感谢流控小姐姐使出这温柔的一刀。

点击 **[关注]**，**[在看]**，**[点赞]** 是对作者最大的支持

23从零用Rust编写正反向代理，流控小姐姐的温柔一刀！

# wmproxy
`wmproxy`已用`Rust`实现`http/https`代理, `socks5`代理, 反向代理, 静态文件服务器，四层TCP/UDP转发，内网穿透，后续将实现`websocket`代理等，会将实现过程分享出来，感兴趣的可以一起造个轮子

## 项目地址

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

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


## 数据包的自白
我是一个小小的数据包，今天我将跟着大部步出发，去体验传说中的HTTP之旅，听前辈说那是一场精彩绝伦的出走之旅。

## 旅行准备

&emsp;&emsp;首先，我先来到了出发地，他们在整理各项目数据，包括选择公交（HTTP1）还是自驾（HTTP2）或者询问是否有私家车（H2C），然后目的地是哪个房间（Path），是否防止旁边的人窥探（TLS），选择轻装上阵还是带上行李箱（GET或POST等），还有其它杂七杂八的事情（是否支持压缩，数据长度等）。

&emsp;&emsp;我问：“导游，我们什么时候可以出发”。

&emsp;&emsp;导游答：“别急，这躺路我熟的很，这次的数据有点重要，正在向对方获取加密信息，这是防止偷窥的秘诀。万一在中途被截走，那会使我们损失惨重。”

&emsp;&emsp;过了一会，我又问：“现在可以出发了吗？”

&emsp;&emsp;导游答：“可以了，我们通过交换已经将约定的加密信号确定下来了，让我先给你做个加工。”

&emsp;&emsp;我就跟着导游来到了一个加工场，进入其中，任由它来操作，当我走出加工场的时候，我突然发现我的模样完全跟变了个人似的。我差点认不出我自己。

&emsp;&emsp;我们就来到了公交站台（浏览器），他看到我们的到来，快速的帮我们排上了班次，紧接着，我们跟着车一直的往前走，我东看看西瞧瞧，我有看到像我一样乔装的自己都认不出来的，也看到了没有经过打扮的，都可以看的一清二楚，我猜那一定不怕别人窥探的吧（没用TLS）。

## 旅行中转
> 突然公交车停了下来，播报着：“欢迎来到wmproxy”。

&emsp;&emsp;我有点疑惑的问导游：“我记得我们的目的地不是这里，为什么在这里停下来？”。

&emsp;&emsp;身经百战的导游对我说：“看来我们的目的地被隐藏起来了，用来更好的保护目的地家园不被破坏，只有通过这里中转走专属的路线才能到达目的地。”

&emsp;&emsp;接着我急着问：“那我们在这里要做啥吖？”

&emsp;&emsp;导游回答：“接下来我们走的就是私人的领域了，我们路上看到的都是主人的朋友，并不会把我们的秘密泄漏出去，所以我们需要把我们身上打扮的乱七八糟的还原。”

&emsp;&emsp;我就跟随着来到了加工场，加工场把我们身上乱七八糟的装扮通过特定的方法进行了还原（卸掉TLS转HTTP），走出加工场，我又看到帅气的自己。我问：“那么接下来我们做什么？”

&emsp;&emsp;导游回答：“根据我们原来的信息，他现在要安排我们做私家车（HTTP2），好灵活地做响应，你看，那车已经来了，我们一起上车吧。”

&emsp;&emsp;我们坐上了私家车，我发现我带的东西被切割成了奇奇怪怪的几个部分。我就问司机：“为什么原来我就一个整体，现在变成了奇怪的几个部分？”

&emsp;&emsp;司机笑着回答：“在这车里，通常副驾驶上坐着Header，也就是你带着的那些属性全都组装在这里了，后排通常就是额外的数据包，当然你们数据包兄弟可能会很多，你看看你的手臂上，跟着相同导游的此刻都被挂上了红色的布。”

&emsp;&emsp;我才发现，原来刚在加工场的时候还帮我和导游都做上了特殊的标记了吖，而且我还发现，每个人头上还顶着一个特殊的帽子。包括了颜色，还有一串特殊的数字。看起来附带了我身高体重（实际长度）这些信息。

## 旅行到达
> 私家车停在了一个漂亮的房间前面，我想这是旅程的目地吧。
> 此时我终于知道我这躺的任务了，原来我需要来这里获得一个重要的文件，这文件数据量还大的有点夸张，是我来时数据的上万倍（Content-Length）。

&emsp;&emsp;这时候我有点慌乱的找到导游：“这要带的数据那么多，那么重要，我怎么样才能把他们安全的带回去吖。”

&emsp;&emsp;导游这时候就说：“你还记得我们开始带的工具包列表（`Accept-Encoding`）吗？”

&emsp;&emsp;我说：“记得记得，当时好像把名字记下来了，好像是说家里有真空机（gzip），压缩机（brotli）吧？”

&emsp;&emsp;导游答：“对的对的，你看到那边的那座大山（gzip）吧，等下我们会带着数据兄弟们爬上那大山，到时候我们就可以瘦很多，那样子接下来我们动用的资源会小很多。”

&emsp;&emsp;我们带着浩浩荡荡的数据大军去爬了山，我确实发现我们的个头都小了许多，但是我觉得这大军的数量远远没有一开始说的上万倍。

&emsp;&emsp;我问：“这大军的数量不对吖，不会有兄弟们迷路了吧？”

&emsp;&emsp;导游笑着回答：“这边的房子就这么大，如果把数据一下子从异次元全部召唤出来（文件中读取）那不直接把这小小的房子全部挤满了吖，看到上面那个指示牌了没有？”

&emsp;&emsp;只见指示牌上面写着：“当前房间可容纳人数4096/4096”，此时前面有100个兄弟走出了房间就变成了，`3996/4096`，然后又看到异次元召唤出了新的100个兄弟。

&emsp;&emsp;此时我晃然大悟：“原来这东西就是控制着不会膨胀的秘密吖（内存缓冲区已满）。”

## 旅行返程
> 当我们瘦完身后，就有一辆辆的小汽车来接我们回家了

&emsp;&emsp;此时一辆辆汽车大军稳稳的向前行驶，突然间速度慢了下来，我就很好奇的问司机：“刚刚不是速度很快的吗，怎么到这个地方突然间速度就慢下来了吖？”

&emsp;&emsp;司机指了指前面说：“前面是一段较窄的路，你看看两边的车流，如果全速全进的话，大家都会堵死在这段路上，所以你看上方，有个牌子100辆/分钟，也就是一分钟只能通过100辆，要不然就会挤到前面的窄路上，所以我们现在速度是慢了下来，但是我们这条线路还是可以每分钟可以通过100辆，也不算慢。”

&emsp;&emsp;于是我就往两边看，两边的车也都是差不多的速度在通行，慢慢的我们来到了比较狭窄的路，确实这里无法通行通行太多的车（从内网转入公网，传输能力下降），我想：“高负载的情况下确实只能通过这种方式来限制，要不然此刻交通应该瘫痪掉了吧，大家越急着挤，越没法正常通行。”

&emsp;&emsp;紧接着，我们又回到了中转站了，我突然很好奇的想着：“要是我们兄弟全部挤到中转站这里，他会不会直接被挤满了？”

&emsp;&emsp;这时我听到导游说：“别发呆了，公交车来了，我们该出发了。”

&emsp;&emsp;我顿时有点迷惑：“我们后面不是还有很多兄弟吗？不用等他们集合完再出发吗？”

&emsp;&emsp;导游就笑着说：“如果全部集合在出发，那我们就得停下来等，然后启动的时候后面的兄弟又得等前面的走完才能走，这样子速度就慢了很多，这是其一。另外，你看这中转台上也容不下这么多的兄弟同时停留在这里，他根据我们帽子的颜色帮我们分好了公交车啦，上车！”（此时代理只处理了头部数据，body数据只做简单的转发）

&emsp;&emsp;我突然想到我们现在来到了公共区域，我问导游：“我们是不是得保证我们的数据安全，现在我们都是属于公共区域了。”

&emsp;&emsp;导游回过神来说，对对我们先去加工厂处理下，那个是我们的专属加工场。还好你提醒，要不然数据就不安全了。（TLS加密）

&emsp;&emsp;我们从加工厂出来乘上公交车，一路平稳的来到了出发的站台（浏览器），这时候我们一个个从加厂场出来（TLS解密），我们的兄弟有点多，浏览器的站台有点放不下了，我就问：“我们不是到达了目的地了吗？他怎么不还来接我们到目的地？”

&emsp;&emsp;导游笑着说：“此次我们带回来的信息量有点大，而且还是经过了瘦身的，我们等下去那个标gzip的房间进行处理，然后你看那边有个异次元空间（临时文件），我们先到那里下，好让后来的兄弟有地方住。”

&emsp;&emsp;我跟着来到了异次元空间，里面是一个空旷，超大的空间，我们这么多兄弟秩序井然的排列在一起，直到最后一个兄弟到达，我们就看到了前面有一个出口，我就问：“从那个出口出去我们就完成任务了吗？”

&emsp;&emsp;导游就回答：“从那个出口，不要乱，现在兄弟都到了，知道大家各自的位置，就不会乱套了，大家排队往前走，不要乱。”

&emsp;&emsp;当我们一个个出来后，慢慢的把身子还原回来，我看着自己变成了一个巨大的人，很完整的，帅气的，我想我应该完成了这一项任务了吧。

> 此时浏览器播报，数据传输完成，完整无误，任务完成，进行展示。

## 结语
这是数据的一趟历险记，也是互联网上每天都在发生的，他快速稳定的传播，给我们构建了一个美好的世界。


点击 **[关注]**，**[在看]**，**[点赞]** 是对作者最大的支持

22从零用Rust编写正反向代理，一个数据包的神奇HTTP历险记!

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