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
103 Early Hints に対応した Starlet 0.31 をリリースしました
Perl のウェブアプリケーションサーバである Starlet の新バージョン、0.31をリリースしました。 今回搭載された新機能は 100 番台の中間レスポンスの送信に対応した点です。 たとえば以下のような感じで 103 Early Hints レスポンスを送信することで、アプリケーションでリクエストを処理する前に、HTTP/2 リバースプロキシに関連アセットのプッシュの開始を指示することができます注。 sub { my $env = shift; $env["psgix.informational"}->(103, [ 'link' => '; rel=preload' ]); my $resp = ... application logic ... $resp; } Early Hints は、現在 IETF の HTTP WG で Call for Adoption を迎えている段
Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた
さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた 先のエントリ「論理削除はなぜ「筋が悪い」か」で書いたとおり、データベースに対して行われた操作を記録し、必要に応じて参照したり取り消したりしたいという要求は至極妥当なものですが、多くのRDBは、そのために簡単に使える仕組みを提供していません。 daifukuは、RDBに対して加えられた変更をトランザクション単位でRDB内にJSONとして記録するためのストアドやトリガを生成するコマンドです。 % daifuku dbname tbl1 tbl2 > setup.sql のように実行すると、指定されたテーブル（ここではtbl1とtbl2）にセットすべきトリガや、更新ログを記録するためのテーブル「daifuku_log」を生成するCREATE TABLEステートメントなど、必要なSQL文をset
Writing signal-aware waitpid in Perl
As I have talked in YAPC::Asia couple of years ago, the wait functions (e.g. wait, waitpid) of Perl do not return EINTR when receiving a signal. This is a problem if you would want to wait for child processes until receiving a signal. Proc::Wait3 can be a solution, however the module may be hard to install as it is an XS module. It should also be noted that the module provides replacement for wait
GitHub で submodule ではなく subtree を使うべき理由
GitHub には、タグを打つとソースパッケージを自動的にリリースするという機能があります。スクリプト言語においては、それぞれの言語について一般的なパッケージ管理システム注1があるため、この機能を使うことが少ないかと思いますが、デファクトのパッケージ管理システムが存在しないC等の言語で書かれたプログラムや、単独で動作する管理用のスクリプトを GitHub で開発・配布する際には、本機能はとても便利なものです。 しかし、この機能は git-archive コマンドのラッパーとして実装されているため、サブモジュールのファイルが含まれないという問題を抱えています。この点は GitHub の人たちも認識しているものの、今のところ GitHub で独自に対応するということは考えていないようです注2。 私がこの問題を 知ることになったのは、picojson の issue で指摘を受けたからです。pi
PicoHTTPParser now has a chunked-encoding decoder
Today I have added phr_decode_chunked - a function for decoding chunked-encoded input - to picohttpparser. As suggested in the doc-comment of the function (shown below), the function is designed to decode the data in-place. In other words, it is not copy-less. /* the function rewrites the buffer given as (buf, bufsz) removing the chunked- * encoding headers. When the function returns without an er
Q. 条件分岐や算術演算を使わずに、max(a,b) を計算するプログラムを書けますか？
「if文（条件分岐）を使わず、max(a, b) を計算 別解 | 津田の開発な日記」に関連した話です。リンク先のブログ記事では、条件分岐を使わずにmax(a,b)を実装する方法が議論されています。 では、更に条件を厳しくして、「条件分岐も算術演算も使わずに」max(a,b)を実装することはできるでしょうか？ も ち ろ ん 可 能 で す 回 答 例 は 以 下 に あ り ま す なぜ、「もちろん」なのか。CPUは、ANDやOR、NOTのようなデジタルな論理回路から構成されています。であれば、当然、ビット演算（ビットシフトと&, |, ^）を使って、max(a, b)を実装することも可能なわけです。こんな感じ。 #include <stdio.h> #define BIT(n, pos) (((n) >> (pos)) & 1) static int mymax(int a, int
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
[memo] Installing nghttp2 onto OSX
Following the steps below should install nghttp2 with all of its useful apps for testing into /usr/local/http2-15 of your OS X machine. -- openssl % wget --no-check-certificate https://www.openssl.org/source/openssl-1.0.2-beta3.tar.gz % tar xzf openssl-1.0.2-beta3.tar.gz % cd openssl-1.0.2-beta3 % KERNEL_BITS=64 ./config shared enable-ec_nistp_64_gcc_128 --prefix=/usr/local/http2-15 % make % make
[メモ] root権限でrsyncする方法
サーバの移転作業時など、rootしかアクセスできない設定ファイルやアクセス権を保ったままrsyncしたいことってありませんか？ そういった際には、sudo の -A オプションと rsync の --rsync-path オプションを使うと良いようです。 まず、リモートサーバに、パスワードを標準出力に出力するスクリプトファイルを配置します（ファイルのパーミッションを厳しくするのを忘れずに）。 % cat > bin/askpass #! /bin/sh echo "{{my_password}}" % chmod 700 bin/askpass % そして、rsync を実行する際には --rsync-path オプションを使い、リモートサーバの rsync を sudo -A 経由で起動するようにすれば良いのです。 % sudo rsync -avz -e ssh \ --rsync-p
Kazuho's Weblog: Making the HTTP server run 20% faster by using qrintf-gcc; a sprintf-optimizing preprocessor / compiler
Making the HTTP server run 20% faster by using qrintf-gcc; a sprintf-optimizing preprocessor / compiler tl;dr This is an initial release announcement of qrintf, a preprocessor (and qrintf-gcc is the compiler frontend) that optimizes calls to sprintf and snprintf. C programs calling the functions may run faster by using the preprocessor / compiler in place of the standard compiler toolchain. Backgr
sprintf を最大10倍以上高速化するプリプロセッサ「qrintf」を作った
最近H2OというHTTPサーバを書いているのですが、プロファイルを取ってみるとsprintfが結構な時間を食っていて不満に感じていました。実際、sprintfは数値や文字列をフォーマットするのに十徳ナイフ的に便利なので、HTTPサーバに限らず良く使われる（そしてCPU時間を消費しがちな）関数です。 では、sprintfを最適化すれば、様々なプログラムが より高速に動作するようになるのではないでしょうか。ということで作ったのが、qrintfです。 qrintfは、Cプリプロセッサのラッパーとしてソースコードに含まれるsprintfの呼出フォーマットを解析し、フォーマットにあわせたコードに書き換えることで、sprintfを高速化します。 たとえば、以下のようなIPv4アドレスを文字列化するコード片を sprintf( buf, "%d.%d.%d.%d", (addr >> 24) & 0xf
The reasons I stopped using libuv for H2O
Libuv is a great cross-platform library that abstracts various types of I/O by using callbacks. So when I started writing H2O - a high-performance HTTP server / library implementation with support for HTTP1, HTTP2 and websocket, using libuv seemed like a good idea. But recently, I have stopped using it for sereval reasons. This blog post explains them. ■No Support for TLS Although libuv provides a
The JSON SQL Injection Vulnerability
tl;dr Many SQL query builders written in Perl do not provide mitigation against JSON SQL injection vulnerability. Developers should not forget to either type-check the input values taken from JSON (or any other hierarchical data structure) before passing them to the query builders, or should better consider migrating to query builders that provide API immune to such vulnerability. Note: 問題の発見者による日
[perl][memo] File::Tempのバッドノウハウ
■まとめ tempfile(...)が作成したテンポラリファイルは、環境によってはflockされていることがある tempfile(CLEANUP => 1)は、テンポラリファイルへの参照をretainする つまり、CLEANUPを指定している場合、参照カウントに頼った自動closeは機能しないので、明示的にcloseする必要がある また、明示的にcloseしないとflock可能にならない場合がある ■ログ 16:23:30 <kazuho_> あれ perl って file handle への refcnt がゼロになったら自動的に close してくれますよね 16:23:43 <tokuhirom> してくれますね 16:23:48 <tokuhirom> しなきゃおかしいw 16:32:33 <kazuho_> https://gist.github.com/kazuho/1116
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
プログラミング言語における正規表現リテラルの必要性について
Twitterに書いたことのまとめです。 プログラミング言語の仕様の一部として正規表現リテラルを提供することの得失について、JavaScriptを例に説明します。 ■より簡潔なコード 言うまでもありませんが、正規表現リテラルを使った方が簡潔なコードになります。 (new RegExp("abc")).exec(s) // リテラルを使わない場合 /abc/.exec(s) // リテラルを使った場合 また、正規表現リテラルがない場合は、文字列リテラルとしてのエスケープと正規表現としてのエスケープが二重に必要になる結果、コードの保守性が低下します注1。 new RegExp("\\\\n"); // リテラルを使わない場合 /\\n/ // リテラルを使った場合 ■エラー検出タイミング 正規表現リテラルがない場合、実際にその正規表現が評価されるまで記述エラーを検出することができません。正規表
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
