QUICのヘッダ圧縮QPACKとは (旧QPACK)

20190408追記
最新版について記事を書きました
asnokaze.hatenablog.com

---

QUICのヘッダ圧縮であるQPACKについて

現在のQUICの策定中仕様の一つである「Hypertext Transfer Protocol (HTTP) over QUIC」では、QUICでもHTTPヘッダの圧縮にHPACKを使用することになっていますが、新しくQUIC用のヘッダ圧縮方式として「HTTP over QUIC - Mapping and Header Compression」という仕様でQPACKなるものが提案されています。

背景 QUICとHPACK

HTTP/2ではヘッダ圧縮方式としてHPACKと呼ばれる方式を利用します。HPACKはRFC 7541「HPACK: Header Compression for HTTP/2」で標準化されています。

HPACKはヘッダ名とヘッダ値をハフマン符号化するほか、静的テーブル・動的テーブル呼ばれる辞書を用いてHTTPヘッダを表現します。特に、一つのコネクションで一度使用したHTTPヘッダは動的テーブルに追加され、次のHTTPリクエスト・レスポンスではindex(1バイト)でそのヘッダ名・ヘッダ値を表現することができます。

QUICでもこのHPACKを使用するのですが、困ったことがあります。前提として、QUICはUDPを使用することで、HTTP2 over TCPの時にあったTCPレイヤのヘッドオブラインブロッキングを克服しています。

どういうことかというと、TCPではパケットの欠損や順番の入れ替わりがあるとそれらが解決出来るまで、すでに届いてるパケット(HTTPリクエスト・HTTPレスポンス)を処理することができません。欠損しているパケットの後続すべてが待たされてしまいます。

QUICではUDPを使用しており、一つのパケットロスなどにより他の処理がブロックされることはないようになっております。QUICが持つストリーム毎にパケットロスの回復や順番の並び替えを行うため、一つのストリームでのパケットロスは他のストリームに影響しません。

しかし、HPACKの動的ヘッダテーブルはテーブルへの挿入・エビクションが発生するため結局は順番通りにしか処理できないという欠点があります。つまり、結局パケットロスにより後続の処理はブロクッされてしまいます。

そこでHPACKが持つヘッドオブラインブロッキングを解消するために、QPACKが提案されているということになります。

QPACK

QPACKでは上記のような、HPACKが持つヘッドオブラインブロッキング問題を解決するために、動的テーブルの扱いに大きな変更が入っています。HPACKでは、動的テーブルへの追加する際にインデックス番号がずれていく他、追加・エビクションの際のインデックス番号は暗黙的でした。

QPACKの動的テーブルは下記のような特徴を持っています。

• 追加する際はインデックス番号を明示する(静的テーブルの一番大きいインデックス番号より大きいこと)
• エビクションは発生しない(テーブル上限を超えるとFatal error)
• すでに使用されているインデックス番号は、明示的に削除するまで変更できない
• 明示的に削除するDeletionを使用する
• そのインデックスを参照するフレームをすべて処理し終わったら、QPACK-ACKフレームを送信して削除できるようになる

このようにして、一度追加されたインデックスはお互いにもう使用しないことが確認でき削除されるまで変更されないようになっています。

もちろんQUICのパケットは入れ替わるため、インデックスへ追加するパケットとインデックスを参照するパケットの順番が入れ替わることがあります。その時はインデックスへ追加するパケットが到着するまで待つことになります。

これを避けるために、QPACKは同じインデックス番号に同じ値を追加する命令は何度でも行って良いことになっており、複数のHTTPリクエストにおいてインデックスの追加命令を行うことで、待つパケットを減らすことができます（ただし、圧縮効率は落ちます）。また、部分的なHeader Block Fragmentsが受信できた際は処理をすすめることができ、この部分にテーブルへの追加がアレば実行して良いことになっています。

削除もお互いに合意できて(QPACK-ACKを受け取って)やっと削除ができます。つまり、そのインデックスを参照するパケットをすべて処理し終わったタイミングです。テーブルサイズの上限まで使用してると、なかなか合意が得られず削除できないこともあるので、仕様では上限になる前に送信側が削除を試みることを推奨してます。

