mini-reverse-proxyを作ってみる話

2026/10 LT

Transcript

1. mini-reverse-proxyを作ってみる話 Tenplant
2. 自己紹介 HN 名前 学年 出身 技術 SNS Tenplant 松本 天獅 学部3年 札幌 Web (Frontend) (@)tenplant1203
3. きっかけ
5. 使ったもの
6. Hyper (HTTP Library) A protective and efficient HTTP library for all すべてのユーザーのための保護的で効率的なHTTPライブラリ Axum axum is an HTTP routing and request-handling library that focuses on ergonomics and modularity. axumは使い勝手とモジュール性に重点を置いた、HTTPルーティングおよびリクエスト処理のためのライブラリ HyperはHTTP通信を処理する低レベルライブラリ AxumはHyperを基盤としてWebアプリケーションを構築するための高レベルフレームワーク
7. Hyper (HTTP Library) A protective and efficient HTTP library for all すべてのユーザーのための保護的で効率的なHTTPライブラリ Axum 今回はこちらを選択 axum is an HTTP routing and request-handling library that focuses on ergonomics and modularity. axumは使い勝手とモジュール性に重点を置いた、HTTPルーティングおよびリクエスト処理のためのライブラリ HyperはHTTP通信を処理する低レベルライブラリ AxumはHyperを基盤としてWebアプリケーションを構築するための高レベルフレームワーク
8. Reverse Proxyとは
9. https://tex2e.github.io/rfc-translater/html/rfc9110.html 「ゲートウェイ」（別名「リバースプロキシ」）は、アウトバウンド接続のオリジンサーバーとして機能 するが、受信したリクエストを変換し、別のサーバーまたはサーバーにインバウンド（オリジンサーバー 方向）へ転送する仲介者です。 ゲートウェイは、レガシーまたは信頼できない情報サービスをカプセル化し、「アクセラレータ」キャッ シングを介したサーバーのパフォーマンスを改善し、複数のマシンにわたるHTTPサービスのパーティ ションまたは負荷分散を有効にするために、多くの場合使用されます。 https://www.rfc-editor.org/rfc/rfc9110.html
10. Client User Request Response Reverse Proxy Gateway Request Response Backend Server クライアントに対してOrigin Serverとして振る舞う 受信したHTTPリクエストを他のサーバーへ転送する そのサーバーが提供するサービスへのアクセスを仲介する中継地点である
11. リクエストを中継する
12. listner建てたり、 TokioのIOを HyperのIOで 使えるように
13. tokioで別タスク に切り出す
15. Clientとの接続の確立
16. tokioで別タスク に切り出す
17. HOSTが 127.0.0.1:4000 (Reverse Proxy) になるのを防ぐ
18. エラーを HTTPレスポンスとして返す
20. Error定義 ProxyErrorをHTTP Responseに
21. errを error_response で HTTP Responseとして返すようにした
22. Before ProxyErrorをそのまま返していた After Errorも全てHTTP Responseで返すようにした
23. Hop-by-hop Headerの処理
24. Hop-by-hop Headerとは
25. 13.5.1 End-to-end and Hop-by-hop Headers - RFC 2616
26. End-to-end Header HTTPメッセージの最終的な受信者まで意味を持つヘッダーフィールド。 中継者（Intermediary）を経由しても、その意味は最終的な受信者に対して維持される。 Hop-by-hop Header 現在の通信区間 (Hop) における接続制御のために 意味を持ち、次の通信区間にはそのまま引き継がれないヘッダーフィールド。 HTTP/1.1では Connection ヘッダーによって 接続固有のフィールドを宣言でき、中継者は転送前に指定されたフィールドを除去しなければならない。
27. End-to-end Header HTTPメッセージの最終的な受信者まで意味を持つヘッダーフィールド。 中継者（Intermediary）を経由しても、その意味は最終的な受信者に対して維持される。 Client User End-to-end Header Reverse Proxy Gateway End-to-end Header Backend Server
28. Hop-by-hop Header 現在の通信区間（Hop）における接続制御のために 意味を持ち、次の通信区間にはそのまま引き継がれないヘッダーフィールド。 HTTP/1.1では Connection ヘッダーによって 接続固有のフィールドを宣言でき、中継者は転送前に指定されたフィールドを除去しなければならない。 Client User Hop1 Reverse Proxy Gateway remove Hop2 Backend Server
29. Hop-by-hop Headerを削除する
31. お気づきでしょうか？
32. 皆さんはRustを手足のように 動かすことができると聞いています
41. immutable borrow mutable borrow
43. GetAll<'_, HeaderValue>
44. GetAll<'_, HeaderValue> ValueIter<'_, HeaderValue> Item=&HeaderValue
45. GetAll<'_, HeaderValue> ValueIter<'_, HeaderValue> Item=&HeaderValue Iterator<Item = Result<&str, ToStrError>>
46. GetAll<'_, HeaderValue> ValueIter<'_, HeaderValue> Item=&HeaderValue Iterator<Item = Result<&str, ToStrError>> Result<Vec<&str>, ToStrError>
47. GetAll<'_, HeaderValue> ValueIter<'_, HeaderValue> Item=&HeaderValue Iterator<Item = Result<&str, ToStrError>> Result<Vec<&str>, ToStrError> 軽くFormat
48. GetAll<'_, HeaderValue> ValueIter<'_, HeaderValue> Item=&HeaderValue Iterator<Item = Result<&str, ToStrError>> Result<Vec<&str>, ToStrError> 軽くFormat name: &str name.as_bytes(): &[u8] Iterator<Item = Result<HeaderName, InvalidHeaderName>>
49. GetAll<'_, HeaderValue> ValueIter<'_, HeaderValue> Item=&HeaderValue Iterator<Item = Result<&str, ToStrError>> Result<Vec<&str>, ToStrError> 軽くFormat name: &str name.as_bytes(): &[u8] Iterator<Item = Result<HeaderName, InvalidHeaderName>> Headerをremoveする
50. Transfer-Encodingについて
51. Transfer-Encodingとは
52. 6.1 Transfer-Encoding - RFC9112 転送エンコードヘッダーフィールドには、メッセージ本文を形成するためにコンテンツに適用された（ま たは適用される）転送コーディングのシーケンスに対応する転送コーディング名をリストします。 転送コーディングはセクション7で定義されています。 6.1 転送エンコード - RFC 9112 - HTTP/1.1 日本語訳
53. Before After
54. HyperのHTTP/1.1リクエスト送信処理では、 次の条件がそろうと、GETなどのBodyを長さ0として扱う。 Bodyの長さが不明 Content-Lengthがない Transfer-Encodingがない 受信したchunkedのBody付きGETから Transfer-Encodingだけを削除して転送すると、 本文が届かなくなる可能性がある souce code: hyper
55. Transfer-Encoding: gzip, chunkedの場合 Hyperはchunkedを処理するが、gzipは自動で解凍しない。 受信したBodyからチャンクの区切りは取り除かれるが、取り出したバイト列はgzip圧縮されている
 ここでTransfer-Encodingを削除すると、圧縮データだけが残り、解凍に必要な情報が失われる remove Transfer-Encoding 圧縮データのみで 解凍ができない Backend Server ※ Transfer-Encoding: chunkedはPOSTの場合自動でつく
56. RequestとResponseに適用する
57. Headerをremoveする Headerをremoveする
58. Client側 Server側
59. できたこと
60. Connection headerとConnection list headerを削除
61. やりたいこと
62. gzipを含むTransfer-Encodingの適切な処理 Timeoutと504レスポンス Forwarding Headersによる元Client情報の伝達 アクセスログ・処理時間の記録 upstream接続の再利用（Connection pooling） Graceful shutdown Client側のHTTP/3・QUIC対応
63. 終わり