用Rust手把手編寫一個Proxy(代理), 動工 項目 ++wmproxy++ gitee 傳送門 github 傳送門 設計流程圖 flowchart LR A[客戶端] -->|Http| B[代理端] --> C[代理服務端] --> D[服務端] B -->|直達| D A -->|Htt ...
用Rust手把手編寫一個Proxy(代理), 動工
項目 ++wmproxy++
設計流程圖
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對命令行的的數據處理，如-p 8090，-b 127.0.0.1，完整的命令行如wmproxy -p 8090，則可在8090埠上實現http及https的轉發，代碼示例
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的非同步函數中，所有針對句柄數據的讀取寫入均由非同步完成，從而實現高效率的處理。
while let Ok((mut inbound, _)) = listener.accept().await {
tokio::spawn(async move {
// tcp的連接被移動到該協程中，我們只要專註的處理該stream即可
})
}
HTTP代理
如果該代理信息配置支持http/https則會嘗試進行http解析，代碼實現在proxy.rs中的process方法，
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信息。
flowchart TD A[客戶端] --> B[代理] --> C[讀取頭信息] --> D[取得地址] -->|成功| E[連接目標地址] -->|成功| F[寫入頭信息] --> G[雙向通道] D -->|不合法關閉| A E -->|連接失敗關閉| A A <-->|雙向| G註意：客戶端和服務端之前可能會存在大數據上傳下載的情況，超過百兆數據的上傳下載，所以我們為了減少序列化帶來的性能損失和保證在低記憶體能正確運行，不做http的完整解析，僅僅只處理http頭信息。
curl測試
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測試
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進行定義
代碼實現在socks5.rs中的process方法實現
因為在處理socks5之前可能進行過http的嘗試，所以socket中的內容已經被讀出了一部分，在處理時則帶上了Option<BinaryMut>，表示預讀的內容。
在socks5中通常需要預讀一個位元組來獲取後續的長度，比如NMethod，或者用戶名長度等，所以我們定義了函數
/// 讀取至少長度為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)表示無驗證方法。
curl http://www.baidu.com --socks5 127.0.0.1:8090
## curl: (97) No authentication method was acceptable.
驗證成功或者無需驗證後
graph TD A[驗證成功] --> B[讀取地址] --> C[連接地址] -->|連接成功| D[雙向通道] E[返回失敗] B -->|讀取失敗| E C -->|連接失敗| E A <-->|雙向| D雙向通道建立後，客戶端已和伺服器能正常的TCP操作，包括Http/Https/Websocket/自定義tcp信息，代理直到一方關閉則正常後續關閉。
錯誤處理方法
這裡主要說明如何多協議相容處理代理協議。以下定義的Continue協議包含了一個已讀的位元組表和當前的Tcp連接。
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並未被讀取過。下個解析器可以拿到完整的數據進行解析。