その他仕様的な話

上記での説明と重複もあるが、以下のことについて書かれている

• 静的テーブルや、文字列リテラル表現、動的ヘッダテーブルを更新しないヘッダ表現は変更はない
• Literal Header Field with Incremental Indexingがなくなり、Literal Header Field with Indexingが新しく定義され、明示的にインデックス番号を指定するようになる
• Dynamic Table Size Updateがなくなり、明示的に削除を行うDeletionになる
• テーブルサイズ管理
• 動的テーブルの伸長・縮小についての変更
• この仕様によりQUICのHEADERSフレーム・PUSH_PROMISEフレームのシーケンス番号が不要になるので削除
• お互いに削除出来ることが確認できるまでの4つの段階の定義
• Performance Considerations, Security Considerations

翻訳

翻訳というのには気が引けるが

一応ざっと目を通したので、QPACKの翻訳をひっそり置いておく。
（読み返したら微妙だったので、後日直します....ます....）

https://github.com/flano-yuki/my-quic-spec-translation/blob/master/draft-bishop-quic-http-and-qpack/draft-bishop-quic-http-and-qpack-01.md

NginxでTLS1.3 動いた(OpenSSL)

昨日書いた「OpenSSLのTLS1.3対応」の続き

特に何かしたわけではないが、OpenSSLのTLS1.3対応が進んでいたのでインストールしてNginxで動かす。

ビルド

openssl
今回はインストールしてしまう。

$ git clone https://github.com/openssl/openssl.git
$ cd ./openssl
$ git log --oneline |head -n1
ef3f621 Fix man3 reference to CRYPTO_secure_used

$ ./config enable-tls1_3
$ make
$ sudo make install

nginx (openssl1.1.0対応が終わってるものなら大丈夫かと)

$ git clone https://github.com/nginx/nginx.git
$ cd ./nginx
$ ./auto/configure --with-http_ssl_module
$ make
$ make install

(conf修正と、証明書は各自)

試す

Firefox Nightlyで、about:configよりsecurity.tls.version.maxを5に設定しておく。
アクセスし、デベロッパーツールのセキュリティパネルより確認する。

この通りTLS1.3と表示される

Nginx側のログも、この通りTLS1.3であることが確認できる

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      'TLS:$ssl_protocol';

192.168.0.105 - - [19/Jan/2017:15:11:54 +0000] "GET / HTTP/1.1" 200 0 "-" TLS:TLSv1.3

実装としてはやはりまだ不安定でChrome Canaryだと通信に失敗する
ちなみに、ALPNも動いてるようでhttp2も普通に喋れている。

ベンチでも取りたかったが、abがopenssl 1.1.0でのインターフェイス変更に対応してるかちょっと怪しかったので断念。

ゆくゆくは何も意識せずTLS1.3が使われるようになるだろう。

PerformancePaintTiming API(First Paint Timing API)とは

昨今、「Navigation Timing API」といったクライアント側でのページの処理時間を取得する機能が充実してきております。

W3CのWeb Performance WGでは、Navigation Timing、User Timing、Resource TimingそれぞれLevel2, Level3が改訂作業が行われております。(ドラフト状況)

