Erlang/OTP 、WebRTC 、QUIC。

2018 年の最後の記事は自分が時間を投資した技術についてダラダラ書いていく。

Erlang/OTP

Lua と Python を少し書いた以外は Erlang/OTP をひたすら書いていた。自分は自社製品以外では特に Erlang/OTP のお仕事はなかったので、自社製品をひたすら書いていた。WebRTC SFU と負荷試験ツール、あとは 11 月からは QUIC を書いていた。

Erlang/OTP は年に 1 回 6 がつ頃にメジャーバージョンが上がる。今年も無事 OTP 21 がリリースされた。

毎年安定してバージョンが上がるというのはすごいことだと実感する。残念ながら最近は一切 OTP にも rebar3 にも貢献できていないので、使ってる側の人になってしまった。

そのため新しいライブラリの資料を書いたり実践に投入してみたりするようにしている。最近だと counters と logger と persistent_term の3つのモジュールが入った。

counters は Erlang/OTP で統計機能を作る際に ets を捨てられる機能だ。とにかく高速だし ets のようにプロセスの monitor も不要になる。

実際自社製品はすでに一部の統計機能を ets から counters へ切り替えた。

logger は error_logger があまりにも使いづらかったので lager をパワーアップさせた機能。

プロダクトには lager を使ってるがライブラリでログを気軽に出したいときに使えるのは大きい。logger:debug/1 は map を渡せるのも楽だ。

また logger は独自フォーマットも定義できる。ssl モジュールが openssl s_client/s_server のようなログフォーマットを採用している

lager のように丁寧に考えなくていいのは楽なので、最近積極的に使うようにしている。Erlang VM に内蔵されているというのも良い。

persistent_term は皆が待ち望んだ mochiglobal だ。簡単に言えば ets を利用せずにすべてプロセスからアクセスできる KVS を提供する。読み込みがほとんどで、削除や更新がほとんど行われない値に利用するのが良い。

これらの 3 つのモジュールは今までの Erlang/OTP 設計を大きく変える仕組みだと考えている。積極的に使っていきたい。

Erlang VM 自体のチューニングもいろいろ行われている。ここでは省略するが、興味がある人は Erlang/OTP チームのブログを読むと良い。

Erlang/OTP の性能が課題になることが多く、Go や Rust へ行くべきか?といろいろ話をした1年でもあった。ただ、Erlang/OTP で行けるところまでいくという決断をした1年でもあった。

も性能に悩みながら Erlang/OTP を利用して製品を生み出していきたい。

WebRTC

今年も WebRTC の仕様を向き合った。主にブラウザの動向にヤキモキさせられた。

ただ Chrome が Unified Plan へ移行したのはとても良いし、Safari が VP8 に対応し始めたのも吉報だ。何より大きいのは Edge が Choromium ベースになることだろうか、来年はいろいろ慌ただしそうだ。

ビジネス面でも FANZA ライブチャットに採用されたりと大規模での採用も増えてきている。とはいえ海外サービスが進出してきた年でもあった。

巨大なマネーで殴ってくるのに真正面から立ち向かっても勝てないので負けない戦いを意識した1年だった。

どうにか潰れずに、自社製品も順調に売上をあげられているし、製品自体の改善ということで超高画質配信(15Mbps) に対応したり、録画周りを安定化させたりとより安定して使える製品としての改善を進められた。

また、サイマルキャストに対応できたのも大きい。今後は a=simulcast/a=rid モデルに移行していくと思うので、それに追従していきたい。

ネイティブクライアントをオープンソースとしてリリースできたのも良かった。WebRTC の強みであるデバイス、コーデック、トランスポートのすべてを一つの製品で実現できた。特にラズパイでの H.264 のハードウェアアクセラレータを使った仕組みはとてもお気に入りだ。

C++ の製品だがとにかく小さく、カスタマイズをできるようにと作っていった。ビルドも気軽にできるように整理。誰もが気軽に使える仕組みを用意した。

WebRTC の分野ではある程度名前が売れてきた1年でもあった。WebRTC 関連の資料のアップデートも継続できている。

来年は今年同様多くの会社に採用していただけるようにより安定的な製品を目指していきたい。特に 100 人以上で会議ができるスポットライト機能と無変換で録画できる機能は製品として強みの機能でもある。

来年は日本国内に攻めてきている海外製品に負けぬよう、より一層良い製品を作り、提供していきたい。

QUIC (TLS 1.3 含む)

