Episode from the podcast 八百万のOSS
Episode
#22 HTTPSでも見えているドメイン名 — ECHとインターネットの未来
Released Tuesday, October 6th 2026 ·1 hr 4 min
Show notes
About this episode
ECH（Encrypted Client Hello）は、TLSのClientHelloをInnerとOuterに分け、実際のSNIなどを含むClientHelloInnerを暗号化する仕組みです。ただ、いざ自分のサーバーで有効にしようとすると、思っていたよりずっと奥が深い世界が待っていました。
前半では、なぜHTTPSでもドメイン名が見えていたのかをSNIから振り返り、ESNIがなぜうまくいかなかったのか、ClientHelloInner／Outer、GREASE ECHといった現在のECHの仕組みまで整理します。暗号化すれば検閲できなくなるわけではなく、中国やロシアでは残された情報を使ったブロックも実際に行われています。
後半はいよいよ運用編です。DNSのHTTPSリソースレコードでECHConfigListを配る仕組み、ECH keyを定期的にローテーションするとDNS cacheとの間で世代がずれる問>題を扱います。複数世代の鍵から復号候補を絞る1 byteのconfig_id、古いECHConfigを持ったclientへ最新のECHConfigListを返せるretry_configs、さらにnginxのssl_ech_fileでは最初に指定した鍵だけがretry用になるという暗黙的な挙動まで掘り下げます。
OpenSSLでECH keyを生成し、nginxで実際に設定すると何が必要なのか。DNSが広告するECHConfigと各Edgeに配置されたprivate keyをどう同期させるのか。CloudflareのようにDNSとTLS Edgeの両方を持つ事業者では、この複雑な仕組みをどう自動化しているのかも考えます。
最後は、サブドメインでテナントを分けるサービスではECHが何を隠せるのか、企業ネットワークのDNSやSNI監視とはどうぶつかるのか、そしてプライバシーを高めよ>うとすると、なぜ大規模なDNS・CDN事業者が有利になるのかまで話が広がります。
ECHの仕様を追っていくと、TLSだけではなく、DNS、CDN、検閲、そしてこれからのインターネットの構造まで見えてきます。インフラやCDN、TLSの運用に関わる人はぜひ本編で。
## 関連リンク
- RFC 9849 TLS Encrypted Client Hello（ECH）: https://www.rfc-editor.org/info/rfc9849/
- RFC 9848 Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings: https://www.rfc-editor.org/info/rfc9848/
- RFC 6066 TLS Extensions（SNI）: https://www.rfc-editor.org/info/rfc6066/
- RFC 9460 SVCB and HTTPS Resource Records: https://www.rfc-editor.org/info/rfc9460/
- RFC 8484 DNS Queries over HTTPS（DoH）: https://www.rfc-editor.org/info/rf...
·1 hr 4 min
Homebrewは、macOSでUnix系ソフトウェアのビルドとインストールを管理するパッケージマネージャーです。今回はcatatsuyが、macOSでソフトウェアをコンパイルするときの難しさと、Homebrewがそれをどう吸収しているかを紹介します。macOSは標準のCコンパイラがClangで、ヘッダーやライブラリの配置もLinuxとは異なります。そのため、`./configure`、`make`、`make install`がそのまま通らないことがあります。Homebrewは、ソフトウェアのビルド手順や依存関係をRubyのFormulaで定義し、必要に応じてソースからビルドできる仕組みです。上流がビルド済みバイナリを配布している場合との違いも紹介します。catatsuyの実体験として、M1 MacでLibreSSLをnginxと一緒にビルドできなかった件を紹介します。原因は、LibreSSLに含まれる`config.guess`と`config.sub`が古く、Apple Siliconを判定できなかったことでした。大元のプロジェクトから新しい版を取り込むPRを送り、マージされています。Homebrewは2009年に登場し、現在はLinuxでも動作します。RubyのDSLを使う理由や、Homebrew自身が利用するPortable Rubyについて話します。System Integrity Protection（SIP）などmacOS特有の事情にも触れます。Apple Siliconでは`/opt/homebrew`、Intel Macでは`/usr/local`を標準のプレフィックスとすることで、Rosetta 2環境との共存を可能にしています。Cellarのディレクトリ構造や、シンボリックリンクを管理する`brew link`も紹介します。Formulaでは`depends_on`で依存関係を指定できます。また、`brew tap`を使うことで、公式以外のリポジトリからもFormulaを導入できます。Formulaは単なる設定ファイルではなくRubyのコードであるため、信頼できるリポジトリを選ぶことが重要です。catatsuyはHTTP/3に対応させて独自にビルドしているcurlを、自分のtapで管理しています。後半では、Homebrewがビルド済みバイナリを配布するBottlesの仕組みを紹介します。続いて、catatsuyが開発しているkekkaiが、本人の知らないうちに第三者によって公式のhomebrew-coreに登録されていた話をします。その流れで、作者本人と第三者とで異なる登録基準や、GitHubのstars、forks、watchersの閾値についても話します。最後はセキュリティの話です。Homebrewは、公式リポジトリのレビューやチェックサムの検証、Bottlesなどによって安全性を高めています。一方で、これらの仕組...
·1 hr 2 min
今回は、AIエージェントを完全自律で動かしてISUCON2026で優勝したkawasyさんをゲストに迎えたゲスト回です。fukabori.fmで語られた大会の全体像を踏まえて、準備の過程での判断と、その背景にある考え方を伺いました。
kawasyさんは当初から「人間が介入せず、8時間止まらずに最後まで自律的に動くこと」を目標に準備していました。AlphaEvolveのような進化的探索や独自コーディングエージェントも構想にありましたが、評価実験の結果、最終的にはClaude Codeをベースに、その上のユーザーハーネスだけを作る形に落ち着いています。
準備の途中では、デプロイとベンチマークに合わせて全ホストのメトリクスを自動で取るツール群を作り込んでいました。しかし、何も用意しない構成のほうがスコアが高いケースがあり、エージェントがその場で必要な情報を取るアドホックな計測スクリプトを書いていたことに気づきます。9月末にハーネスを一度捨て、終盤のばらつきを減らす知識だけを慎重に足していったそうです。
当日はSlackへの通知ツールやRemote Controlを用意しつつも、人間からの入力も通知も0回。競技開始から1時間22分で50万点に到達しました。後半では、汎用ツールやOSSはエージェント時代にどう使われるのか、長期的なプロダクト開発との違い、そして評価環境の整備やエージェント構成の判断など、人間に残る仕事について話しています。
AIエージェントにどこまで任せ、人間が何を担うのかを、ISUCONという評価基準が明確な舞台での実験から掘り下げた回です。
## 関連リンク
- fukabori.fm 142. ISUCON2026で優勝する方法 w/ kawasy: https://fukabori.fm/episode/142
- ISUCON2026 で優勝しました（当日編）: https://zenn.dev/luvtechno/articles/isucon2026-competition-day
- ISUCON2026 受賞チームと全チームのスコア: https://isucon.net/archives/60126600.html
- herdr: https://github.com/herdrdev/herdr
- kawasy（X）: https://x.com/kawasy
─────────────
YouTube: https://youtu.be/TeqlzPxliAI
Web: https://yaoyorozu-oss.henteko07.com/
X: https://x.com/yaoyorozu_oss
·51 min
Renovateは、リポジトリ内の依存関係を検出し、新しいバージョンが出たら更新のプルリクエストを作ってくれるOSSです。今回は、catatsuyがメンテナンスしているnginx-buildとprivate-isuを例に、デフォルト設定の先でRenovateをどこまでカスタマイズできるのかを話しました。
nginx-buildは、nginxや依存ライブラリのバージョンをGoのソースコードに直接書いています。`customManagers`の正規表現を使えばこれも更新対象にできますが、そもそも何を最新版とするのか、バージョン情報をどこから取得するのかという問題があります。マイナーバージョンの末尾を`[02468]`に限定してnginxのstable版だけを追う設定や、4つ目の数字を持つOpenRestyへの対応を紹介します。
OpenRestyではタグが後から削除・変更されるなど、リリース運用に問題があります。こうした問題を避けようと導入した`minimumReleaseAge`は、現在ではサプライチェーン攻撃への備えとしても役立っています。stable版を機械的に判定しづらいLibreSSLは、`dependencyDashboardApproval`で人が確認してから承認しています。また、5言語の実装が同居するprivate-isuでは、定期的なロックファイルメンテナンスを言語ごとのPRに分けています。
後半はLTSの扱いです。MySQLのInnovationリリースが年月ベースの番号（26.7など）になり、LTSではない版への更新が提案されるようになりました。Docker Official Imagesの情報からLTS系列を抽出するカスタムデータソースや、JSONataを使って取得した情報を加工する仕組みを紹介します。さらにOpenSSLでは、LTS系列の変更を検出してRenovateが`renovate.json`自身の設定を書き換える仕組みまで実装しています。
一時期放置されていた2つのリポジトリのメンテナンスを続けられているのは、Renovateによって更新作業を自動化できたからでした。依存関係の更新を自動化したい人や、OSSのバージョニングやリリース運用に興味がある人に聞いてほしい回です。
## 関連リンク
- Renovate: https://github.com/renovatebot/renovate
- Renovate Docs: https://docs.renovatebot.com/
- Renovate（GitHub App）: https://github.com/apps/renovate
- nginx-build: https://github.com/cubicdaiya/nginx-build
- nginx-buildのrenovate.json: https://github.com/cubicdaiya/nginx-build/blob/f922e02770fec219eea31a2d80aaadae1636cf14/renovate.json
-...
·1 hr 22 min
go-jsonは、Go標準の`encoding/json`と互換のインターフェースを持つ高速なJSONライブラリです。今回は作者のgoccyさんをゲストに迎え、主にエンコーダの高速化の仕組みを深掘りしました。
開発のきっかけは、ブラウザゲームのサーバーで大量のJSONを返す際に、エンコードがボトルネックになったことでした。json-iterator/goへの置き換えでも十分な改善が得られず、自ら実装に取り組みます。
go-jsonの中心にあるのは、型ごとにOpcode（命令列）を生成・キャッシュし、VM（バーチャルマシン）で実行する仕組みです。関数呼び出しを繰り返す代わりに、巨大なswitch-caseで命令を処理します。ジャンプテーブルへのコンパイルをアセンブリで確認する方法や、caseの配置によってベンチマーク結果が変動する問題など、低レイヤーの最適化について詳しく聞きました。
さらに、`reflect`のヒープへの強制エスケープを回避するために利用していた`go:linkname`の話へ。標準ライブラリの非公開APIへの依存がGo本体の開発を妨げる事例として、2024年にRuss CoxさんのIssueでgo-jsonが名指しされました。この問題を背景にGo 1.23では`go:linkname`への制限が強化され、Goのソースコードには今もgo-jsonの名前が残っています。
2026年9月のv0.11.0では、コーディングエージェントも活用しながら`go:linkname`を全面的に削除。Go 1.21での`reflect`の改善に加え、`typelinks`を使ったキャッシュをオープンアドレス法のハッシュテーブルに置き換え、読み出しをロックフリーに保ちながらメモリ使用量と性能を改善しました。その結果、bytedance/sonicを上回るベンチマーク結果も得られています。
後半では、さらに高速なvelox-io/jsonの実装にも注目します。Cで記述したVMをELFとして埋め込み、GCCのcomputed gotoで命令を直接ディスパッチする方式です。こうした手法との比較を踏まえ、`encoding/json/v2`への対応やeasyjsonのようなコード生成方式など、go-jsonの今後についても議論しました。
JSONライブラリの内部実装から、ベンチマークとプロファイリングの向き合い方、OSSの保守と設計判断まで。GoでJSONを扱う方や、ISUCONに参加する方にぜひ聞いてほしい回です。
## 関連リンク
- go-json: https://github.com/goccy/go-json
- go-json v0.11.0 リリースノート: https://github.com/goccy/go-json/releases/tag/v0.11.0
- go-json ベンチマークレポ...
·1 hr 1 min
CloudWatch Logsのようなクラウドのログ機能も、裏側ではログファイルを読み取り、別のサーバーへ送る仕組みが動いています。今回はFluentdを入口に、Linuxのファイル操作とログローテートの仕組みをcatatsuyが解説します。
まずはファイルディスクリプタとinodeの基本から。`read()`によるファイルポジションの更新、並行処理での`pread()`の利用、複数プロセスからログを書き込む際の`O_APPEND`と`write()`の関係を説明します。
続いてログローテートの仕組みを掘り下げます。ファイルを`mv`してもinodeは変わらず、開いたままのファイルディスクリプタは古いファイルを参照し続けます。Fluentdの`in_tail`はどうやってローテートを検知するのか。inotifyによるファイル監視がログの書き込み頻度によってCPU負荷を高める問題や、`enable_stat_watcher`による対策も紹介します。さらに、nginxが`USR1`シグナルでログを開き直す理由や、logrotateの`create`と`nocreate`の違いも解説します。
logrotateの`O_EXCL`によるファイル作成にも触れ、最後はFluentdの不具合をcronの`touch`で回避した結果、ログファイルの所有者がrootになり、アプリケーションが書き込めなくなった実際の障害を紹介します。
普段は意識しないLinuxのファイル操作が、ログ収集や運用上の問題にどうつながるのかを掘り下げる回です。
## 関連リンク
- catatsuy「logrotateの設定とファイルのアクセスモードについて」（2018年）: https://catatsuy.medium.com/logrotateの設定とファイルのアクセスモードについて-f9719352dada
- Fluentd: https://www.fluentd.org/
- Fluentd（GitHub）: https://github.com/fluent/fluentd
- Fluentd in_tail（rotate_wait / enable_stat_watcher）: https://docs.fluentd.org/input/tail
- Fluentdのログローテート検知時のwatcher修正: https://github.com/fluent/fluentd/pull/1598
- Fluent Bit: https://fluentbit.io/
- logrotate: https://github.com/logrotate/logrotate
- logrotateのファイル作成処理（O_EXCL）: https://github.com/logrotate/logrotate/blob/1aba3764602a0a013ac3fb1ee57ed547dff03f88/logrotate.c#L600-L614
- logrotate(8): https://man7.org/linux/man-pages/man8/logrotate.8.html
- Debianのnginxパッケージのlogrotate設定: https://sources.debian.org/src/nginx/1.26.3-3+deb13u7/debian/nginx-co...
This podcast, its content and its artwork are not owned by, affiliated with, or endorsed by Castquire.