Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サーバーフレームワークの仕組みが気になったので車輪の再発明をしてみた
Search
Yuta Tomiyama
March 12, 2022
Programming
0
210
サーバーフレームワークの仕組みが気になったので車輪の再発明をしてみた
2022/03/12 全国学生エンジニア交流会「NSEEM」にて発表
https://github.com/yt8492/NativeServer
Yuta Tomiyama
March 12, 2022
Tweet
Share
More Decks by Yuta Tomiyama
See All by Yuta Tomiyama
モバイルアプリ開発を始めよう!
yt8492
0
66
Git勉強会
yt8492
0
150
なんでもやってみる勇気
yt8492
0
99
Android Autoが思ったよりしんどい話
yt8492
0
210
apollo-kotlinにcontributeした話
yt8492
0
140
DMM TVのSDカードダウンロード機能を実装した話
yt8492
1
860
今だからこそ知りたいKotlin Multiplatform
yt8492
0
300
State management and API calls in Jetpack Compose: Learning Apollo + Jetpack Compose through React Hooks
yt8492
0
1.3k
Compose for Webを始めよう
yt8492
0
410
Other Decks in Programming
See All in Programming
AI Agent 時代的開發者生存指南
eddie
2
1.4k
Web フロントエンドエンジニアに開かれる AI Agent プロダクト開発 - Vercel AI SDK を観察して AI Agent と仲良くなろう! #FEC余熱NIGHT
izumin5210
3
540
理論と実務のギャップを超える
eycjur
0
140
CSC509 Lecture 05
javiergs
PRO
0
300
コードとあなたと私の距離 / The Distance Between Code, You, and I
hiro_y
0
170
Range on Rails ―「多重範囲型」という新たな選択肢が、複雑ロジックを劇的にシンプルにしたワケ
rizap_tech
0
6.6k
overlayPreferenceValue で実現する ピュア SwiftUI な AdMob ネイティブ広告
uhucream
0
180
開発生産性を上げるための生成AI活用術
starfish719
3
1.1k
Server Side Kotlin Meetup vol.16: 内部動作を理解して ハイパフォーマンスなサーバサイド Kotlin アプリケーションを書こう
ternbusty
3
200
2分台で1500examples完走!爆速CIを支える環境構築術 - Kaigi on Rails 2025
falcon8823
3
3.7k
実践Claude Code:20の失敗から学ぶAIペアプログラミング
takedatakashi
2
490
登壇は dynamic! な営みである / speech is dynamic
da1chi
0
340
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Keith and Marios Guide to Fast Websites
keithpitt
411
23k
Navigating Team Friction
lara
190
15k
The World Runs on Bad Software
bkeepers
PRO
72
11k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
870
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
35
6.1k
Producing Creativity
orderedlist
PRO
347
40k
GraphQLとの向き合い方2022年版
quramy
49
14k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How STYLIGHT went responsive
nonsquared
100
5.8k
Transcript
サーバーフレームワークの 仕組みが気になったので 車輪の再発明をしてみた 2022/03/12 NSEEM
自己紹介 HN: マヤミト ID: yt8492 会津大学 学部4年 OtakuProject運営 GitHub: https://github.com/yt8492
趣味: Kotlin, Twitter, ウマ娘 Twitter: yt8492
バックエンドの開発してる人
フレームワークの仕組み、気になりません?
じゃあ作ってみよう!w
今回のテーマ: サーバーフレームワーク自作
やること - TCPのソケット通信をラップしてHTTP通信を実装 - それをもとにフレームワークを実装 - 使用言語はKotlin/Native (苦行) - Cの標準関数のブリッジくらいしか提供されてないので逆に勉強になると思った
- もしこのLTを見ている人が同じことをしたいと思ったら素直に Kotlin/JVMでやることをおすすめしま す
HTTP通信 - HTTPの仕様はRFCで定義されている - 今回はHTTP/1.1でやるのでRFC2616 - TCPのリクエストをどのように解釈して、レスポンスをどのような形式で送ればいいかなどが書かれ ている - リクエストを解釈してレスポンスを返せれば良い
- リクエスト - リクエストライン - ヘッダ - ボディ - レスポンス - ステータスライン - ヘッダ - ボディ
HTTPリクエストを解釈する - TCPのリクエストから以下を解釈できればよい - リクエストライン - ヘッダ - ボディ -
RFCではこのように定義されている - Request = Request-Line *(( general-header | request-header | entity-header ) CRLF) CRLF [ message-body ]
リクエストのリクエストラインを解釈する - RFCではこのように定義されている - Request-Line = Method SP Request-URI SP
HTTP-Version CRLF - メソッド、URI、HTTPバージョンが空白区切りで、最後に CRLF(改行)がある - つまり、ソケット通信で以下のことができればよさそう - CRLFが現れるまで通信を読み込む - 読み込んだバイト列を文字列として扱う - 空白で区切り、それをメソッド、 URI、HTTPバージョンとする
リクエストのリクエストラインを解釈する
リクエストのヘッダを解釈する - ヘッダフィールドのフォーマットは以下のように定義されている - message-header = field-name ":" [ field-value
] field-name = token field-value = *( field-content | LWS ) field-content = <field-value を構成し、*TEXT あるいはtoken, separators, quoted-string を連結したものから成る OCTET> - 名前と値がコロン区切りになっていて、値は前後に 0個以上の空白を含む場合がある - リクエストのヘッダは 0個以上のヘッダフィールドが CRLF区切りになっていて、 CRLFのみの行がヘッ ダの終わりになる
リクエストのヘッダを解釈する - ソケット通信で以下のことができればよさそう - CRLFが現れるまで読み込む - 読み込んだ結果が空であればヘッダの終わり、そうでなければコロンで区切ってそれを名前と値と する - 終わりでない場合は繰り返す
リクエストのボディを解釈する - ボディは以下のように定義されている - message-body = entity-body | <Transfer-Encoding にてエンコードされた
entity-body> - ヘッダに Content-Length や Transfer-Encoding 各ヘッダフィールドを含むとボディが存在し、 な ければボディが空 - Content-Lengthが指定されている場合はそのバイト数だけボディをよみこむ
リクエストのボディを解釈する - 簡単のためTransfer-Encodingは今回考慮しないことに🙏
レスポンスをHTTPの形式にする - 以下の情報をTCPのレスポンスとして返せればよい - ステータスライン - ヘッダ - ボディ -
RFCではこのように定義されている - Response = Status-Line *(( general-header | response-header | entity-header ) CRLF) CRLF [ message-body ]
ステータスラインをTCPのレスポンスに書き込む - RFCではこのように定義されている - Status-Line = HTTP-Version SP Status-Code SP
Reason-Phrase CRLF - つまり、ソケット通信で以下のことができるとよさそう - HTTPバージョンと区切りの空白を書き込む - ステータスコードと区切りの空白を書き込む - 説明句と終端のCRLFを書き込む
ヘッダをTCPのレスポンスに書き込む - 基本的にはリクエストと同じ - ヘッダフィールドの名前と値がコロン区切りになっていて、 CRLFで終わる - CRLFのみの行がヘッダの終わり
ボディをTCPのレスポンスに書き込む - 今回はTransfer-Encodingを考慮しないので単純にボディとして渡されたバイト列 をそのまま書き込む
ここまでがRFCに沿った実装
ここからフレームワークとしての便利実装
フレームワークなら便利であってほしい - HTTPを最低限実装しただけではバックエンド開発に使うには厳しい - Nodeのhttpモジュールとかだけでやろうとするとしんどい - フレームワークなら次のような機能があってほしい - クエリパラメータ -
パスパラメータ - ルーティング
クエリパラメータの取得 - 今回は以下のようになっているという前提で扱う - URIを?で区切った後ろの部分 - 名前=値という形でフィールドが構成され、それが &で連結されている - 名前と値はURLエンコードされる
- 以下のように実装する - URIを?で区切った後ろの部分を取得する - 空でなければさらに &で区切る - 更に=で区切り、それぞれを URLデコードする
ルーティング - 今回はユーザーが以下のように使えるように実装する - get("/hoge") { … }, post("/fuga") {
… } のように、メソッドごとに関数が用意されていて、それ に パスを指定し、ラムダ関数の中で実際にリクエストを受け取ったときの処理を書く - 次のように実装する - ユーザーが get("/hoge") { … } のように関数を呼び出すとハンドラが追加される - ソケットから受け取った TCPのリクエストをHTTPのリクエストとして解釈する - 受け取ったリクエストの URIをもとにどのハンドラで処理するべきか評価し、最も評価度が高いハン ドラに実際に処理をさせる - 処理の結果ユーザーが生成したレスポンスのインスタンスを実際に HTTPのレスポンスとしてTCP のソケットに書き込む
ハンドラの実装 - ハンドラ自体はパスとHTTPメソッドと処理をする関数を持つだけ - ユーザーがHTTPのリクエストに対応した関数を呼び出すとハンドラのリストに追加 されていく
リクエストをハンドラにマッチさせる - 同じリクエストでも複数のハンドラにマッチする可能性がある - /hoge/fuga は /hoge/fuga, /hoge/:param, /hoge/* にマッチする可能性がある
- マッチ度が高いのは /hoge/fuga > /hoge/:param > /hoge/* - これを実際にリクエストが来るたびに行う - ハンドラのパスを/で区切り、それぞれが定数、パスパラメータ、ワイルドカードかど うかによってそのハンドラがマッチした場合の評価度を計算する - パスパラメータを持つ場合は実際にそれを取り出す - ソースコードは結構長くなったのでGitHubまで見に来て
使う側はこんな感じで使える
実際のソースコードはこちら - yt8492/NativeServer https://github.com/yt8492/NativeServer
まとめ - ソケット通信からサーバーフレームワークの実装できた - RFCを読みながら実装するとかなり勉強になる - 自分の知らなかった仕様に出会える - 実際に動くと感動
みんなも車輪の再発明しよう! 楽しいよ!