WebRTC が DTLS-SRTP や SCTP over DTLS から WebRTC ベースに切り替わる可能性が高くなってきたということもあり、QUIC プロトコルスタックの実装を 11 月から始めた。

当面は Erlang/OTP で行くという覚悟があったこともあり、 QUIC も Erlang/OTP でチャレンジすることにした。

さらに QUIC はオープンな環境におくということもあり、ポート番号を固定するため、Erlang/OTP で SO_REUSEPORT を採用して実装している。

スケールする QUIC サーバを Erlang/OTP でという前提で開発している。

それにしても QUIC というプロトコルは複雑すぎる。WebRTC の 100 倍くらい難しい。WebRTC はエンコーダ部分や P2P の部分があるので、単純に比較はできないが QUIC はしんどい。

何がしんどいってとにかく TLS 1.3 をさくっと使ってるだけではないところがしんどい。TLS 1.3 の機能を一部利用して実装しているというのが正しい。

Erlang/OTP の ssl ライブラリは今頑張って TLS 1.3 対応しているレベルなので、自前で TLS 1.3 ライブラリを開発することにした。

DTLS と TLS は実装経験があるので TLS 1.3 もそんなに大変ではないだろうと甘く見ていたが、TLS 1.3 は TLS 2.0 と言ってもいいほど別物のプロトコルだ。Client/Server Hello はできるだけ互換性をもたせているが、それ以外は大きく異なる。

MasterSecret 関連や証明書関連も大きく変わっており、おいおいという感じ。

TLS 1.3 の RFC を読み、淡々と実装するしかない。x25519/x448 の知識も1からだった。Erlang/OTP が対応してくれてるのは助かった。ed25519 / ed448 は当面ないだろうと思い見送った。

TLS 1.3 over TCP を OpenSSL 1.1.1 の s_client で動作が確認できたので、よしさぁ QUIC だと思ったが、コレがまた難しい。

QUIC はとにかく最初からパケットが暗号化されている。イニシャルパケットから普通に DstConnectionId を利用して AES-GCM で暗号化されている。

それが終わったら HandshakeSecret を利用して CipherSuite で決めた暗号方式で暗号化され、最後に MastereSecret を利用して暗号化される。

これは 1-RTT の話なので、 0-RTT はもっと鍵の保持が複雑になる。

draft-16 を前提に実装してるのでパケットナンバーの暗号化がされているためそもそもそのパケットが何番目かすら暗号化されている。SRTP も真っ青だ。

draft-17 ではもっと暗号化されれてヘッダー自体が暗号化されるようだ。

UDP なためセキュリティ対策もいろいろはいってる AMP 攻撃対策はシンプルでわかりやすい。クライアントが投げてくるイニシャルパケットは 1200 バイト以上でなければ無視しろという話。面白い。

とにかく状態がかなり複雑になるし、ストリームも複数持てるし、双方向も片方向もできる。もう何でも入といって間違いないと思う。

QUIC を実装するまでは SCTP over DTLS を実装していたのだが、 SCTP をモダンにした実装という感じがある。より複雑さは増してる。

WebRTC で利用する QUIC はユーザランドになると思うので、実装しておいて損はないと考え実装したが、とにかく時間がかかる。

ササッと実装できる人はそうそういないのではないか。TLS 1.3/QUIC draft-16 の最低限なハンドシェイク実装だけでほぼフルタイムで 2 ヶ月かかった。これから細かい実装をいろいろやると考えるとあと 3 ヶ月以上はかかると思う。一人で書いているのと Erlang/OTP で書いてるのと、サーバのみに絞っているのと、ngtcp2 への追従という形で実装してこれだ。

最先端を走っている人たちは化物すぎる。マネしてはダメだ仲間にしてもらうんだ、という気持ちでいる。

来年は draft-16 をある程度完成させ、draft-17 への移行、リカバリ周りの実装、暗号周りの整理、QUIC サーバを誰もが使えるように立ててみるなどいろいろやることがある。間違って HTTP/3 を実装してしまうということも考えられる。

ただ QUIC は複雑であるが、とてつもなく頭の良い人たちによって考えられた最先端のプロトコルだと実感できる。自分は仕様策定の立場ではなく実装者として何か貢献できればと考えている。

来年は現在開発している QUIC サーバを GitHub の QUIC 実装一覧に載せていきたい。

今年1年、ブログをお読みいただき、ありがとうございました。また来年もよろしくおねがいします。

Written by

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store