セキュキャン 2015 高レイヤートラック(Jxck) 本資料は、セキュキャン 2015 高レイヤートラックの講義資料です。 セキュキャン参加者であるセキュリティエンジニアの卵を対象に、 Web のセキュリティの知見が、実際どのように Web アプリ開発に反映されているか、もしくはどう反映すべきかを、フレームワークの視点から解説することを目的としています。 将来、 Web のセキュリティに興味を持ったエンジニアが、その知見を多くの開発者に啓蒙する手段として、フレームワークに反映するというのは非常に有効な方法です。 ここではその実例として Rails を例にとり、 Rails がこれまでに積み上げてきたセキュリティに関する知見を振り返るとともに、フレームワークとしてそれをどう取り入れているかを解説します。 Intro Web アプリケーションを開発する場合、 Web アプリケーションフレーム

pre-browsing シリーズの最後。 後ろに隠しタブを実際に立ち上げて、 pre-fetch した結果をレンダリングするイメージ 。 実際に location が変わった場合は、その結果を前に持ってくるだけなので、最速で遷移することができる。 API page visibility の考慮 ただし、この場合はブラウザ上で実際に CSS の適用や JS の実行なども含めて動くので 注意が必要。 例えば、ユーザが見ていないのに video の再生が始まったり(音は出るんだろうか？)、 実際にはアクセスしていないのに Analytics に情報を飛ばしたりしてしまう可能性があ るので、それがまずい場合は、 page visibility API などを用いて場合分けする必要が ある。 range をつける prefetch もそうだけど、例えば prefetch をしている最中にその画面に

Prebrowsing シリーズ 次に表示するリソースが、高い確度でわかっている場合は、 prefetch という手段がある。 しかし、 prefetch の並列度(ff は一度に一つ、 chrome は 10 並列)や、走るタイミング(firefox は onload 後、chrome/opera は現在のページを取得中でも TCP を奪ってまでやる。)など仕様が若干曖昧なところがある。 API キャンセル時 prefetch 中に画面遷移すると、 prefetch はキャンセルされる。すると遷移(遷移のために)にもう一度やらないといけない。 この無駄を減らすには、 "Accept-Ranges: bytes" ヘッダが考えられる。 ブラウザが途中からの取得を可能にする。 steve 御大いわく It's best to prefetch the most important resou

preconnect prebrowsing シリーズ、今回は preconnect. TFO でも少し触れたが、これは dns-prefetch と似た感じで、 実際の TCP コネクションを先に貼っておくというもの。 HTTP に必要な DNS + 3WH HTTPS に必要な DNS + 3WH + TLS 実装されてれば、これらを丸っと削減できる。これは結構でかい。 使いどころとしては、まだ実際の URL まではわからないが、ドメインレベルではわかっている場合に、先に繋いでおくのに利用できる。 もし接続するホストだけでなく URL までわかっているなら、 prefetch や prerender などを使うことができる。 API API は resouce-hints に定義されている。 Link タグか、 Link ヘッダに書く。 <link rel="preconnect" h

HTTP のリクエストも実際は、サーバとの TCP 接続の確立が必要になる。 そのためには、ホストを DNS で名前解決しないといけない。 この DNS もチューニングが進んでいくと気になる存在になる。 特にクライアントが DNS を設定している場合は、それ自体を速くするみたいなことはしにくい。みんなが 8.8.8.8 にしているとも限らないし、Web アプリというレイヤで見ると手を入れにくい部分だった。 最近のブラウザは、例えばページにリンクが埋め込まれていれば、そのリンクのドメインを先に解決しておいてくれる。つまり、リンクをクリックした時点では、すでに名前解決が行われている状態にできる訳だ。 ドメインの解決は、パケットが飛ぶ訳だけどそのペイロードは Web の中で言えば結構小さい部類だし、結果は TTL の間はキャッシュされるのですぐ次のページで使われなかったとしても、そこまでデメリッ

指標の一つ、 SpeedIndex について。 ドキュメントとしてはここに書かれてる。というのもあって、出典は Google と認識している。 要するに こういう違いを こうやって数値化する 式はこう。 つまり、小さければ小さいほどよいことがわかる。 (最初の 1ms で 100% になれば、スコアは 0) 画像はっただけだが、説明いらなくて困る。 これによって、同じ表示時間でも、体感として「表示された感」に近いものを現せていると見てもまあ良さそうだろう。 Response Time が同じでも、 SpeedIndex の値が悪ければ、せっかくのチューニングがフロントでだいなしになっている事が数値でわかる訳である。 測り方 式を見ると、 1ms ごとに完了率を出して加算 ということだが、この完了率はどうだすかという問題がある。 G 様曰く方式は二つ ビデオとってピクセル数える Paint

Web のパフォーマンスの今 自分の持っている Web のパフォーマンスに関する知識を、一旦全部吐き出してまとめたいと思っていたので、それをやってみようと思う。 予定 この辺が頭にはある。 Metrics TCP TLS Rendering Prebrowsing Async/Defer Cache Priority HTTP2 QUIC とりえず、思いついた順に書いて後で整理する。 スタンス まずは知識のダンプを目的としたい。 デモとか実際の計測細かく作ると時間がかかるので、まず書くだけ書いて、やるとしても後でやる。 あといつも、自分で書き溜めて、見直して、書き直して、、、とやっていて気がつくと飽きて出さずに終わることが結構多いので、 今回はとにかく出して、追記や修正は後からがんがん更新していく感じにしたい。 更新履歴は Qiita で勝手に残るので、そこに任せる。 書いたものリスト こ

graphite, grafana, sitespeed.io, diamond で継続 Web パフォーマンスモニタリングgraphitegrafanadiamondperformancesitespeed.io Web のパフォーマンス継続モニタリング環境 intro Web の健康状態を把握するためには、きちんとしたモニタリング環境を整える必要がある。 正しくメトリクスが測定できていないと、正しくボトルネックの把握ができないし、チューニングの副作用も正しく把握できない、アプリの変更の影響もわからないし、負荷対策もできない。 単にパフォーマンスチューニングだけのためではない。が、パフォーマンスチューニングには必須、という関係。 そして、メトリクスは一回適当に取っただけでは正確とは言えず、やっぱり定期的な取得が必要になる。 この辺のノウハウは、サーバサイドではかなり成熟している。 しかし