tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど1年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
1. はじめに、 本日早朝、Android の Chrome のベータ版がアップデートし、バージョン26になりました。 それに伴い、Googleより Chrome の SPDY Proxyの機能と、Googleが提供する Page Speed サービスを組み合わせたData Compression Proxy という実験サービスのアナウンスがあり、早速使っていろいろ調べてみました。 2. Data Compression Proxyとは何? このData Compression Proxyはどういうものでしょうか? Googleの案内ページに記載されている下記の図が一番わかりやすいです Andoroid端末からData Compression Proxyを有効化したChrome(ベータ版)を使ってWebページにアクセスをすると、 HTTPSは、これまで通りAndroid端末から直接サーバへ
CRLSetではZIP復元処理が2回あるのでCRLのASN.1の 処理コストと比較して5分5分といったところだろうか。 ちなみに、現在プッシュしているCRLSetはたった35のルートCA,中間CAしかサポートしていない。 ImperialVioletのブログの主張のおかしな点 「オンライン失効検証ができない場合様々な問題が起きる」として幾つか問題点を述べている。 「"captive portal"(ホテルのインターネットなどでウェブブラウザで認証してから ネットが使えるようになる仕組みの事)などでは接続前はオンラインの失効検証が できない」としているが、その時点ではホテルのサービスの認証のページしか繋がる 必要が無いのであまり大きなリスクとも思えない。特定の問題なので 別に解決策もあると思う。 「認証局のCRLを提供するリポジトリやOCSPレスポンダがダウンした場合、 そこが単一障害点にな
Google Chrome runs web pages and applications with lightning speed. Googleは5月18日(米国時間)、SSL False StartのテクニックをChromeに適用することでSSL接続時における処理時間を30%削減できたと発表した。「SSL False Start」と呼ばれているテクニックはTransport Layer Security (TLS) False Startとして提案されている手法のこと。SSLハンドシェイクにおいて1回分のラウンドトリップを削減する方法で、クライアントサイドの変更で済むという特徴がある。サーバサイドは変更する必要がない。 GoogleはすでにChrome 9に「SSL False Start」の実装を追加していた。この実装によってSSL接続時における時間短縮が実現されたという。報告によ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く