30. 干货系列从零用Rust编写正反向代理，HTTP的组装之旅（中间件） ...

wmproxy

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

国内: https://gitee.com/tickbh/wmproxy
github: https://github.com/tickbh/wmproxy
旅程路线

  大家好，我是这趟旅程的导游，可以叫我导游，我为大家来介绍HTTP的组装之旅。
  大家好，我是这趟旅程的乘客，可以叫我小H，出来玩实在太开心了
旅行开端

首先导游带我来了码头，说是我接一位神秘的来客

  我问：“这个神秘的来客有什么来头？”
  导游答：“这个神秘的来客，名字叫socket，这码头能正常的运营有一半的功劳是他的存在，等下他来了我们要赶紧麻溜的接待。”
  只见远处来了一艘轮船正在缓缓的驶来，他看起来好壮观。
  导游这时候急忙的说：“他马上就停靠进来了，这边码头的工人马上就会将他的货卸下了，去晚了就看不到全过程了。”
  我们就立即来到了停靠点，只见有一套完善的流程正在对接着这一切，我想这是这码头能繁荣的原因吧，高效！
  socket说：“这些东西是http大神要的东西，你们把它们按照指定的顺序转交给他，他会安排如何处理的！”
旅行中转

接下来运送集装箱的过程又会碰到什么有趣的事呢？

  我们跟随着运送车队前行，只见http大神安排了查验数据，但奇怪的是他只检查前面的一辆车，后面的就数一数就放行了。
  于是我就好奇的问：“为什么前面一辆车要检查，后面的车就数一数都不用拿出来检查？”
  http大神就笑着说：“我检查前面的车，因为我不知道这些车装了什么东西，第一辆车带有车队的信息，我就通过他来知道这趟车的内容是什么了。下面我跟你说下这辆车带的信息。”

