81 lines
10 KiB
Markdown
81 lines
10 KiB
Markdown
# Project-2 Balancebeam 实现记录
|
||
|
||
## 综述
|
||
|
||
这东西本质上是一个类似于反向代理之类的东西，
|
||
|
||
## 每个 Milestone 的说明
|
||
|
||
### Milestone 0
|
||
|
||
依然是传统的看代码环节。
|
||
|
||
首先是 `main.rs` 里面的东西。
|
||
1. `CmdOption` 用的是 `clap` 这个 crate，用非常奇葩的 macro 语法来定义命令行参数并解析。
|
||
2. `ProxyState` 是执行线程的共享参数，不知道有啥特别的意义，可能是为后面的东西预留的
|
||
3. `TCPListener` 是标准库提供的东西，提供了一个简单的 TCP server。它通过 `incoming` 迭代器来返回构造的 TCP stream 抽象，这种字节流抽象最终会被分发给执行线程。
|
||
4. 执行线程：
|
||
1. 首先，它随机选择一个上游服务器并打开与该服务器的连接。如果服务器无了，返回502。
|
||
2. 然后循环从客户端读取请求，客户端可以在一个连接上发送任何数量的请求，而 `balancebeam` 会将每个请求转发到上游服务器。如果客户端发送了一个错误的请求，会有一些错误处理。
|
||
3. 一旦请求被读取，`balancebeam` 就会添加一个 `X-Forwarded-For HTTP` 头，以便上游服务器能够知道客户端的IP地址。（这对理解并不特别重要；它只是一个事实上的标准头。）
|
||
4. 接下来，`balancebeam` 将请求转发给上游服务器。如果在传输请求时有错误，它就会通知客户端。
|
||
5. 接下来，`balancebeam` 试图从上游服务器读取响应。如果响应被破坏或在接收时有其他问题，它将通知客户端。
|
||
6. 最后，`balancebeam` 将响应转发给客户。
|
||
|
||
然后是封装库 `request.rs` `response.rs`，就像 project 1 里面的 gimili wrapper 一样，又臭又长。分别用来基于 TCP 字节流来处理 HTTP 请求和响应。分别提供了 `read_from_stream` 和 `write_to_stream` 这两个接口供 main 处理两个 TCP 链接（ Client HTTP req -> Proxy HTTP req -> Server, Server HTTP resp -> Proxy HTTP resp -> Client）。具体的里面的接口我也没细看，等到 Milestone 2 需要修改的时候再说吧。
|
||
|
||
### Milestone 1
|
||
|
||
讲义上没有提出明确的实现目标，简单的把代码改成多线程而已。主要就是把 `state` 用 `Arc` 给共享掉（反正是不可变借用，十分的安全）。
|
||
|
||
`ThreadPool` 和 `std::thread` 没啥太大区别，都封装的很好了，直接看一下 `doc.rs` 里面的例子就行了。
|
||
|
||
### Milestone 2
|
||
|
||
又是一个奇怪的 task point，要求把所有的 IO 换成异步的。但是依然没有任何的难度，根据 IDE 提示加 `async` 和 `await` 就可以了。
|
||
|
||
### Milestone 3
|
||
|
||
实现故障转移（failover）：如果一个 upstream 挂了，将连接选一个别的（一开始有一堆可用的 upstream），同时还要标记这个挂掉的 upstream 防止后面的连接继续选择它；如果所有的 upstream 都挂了，这时候才返回错误。实现方法是修改 `main.rs::connect_to_upstream`，因为这个过程仅在建立连接的时候执行。
|
||
|
||
实现了一个最简单的，在 `ProxyState` 里面加了一个 `Arc<Mutex<Vec<usize>>>`，用来存放可用的 upstream 的 index。
|
||
选择的时候就在这个加了锁的 `Vec` 里面选，然后用这个里面的 index 来取对应的 upstream 的地址。如果一开始就发现这个可用列表为空，那么直接返回错误；否则尝试连接。如果连接失败，需要将这个 index 从可用列表里面删除。唯一需要注意的就是，可以在 `TcpStream::connect` 之前释放一次锁，然后需要修改可用列表的时候再加锁，因为 connect 比较耗时。
|
||
|
||
感觉 RwLock 和这个东西差不多，但是可能在某些情况下的并发性能会更好一些。至于它说的用 channel，感觉挺麻烦的，所以没写。
|
||
|
||
### Milestone 4
|
||
|
||
实现周期性的主动连接测试（active health check）：就是我们的代理程序隔一段时间向每个 upstream 的某一个特定地址（参数里面的 `active_health_check_path`）发一个 HTTP 请求，如果返回 200 就说明没问题；如果之前有问题现在没问题，就可以继续用；出现问题则需要标记为下线。
|
||
|
||
由于上个 Milestone 里面用到的极简数据结构，导致实现起来有点生草。这里我是用 `tokio::spawn` 来生成了一个 task，根据文档的说明，这是一个 green thread，鬼知道是什么东西。然后一个大循环，先 sleep 一波（不能放到后面，因为他的测试比较智障，放到后面会出错）；遍历所有的 upstream（不管有没有被 disable），建立 `tcpstream` ，构造空请求，然后接受响应，最后判断状态码是不是200。以上任何一步出错，都必须从可用列表中删除（注意有可能已经删除了）；如果是 200，则需要将它重新加入到可用列表中（如果之前被删除了的话）。
|
||
|
||
一个坑：不要使用前面实现的 `connect_to_upstream`，因为它无法连接到已经被移出可用列表的 upstream（不如说它根本就不让自己选 upstream），但是我们这里需要测试每个 upstream。
|
||
|
||
### Milestone 5
|
||
|
||
实现请求速率限制。针对每个 IP 限制一段时间内的请求数量，如果次数过多就返回 `HTTP 429`。提到了三个算法，leaky bucket、fixed window 和 sliding window。leaky bucket 不太适合这里的要求，就不管了。
|
||
|
||
这里实现了 fixed window 和 sliding window。这两个玩意基本上一样，fixed window 简单一点，单纯记录每个 time unit 里面请求的次数，达到上限就丢掉，开始下一个 unit 的时候就重置计数器。这就导致了一个问题，如果请求集中在计数器重置的时间点附近，就会导致短时间内的请求速率翻倍，实际上超过了限制。 sliding window 在此基础上考虑了上一个 unit，按照一定比例将上一次 unit 的请求计数折算到当前的请求计数中，从而避免了上述的问题。一种简单的实现方式就是，记录当前 unit 的计数和上个 unit 的计数，考虑当前时刻向前推一个 unit 的窗口，用窗口和上个 unit 重叠的比例进行折算。写成算式就是 $\frac{UNIT - (time.now - cur\_unit\_start)}{UNIT} \times prev\_cnt + cur\_ cnt$。
|
||
|
||
具体实现上，用一个 `HashMap<String, RateRecord>` 来维护 IP 地址到请求次数的信息。因为一个 IP 地址会发起多个 connection，所以得把数据放到全局的 `ProxyState` 里面再用 `Arc<Mutex<>>` 裹起来。封装了 `RateRecord` 类型来存放前面提到的这些数据，然后写了几个简单的小函数来让 handler 代码更加简洁一些。这些都不是什么难绷的事情，最难绷的是 `HashMap` 居然不支持直接修改内容，下面细说遇到的问题。
|
||
|
||
遇到的问题
|
||
1. `HashMap` 不能直接修改 `value` 的内容，说是要实现 `IndexMut` 这个 trait，但是 `HashMap` 没实现，所以不能像实现了这个 trait 的 `Vec` 类型那样直接 `map[key] = newvalue`，而是要用非常别扭的 `(*map.get_mut(&key).unwrap()).field = new_val_for_field` 来写。
|
||
2. 对于 primitive 类型之间的显式类型转换好像可以直接用 `as xx`，这个东西好像是编译器实现的，因此既不需要标准库也不需要什么其他的转换方法。不过剩下的转换就要通过 `From` 和 `Into` 这些 trait 来整了。
|
||
3. 最后就是，直接运行 `cargo test` 的时候有可能会在 `assert_eq!(total_request_count, rate_limit_threshold);` 这个断言上报错，不过单独测这一个点的时候从来不会错。根据打印信息判断，这大概是由于前面实现的 health check 的线程发送的检查请求也被计算在累计请求数中，所以导致这个东西爆炸。至于为啥会出现这个事情，可能是随机数（或者是 cpu 性能问题）导致测试时间过长，然后 health check 的线程开始执行了。
|
||
|
||
## 附加任务？
|
||
|
||
实验设计者提供了不少的可选项，看上去都挺棒的，但是我懒得自己写测试了，所以就不做了捏，啦啦啦。
|
||
|
||
## 完结感言
|
||
|
||
至此， CS110L 的5个 Assignment 和2个 Project 就全部做完了，因为刚开学不太适应直接给感冒了、外加要上无聊的课（说的就是你们，智障思政课），进度有点慢，不过姑且还是在第一周内写完了，前前后后大概花了一个多星期吧（CS144 那么多我才写了6天，不过那个属于是 full-time 了），基本上 rust 这些东西算是有点入门的感觉了（之前好几次尝试通过看 rust book 入门都失败了）。
|
||
|
||
这些编程作业虽然量不是很多（总计 1k lines 不到？），不过基本上覆盖了 rust 编程的大部分常见主题。写这种 project 代码的好处是，相比于看 rust-lang 那些书，调试运行更加形象，而且需要大量重复那些最常见、最基本的概念和模式，比较让人能够记得住（大雾）。
|
||
|
||
之所以想起来学 rust，起源于寒假的时候做的操作系统试点班，那一坨蕴藏这各种各样内存和并发问题的代码真的是把我恶心到了，为啥 boilerplate 能这么垃圾啊。rust 通过强制的编译检查，能够避免大部分这种内容，同时提供比 C 语言更高级的抽象，使得处理一些问题的时候不用手写了。但是 rust 的坏处在于，它的机制比较独特，有很多 C 语言里面的 trick 和直观的写法不能用，对于底层代码的映射也不够直观。对于我这种习惯于自动把 C 语言翻译为机器模型的人来说，实际上 rust 的抽象层是增加了心智负担，因为我没法直接通过代码看到汇编了（这就是 C 语言的好处，足够接近机器模型）。现在的感觉这东西对标的其实是 Modern C++ 来着（没错，就是那个 auto script），写完 CS144 的 modern C++ 再来看，这什么 concept、optinal、move 之类的东西，其实和 rust 也差不多来着。如果 C++ 严格 RAII 的话，这 rust 也就比 C++ 多个强制生命周期和所有权检查的样子。
|
||
|
||
虽然做完了，rust 还有很多深入的内容没有去了解，这就以后慢慢看吧，如果用的多的话。
|
||
|
||
就酱，完结撒花。 |