MoQTフルスクラッチ実装

2026/8/27 社内LTで発表した内容

1. MoQT フルスクラッチ実装 発火大根
2. 自己紹介 1 発火大根 出身: 岡山県倉敷市
3. 今日のテーマ claudeで作ったwebサーバー / SDKを紹介します https://github.com/Hakkadaikon/wired マニアックな話をして終わります
4. 以前の発表 以前の開発定例で 自作WebSocket の 発表をしました (2025/12/18)
5. 開発当時 (自作 WebSocket) - この「自作WebSocket」を作ったのが2025年2月ごろ この時はほとんどAIを使わず、手で実装していた
6. あれから - claude や codex など、コードを書くモデルの性能が飛躍的に進化 もっと高度なネットワークのSDKを作れるのではないか
7. あれから そうだ もっと難しそう & 挑戦している人が少なそうなものを作ろう
8. 自作範囲 (WebSocketの時) C言語で直接システムコールを呼 び出し、青い部分は自作 TCPの部分は自作せず、カーネル の機能を使用 暗号化 (SSL/TLS)の対応は無し
9. 今回自作したもの MoQT 実装 (Media over QUIC Transport)
10. MoQT (Media over QUIC Transport)とは？ ライブ配信・双方向音声通話などに使えるメディア配信プロトコル
11. MoQT (Media over QUIC Transport)の特徴 他の配信プロトコルと比較 (配信遅延と大規模配信のいいとこ取り) プロトコル 配信遅延 大規模配信 主な用途 MoQT 数百ms〜1秒 高い インタラクティブ配信、ライブス ポーツ、クラウドゲーム （MoQリレー対応の基盤が必要） WebRTC 0.5秒未満 中〜高 （SFU／専用CDNが必要・コスト高） LL-HLS 2-5秒 非常に高い （既存HTTP CDNをそのまま利用） HLS / DASH 6-30秒 非常に高い （既存HTTP CDNをそのまま利用） ビデオ会議、双方向通話、低遅延 1対多配信 低遅延ライブ配信（スポーツ、オー クション） VOD(ビデオオンデマンド )、 大規模ライブ配信
12. MoQT (Media over QUIC Transport)の特徴 330都市以上の全ての Cloudflareサーバーが MoQTをサポート (2025/8/22) https://blog.cloudflare.com/ja-jp/moq/
13. MoQT (Media over QUIC Transport)の特徴 ネットワークレイヤー MoQT WebTransport HTTP/3 QUIC (+ TLS1.3) UDP IP ハンドシェイク 確立後データ通信 ネイティブアプリ
14. 一般的な実装範囲 - 大体QUICから上 TLS1.3は別の既存のOSSを使用 (opensslなど) UDPやIPはカーネルの機能を使用 MoQT WebTransport HTTP/3 QUIC (+ TLS1.3) UDP IP
15. 今回作ったOSSの実装範囲 IPから上、全部。 MoQT WebTransport HTTP/3 QUIC (+ TLS1.3) UDP IP
16. 今回作ったOSSの実装範囲 - C言語製、libc依存なし (x86-64に特化)、シングルバイナリで起動 - 約360KBのシングルバイナリ、scratchコンテナで動作する - 他の実装のバイナリは6-8MB程度 - カーネルのネットワークスタックを迂回、自分でIPレイヤーから構築 - AF_XDPと呼ばれる技術を使用 - カーネル内部のVM (eBPF)でパケットをポーリングで刈り込む - カーネルのUDPを使うモードもアリ
17. 実装した仕様 種類 件数 RFC 40 FIPS (NIST) 4 SP (NIST) 1 IETF draft 2 合計: 47種類の仕様を実装
18. 実装方法 - ほぼ全てclaude - RFCなど、必要な仕様をかき集める - 実装した仕様とテストコードをセットにした台帳を用意、TDDで実装 - 基本はbypass モードで放置実装 - 1日30分 - 1時間ほどかけて、指示を与え直したりテスト確認したり これを2ヶ月続けました。(現在、2050 commit over)
19. テスト (e2e) - quic-interop-runner (OSS) をforkして使用 様々なサーバー x クライアントと掛け合わせでテストをしてくれる QUICとWebTransportに対応 https://interop.seemann.io/quic
20. テスト (e2e) クライアント別に 22ケースのテストを実施 著名な実装 (nginx) 等と比較しても、遜色ない程度にテストが通るように 今回作った実装 (quicのテスト) nginx (quicのテスト)
21. 速度 一部のテストでは、他の実装を大きく上回る結果に (VPSでテスト) 10MB転送テスト ループバックでリクエストを与え続ける
22. 苦労したところ - bypassモードで放置実装・テストがしにくい所は手動でテストした - ループバックではなく、ネットワーク外から実行するテスト - AF_XDP - カーネル側の制御を行うためsudoが必要 - RFC等の仕様からトップダウンでTDDしたはずだが、 e2eで失敗しまくる - 実際のクライアントと対向させないと分からない部分もある
23. 実際のサンプル 通話するためのクライアントを作成、VPSでサーバーを動作させて接続 -> 実際にチャット・通話が出来た
24. Q. ところで... - 機能も他の実装と遜色ない程度に出来てきている 速度もそれなりに出ている 他の実装より圧倒的に優れている部分もある (バイナリサイズなど) では、もう「実用的」なのか？
25. A. 答え 現段階では、全く実用的ではない。(実務では使えない)
26. なぜ？ - 運用実績 セキュリティ
27. なぜ？ - openssl - - 1999 - 2026年 (27年間) で280件以上のCVEあり https://openssl-library.org/news/secjson/index.html nginx - 2009 - 2026年(17年間)で45件程度のCVEあり https://nginx.org/en/security_advisories.html 過去の様々な運用の中で、これだけの脆弱性を乗り越えてきている
28. なぜ？ 文字通りフルスクラッチの実装なので まだ見ぬ脆弱性や不具合が大量にあると予想
29. ただ... 強みとして、 - 依存がほぼない - 他のOSSに縛られない - 脆弱性の修正には、完全に自分の意思とタイミングで反映可能 - 別のWebサーバーがCVE発行 -> AIが検知 -> 自動で水平展開チェック -> 反映 の流れを作れたら強いかも？ 将来的に、今回作った実装の方がセキュアになる可能性も？
30. 今後 引き続きAIによる放置実装で - パフォーマンス改善 脆弱性対応 ドキュメント改善 映像配信のサンプル (音声とチャットは出来たが映像配信はまだ試せていない) などを行っていく予定
31. ありがとうございました！ EDムービー : 私のダンス動画 (AI) 動画: Seedance 2.5 / 人物画: 実写をgrokでデフォルメ / 背景: フリー素材 / ダンス: 別動画 (フリー素材 )