1. POST /report HTTP/1.1\r\n
2. Content-Type: application/x-www-form-urlencoded; charset=UTF-8\r\n
3. Accept: */*\r\n
4. Accept-Language: zh-CN,zh-Hans;q=0.9\r\n
5. Accept-Encoding: gzip, deflate, br\r\n
6. Host: www.wm-proxy.com\r\n
7. Origin: https://www.wm-proxy.com\r\n
8. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1 Safari/605.1.15\r\n
9. Referer: https://www.wm-proxy.com/\r\n
10. Content-Length: 218\r\n
11. Connection: keep-alive\r\n
12. \r\n

复制代码

  通过这第一辆车的信息，我就知道了他要找的是叫/report的，他用POST的方法去敲他家的门，他可以接受Accept-Language: zh-CN,zh-Hans;q=0.9这种格式的语言，接受Accept-Encoding: gzip, deflate, br这三种格式的压缩，及后面还带着218的数据，在他访问结束的时候不要立刻关闭Connection: keep-alive他可能还有话没说完，叫我再等等，然后通过\r\n\r\n表示他没有其它信息了。
  我惊叹的答到：“原来这车上隐藏了这么多的信息吖，那接下来他们会遇到什么？”
  http大神说：“我现在知道了他们的全部信息了，我现在会把这些车队组装成Request的结构体，等下你看到那边的一扇扇门了没有，那个叫中间件。”
  我来到这门前：“这怎么有两个门呢？他们等下走哪个门呢？”
  http大神说：“他们这些门，都是有统一的规格的，他们需要按照我的规格来建这些门，左边是进的process_request，右边是出的process_response，要严格的按照这流程来，要不然会出错哦。下面我给你说下他这个门有哪些注意的”

1. #[async_trait]
2. pub trait Middleware: Send + Sync {
3.     async fn process_request(&mut self, request: &mut RecvRequest) -> ProtResult<()>;
4.     async fn process_response(&mut self, request: &mut RecvRequest, response: &mut RecvResponse) -> ProtResult<()>;
5. }

复制代码

  他们按照这规格建起各种各样的门，他们可以规定进门后要怎么处理我组装的这个车队RecvRequest，比如要把车队变成红色之类等操作或者记录下有多少个车队经过等，这样我就可以不会显得臃肿，但是我的能力却是大大的提升了起来。
  我表示羡慕到：“原来这种方式强大可以变得这么优雅。那通过这些门后会有什么好玩的？”
旅程终点

过了中间件的门，我们就来到了这旅程的终点。我们来到了一个大广场，广场上有个神奇的装置，看起来像传送门。

  我就很好奇的问：“这传送门看起来的有点高级，这边角好像和刚才那门有点像，难道也是要遵循你的规则？”
  http大神回答：“观察力不错哦，这传送门也是同样的道理哦，因为我也不知道他们要把这个数据拿来干什么，所以我就弄了个传送门，让他们把数据加工好后再给我咯，我的要求就是建传送门必须要按以下格式”

1. #[async_trait]
2. pub trait OperateTrait {
3.     async fn operate(&mut self, req: &mut RecvRequest) -> ProtResult<RecvResponse>;
4. }

复制代码

  “他们必须返回给我一个RecvResponse或者一个错误，我等下好告诉socket要运送哪些东西回去。你看，从传送门里出来了一个对象Ok(RecvResponse)，那我们接下来把这个对象带回去。这对象类似这样子的内容：”

1. HTTP/1.1 200 OK\r\n
2. Content-Encoding: deflate\r\n
3. Date: Wed, 22 Nov 2023 11:30:23 GMT\r\n
4. Content-Type: application/json;charset=UTF-8\r\n
5. Content-Length: 31\r\n
6. Connection: keep-alive\r\n
7. Access-Control-Allow-Origin: *\r\n
8. \r\n

复制代码

旅程返程

得到了正在的返回结果，我们就马不停蹄的往回走了

  我们又回到了中间件的门，但是此时是从另一侧的门回来，上面标注着process_response，我想这应该是处理我们刚刚从传送门回来的对象吧，这也是逻辑严密的结构。

1. async fn process_response(&mut self, request: &mut RecvRequest, response: &mut RecvResponse) -> ProtResult<()>;

复制代码

  经过了中间件的门，对象Ok(RecvResponse)被重新粉刷了蓝色，也做了标记，我们就把他带到了socket的面前。
  socket说：“你们回来的真快，这才过去了不到10ms，把我要的东西带过来了吗？”
  http大神说：“都在这了，顺序不要乱了哦，他们可是被暗中标记过了，乱了的话，等下就还原不回来了。”
  于是socket就把这些数据带回去了，看着这船来船往的码头，我就感慨到，原来他们都已经预处理好各种情况的应对了，难怪看起来那么的井井有条。只见HTTP大神给了例子：

1. use std::{env, error::Error, time::Duration};
2. use async_trait::async_trait;
4. use tokio::{net::TcpListener};
5. use webparse::{Response};
6. use wenmeng::{self, ProtResult, Server, RecvRequest, RecvResponse, OperateTrait, Middleware};
8. struct Operate;
9. #[async_trait]
10. impl OperateTrait for Operate {
11.     async fn operate(&mut self, req: &mut RecvRequest) -> ProtResult<RecvResponse> {
12.         tokio::time::sleep(Duration::new(1, 1)).await;
13.         let response = Response::builder()
14.             .version(req.version().clone())
15.             .body("Hello World\r\n".to_string())?;
16.         Ok(response.into_type())
17.     }
18. }
20. struct HelloMiddleware;
21. #[async_trait]
22. impl Middleware for HelloMiddleware {
23.     async fn process_request(&mut self, request: &mut RecvRequest) -> ProtResult<()> {
24.         println!("hello request {}", request.url());
25.         Ok(())
26.     }
28.     async fn process_response(&mut self, _request: &mut RecvRequest, response: &mut RecvResponse) -> ProtResult<()> {
29.         println!("hello response {}", response.status());
30.         Ok(())
31.     }
32. }
34. #[tokio::main]
35. async fn main() -> Result<(), Box<dyn Error>> {
36.     env_logger::init();
37.     let addr = env::args()
38.         .nth(1)
39.         .unwrap_or_else(|| "0.0.0.0:8080".to_string());
40.     let server = TcpListener::bind(&addr).await?;
41.     println!("Listening on: {}", addr);
42.     loop {
43.         let (stream, addr) = server.accept().await?;
44.         tokio::spawn(async move {
45.             let mut server = Server::new(stream, Some(addr));
46.             server.middle(HelloMiddleware);
47.             let operate = Operate;
48.             let e = server.incoming(operate).await;
49.             println!("close server ==== addr = {:?} e = {:?}", addr, e);
50.         });
51.     }
52. }

复制代码

小结

在http的处理过程中，还有其它的好玩的东西，需要注意的东西，这次我们介绍了中间件及回调处理的小小见闻。以下是一个小demo
点击 [关注]，[在看]，[点赞] 是对作者最大的支持

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！