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大神就笑着说:“我检查前面的车,因为我不知道这些车装了什么东西,第一辆车带有车队的信息,我就通过他来知道这趟车的内容是什么了。下面我跟你说下这辆车带的信息。”
httpPOST /report HTTP/1.1\r\n Content-Type: application/x-www-form-urlencoded; charset=UTF-8\r\n Accept: */*\r\n Accept-Language: zh-CN,zh-Hans;q=0.9\r\n Accept-Encoding: gzip, deflate, br\r\n Host: www.wm-proxy.com\r\n Origin: https://www.wm-proxy.com\r\n 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 Referer: https://www.wm-proxy.com/\r\n Content-Length: 218\r\n Connection: keep-alive\r\n \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<RecvStream>
的结构体,等下你看到那边的一扇扇门了没有,那个叫中间件
。”
我来到这门前:“这怎么有两个门呢?他们等下走哪个门呢?”
http大神说:“他们这些门,都是有统一的规格的,他们需要按照我的规格来建这些门,左边是进的process_request
,右边是出的process_response
,要严格的按照这流程来,要不然会出错哦。下面我给你说下他这个门有哪些注意的”
RUST#[async_trait]
pub trait Middleware: Send + Sync {
async fn process_request(&mut self, request: &mut RecvRequest) -> ProtResult<()>;
async fn process_response(&mut self, request: &mut RecvRequest, response: &mut RecvResponse) -> ProtResult<()>;
}
他们按照这规格建起各种各样的门,他们可以规定进门后要怎么处理我组装的这个车队RecvRequest
,比如要把车队变成红色之类等操作或者记录下有多少个车队经过等,这样我就可以不会显得臃肿,但是我的能力却是大大的提升了起来。
我表示羡慕到:“原来这种方式强大可以变得这么优雅。那通过这些门后会有什么好玩的?”
过了
中间件
的门,我们就来到了这旅程的终点。我们来到了一个大广场,广场上有个神奇的装置,看起来像传送门。
我就很好奇的问:“这传送门看起来的有点高级,这边角好像和刚才那门有点像,难道也是要遵循你的规则?”
http大神回答:“观察力不错哦,这传送门也是同样的道理哦,因为我也不知道他们要把这个数据拿来干什么,所以我就弄了个传送门,让他们把数据加工好后再给我咯,我的要求就是建传送门必须要按以下格式”
#[async_trait] pub trait OperateTrait { async fn operate(&mut self, req: &mut RecvRequest) -> ProtResult<RecvResponse>; }
“他们必须返回给我一个RecvResponse
或者一个错误,我等下好告诉socket
要运送哪些东西回去。你看,从传送门里出来了一个对象Ok(RecvResponse)
,那我们接下来把这个对象带回去。这对象类似这样子的内容:”
HTTPHTTP/1.1 200 OK\r\n Content-Encoding: deflate\r\n Date: Wed, 22 Nov 2023 11:30:23 GMT\r\n Content-Type: application/json;charset=UTF-8\r\n Content-Length: 31\r\n Connection: keep-alive\r\n Access-Control-Allow-Origin: *\r\n \r\n
得到了正在的返回结果,我们就马不停蹄的往回走了
我们又回到了中间件
的门,但是此时是从另一侧的门回来,上面标注着process_response
,我想这应该是处理我们刚刚从传送门回来的对象吧,这也是逻辑严密的结构。
RUSTasync fn process_response(&mut self, request: &mut RecvRequest, response: &mut RecvResponse) -> ProtResult<()>;
经过了中间件
的门,对象Ok(RecvResponse)
被重新粉刷了蓝色,也做了标记,我们就把他带到了socket
的面前。
socket说:“你们回来的真快,这才过去了不到10ms,把我要的东西带过来了吗?”
http大神说:“都在这了,顺序不要乱了哦,他们可是被暗中标记过了,乱了的话,等下就还原不回来了。”
于是socket就把这些数据带回去了,看着这船来船往的码头,我就感慨到,原来他们都已经预处理好各种情况的应对了,难怪看起来那么的井井有条。只见HTTP大神给了例子:
RUSTuse std::{env, error::Error, time::Duration};
use async_trait::async_trait;
use tokio::{net::TcpListener};
use webparse::{Response};
use wenmeng::{self, ProtResult, Server, RecvRequest, RecvResponse, OperateTrait, Middleware};
struct Operate;
#[async_trait]
impl OperateTrait for Operate {
async fn operate(&mut self, req: &mut RecvRequest) -> ProtResult<RecvResponse> {
tokio::time::sleep(Duration::new(1, 1)).await;
let response = Response::builder()
.version(req.version().clone())
.body("Hello World\r\n".to_string())?;
Ok(response.into_type())
}
}
struct HelloMiddleware;
#[async_trait]
impl Middleware for HelloMiddleware {
async fn process_request(&mut self, request: &mut RecvRequest) -> ProtResult<()> {
println!("hello request {}", request.url());
Ok(())
}
async fn process_response(&mut self, _request: &mut RecvRequest, response: &mut RecvResponse) -> ProtResult<()> {
println!("hello response {}", response.status());
Ok(())
}
}
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
env_logger::init();
let addr = env::args()
.nth(1)
.unwrap_or_else(|| "0.0.0.0:8080".to_string());
let server = TcpListener::bind(&addr).await?;
println!("Listening on: {}", addr);
loop {
let (stream, addr) = server.accept().await?;
tokio::spawn(async move {
let mut server = Server::new(stream, Some(addr));
server.middle(HelloMiddleware);
let operate = Operate;
let e = server.incoming(operate).await;
println!("close server ==== addr = {:?} e = {:?}", addr, e);
});
}
}
在http的处理过程中,还有其它的好玩的东西,需要注意的东西,这次我们介绍了中间件及回调处理的小小见闻。以下是一个小demo
点击 [关注],[在看],[点赞] 是对作者最大的支持
本文作者:问蒙服务框架
本文链接:
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!