komake: Make の -j オプションに潜む罠とその解決策
ビルドツールのダジャレの大家と言えば @shinh さんですが、それはさておき、皆さんは今でも Make を使ってビルドすることが多いと思います。かく言う私も、その一人。 最近は CPU のコア数も多いですから、当然 -j 16 とか、やりたいわけです。大きいプロジェクトになればなるほど、威力絶大ですね。 ですが、ここで問題がひとつ。大規模プロジェクトでは Makefile が別の Makefile を呼び出すような依存関係が良く見受けられます。この際、ターゲット間の依存関係で菱形が存在すると（例: ターゲット sub1 と sub2 が shared に依存）、make shared が make sub1 と make sub2 から同時に起動されることが起こりえます。CMake で生成した Makefile の場合も、ターゲット毎に make を起動しますね。 二重起動が発生すると、
QUICむけにAES-GCM実装を最適化した話 (2/2)
前半で述べたように、OpenSSLのAEAD暗号器は、長いAEADブロックの処理を前提に作られています。平文の暗号化処理においては理論上の上限にあたる速度を叩き出す一方、事前処理と事後処理、および呼出オーバーヘッドについては、あまり最適化が図られているとは言えません。これは、AEAD暗号の主な使用用途が、これまでTLSという長いAEADブロックを使う（ことが一般的な）プロトコルであったことを反映していると言えるでしょう。 一方、QUICにおいては、UDPパケット毎に独立した、短いAEADブロックを暗号化する必要があり、したがって、次のような速度向上の機会があることが分かります。 AEAD処理をひとつの関数にまとめ、事前処理と事後処理を、パイプライン化されスティッチングされた暗号処理と並行に走らせることができれば、AEADブロックが短くても、理論値に近いスループットを発揮するような、AES-
QUICむけにAES-GCM実装を最適化した話 (1/2)
4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC
HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
TLS の SNI 暗号化に関する Internet Draft を共同提出しました
Eric Rescorla (RTFM), Nick Sullivan (Cloudflare), Christopher Wood (Apple) の各氏とともに、SNI を暗号化する TLS 拡張を提案する Internet Draft を提出しました。 Encrypted Server Name Indication for TLS 1.3 アナウンスのメールにあるとおり、すでに NSS / Firefox と picotls / H2O で実装作業が開始されており、今月開催される IETF 102 で相互運用試験を行うとともに、標準化にむけた議論を深める予定です。 スノーデン事件以降、広範囲におよぶトラフィックモニタリングによるプライバシー侵害の懸念が明らかになるとともに、できるだけ多くのインターネット上の通信プロトコルを暗号化することが求められるようになってきました (参考: R
Kazuho's Weblog: 次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon
９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。 QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。 聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。 PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通
Kazuho's Weblog: 海賊版サイトのブロッキングについてアンケートをとってみたら興味深い結果が出た
政府がISPに対し対し海賊版サイトのブロッキングを要請し、議論になっています。あなたは以下のどの対策が正しいと思いますか？ — Kazuho Oku (@kazuho) April 25, 2018 832票もの回答をいただきました。ありがとうございます。結果をみて、いくつか感想を述べさせていただきたいと思います。 ▪️海賊版サイトに対し、なんらかの新たな対策が必要かどうかについて 83%の方々が、なんらかの新しい対策を取ることに積極的賛成、あるいは消極的賛成という立場を取られていることがわかりました。一方で、17%の方々が、少なくとも現時点では新たな対策は不要であり、出版社等の権利者は現行法に基づき、刑事告発、民事訴訟、DMCA Takedownなどの手法を用いて戦うべきだと考えていらっしゃることもわかりました。 ▪️ブロッキングという手法について 意見が綺麗に割れました。 42%の方々
CI 用 Docker イメージ作成におけるベストプラクティス
H2O の CI では長らく、秘伝のタレ的な .travis.yml を使い続けてきたのですが、なにぶん依存関係が多いもので、だいぶメンテナンスが辛い感じになってきていました。また、CI テストで発生したエラーの調査の度に、時間のかかる CI を回さなければならないことが、開発者のストレスとなっていました。 そこで一念発起して、Docker イメージを使った CI に切り替えることにしました（実行環境としては引き続き Travis を使います）。 その際に、要件として以下のようなことを考えました。 CI以外に、コミット前のテストにも使えるようなイメージにすること コマンド一発でビルドとテストが動作すること 無駄な処理をしないこと その結果、以下のような実装になりました。 テストに必要なソフトウェア群をインストールしたイメージを Docker Hub にアップロードしておく テストには、1.
コマンド一発でソースコード検索＆表示できる「peco」改が凄い！
lestrratさんがやってくれました。 ずいぶん前から、ソースコードを検索して読みやすいコマンドはないかなーと思っていました。個人的にはackで検索して見つかったファイルをlessで開いて再びキーワードを入れて当該行までジャンプしていたのですが、毎回毎回めんどくさい感じでした。コマンド一発でインクリメンタル検索してキーワード周辺のソースコードを読めるツールが欲しいなぁって思ってたんです。 とあるslackでお昼時に、mattnさんと「ほしいですよねー」という話から始まって、vimにあるgrepとかも物色しながら「いいのないねー」とか言ってたらkanさんが「@lestrrat 案件だ」って言い出して牧さんが召喚されてついさっきpecoに必要な機能が追加されてました。速いw ためしにpicotlsの開発ディレクトリでpecoの一行ラッパーperoを起動し、「EVP_Digest」を検索してみ
Fastly に入社しました
Summary in English: Joined Fastly, will continue my work on H2O there as an open-source developer. 2017年1月1日付で、Fastly 社へ転職したので報告いたします。 過去５年間、DeNA では R&D 的な立場から、様々な基盤的ソフトウェア（オープンソースになったものもありますし、クローズドなものもあります）の開発に携わってきました。 最近２年間は、同社のゲーム用サーバに端を発するオープンソースの HTTP/2 サーバ「H2O」の開発に従事してきましたが、その実装品質が高く評価され、世界有数のコンテンツ配信ネットワーク（CDN）である Fastly で採用された他、大規模なウェブサービス事業者で採用にむけた動きが進むなどの成果が出つつあります。 また、H2O における実装経験をもとに、H
mmapを使ってファイルベースの巨大なバッファを確保する話
小さなバッファはインメモリでもつが、メモリに収まらないような大きなバッファはテンポラリファイルを作り、file I/Oでアクセスする、というのが昔からの汎用的なバッファ実装のアプローチ。 だが、バッファに格納するデータ量によってアクセス手段を変えるというのはめんどくさいし、そこを抽象化すると無駄なオーバーヘッドが発生する。 幸いなことに最近は、メモリ空間が広い 64bit CPU だけ考えればいい。なので、ファイルの「読み込み」については、めんどくさいから全部mmapするというのが一般的なアプローチになってきている（例: LLVMのリンカであるlld）。 同様のことが、テンポラリファイルを使う可変長のバッファについても可能であり、h2o では実際に実装している。詳しくは h2o_buffer_reserve 関数の実装を見てもらえばいいと思いますが、ざっくりとした手順は以下のとおり： ▪️
Name Constraints を使った独自CAの運用手順
ウェブブラウザが新機能をHTTPSでしか有効にしないことが多くなってきたので、開発環境でもHTTPSを使いたい。でも、開発環境用にサーバ証明書を買うのは手間。Let's Encryptも運用がめんどくさいとか、社内からしかアクセスできないサーバへの証明書発行が難しいとかいろいろあるし…ってそこでName Constraintsを使った独自CAですよ奥さん。 Name Constraints が何であるかについては、以前オレオレ認証局の適切な運用とName Constraintsに書いたとおり。 本稿では、Name Constraintsを使うCAの運用手順を説明する。 1. CA鍵と証明書の作成 1.1. CAの秘密鍵を作成 % openssl genrsa -out ca.key 2048 1.2. openssl.cnfにCA証明書に設定する属性を指定するセクションを追記 [priva
Optimizing performance of multi-tier web applications using HTTP/2 push
Optimizing performance of multi-tier web applications using HTTP/2 push Push is a feature of HTTP/2, that allows a server to speculatively send response to a client, anticipating that the client will use the response. In my earlier blogpost, I wrote that HTTP/2 push does not have significant effect on web performance when serving static files from a single HTTP/2 server. While that is true, push d
mruby で同期呼出を非同期化する話（もしくは H2O の mruby ハンドラでネットワークアクセスする話）
■背景 H2Oではバージョン1.5より、mrubyを用い、Rackのインターフェイスに則った形でハンドラを書けるようになっています。 この機能を提供している目的は、正規表現による書き換え等を用いる複雑な設定ファイルではなくプログラミング言語を用いることで、ウェブサーバの設定をより簡潔に拡張しやすくするためです（Apacheのmod_rubyやmod_perlのようにウェブアプリケーションをウェブサーバ内で実行可能にすることではありません）。 とは言っても、現実のウェブサーバの設定においては、外部のデータベース等に問い合わせた結果に基づいたルーティングが必要になることがあります。 H2Oのようなイベントドリブンなウェブサーバ上で動作する、同期モデルを採用するRackインターフェイスを用いて記述されるハンドラ内において、データベースへの問い合わせをどのように実現すれば良いか。問い合わせが同期的
ソート済の整数列を圧縮する件
圧縮されたソート済の整数列ってのは汎用的なデータ構造で、たとえば検索エンジンの転置インデックスとか、いろんなところで使うわけです。で、検索エンジンの場合は速度重要なので、PForDeltaとか様々なデータ構造が研究されてる。 一方、H2O には、ブラウザキャッシュに載ってない js や css をサーバプッシュする仕組み「cache-aware server push」があって、何がキャッシュされているか判定するためにブルームフィルタを全ての HTTP リクエストに含める必要がある。 で、ブルームフィルタを圧縮しようと思うと、ブルームフィルタってのはソート済の整数列として表現できるので、これを圧縮しようって話になる。 検索エンジン等で使う場合は速度重要だけど、HTTPリクエストに載せる場合は空間効率のほうが重要になる。ってことで、空間効率が理論限界に近いゴロム符号（の特殊系であるライス符号
Kazuho's Weblog: Performance improvements with HTTP/2 push and server-driven prioritization
Performance improvements with HTTP/2 push and server-driven prioritization tl;dr HTTP/2 push only marginally improves web-site performance (even when it does). But it might provide better user experience over mobile networks with TCP middleboxes. Introduction Push is an interesting feature of HTTP/2. By using push, HTTP servers can start sending certain asset files that block rendering (e.g. CSS a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2で 速くなるとき ならないとき
HTTP/2の課題と将来について、YAPC Hokkaidoで話してきた
Velocity in Amsterdam 2016 で HTTP/2 とその先にある最適化について話してきた