また、昨年末頃より「PerformancePaintTiming」APIの議論が行われているように感じます。簡単な仕様はgithubのwicg organization以下に公開されております ( https://github.com/WICG/paint-timing )。これは、より多くの情報を取得できるようにする一環で、実際の描画時間が重要度が高いためのようだ。

数年前に、ふろしきさんが「Webページ遷移時間のパフォーマンス「First Paint」を計測する方法」で書かれている通り、window.chrome.loadTimes()より、firstPaintがとれましたが、より現代的な標準APIが検討されております。

PerformancePaintTiming

リポジトリの使い方とサンプルを見るのがわかりやすいかと思います。
PerformanceObserverから、firstPaintエントリより最初の描画タイミングが取得できます。

var observer = new PerformanceObserver(function(list) {
  var perfEntries = list.getEntries();
  for (var i = 0; i < perfEntries.length; i++) {
     // Process entries
     // report back for analytics and monitoring
     // ...
  }
});

// register observer for long task notifications
observer.observe({entryTypes: ["firstPaint"]});

(https://github.com/WICG/paint-timing#examples

• first-paint: ナビゲーション後のcontaining blockを最初に描画した時間(背景を除く)
• first-contentful-paint: 最初の、テキスト、画像、キャンバス、SVGを描画した時間

Improving accuracy of FP / FCP

Chromeでは、内部的にFPとFCPの時間を取得しており stable版で情報収集をしている。
https://docs.google.com/document/d/1XVP9jaZT7acQtK5O6vO-mIz31i5iB-pZn1S41_YP6p0/edit#

その中で、さらに細かくどこまでの時間をFP, FCPに含めるべきなのかというレポートを出している。どこまで仕様化できるかはわからないが、今後共WebPerf WGで議論が続けられる模様である。

OpenSSLのTLS1.3対応 喋れる

追記 20170120

NginxでTLS1.3 動いた(OpenSSL)
後日Nginxでも動いたので、上記記事に記載

---

セキュリティとパフォーマンスが向上したTLS1.3の登場が待ち望まれております。

標準化としては、現在IETFのTLSワーキンググループではWGラストコールという段階に入っており、2月頃にはIESGに提出され標準化は最終段階となる見込みになっております(結構そっから議論があったりはするんですが)。

すでに、実装としてはChrome, Firefoxといったブラウザもオプションで有効化に出来る他、BoringSSL, picotls, nssといった実装も出てきており、相互通信テストなども行われております。

昨年行われたIETF97時点ですが、下記のような実装で通信テストに成功しています。

https://www.ietf.org/proceedings/97/slides/slides-97-tls-tls-13-00.pdf

さて、OpenSSLはと思うところですが、同じくIETF97時点ですが、OpenSSLの状況が報告されております。すべての作業はgithub上でプルリクが出されており、次のリリースで出るとのことでした。
https://www.ietf.org/proceedings/97/slides/slides-97-tls-openssl-update-00.pdf

TLS1.3の中身の話は、kazuhoさんやkazuさんの資料がわかりやすいかと思います

• http://www.slideshare.net/kazuho/tls-13-0rtt
• http://seminar-materials.iijlab.net/iijlab-seminar/iijlab-seminar-20170110.pdf

とりあえず、現状で試してみる

OpenSSLはまだまだ開発中で動かないかもと思いながらも、試してみる
./config時にenable-tls1_3を与える

$ git clone https://github.com/openssl/openssl.git
$ cd ./openssl
$ git log --oneline |head -n1
ef3f621 Fix man3 reference to CRYPTO_secure_used

$ ./config enable-tls1_3
$ make

既存実装のリストは下記にあるので、公開URLのものから幾つか繋いで見る
https://github.com/tlswg/tls13-spec/wiki/Implementations

クライアントで試す

他のバージョンと同様 --tls1_3を与える

$ LD_LIBRARY_PATH=./ ./apps/openssl s_client -connect franziskuskiefer.de:9913 --tls1_3
...
New, TLSv1.3, Cipher is TLS13-AES-128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS13-AES-128-GCM-SHA256
    Session-ID:
    Session-ID-ctx:
    Master-Key: AC496ABF3FE5EF1C197CA5B825746CD58A05E86494288C82057604F819C2B757
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1484672332
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: no
---
GET / HTTP/1.1
host:test

HTTP/1.1 200 OK
Date: Tue, 17 Jan 2017 16:58:56 GMT
Server: Apache
Upgrade: h2
Connection: Upgrade, close
Last-Modified: Fri, 03 Jun 2016 08:50:46 GMT
ETag: "d5f-5345bd194edaf"
Accept-Ranges: bytes
Content-Length: 3423
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
...

他のは繋がらなかったものの、つながるサーバもあった。
(どこが悪いのかまだちゃんと見てない...

サーバ側で試す

Chrome canaryと通信させる

$ LD_LIBRARY_PATH=./ ./apps/openssl s_server -cert ../server.crt -key ../server.key  -tls1_3
...
-----BEGIN SSL SESSION PARAMETERS-----
MGUCAQECAgMEBAITAQQgMuuXEJUnlwWHomt0g/L89WPXiudXU2AHGFd6NdSKBPYE
IIKAszcJj6hsNaEPwtZz6t/IskTrQB5QnBvCCV9YjxZ+oQYCBFh+TwiiBAICHCCk
BgQEAQAAAA==
-----END SSL SESSION PARAMETERS-----
Shared ciphers:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
Signature Algorithms: ECDSA+SHA256:RSA+SHA256:RSA+SHA256:ECDSA+SHA384:RSA+SHA384:RSA+SHA384:RSA+SHA512:RSA+SHA512:RSA+SHA1
Shared Signature Algorithms: ECDSA+SHA256:RSA+SHA256:RSA+SHA256:ECDSA+SHA384:RSA+SHA384:RSA+SHA384:RSA+SHA512:RSA+SHA512:RSA+SHA1
Supported Elliptic Groups: 0x9A9A:X25519:P-256:P-384
Shared Elliptic groups: X25519:P-256:P-384
CIPHER is TLS13-AES-128-GCM-SHA256
Secure Renegotiation IS NOT supported
GET / HTTP/1.1
Host: 192.168.0.179:4433
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2984.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: ja,en-US;q=0.8,en;q=0.6

なんか、怪しいけど、HTTPリクエストが来てることは確認できた。

2016年振り返り

早いもので2016年も終わりですね。

今年は、毎月コンスタントにブログ記事を書けたもの、記事数39と去年よりも少なくなってしまいました。internet-draft絡みも9本でした。

ただ反面、OSSにPR投げてマージされたり、英語でissue投げてみたり、Nginxのモジュール書いてみたり出来たのは良かったなと思いました。

昨年同様 IETFにも行けましたし、来年も行けるように頑張ります。
来年も、微力ながら誰かのお役に立てるように精進していければと思います。

今年もありがとうございました。

• varnishtestのHTTP/2対応 アップデート
• 103 EarlyHintsを送信するNginxモジュール書いた
• Apache mod_http2 で 103 EarlyHints を試す
• ntpdのLeap Smearingを有効にし、うるう秒を24時間かけて調整する
• Nginxのtoken binding実装を試す
• NTP leap indicatorを上書きするProxyを書いた
• CT対応を示すExpect-CTヘッダとは
• CloudFlareの提案するHTTP/2の圧縮辞書拡張
• googleの新しい時刻同期プロトコル Roughtimeとは
• XSSを防ぐ新しいXSS-Protectionヘッダ
• Chrome 56 のHTTPサイトへの日本語版警告
• Secure Contextsに関する localhost と、IETFでの新提案
• wicgのFace detection API
• HTTP/2のデバック用情報エンドポイントの仕様
• Site-Wide HTTP Headers とは
• ポリシーをオリジン全体に適応する Origin Policy
• QUICの仕様を翻訳していく
• iframeのアプリケーションにPermissionを委譲する仕様
• Go実装のWebサーバ CaddyのQUICを試す
• Feature Policy、ブラウザの特定機能を無効にする仕様
• Firefox Nightly がTLS1.3対応したので試す
• 安全でない通信路でセットされたCookieの有効期限を短くする仕様
• Mixed ContentのブロックされたURIをレポートさせる仕様追加
• Cache-Control: immutableについて
• CloudFlareのNGINX HTTP/2 + SPDY両対応するパッチを試す
• TLS1.3のgo実装 Mintを触ってみる
• ブラウザのクレデンシャル管理と連携するCredential Managementを試す
• HTTP/2における証明書に基づいたリアクティブなクライアント認証 その２
• CSP3のunsafe-dynamicとunsafe-hash-attributes
• Nginxでchacha20 poly1305を有効にする
• NGINX Amplifyを触ってみる
• BlinkのMLで提案されている AppInstalled API とは
• Captive Portal Problem Statementについて
• プライベートネットワークへのCSRFを緩和する仕様の提案
• QUICはXORベースのFECをやめるらしい
• apache2 mod_http2のhttp2-status
• Limited Use of Remote Keys(Lurk)についてのメモ
• varnishtestがHTTP2対応して超便利！
• まもなく公開される CSP Level3 の変更点

varnishtestのHTTP/2対応 アップデート

これは、http2 Advent Calendar 2016の10日目の記事です。

---

今年の頭に書いた「varnishtestがHTTP2対応して超便利！」で紹介しましたvarnishtestのHTTP/2対応ですが、シンタックスの一部変更で当時のサンプルが使えなくなっていたのでアップデートについて軽く書きたいと思います。

当時は開発者様の個人リポジトリで開発が進められている状況でしたが、varnish5でmasterにマージされております。
また、varnish5で本体側もhttp2対応が進められているため、ようやくvarnish本体を経由するようなテストもかけるようになりました。ただし本体側のhttp2はまだまだバグがあるようで実際に使う場合は慎重になったほうが良いようです。

varnishtest自体については前回の記事を見ていただくか、いわなちゃんさんの記事がわかりやすいかと思います

• Varnishでテストコードを書こう！

サンプル

HTTP/2のサーバとクライアントでボディ付きの通信をする例になります。
https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/a02002.vtc

varnishtest "Simple request with body"

server s1 {
	stream 1 {
		rxreq
		txresp -body "bob"
	} -run
} -start

client c1 -connect ${s1_sock} {
	stream 1 {
		txreq
		rxresp
		expect resp.bodylen == 3
	} -run
} -run

• 以前は「 h2client」のように明示的にh2対応のクライアントと書いていましたが、stream句を使うことで各エンドポイントはHTTP/2通信に切り替わるようになりましｔ(http1からのアップグレードの手順も記述できるようになっています)
• HTTP/2で要求される疑似ヘッダ(scheme, method, authority)などが明示的に書く必要がなくなりました

その他新機能

コネクションレベル・ストリームレベルのウィンドウサイズのテストが記述できるようになりました
https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/a02023.vtc

ウィンドウサイズのテストにおいて、SETTINGSフレームで指定される初期ウィンドウサイズを考慮するようになりました
https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/a02010.vtc

ストリームの依存関係・ウェイトのテストが記述できるようになりました
https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/a02015.vtc

サーバプッシュのテストが記述できるようになりました
https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/a02017.vtc

varnishを間に挟む場合のテスト

varnish本体がh2(h2cのみ)に対応しているため、varnishtestもクライアント・(バックエンドとしての)サーバの間にvarnishを挟む形のテスト例も追加されています。

https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/t02000.vtc

server s1 {
	rxreq
	expect req.http.host == foo.bar
	txresp -bodylen 10
} -start

varnish v1 -vcl+backend {} -start

varnish v1 -cliok "param.set feature +http2"
varnish v1 -cliok "param.set debug +syncvsl"

client c1 {
	stream 1 {
		txprio -weight 10 -stream 0
	} -run
	stream 3 {
		txprio -weight 10 -stream 0
	} -run
	stream 5 {
		txprio -weight 10 -stream 2
	} -run
	stream 7 {
		txreq -hdr :authority foo.bar
		rxresp
		expect resp.status == 200
	} -start
	stream 0 {
		txping -data "_-__-_-_"
		rxping
		expect ping.ack == "true"
		expect ping.data == "_-__-_-_"
	} -run
	stream 7 -wait
} -run

この例では、バックエンドサーバはhttp/1を使用して、クライアント側からはh2で接続するテストになっています。
varnishのパラメータでhttp2を有効にする必要はありますが、ココらへんは記述方式的にはhttp2独自ではないので通常通り動くという感じになるかと思います。

おまけ

テスト例として、別のクライアント実装と通信する例もあります
https://github.com/varnishcache/varnish-cache/blob/master/bin/varnishtest/tests/a02022.vtc

feature cmd "nghttp --version | grep -q 'nghttp2/[1-9]'"

server s1 {
	rxreq
	upgrade

	stream 3 { rxprio } -run
	stream 5 { rxprio } -run
	stream 7 { rxprio } -run
	stream 9 { rxprio } -run
	stream 11 { rxprio } -run

	stream 1 {
		rxprio
		txresp
	} -start

} -start


shell { nghttp http://${s1_addr}:${s1_port} -nu }

varnishtestはvarnish以外でも使用できます。IP指定も出来ますし、今回はありませんが複数クライアントで同時にリクエストを送らせたりも出来ます。
工夫次第では色々な使い方ができるかと思います！！

103 EarlyHints (RFC 8297) を送信するNginxモジュール書いた

これは、nginx Advent Calendar 2016の8日目の記事です。

---

103 Early Hints

先日の「Apache mod_http2 で 103 EarlyHints を試す」という記事でも書きましたが。軽くおさらい。

103 Early Hintsは、@kazuho氏によって提案されている仕様です。すでに Individual-Draftが提出されています。
https://tools.ietf.org/html/draft-kazuho-early-hints-status-code-00

IETF97でも仕様についての議論が行われており、その際のスライドを見ると分かりやすいかと思います。
https://www.ietf.org/proceedings/97/slides/slides-97-httpbis-sessb-early-hints-00.pdf

ステータスコードはコンテンツの生成が終わったあとに決定されるため、コンテンツの生成が終わるまでHTTPレスポンスは送信開始できません(1行目がステータスコードのため)。

103ステータスコードのレスポンスは本来のHTTPレスポンスに先んじて送信できるので、先行してHTTPレスポンスヘッダを送信することができます。たとえばLinkヘッダでPreloadを先に送信すれば今後必要になるリソースをより早くクライアントに知らせることができます。

前回の103ステータスコードを用いたmod_http2の実験では、103ステータスコードを返すサーバはモックサーバを立てましたが今回はNginxモジュールを書いてみました。(試験実装なので怪しいとは思います)

ngx_http_early_hints

試験実装ですがngx_http_early_hints モジュールとして、すでに公開済になります。
https://github.com/flano-yuki/ngx_http_early_hints

以下のように、locationディレクティブに add_early_header を宣言すると、マッチする際に103ステータスのレスポンスを返すようになります。

location /103.html {
    add_early_header "Link" "</main.css>;rel=preload";
}

実際にHTTPリクエストを送信してみると以下のように103スレータスのレスポンスがまず送信されます。
(NGX_HTTP_ACCESS_PHASEでフックしてるので、コンテンツの生成より早いタイミングで送信されます)

vagrant@vagrant:~$ telnet localhost 80
Connected to localhost.
Escape character is '^]'.
GET /103.html HTTP/1.1
host:localhost

HTTP/1.1 103 Early Hints
Link: </main.css>;rel=preload

HTTP/1.1 200 OK
Server: nginx/1.11.6
Date: Wed, 07 Dec 2016 13:29:12 GMT
Content-Type: text/html
Content-Length: 22
Last-Modified: Wed, 07 Dec 2016 13:28:44 GMT
Connection: keep-alive
ETag: "58480e8c-16"
Accept-Ranges: bytes

This is main contents

あとがき

Nginxモジュールを初めて書くので、お作法がだいぶわからなかったのですが、下記サイトが非常に参考になりました。ありがとうございます。

• cubicdaiya/ngx_http_hello_world https://github.com/cubicdaiya/ngx_http_hello_world
• ngx_mrubyから学ぶnginxモジュールの作り方 http://blog.matsumoto-r.jp/?p=2841

実用に足るかはわかりませんが、エラーハンドリング、HTTP/2のサポート、複数add_early_headerのサポート、ほかモジュールとの併用検証など進めていければと思います。