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 ワーキング
Kazuho's Weblog: 海賊版サイトのブロッキングについてアンケートをとってみたら興味深い結果が出た
政府がISPに対し対し海賊版サイトのブロッキングを要請し、議論になっています。あなたは以下のどの対策が正しいと思いますか？ — Kazuho Oku (@kazuho) April 25, 2018 832票もの回答をいただきました。ありがとうございます。結果をみて、いくつか感想を述べさせていただきたいと思います。 ▪️海賊版サイトに対し、なんらかの新たな対策が必要かどうかについて 83%の方々が、なんらかの新しい対策を取ることに積極的賛成、あるいは消極的賛成という立場を取られていることがわかりました。一方で、17%の方々が、少なくとも現時点では新たな対策は不要であり、出版社等の権利者は現行法に基づき、刑事告発、民事訴訟、DMCA Takedownなどの手法を用いて戦うべきだと考えていらっしゃることもわかりました。 ▪️ブロッキングという手法について 意見が綺麗に割れました。 42%の方々
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
H2O HTTP2 server 2.0 released!
We are happy to announce the release of H2O version 2.0. It is a major update from 1.7 series, including many improvements and bug fixes. The most prominent changes are:support for Brotli compression directives for file-level resource mapping addition of the status handler reverse proxying using HTTPS Full list of changes can be found here. Please refer to the reference documentation to find out h
雑なツイートをしてしまったばかりにrubyを高速化するはめになった俺たちは！
逆に言うと、Rubyの文字列型の内部実装がropeになれば、freezeしてもしなくても変わらない速度が出るようになって、結局freezeする必要なんてなかったんやーで丸く収まるんじゃないの？と思いました #雑な感想 — Kazuho Oku (@kazuho) October 6, 2015とツイートしたところ、処理系の中の人から @kazuho 文字列を弄る話じゃなくて、文字列の identity の話なので、ちょっと関係ないかなぁ、と — _ko1 (@_ko1) October 6, 2015みたいなツッコミをもらって、うっすみません…ってなってRuby VMのコードを読むことになったわけです。 で、まあ、いくつか気になる点があったので手をつけてしまいました。 1. オブジェクト生成のホットパスの最適化 ホットスポットだとされていたところのコードを読んでると、オブジェクト生成の際に
Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
H2O version 1.5.0 released
Today, I am happy to announce the release of H2O version 1.5.0. Notable improvements from 1.4 series are as follows: On-the-fly gzip support This was a feature requested by many people, and I would like to thank Justin Zhu for doing the hard work! mruby-based scripting Server-side scripting using mruby is now considered production level. And now that the our API is base on Rack, it would be easy f
Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話
機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています（参照: Privilege Separated OpenSSH）。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
C言語で「1時間以内に解けなければプログラマ失格となってしまう5つの問題が話題に」の5問目を解いてみた
「Java8で「ソフトウェアエンジニアならば1時間以内に解けなければいけない5つの問題」の5問目を解いてみた」と「Perl6で「ソフトウェアエンジニアならば1時間以内に解けなければいけない5つの問題」の5問目を解いてみた」経由。 以下のような問題ですね。 1,2,…,9の数をこの順序で、”+”、”-“、またはななにもせず結果が100となるあらゆる組合せを出力するプログラムを記述せよ。例えば、1 + 2 + 34 – 5 + 67 – 8 + 9 = 100となる とてもいい問題だと思うし、一方で上の回答例がeval的な手法を使っていたので、そういうズルをせずに解いたらどうなるだろう、ということでCで書いてみた。 正解が出るようになるまでの所要時間、約30分。なんとかプログラマ合格のようです。 #include <stdio.h> #define MAX_POS 9 #define EXPE
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
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
64bit時代のバッファ処理
プログラミングの「常識」は時代とともに変化します。そのひとつが、サーバプログラムにおけるバッファ処理です。 1990年代後半から2010年頃までは、メモリ空間の大きさ（32bitすなわち4GB注1）を超える大きさのファイルを扱う時代でした。このため、httpdなどのサーバプログラムにおいても、入出力データをいったんテンポラリファイルとしてバッファリングする必要がありました。ですが、ファイルI/Oはメモリアクセスと比べると低速です。このため、小さなサイズのデータについてはメモリアクセスする一方で、大きなサイズのデータについてはファイルI/Oを用いる、という煩雑なコードを書く必要がありました。 しかし、2014年も暮れとなる今 、サーバサイドにおいては64bit環境のみを考えれば良い時代に入りつつあります。 もちろん、64bit環境といったところで、64bit空間の全てをユーザプロセスが使える
[メモ] 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
自社サーバと交信するスマホアプリにおけるサーバ証明書の発行手法について（SSL Pinningと独自CA再考）
■背景 自社のサーバと通信する自社アプリについて、本来不要であるにも関わらず他社であるCAに認証情報の管理を委託することが多いわけですが、CAが証明書を誤発行した結果情報漏洩が発生したとして、その責任は自社にはないと主張できるのか、もう一度考えなおしたほうがいいんじゃないかと思うんです — Kazuho Oku (@kazuho) July 15, 2014 .@ockeghem @smbd @ando_Tw スマホアプリの提供においてはコードの署名鍵を安全に管理することが求められますが、その前提において通信相手の認証管理をCAに委託することにどれほどの意味があるんでしょう — Kazuho Oku (@kazuho) July 14, 2014 ■他社CAは信頼できるのか 特定のCAにpinningするのはしないより安全だけど、そもそも誤発行しないCAなんてあるのかという議論は重要。見知
Unix系OSの権限分離の変遷について（もしくはなぜ、アプリ単位の権限分離が求められるようになったか）
Unix系OSの権限分離の変遷について（もしくはなぜ、アプリ単位の権限分離が求められるようになったか） [ブコメした件について。大筋でおかしなことは書いてないと思いますが、出典は確認していません] Unix系OSにおける権限分離は、伝統的に、利用者ごとに異なるuser idを割り振り、これを用いてアクセス制御を行うという方式で実現されてきた。また、デーモンプロセスについては、不要な権限付与を避け、デーモンプロセス間の相互作用を抑制するために、デーモンごとに専用の「user id」を発番するのが一般的な慣習とされるようになったという経緯がある。 しかし、2000年代に入ると、インターネットの普及とあいまって、クライアントサイドではこのような「利用者ごと」の権限分離では不十分という考え方がされるようになってきた。具体的には、 （オンラインバンクのパスワードに代表されるような）攻撃価値が高い情報
[メモ] Perlのクロージャ生成速度は遅くない件
いくつかのスクリプト言語の処理系では、オブジェクトを生成して利用する場合と比較して、クロージャを生成する場合のオーバーヘッドが大きいという問題が知られています。最近、Perlでクロージャを使いたい場面に遭遇したので、ベンチマークをとってみることにしました。 結果、以下のように両者を使うアプローチで大きな速度差はないということがわかったのでメモ。 $ perl closure-vs-method.pl Rate method closure method 535/s -- -12% closure 609/s 14% -- $ cat closure-vs-method.pl use strict; use warnings; use Benchmark qw(cmpthese); my $COUNT = 1000; sub doit_closed { my $cb = shift; $cb
[メモ] Apache+mod_sslでSIGBUSが発生した件
@hirose31さんと、Apache HTTPDからHTTPSでファイルダウンロード中にサーバプロセスがSIGBUSで死ぬって件にぶちあたり、 「OpenSSLの中でmemcpyがSIGBUSしてます」「な、なんだってー！」 って調べたのですが、理由は以下のとおりだった。 HTTPSの場合、デフォルト設定だとファイル読込にmmap(2)が使われる mmapされたファイルのサイズが変更されてもApacheはそれを検知しようがない そして、ファイル末尾以降のデータを読もうとするとセグメンテーションエラー(SIGBUS)が発生し、Apacheのサーバプロセスは異常終了する HTTPの場合は、ローカルファイルシステムの場合sendfile(2)が使われるので、ファイルサイズが変更になってもApacheは異常終了しない ただし、mod_deflateのような出力フィルタを使っている場合は、HTTP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2で 速くなるとき ならないとき